Comment by eminence32
2 days ago
Question from a reverse-engineering noob:
Why can't ghidra (or any other reverse engineering tool) be used directly on the .exe? Why do you have to go through this emulator? Is it because the thing you want to debug only runs in x86 realmode?
You can, it's just harder, sometimes.
Very roughly spoken, the older the platform, the "weirder" stuff that happens at runtime gets in order to make the best of the measly hardware.
I'm looking at a many decades old C64 game right now, and the way I'm doing it is by having taken a memory snapshot when the game was in the state that I'm most interested in at first.
Starting with just the "binary" on disk would be much harder, since there's so much code that just loads, decompresses, initializes overlays etc. which isn't particularly interesting from an actual game logic point of view (though may be very interesting for other reasons), and only exists because the whole game just doesn't fit into all of memory.
There's also a bunch of loading and overlay magic at runtime of the game, but by looking at a snapshot of the game in the state that interests me, I don't have to dive into that (yet).
Obfuscation and compression are two potential extra hoops to jump through. It's easier to let the executable run for a bit and start from there.
there are so many reasons for that
-there is sometimes not a single statical exe (that means all code inside) but overlays(DOS like DLLs) or serveral other ways of loading code at runtime (example for sound/gfx-drivers) - DOS allows technicaly nearly everything so everything is done in games :)
-many game loaders combine code/data parts of a game in memory - for keeping floppy releases smaller
-self modifying code, also hard to disassemble statically with Gidrah/IDA
-good old segment/offset 16bit realmode games - a complete different beast compare to 32bit linear DOS games (Ghidra isn't very good at this, IDA is much much better)
some examples:
the Stunts loader combines several (in itself non valid) files in memory to create a exe (the single files are packed and the result in exe in memory is also packed) - not that easy to static disassemble something like that
Alpha Waves also got an loader and self modifying code that is not easy to reverse statical
its good to have the best disassemblers available and the best (or better dedicated) debuggers around to keep your reversing project shorter then decades :)
I believe part of the problem is the fact that Aa.exe fil B is created BY packaging multiple library files And or graphics , arrays ETC. and there is no default order into which part of the EXE file they land. there are some Tools ... hex editors come to mind. I seem to recall NOPING out A jump or two in my younger days edit: the these days that probably wouldn't work due to CRC checks... but there was a time... Then again that may be just the perfect place to start riverus engineering;) smile I have some good memories of playing a Medal of honor in which I changed all the door Textures to transparent window textures and having to work around CRC protection... good times smiley :)
Approximately how long does it take to collide a CRC naively? I'm guessing there's a trick that makes it faster, these days?
It takes my computer on a single core about 7 minutes to find a nonce for an arbitrary files sha256 to prefix the left side with 4 or 5 zeros (like bitcoin difficulty doubling). Obviously the heat death of the universe would occur trying to collide sha256 on a single core, but CRC - Gemini says it depends on the algorithm, but crc 32 should take about an hour to collide, but it didn't specify "any" or "arbitrary" collisions, but mentioned "any" right before that. So if the most probable sentence after "any collision" is a time estimate, with the logic of LLM implies that's the easier case of any collision.
I'm surprised brute force is even needed. As far as I know, CRC has absolutely no intent to be a cryptographically secure one-way function. It is purely used against unintentional corruption of data. With that in light, does it really take an hour to find a collision? Can't you construct one much quicker?
1 reply →
Once saw a writeup where someone figured out how to reverse the crc32 calculation… Absolutely no brute forcing needed!
Oddly, this kind of topic doesn’t get a lot of attention
x86 segmentation makes it very hard to statically analyze anything. In real mode, any byte can be referenced in 4096 different ways. It is even messier in protected mode, since now every selector is an entry in a table, so its value itself is meaningless. So, without runtime analysis, there is no way to tell if 04:1234 is or is not the same byte as fa:1204
> It is even messier in protected mode, since now every selector is an entry in a table, so its value itself is meaningless.
Actually, my experience is that things are much easier in protected mode. Since selector values are chosen by the OS, that means you rely a lot more on internal relocations. And the use of segment selectors is a strong indicator that you have a pointer in the first place.
Unfortunately, ghidra itself struggles to apply these techniques, especially in the decompiler, which seems completely unable to cope with the concept of far pointers.
In DOS, plenty of applications/games load selectors and do nasty things with them
so indeed you'd know it is a far pointer, but may not know what to :D
1 reply →