4

So, I've been working on reversing several file formats from the Nintendo DS game Pokemon Mystery Dungeon: Explorers of Sky.

So far most formats were pretty easy to reverse, until I stumbled on a compressed format using a header I've never seen in any other compressed files in other games on the DS so far (I'm not all that experienced in reversing)..

Its magic number is PKDPX or 0x50, 0x4B, 0x44, 0x50, 0x58. And here's the header :

The 2 bytes right after the magic number is the file length. Its a little odd to store a file length on only 2 bytes though. Especially when every other format I've seen this far uses mainly 4 bytes integers... And I'm wondering if it couldn't be an older compression format used in GBA games. Given that a lot of data from the previous game, for the GBA, was re-used in this one.

However I'm still at a loss as to how to deal with this format. I haven't found anything from the NDS hacking scene about those, besides people mentioning they never saw that format before, or on the contrary, people just talking about it as if it was a very obvious format.

From what I know, NDS games are known for using huffman and lz compression, or even rle, but I really doubt this is rle, given its probably not an image, and I doubt a pure data format would see much advantage from having rle compression applied to it.. But, I'm not an expert on compression, or I wouldn't posting this here XD.

One thing to note is the SIR0 magic number down there, 0x53, 0x49, 0x52, 0x30. SIR0 is a format I'm familiar with, right after the magic number there are 2 4bytes pointers that points to some file structure related data at the end of the file. Thus if those aren't too mangled, just like the SIR0 magic number, it could give a decent idea of the decompressed file size, give or take a couple hundred bytes.

However, right now there is no indication that those weren't mangled, or where the first value ends and where the other starts...

Any tidbits of info would be welcome at this point !

EDIT: I also found out that, the DS has built-in LZ10 compression handling, however its common for devs to make their own "custom" compression and do it themselves. But, given it was made near the end of the DS's life cycle, it might just be "custom" LZ11, LZSS, or another variant..

Psy_commando
  • 41
  • 2
  • 1
    Why not analyze the code that reads from this file in order to determine how it decompresses this data? – Jason Geffner May 29 '14 at 17:23
  • Well, I'd do but I don't know where to look. I mean, I got the code, its ARM assembly. But, I can't tell where this file in particular is being loaded, or where its being unpacked.. I'm willing to investigate that path and learn about ARM assembly and how the whole thing works, but having some pointers would help greatly ! – Psy_commando May 29 '14 at 21:30
  • 2
    Are you sure the data is compressed? From the partial hex output you've posted, the data doesn't look random enough to be compressed (e.g., lots of 0xAC, 0xFE, 0x2F bytes). – devttys0 May 30 '14 at 12:43
  • Honestly, I'm not sure. The fact that the compressed file's magic number is readable leaves me in doubt. But then again, doesn't some compression methods keep a list of data strings and how often they're repeated ? I can't say if its a good assumption on my part though.. I think I'd need to find some LZ10, LZ11, LZM, LZSS, LZ77 compressed files examples..I was able to run binwalk on it, and entropy spiked at the beginning, then down and spiked again way higher midway through the file.. From my limited understanding of entropy, I can't really tell if its a false positive or if its a good sign.. – Psy_commando May 30 '14 at 18:08
  • Oh, and the rest of the header for the SIR0 file contained, besides the magic number, is mangled, so that leads me to believe its compressed somehow. – Psy_commando May 30 '14 at 18:23
  • Hey, I was just playing this game! I'd love to find out what progress you were able to make on this. – Austin Burk May 17 '18 at 13:52

0 Answers0