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
memaddressanalysis/memanalysis.py at master · nccgroup/memaddressanalysis
Research project related to memory address analysis - memaddressanalysis/memanalysis.py at master · nccgroup/memaddressanalysis
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.
here they all are, converted with a standardized palette.
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.
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.
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.
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
I think if you write a function like:
void debugPrint(char *message){
#ifdef DEBUG
fprintf(stderr, "ERROR: %s\n", message);
#endif
}
watcom will still compile it, to a function that does nothing, and it just does some stack manipulation and then throws it away.
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
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.
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"
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
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
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!?
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.
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.
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.
@foone if it wasn't bullshit, it would be easy. what's the fun in that
Alice Averlong🏳️⚧️
wilkie