3 ms·

Ghidra is really neat, so a couple times I've tried to do reversing of small games through it to practice. Turns out stuff is really hard, despite Ghidra doing

by rtpg 5y ago

Ghidra is really neat, so a couple times I've tried to do reversing of small games through it to practice. Turns out stuff is really hard, despite Ghidra doing a bunch of work to try and get things to be super easy. Even for really small old indie windows games I think you really have to have a good idea of what kind of tools the people are using to get places. That or get really lucky in a string search :)

ChuckNorris89 5y ago
It's more like you need to have cut your teeth before on SW development and RE since you need a good gut feeling of what bundle of assembly lines/C code correspond to what kind of functionality the developer had in mind. Trying to RE production SW without any prior development experience is brutally hard.
- bluedino 5y ago
  >> you need to have cut your teeth before on SW development I remember this back when people wanted to learn cracks/keygens: If it was anything more than replacing a value with a hex editor, it was too complicated.
- sumtechguy 5y ago
  Even then I would add. Lets say you have the code to something. Just figuring out what goes where and what does what takes time. Then each dev/compiler has its own 'style'. It is a process that takes time. Sometimes you can get lucky and pull on a thread and the whole sweater comes apart. But finding that one thread to tug on... Then on top of that if they turned on optimizations the code may look 'odd' as it has been optimized and that part of many compilers can do some very strange things. I am trying to RE a 16bit windows game. Ghidra gets lost a lot on the exe to system dll paths for me. For 32bit it seems fine though.
doix 5y ago
For games, I find that it is much easier to dynamically anaylze them while they are running to get an idea where you should be looking. Use something like cheat engine to get the address of health and use the built in debugger to find what writes to that health address. Then you can get the address for the instructions that write to the health and go back to something like Ghidra and start reverse engineering from there. But for small indie games, the dissasmbler in Cheat Engine is actually quite good depending on what you are trying to do. An understanding of how C/C++ memory mangement works and how things like arrays/pointers etc normally get compiled down by the compiler. Having a general idea of how indie games a typically made (a loop which reads input -> updates game state -> draws to the screne) helps as well. In the case of finding what writes to the HP, you'll end up in a function that most likely updates game state, so you can then just walk up the functions to get to the main loop. I spent a lot of my youth reverse engineering a small indie game. It go to the point where as a community we reverse engineered most of the in game objects into C header files. Then with the help of those header files, we made custom AI possible. Used a DLL to detour the normal AI function to our function and in that function we loaded Angelscript files that had access to the original game objects so they could control the objects. Ghidra didn't exist back then, and IDA was too expensive and the Cheat Engine dissambler was bad, so we reverse engineered everything in Ollydbg. This was of course for a tiny indie game with a custom engine. I imagine now days with everything being made in Unity/Unreal etc, it's much harder to reverse engineer. Also x86 calling conventions were nicer than x64 imo ;).
- Faark 5y ago
  > I imagine now days with everything being made in Unity/Unreal etc, it's much harder to reverse engineer. Unity games are actually incredibly pleasant to reverse engineer most of the time, since they are built on .NET/Mono. Unless they are intentionally obfuscated (don't think I had that more than once) you can pretty much just drag and drop the Data\Managed\Assembly-CSharp.dll into your .NET decompiler of choice. The byte code is pretty close to source, with pretty much the entire class structures still there. Only the inside of functions has to be restored, thus the AST might be slightly different and variable names gone. Even more comfortable are pure .NET games... simply attached the full IDE to debug. Rider even takes care of the decompilation on the fly.
  - doix 5y ago
    Interesting, I was unaware that Unity was all .NET, thanks for the info! I have messed about with Terraria reverse engineering (pure .NET) and that was easy like you said.

by rtpg 5y ago

ChuckNorris89 5y ago

It's more like you need to have cut your teeth before on SW development and RE since you need a good gut feeling of what bundle of assembly lines/C code correspond to what kind of functionality the developer had in mind. Trying to RE production SW without any prior development experience is brutally hard.

bluedino 5y ago
>> you need to have cut your teeth before on SW development I remember this back when people wanted to learn cracks/keygens: If it was anything more than replacing a value with a hex editor, it was too complicated.
sumtechguy 5y ago
Even then I would add. Lets say you have the code to something. Just figuring out what goes where and what does what takes time. Then each dev/compiler has its own 'style'. It is a process that takes time. Sometimes you can get lucky and pull on a thread and the whole sweater comes apart. But finding that one thread to tug on... Then on top of that if they turned on optimizations the code may look 'odd' as it has been optimized and that part of many compilers can do some very strange things. I am trying to RE a 16bit windows game. Ghidra gets lost a lot on the exe to system dll paths for me. For 32bit it seems fine though.

doix 5y ago

For games, I find that it is much easier to dynamically anaylze them while they are running to get an idea where you should be looking. Use something like cheat engine to get the address of health and use the built in debugger to find what writes to that health address. Then you can get the address for the instructions that write to the health and go back to something like Ghidra and start reverse engineering from there. But for small indie games, the dissasmbler in Cheat Engine is actually quite good depending on what you are trying to do. An understanding of how C/C++ memory mangement works and how things like arrays/pointers etc normally get compiled down by the compiler. Having a general idea of how indie games a typically made (a loop which reads input -> updates game state -> draws to the screne) helps as well. In the case of finding what writes to the HP, you'll end up in a function that most likely updates game state, so you can then just walk up the functions to get to the main loop. I spent a lot of my youth reverse engineering a small indie game. It go to the point where as a community we reverse engineered most of the in game objects into C header files. Then with the help of those header files, we made custom AI possible. Used a DLL to detour the normal AI function to our function and in that function we loaded Angelscript files that had access to the original game objects so they could control the objects. Ghidra didn't exist back then, and IDA was too expensive and the Cheat Engine dissambler was bad, so we reverse engineered everything in Ollydbg. This was of course for a tiny indie game with a custom engine. I imagine now days with everything being made in Unity/Unreal etc, it's much harder to reverse engineer. Also x86 calling conventions were nicer than x64 imo ;).

Faark 5y ago
> I imagine now days with everything being made in Unity/Unreal etc, it's much harder to reverse engineer. Unity games are actually incredibly pleasant to reverse engineer most of the time, since they are built on .NET/Mono. Unless they are intentionally obfuscated (don't think I had that more than once) you can pretty much just drag and drop the Data\Managed\Assembly-CSharp.dll into your .NET decompiler of choice. The byte code is pretty close to source, with pretty much the entire class structures still there. Only the inside of functions has to be restored, thus the AST might be slightly different and variable names gone. Even more comfortable are pure .NET games... simply attached the full IDE to debug. Rider even takes care of the decompilation on the fly.
- doix 5y ago
  Interesting, I was unaware that Unity was all .NET, thanks for the info! I have messed about with Terraria reverse engineering (pure .NET) and that was easy like you said.