June 27, 2011 at 19:26The Terraria game and its “good” profile encryption system
One of these days I was sitting and preparing for the upcoming exam. But the classmate wanted me to fill him up. Knowing that I was "avid" for Minecraft-style games, he threw me the Terraria game. At first, interest in her went through the roof, but a little later, because of the “wretchedness” in my opinion of the single player game, he fell, and I decided to play multiplayer, where an interesting feature was discovered: all the things I got in the single player game were in my possession inventory even on various servers in multiplayer. This gave me the idea to collect more “cool” things in my inventory. How it was achieved - under the cut.
First, the user data file was fed to WinHex and the following result was obtained from it:
From here, no simple way to “decrypt” this file is visible.
Therefore, ProcessMonitor from SYSInternals was involved. He showed that the bcrypt.dll library was used to encrypt a user file. After reading about this library and the algorithm that it uses, it became clear that I could not decrypt the file without the key. Therefore, it was decided to disassemble the Terraria.exe file. Well, I think at least the assembler code will shed more light on this. I wanted to take IDA Pro Advanced 6.1 and use it, but they stopped me on time and poked my nose with the fact that the game itself was written in .Net, which allows me to get the program code better. All the same, CILparsing is easier than assembly code.
Therefore, looking for guidance for this action, I read this article from avaver . Fortunately, Visual Studio 2010 was installed on the computer, where the necessary ilasm.exe and ildasm.exe were installed. I am
guided by this article and driven this into the command line (opened through the Start menu item from the MS Visual Studio group):
Having received a pretty clear CIL code I found Player :: EncryptFile and Player :: DecryptFile methods. A study of them and the context of their use showed how the procedure for loading / saving user data proceeds.
Reading data at boot is performed according to the following algorithm:
The procedure for writing data is similar in the reverse order:
Looking at such an algorithm, it becomes clear that all the “goodies” are contained in the player1.plr.dat file. But, unfortunately, all actions with him occur so quickly that you do not even have time to notice him in the "Explorer". And then a function was found in the sources that deletes the given file. By commenting out this function and rebuilding the file, the goal was achieved.
By the way, to rebuild the file, the following command was entered into the console that was still running:
Well, after starting the game, the player1.plr.dat file is finally in my hands.
As expected, it has all the goodies:
Well, we got the file, and now let's try to figure it out.
I didn’t understand everything there, but here is what I understood:
Since this is a user file, it contains data about the user: first, the nickname is in length (red), then the nickname itself (in green). Next comes the “health” of the character at the time of exit from the game (pink) and generally the maximum value of health (brown).
After that there is information about the "equipment" of the character, his "accessories" and the contents of the inventory, which is described in this way:
If there are several (n) free cells in the inventory, then n * 5 zero bytes are inserted (this is the name length equal to zero + number of items, also 0 + indent 3 zero bytes).
But we need not only to “read” the file, but also to apply it for our own purposes. To do this, the procedure call was simply commented out, which decrypts the source file player1.plr and overwrites player1.plr.dat. Thus, reading always occurs from the player1.plr.dat file and it is not deleted. Therefore, we can make changes to it without worrying about the original player1.plr - it will not spoil the picture for us.
As you can see from my screenshots, I made myself “cool little things” and played with them in multiplayer. But it quickly got bored, and interest in the game completely dried up. Preparation for the exam continues!
First attempts
First, the user data file was fed to WinHex and the following result was obtained from it:
From here, no simple way to “decrypt” this file is visible.
Therefore, ProcessMonitor from SYSInternals was involved. He showed that the bcrypt.dll library was used to encrypt a user file. After reading about this library and the algorithm that it uses, it became clear that I could not decrypt the file without the key. Therefore, it was decided to disassemble the Terraria.exe file. Well, I think at least the assembler code will shed more light on this. I wanted to take IDA Pro Advanced 6.1 and use it, but they stopped me on time and poked my nose with the fact that the game itself was written in .Net, which allows me to get the program code better. All the same, CILparsing is easier than assembly code.
Therefore, looking for guidance for this action, I read this article from avaver . Fortunately, Visual Studio 2010 was installed on the computer, where the necessary ilasm.exe and ildasm.exe were installed. I am
guided by this article and driven this into the command line (opened through the Start menu item from the MS Visual Studio group):
ildasm.exe Terraria.exe /source /out:Terraria.ilHaving received a pretty clear CIL code I found Player :: EncryptFile and Player :: DecryptFile methods. A study of them and the context of their use showed how the procedure for loading / saving user data proceeds.
Reading data at boot is performed according to the following algorithm:
- First, the player1.plr file is decrypted into player1.plr.dat
- Next, data is read from player1.plr.dat and written to RAM (file size <1KB)
- After these actions, the file player1.plr.dat is deleted.
The procedure for writing data is similar in the reverse order:
- Writing data from RAM to player1.plr.dat
- Player1.plr.dat encryption in player1.plr
- Player1.plr.dat removal
Looking at such an algorithm, it becomes clear that all the “goodies” are contained in the player1.plr.dat file. But, unfortunately, all actions with him occur so quickly that you do not even have time to notice him in the "Explorer". And then a function was found in the sources that deletes the given file. By commenting out this function and rebuilding the file, the goal was achieved.
By the way, to rebuild the file, the following command was entered into the console that was still running:
ilasm.exe Terraria.il /exe /out:Terraria.exeWell, after starting the game, the player1.plr.dat file is finally in my hands.
As expected, it has all the goodies:
Personal use
Well, we got the file, and now let's try to figure it out.
I didn’t understand everything there, but here is what I understood:
Since this is a user file, it contains data about the user: first, the nickname is in length (red), then the nickname itself (in green). Next comes the “health” of the character at the time of exit from the game (pink) and generally the maximum value of health (brown).
After that there is information about the "equipment" of the character, his "accessories" and the contents of the inventory, which is described in this way:
- First, the length in bytes of the item name (in red)
- Then the name itself (in green). By the way, this name can simply be copied from the official wiki project
- After that, the number of units of this item (orange)
- And at the end, indent 3 null bytes to the next inventory item (blue)
If there are several (n) free cells in the inventory, then n * 5 zero bytes are inserted (this is the name length equal to zero + number of items, also 0 + indent 3 zero bytes).
But we need not only to “read” the file, but also to apply it for our own purposes. To do this, the procedure call was simply commented out, which decrypts the source file player1.plr and overwrites player1.plr.dat. Thus, reading always occurs from the player1.plr.dat file and it is not deleted. Therefore, we can make changes to it without worrying about the original player1.plr - it will not spoil the picture for us.
Conclusion
As you can see from my screenshots, I made myself “cool little things” and played with them in multiplayer. But it quickly got bored, and interest in the game completely dried up. Preparation for the exam continues!