[HN Gopher] Spice86 - A PC emulator for real mode reverse engine...
___________________________________________________________________
Spice86 - A PC emulator for real mode reverse engineering
Author : alberto-m
Score : 124 points
Date : 2025-02-20 15:47 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| johnklos wrote:
| Forty years ago I had a Sinclair QL with an 8086 emulator.
| Because the Sinclair QL had preemptive multitasking, I could
| easily search memory for patterns, monitor locations, stop and
| start the emulation, or change memory programmatically and easily
| from the QDOS side. It was worlds easier than using a debugger,
| particularly since I didn't own an 8086 system.
|
| I always thought it was a clever way to get insights in to
| software while it was running that wasn't available to people
| with 8086 systems, and it's interesting to see this idea so many
| years later.
| mananaysiempre wrote:
| Bochs and MAME both have superb and widely-used debuggers,
| while Qemu is more limited but still has some debugging
| capabilities in its monitor, as well as a gdb integration.
| (Can't say anything about PCem/86Box.) It seems that developers
| of emulators targeting good coverage of old stuff simply can't
| _not_ build a debugger, because it's an integral part of their
| task to figure out what the hell the devs of the latest failing
| thing did to make it fail. Bochs is (was?) also quite popular
| in the OSDev scene as a debugging tool.
| rzzzt wrote:
| DOSBox can be configured to include a debugger. The feature
| is not enabled in the official binary but the enhanced
| derivative projects probably have it (DOSBox-X definitely
| does):
|
| - https://www.vogons.org/viewtopic.php?t=3944
|
| - https://github.com/joncampbell123/dosbox-x/wiki/DOSBox%E2%8
| 0...
| DrNosferatu wrote:
| A tutorial on how to reverse engineer a simple DOS game would be
| absolutely awesome!
| alberto-m wrote:
| From my brief experience, it seems that reversing old games is
| one of those disciplines where there is no good step-by-step
| course. One can start learning some theory (I did so by reading
| "The Art of Assembly Language Programming" - if I had more
| time, I'd try "Reverse Engineering for Beginners") but then one
| has to get his hands dirty. Real-life games are typically not
| simple, but one usually just needs to reverse some small parts
| to produce new interesting modifications.
|
| But surely reading tutorials is useful to learn techniques and
| tricks. I recommend this article to start:
| https://www.lodsb.com/reversing-lz91-from-commander-keen (not
| totally for beginners, but very friendly, and it can help to
| get used with the jargon). I am also publishing war stories on
| this topic on my blog (marnetto.net).
| pjturpeau wrote:
| https://cosmodoc.org/
| stevekemp wrote:
| Tutorials are hard, but there are some great writeups like this
| which discuss some of the specific problems and trial/error
| involved
|
| https://neuviemeporte.github.io/category/f15-se2
|
| In this case one hard part was trying to get code to compile to
| identical byte for byte output. Which meant working out which
| compiler options were used, and which specific compiler too.
| That gives you a hint of what kinda things are involved.
| bernadus_edwin wrote:
| Why are so many emulators written in C#?
| sixothree wrote:
| My guess is portability, then obviously performance.
|
| edit: actually there is a specific answer for this particular
| project - "We had to rewrite the project in C# to add automated
| code generation (java doesn't have the goto keyword, making
| automated ASM translation challenging)". There you are.
| throw-qqqqq wrote:
| I don't think the language is necessarily chosen for the
| project. I think C# is just a main stream language that a lot
| of people know.
| gexos wrote:
| Reverse engineering old games is like digital archaeology--except
| instead of digging up fossils, you're unearthing spaghetti code
| and DRM nightmares. Spice86 seems like an exciting new shovel for
| the job!
| eminence32 wrote:
| 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?
| rzzzt wrote:
| 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.
| dmitrygr wrote:
| 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
| jcranmer wrote:
| > 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.
| dmitrygr wrote:
| 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
| sigmaprimus wrote:
| 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 :)
| ggambetta wrote:
| Oooh, I LOVE this! Especially the ability to "Overriding emulated
| code with C# code" I had a similar idea years ago
| (https://gabrielgambetta.com/remakes.html), not in the context of
| a debugger or reverse engineering per se, but in the context of
| remakes and "special edition" games. Not entirely surprised that
| this is a byproduct of OpenRakis. Amazing work!
| vunderba wrote:
| I tried doing something like this about 15 years ago but
| specifically for audio by routing NES NSF rom audio data
| (square, triangle, PWM, etc) to virtual midi cables attached to
| VSTs so you could play any old school Nintendo game with modern
| instrumentation. Was a pretty fun project.
|
| The closest thing I can think of for graphical rehauls is
| probably shader pack type stuff - Minecraft is a great example
| of this.
|
| https://www.sonicether.com/seus
___________________________________________________________________
(page generated 2025-02-20 23:00 UTC)