08-19-2012, 06:58 PM
Here are a few tricks you can use, while ripping sprites or just reversing a video game.
First of all, to open a 32-bit dos4gw executable inside IDA, remove in hex editor all bytes from the start of EXE up to the 4th MZ occurrence.
Second, DOS games output graphics through 0A000h and related addresses. Searching for them should be the first thing you do after opening EXE in disassembler.
In some cases you can get unpacked tiles by just dumping DOSBox memory and then treating it as a big 8-bit image (with current palette) and changing it's width until tiles get aligned. In many cases dumping memory won't work, because many DOS games store sprites in biplanes and/or RLE, unpacking them only during drawing. For example, DOS version of Heimdall stores each scanline in RAM as a number of interleaved bitplanes, each compressed with simple RLE scheme.
If some graphics aren't present in memory, you can get it loaded by just patching offsets/filenames in hex editor. I.e. overwrite some GameOver.bin in game.exe with Victory.bin.
If you want to easily dump entire game map as a single png image, then get DOSBox source code and patch it to trace changes in memory, so you can get addresses of the X,Y variables of the game viewport. Now you can programmatically change them, saving screenshots into png after each increment. This way you can also position viewport on inaccessible places or just teleport your character there.
When ripping from Amiga games (and some DOS games), look for "RNC" signature. It's a common compression scheme on Amiga. Although some games (like Heimdall) use a variation of RNC.
Similarly for Windows and iOS games, signature 0x9C78 near the beginning of a sprite points to deflate compression. For example, Might & Magic 6, MapleStory and Zenonia use it to compress sprites.
First of all, to open a 32-bit dos4gw executable inside IDA, remove in hex editor all bytes from the start of EXE up to the 4th MZ occurrence.
Second, DOS games output graphics through 0A000h and related addresses. Searching for them should be the first thing you do after opening EXE in disassembler.
In some cases you can get unpacked tiles by just dumping DOSBox memory and then treating it as a big 8-bit image (with current palette) and changing it's width until tiles get aligned. In many cases dumping memory won't work, because many DOS games store sprites in biplanes and/or RLE, unpacking them only during drawing. For example, DOS version of Heimdall stores each scanline in RAM as a number of interleaved bitplanes, each compressed with simple RLE scheme.
If some graphics aren't present in memory, you can get it loaded by just patching offsets/filenames in hex editor. I.e. overwrite some GameOver.bin in game.exe with Victory.bin.
If you want to easily dump entire game map as a single png image, then get DOSBox source code and patch it to trace changes in memory, so you can get addresses of the X,Y variables of the game viewport. Now you can programmatically change them, saving screenshots into png after each increment. This way you can also position viewport on inaccessible places or just teleport your character there.
When ripping from Amiga games (and some DOS games), look for "RNC" signature. It's a common compression scheme on Amiga. Although some games (like Heimdall) use a variation of RNC.
Similarly for Windows and iOS games, signature 0x9C78 near the beginning of a sprite points to deflate compression. For example, Might & Magic 6, MapleStory and Zenonia use it to compress sprites.