3 ms·
It 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 i
by simcop2387 5y ago
It 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 agoThe sibling comment covers it a bit more in detail, but it's largely just some guessing and as much an art to figuring out what the types are or could be. This particular one looks like it's taking a function pointer in and checking if it's a valid function (not null) and then checking the first two bytes of the function. From my memory, the windows ABI uses the first two bytes of functions for installing hooks/debugging by patching the first two bytes into some kind of jump (while originally being nops). The 0x2b part I'm not sure about myself but it looks like some other kind of similar checks. And actually then thinking about the way it's calling it, i'm wondering if this is actually from some C++ standard library code for doing stuff with a vtable, looking up the vtable entry and checking it's validity before calling it (in this case, location 0x18, and checking some kind of RTTI at 0x28 and 0x2b) and storing that it's been initialized in 0x21. So I think this might be part of an initialization function for some property on top of a object that exists at *param_1. and the decompiler has misinterpreted it as a longlong because of the access patterns (64bit pointers).
- ndiddy 5y agoIn the case of Pinball, Microsoft released the debug symbols for the game because it was a part of Windows (meaning that there wasn't a need to figure out the function/variable/type information).