Alice Averlong🏳️⚧️automating a DOS game that requires you to capture the mouse in DOSBox is a fucking nightmare.
You can't tell where the cursor is! you can't consistently move it, either!
and this game is 100% mouse driven. I'm not sure there even ARE any keyboard commands.
maybe I can spy into DOSBox and pull the X/Y coordinates out of the virtual mouse driver?
assuming the virtual driver even has an idea. the game might have put the mouse driver in relative mode, and is doing its own cursor movement nonsense
the worst part is that for greater reliability I'm restarting dosbox for every file.
so I can't even set up a standardized memory location to spy on, since it changes every time I reboot DOSBox
so I can't even set up a standardized memory location to spy on, since it changes every time I reboot DOSBox
someday I'm gonna need to sit down and make my Universal External Debugging Interface.
A tcp/ip protocol for doing things like reading/writing memory and saving/loading savestates and providing input (keyboards, mice, controllers)
then go around and implement it in a bunch of emulators
A tcp/ip protocol for doing things like reading/writing memory and saving/loading savestates and providing input (keyboards, mice, controllers)
then go around and implement it in a bunch of emulators
so you could control an emulator from an external python script, or whatever language you want, so long as the UEDI is implemented
okay so I was able to find x/y cursor positions in RAM pretty easily. the trick is to do that in a way that can be done automatically/reliably.
or maybe I just need to stop restarting DOSbox.
or maybe I just need to stop restarting DOSbox.
I have a devious plan
so the mouse coords seem to consistently be at 2304500 bytes into the memory region where I find them, right? but that region moves around from launch to launch.
but it's also easy to find on the memory regions list:
it's 0x1001000 bytes long, which is a bit more than 16mb.
it's 0x1001000 bytes long, which is a bit more than 16mb.
and guess what my dosbox conf says?
memsize=16 (mb)
memsize=16 (mb)
so my script could launch DOSBox, then enumerate the memory regions allocated, and find the one that's 16mb, and that's the DOS RAM!
okay I confirmed this works manually. I can find the new DOS-RAM section, add 2304500 to it, and I get the x-pos of the cursor.
now to do it automatically.
I was kinda hoping there was an API that let me point at a process and go "hey what memory regions does this have mapped?"
NOPE
I looked up how cheat engine does it.
it's pretty simple.
you start at 0, and call VirtualQueryEx at that address.
it's pretty simple.
you start at 0, and call VirtualQueryEx at that address.
then you increase your pointer by the size of the region you found there, and try again.
so you just call VirtualQuery repeatedly on a ton of memory addresses.
why not
windows is one of the most operating systems in all the world
got it. hacked a bit on this script and now I have a script that takes a PID and tells you the address of the DOS RAM in that process:
https://github.com/nccgroup/memaddressanalysis/blob/master/Windows/memanalysis.py
and I have extracted all 306 distinct backgrounds.
the only problem? I don't have their palettes yet.
or rather, I do have their palettes, but I don't know which palette goes with which background.
the only problem? I don't have their palettes yet.
or rather, I do have their palettes, but I don't know which palette goes with which background.
here they all are, converted with a standardized palette.
most look "decent", but a bunch of clearly wrong.
most look "decent", but a bunch of clearly wrong.
so the game has some kind of "database" format, and it's in the .LST and .ALL files. I spotted it in ghidra, but I haven't tried to decode it yet.
the CB and CCS databases seem to reference palettes (or at least backgrounds), so one of them must be the datafile I'm looking for.
the CB and CCS databases seem to reference palettes (or at least backgrounds), so one of them must be the datafile I'm looking for.
OH NO
I just realized my computer crashed earlier and I had ghidra open. I may have lost all my reverse engineering work ;_;
ahh, nope. it's at least partially here. cool.
they compiled it with some version of Watcom C from 1994. I should find that version and figure out how it encodes FILE* because I can't really tell what's custom code and what's statically linked stdio.h code
CCS I think is for scripts.
oh god I do not want to decode the scripting language this thing uses. it has a big interpreter here and it's huge
okay it's got a function that tries to find... three greys.
instead of putting them at standard positions in the palette, every time it loads a palette, it goes through all the palette entries and finds the color that's closest to that shade of grey.
The three shades are: black, rgb(161,161,161), and white.
huh.
instead of putting them at standard positions in the palette, every time it loads a palette, it goes through all the palette entries and finds the color that's closest to that shade of grey.
The three shades are: black, rgb(161,161,161), and white.
huh.
I found the font renderer.
I wasn't even looking for one! this isn't a death generator thing!
but you can't stop Foone from Fooning
it calls malloc for every character it draws?
huh.
correction:
twice.
twice.
uhh.
I don't see any free()
I mean it's only allocating like, 24 bytes per character?
and this game has VERY little text.
but still.
you know you've been reversing too long when you have functions named stack_fuckery, more_stack_fuckery, and StackFucker9000
I should have kept my mouth shut, as StackFucker2TheReturn and StackFucker3ThisTimeItsPersonal just showed up
and it looks like this game had a bunch of functions that only existed to do various things that have been defined out, so the machine code is full of these pointless functions that do fuck-all
StackFucker4BeyondThePortalOfTime
StackFuckerOrigins
StackFuckerForever
StackFuckerOrigins
StackFuckerForever
several of these are not even called from anywhere.
probably because they were originally only called from functions that no longer have any contents, thanks to a define.
probably because they were originally only called from functions that no longer have any contents, thanks to a define.
this code appears to be strlen but it seems to count backwards from -1 and then inverts it at the end?
the fuck?
this is weird. the "Load_Dialogues" function tries to load .ccb files.
but there are no CCB files on the retail disc. Did... did they forget to include the dialogue files? IS THIS WHY THE GAME HAS NO SUBTITLES?
huh.
so the game has no "new_game" function.
instead, if you select "new game", it loads a special savegame named "new.can"
so the game has no "new_game" function.
instead, if you select "new game", it loads a special savegame named "new.can"
Lothus Marque@foone I mean, /technically/ this is a new game. It's an odd way to go about it though! I wonder if it was a development decision to avoid having to recompile to tweak things.
Mr. Fred 🔥@foone YES WE new.can
Will Blanton@foone ooo I really like that tbh, will probably start doing this in my games :)
well now I've run into the minor problem where I can load the code in the dosbox debugger but debugging has gone non-linear, which is a problem. I hit "trace over" and it jumps to a different function completely.
I suspect this is because DOSBox is doing dynamic recompilation.
time to see if I can run this on slow-ass mode
time to see if I can run this on slow-ass mode
Yep. I've got the palette names array now. Unfortunately it's just a bunch of pointers to strings, which I'd have to dump one by one, but I'm sure I can automate that somehow.
Also a problem is that this maps background numbers to palettes.
I don't know numbers, I know filenames
I don't know numbers, I know filenames
So I'm going to have to also dump the array of pointers to background filenames, so I can match them up
naturally, to celebrate this near-goal, memdumpbin has broken in dosbox
I run memdumpbin on what I can see in the debugger, it tells me "Memory dump binary success", and creates a file with 0 bytes in it.
weird.
and it persists through restarts of DOSBox!?
Pyrex, nightsworn alchemistrandom thought: is it possible memdumpbin is an alias for a com file that you have accidentally overwritten with an empty file
okay I got it through cheat engine. weird.
minor problem, though: there's 43 entries.
That's... that's not enough.
There's 306 backgrounds.
That's... that's not enough.
There's 306 backgrounds.
wait but there's 42 palettes! so maybe... this is getting complicated.
time to write some angry python code
oh hey fun fact: the pointer list is always loaded, but once execution leaves Load_Backgrounds the data it points to is unloaded!
0r no, I'm just wrong because there's an extra layer of indirection!
okay I extracted it.
problem: this is not enough.
there's not enough palettes to match every file, and there's palettes listed here which do not exist.
problem: this is not enough.
there's not enough palettes to match every file, and there's palettes listed here which do not exist.
oh god they're manipulating strings by using 32bit words to address them
they copy the DWORD at p to a char buffer, then assign to buffer[1] and buffer[3] to replace some of the characters.
I hate it.
they copy the DWORD at p to a char buffer, then assign to buffer[1] and buffer[3] to replace some of the characters.
I hate it.
and it turns out they build the filename like foo/bar/baz.pal, then pass it to a function that replaces the .pal with .cmp.
SO THIS DOESN'T LOAD PALETTES AT ALL
okay so there's a palette buffer that gets modified.
it gets touched by unload_buffers, Restore_Backgrounds, Game_Setup2, Display_Credits_Background, allocate_buffers, and Load_Saved_Game.
NONE OF THOSE MAKE SENSE FOR WHERE THE PALETTE FILE GETS PICKED
there's another buffer I'm calling current_palette.
maybe it only double-buffers it sometimes. lemme see if anything touches that one directly.
maybe it only double-buffers it sometimes. lemme see if anything touches that one directly.
Nathan@foone
Ah .. code that makes sense.
Been a long time since I remember seeing code that makes sense. 😄
(Actually, it's surprising how much I'd look at my *own* code, go "well that's stupid", change it, realise how much it breaks, then change it back.) 😎
Ah .. code that makes sense.
Been a long time since I remember seeing code that makes sense. 😄
(Actually, it's surprising how much I'd look at my *own* code, go "well that's stupid", change it, realise how much it breaks, then change it back.) 😎
wilkie@foone if it wasn't bullshit, it would be easy. what's the fun in that
Pointing Device@foone There's no better 386-class memcpy than a hand-written (REP) STOSD.
slim_vim
crumbcake@foone Me every day at work
maya 
now at catgirl.global@foone sorry, you must've used my brain as the source buffer ^^
HenriHave you thought about using QEMU and GDB instead of DOSBox?
https://astralvx.com/debugging-16-bit-in-qemu-with-gdb-on-windows/
Lorenzo Miniero@foone is this very uncommon? I've been playing with a point and click adventure engine of my own, and while there's no savegame support yet, that's one of the ways I had been thinking of implementing things eventually. Due to the way scripting works, with resources that can change depending on state, it feels like going through something like that simplifies the "reset" process