I don't know if I'm weird or if it's just normal to get random reverse engineering urges.
-
for the ones with 0/1 versions (COVE and DASH), 0 seems be the CGA/Monochrome version, while 1 is the VGA version
-
here's P0.HUF to show what I mean about corruption:
-
CMP files seem to contain object info, since I see text in them.
the game supposedly has 240 objects on the map, which can be transported onto your ship when found. Some are useless, some are clues to The Main Puzzle, and some are instant death bombs
-
I suspect the maps are compressed too.
time to find the decompress routine in the exe!
-
interesting. this code that opens A2.ARE reads 1536 bytes and then closes it.
the file is 2432 bytes, though
-
I think this game was programmed in assembly. passing one pointer in SI is not a calling convention I have seen compilers use
-
@foone
You keep getting ideas for more DOS games to hack to the point that it keeps you from doing anything. I believe this is a DOS attack -
ahh, I think I was looking at a custom loader that just handles TITLE.HUF
(which is 7687 but presumably the files is re-opened later?)
-
yeah the version that works for maps loads 8194 bytes.
which is an annoying number.
-
but I bet it's because it can read non-huffman'd files, and 8192 + 2 byte header?
-
ahh. so it's got a string in the EXE that's A0.ARE.
Then it has another string that's 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ.
So when it wants to load area N, it indexes into the Nth item of the second string, then shoves it in over the 0 in A0.ARE and opens that file -
@phi1997 it sure is!
-
Programming used to be fun
. -
Ghidra: I support disassembly of 16-bit DOS programs!
also Ghidra: WHAT THE FUCK IS "DS"? all segment-relative poitners are aimed at segment 0000, right? -
either ghidra's set-register doesn't work or I don't understand what it's doing
-
uh-oh.
after loading the file, it calls two functions. One seems to just be shoving it into memory, but the other shows up as blank, and instant ret.
That smells like dynamic code loading and I don't like that
-
16bit assembly is so silly.
You enter a function and step one is you make a pointer to 2, and then increment from there -
the calling code changes the data segment to one just used for your specific buffer, so you don't need a pointer, it's just in the implicit state of the processor. you just work from 2
-
okay I haven't checked against the actual output (since I haven't gotten the actual output yet) but I think this isn't huffman, it's not even regular RLE, it's Very Simple RLE: You can represent all bytes 00-7F normally, but if the high bit is set, it instead means "repeat this many zeros"
-
so 44 82 44 turns into 44 00 00 44
