Co-pilot like tool hooked-in to guess meaning of reverse engineered code would be awesome ;)
Analysis of large binaries and games in Ghidra-SRE
21–25 of 25 posts
Re: Analysis of large binaries and games in Ghidra-SRE
#22I 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 imperat…
Re: Analysis of large binaries and games in Ghidra-SRE
#23I 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 imperat…
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.
Re: Analysis of large binaries and games in Ghidra-SRE
#24Ghidra 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 :)
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 th…
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.
Re: Analysis of large binaries and games in Ghidra-SRE
#25Earlier quoted context omitted.
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 th…
> 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. T…
I have messed about with Terraria reverse engineering (pure .NET) and that was easy like you said.