5 ms·
Could anyone speak more about how this decompilation is done from a technical perspective? This looks nothing like the pseudocode C that IDA/Ghidra spit out, s
by gavinray 5y ago
Could anyone speak more about how this decompilation is done from a technical perspective?
This looks nothing like the pseudocode C that IDA/Ghidra spit out, so how would you go about doing this even?
It says in the README:
Tools used: Ghidra, Ida, Visual Studio
What was done:
All structures were populated, globals and locals named.
All subs were decompiled, C pseudo code was converted to compilable C++. Loose (namespace?) subs were assigned to classes.
Which is a bit "Draw-the-rest-of-the-fucking-owl" for me. Or am I just clueless.
- bri3d 5y agoI'm not aware of any good general-case automation for this. When I've done this in the past, it basically consists of: 1) Decompile project using Ghidra/IDA, first pass. 2) Load symbols if present (sounds like there was a PDB for this one, which makes things a lot easier). 3) Read decompilation/asm for unnamed subs and try to name them based on what they do. 4) Export all decompiled source into an editor and start copy/paste/editing into readable source. Highly manual process, for some files it's just pattern matching / renaming and goes really quickly, for others it's full reimplementation and a bit harder. And, if you look at most "decompiled game" projects, I think this is the industry standard way to do this. For example, OpenRCT2 started as a repository full of manually created source with Hex-Rays names and slowly evolved module-by-module into readable source code. (disclosure: per the child post, my original assumption that OpenRCT2 was copied out of Hex-Rays was inaccurate, since it was originally written in assembler it didn't follow a standard C ABI and the decompiler wouldn't work properly anyway).
- gavinray 5y ago> sounds like there was a PDB for this one, which makes things a lot easier Ah yeah that certainly reduces the difficulty by an order of magnitude. Do you know of anyone who has done this with high-skill as a recorded video tutorial? Seems like one of those things much easier to follow in video than text due to how complicated IDA/Ghidra are as tools.
- bri3d 5y agoCheck out `wrongbaud` tutorials: https://hackaday.io/course/172292-introduction-to-reverse-engineering-with-ghidra https://hackaday.io/course/172292-introduction-to-reverse-en... . wrongbaud's are the best trainings I've seen for Ghidra so far. I actually haven't watched this particular course (I confused it with some other ones) - but given what I've seen, I'm sure it's good.
- gavinray 5y agoThanks a ton for the point in the right direction!
- duncanspumpkin 5y agoFor OpenRCT2 thats not quite how we did it. We didn't use IDA decomp output as its useless with Chris Sawyer calling conventions you had to just read the assembly. We did name things as per IDA when things were completely unknown hence why there was lots of sub_XXXX functions and byte_XXXX. I personally just used OllyDbg and read the assembly and wrote equivalent C code. I've a few videos of implementing functions for OpenRCT2 and OpenLoco if you are interested.
- bri3d 5y agoI stand corrected - I'll check them out! It makes sense that the Sawyer calling conventions wouldn't decompile correctly, since he was just making the ABI up as he programmed.
- simcop2387 5y agoIt is definitely skipping over a lot of the details. Essentially the code put out by those tools is going to be almost the right code. The thing you do then is go through each function it produces and fix up the names and maybe re-organize it to be more readable. Then you try to compile it and find and fix the errors. It's going to be entirely project and file specific as to what you'll need to do but usually you'll need to rewrite the conditionals in if statements to be more understandable since the optimization passes that the original compiler did will have likely scrambled the logical version of things before (to reduce the number of things that need to be done, or reordered them to take better advantage of the way the processor pipelines things).
- gavinray 5y ago> " The thing you do then is go through each function it produces and fix up the names and maybe re-organize it to be more readable." How do you do this, when most of the code is like (real fn decompilation from random binary opened with Ghidra v10.0.4 for example's sake just now): undefined8 FUN_14004dd60(longlong *param_1) { if ((((*param_1 != 0) && (param_1[1] != 0)) && (param_1[2] != 0)) && ((param_1[0x2b] != 0 && (*(longlong *)(param_1[0x2b] + 0x28) != 0)))) { if (*(char *)((longlong)param_1 + 0x21) != '\0') { return 0; } (**(code **)(param_1[1] + 0x18))(); *(undefined *)((longlong)param_1 + 0x21) = 1; return 1; } return 0; } This program is 14MB, and Ghidra says: # of Functions: 12661 # of Symbols: 118504 # of Data Types: 6513 It just seems unapproachably daunting. (Serious question, not being passive-aggressive. I find this stuff interesting and wish I understood it more.)
- an-unknown 5y agoWhat's missing here is type information. This is the reason why the decompiled code is quite unreadable. How to solve this: try to figure out what these missing types (like structs, arrays, ...) are, by looking at how the code uses the variables. Then you define these types in IDA/Ghidra/..., and this will already give you decompiled code that's much easier to read.
- simcop2387 5y ago