Analysis of large binaries and games in Ghidra-SRE(kiwidog.me)
kiwidog.me
Analysis of large binaries and games in Ghidra-SRE
https://kiwidog.me/2021/07/analysis-of-large-binaries-and-games-in-ghidra-sre/
8 comments
I've also found Ghidra nearly useless for most things. IDA seems to blow it out of the water.
I've also had significantly more success with OOAnalyzer but as you say, it's dog slow and just consumes an unfathomable amount of memory. I had a few binaries it just completely choked on regardless of part size.
Finally, while Ghidra is pretty cool in theory, in practice it's quite brittle and rough at the edges. I've had projects get corrupted, analysis that always hang indefinitely with no diagnostic information why. And it performs about the same on a 4-core host as a 64-core host, which deeply saddens me, as almost nothing is multithreaded.
I've also had significantly more success with OOAnalyzer but as you say, it's dog slow and just consumes an unfathomable amount of memory. I had a few binaries it just completely choked on regardless of part size.
Finally, while Ghidra is pretty cool in theory, in practice it's quite brittle and rough at the edges. I've had projects get corrupted, analysis that always hang indefinitely with no diagnostic information why. And it performs about the same on a 4-core host as a 64-core host, which deeply saddens me, as almost nothing is multithreaded.
That’s another reason I looked into scripting: fear of losing many hours of work through corruption. My last workflow meant writing scripts to define everything so I _always_ started from a blank slate. Naturally this rots over time as the API changes, but I feel much more confident I won’t lose work completely. Not a glowing review of Ghidra though :)
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 :)
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 :)
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 ;).
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 ;).
> 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.
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.
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.
I have messed about with Terraria reverse engineering (pure .NET) and that was easy like you said.
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.
Trying to RE production SW without any prior development experience is brutally hard.
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.
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.
>> 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.
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.
I started reverse engineering a game about 3 months ago with no prior experience. It is insanely difficult. I like to think that I have very good pattern recognition and investigative skills, I find most problems surmountable given enough time. But I'm barely making any progress and am tearing my hair out just to find tiny breadcrumbs of clues. Maybe this is one of those things where picking up a few books is imperative.
In software development, we share massive amounts of information, and there's always a premade tool out there that does what you need and will work the first time. This isn't my experience in the reverse engineering world. Information is sparse, seems to be kept private, and there's not always a tool that does what you want. Even if there is, good luck getting it to work.
In software development, we share massive amounts of information, and there's always a premade tool out there that does what you need and will work the first time. This isn't my experience in the reverse engineering world. Information is sparse, seems to be kept private, and there's not always a tool that does what you want. Even if there is, good luck getting it to work.
It depends on the game you are trying to work on.
If the game has protections, then it does not make sense to make that your first game to analyze.
It doesn't, just a little obfuscation in certain functions. Some parts of that I already know how they work from other people/prior work. I don't think there is a better candidate actually, besides a tiny DOS-like game written in C, but the game I'm looking at is something I'm actually interested in.
There are ton of docs on the subject of rce. What about tuts4you or Woodmann board?
The best way to do this is to code yourself some game, view it's assembler in your preferred IDE while doing step-by-step/trace into to familiarize how its instructions are executed at CPU level. Then do the same in Ghidra. After a while, all of this during the process of coding the game to completion, you'll be able to pickup fairly easily different patterns in assembler which will make you more productive at reverse engineering.
I did this with a Tetris clone, then a Minesweeper clone and then I did a multi-threaded "Shoot the ducks" clone, each duck being a thread. Probably will take you several months but at the end you'll really be able to do a lot of RE.
I did this with a Tetris clone, then a Minesweeper clone and then I did a multi-threaded "Shoot the ducks" clone, each duck being a thread. Probably will take you several months but at the end you'll really be able to do a lot of RE.
I wanted to do the same a few years ago. I didn't even reach that point, as I was interested in doing 90s games. Pretty much every game I tried was compiled with watcom, which ghidra doesn't know, so cannot apply any tricks when analyzing. Watcom even has its own calling convention which ghidra doesn't understand, so the pseudo C code for most functions was almost useless. Already gave up at that point.
Could anyone recommend some quality resources on RE?
I've always wanted to learn how they encrypted Valkyrie Profile 2 for the Ps2. I could never reverse it to get the audio of the English voice actors.
And there is a dub patch to apply the Japanese audio to it too, or was.
Now to find a copy...
And there is a dub patch to apply the Japanese audio to it too, or was.
Now to find a copy...
[deleted]
[1] https://github.com/cmu-sei/pharos/blob/master/tools/ooanalyz... [2] https://github.com/cmu-sei/pharos/blob/master/share/prolog/o...