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). 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. The 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. (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). 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.
#IN 3D PINBALL MANUAL#
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.Īnd, if you look at most "decompiled game" projects, I think this is the industry standard way to do this. When I've done this in the past, it basically consists of:ġ) Decompile project using Ghidra/IDA, first pass.Ģ) Load symbols if present (sounds like there was a PDB for this one, which makes things a lot easier).ģ) Read decompilation/asm for unnamed subs and try to name them based on what they do.Ĥ) Export all decompiled source into an editor and start copy/paste/editing into readable source. I'm not aware of any good general-case automation for this.
0 kommentar(er)
