

Pokémon Mystery Dungeon: Keep Going! Blazing Adventure Squad MegaMinerd - For most of the research into filling data This data occurs between each file to show that its sepparate data, it can either be 16 or 32 bytes long, the FF value marks the end of the file data and start of the filling data, all the rest of the filling data is 00 value bytes, after that, the next file begins. This means that an addition of a new file or renaming a file in the archive has the potential to create junk data, overwriting text in an existing entry while leaving some of it there.Įach file data fits into this area as followed: Alternatively if we renamed or removed "bg_d", the file name in the table row below it called "bg.swd" would take priority and overwrite the text (and file offset data) on that table row and the namespace would look like "bg.swd t.sed", then if the file was renamed again to "b.swd", it would be "b.swd t.sed" which would look like "62 2E 73 77 64 00 00 74 2E 73 65 64 00 00 00 00 00 00 00 00" in hex. For example, we have a file called adev_app_icon.tex, then we name it "app_icon.tex", it would look like this: "app_icon.tex tex".

It's possible to create a program that would re-replicate the same type of junk data results though file namespace overwriting. So essentially it would be development leftovers. Junk text is the remains of what used to be a previous file that existed on that entry before it was overwritten by a different filename, either through renaming or removal of a file during development. Anything after the 00 valued byte through to offset 0x1B will be what we'll refer to it as "junk text". Filenames can only be a maximum of 19 characters long, every filename always ends with a 00 value byte and must be in the namespace data in order for it to function properly.

This data contains the filename data, and all filenames can only be in ASCII format. This data contains all the pointers of all files, as well as their file names. Part 1 - Pointer and file name table Part 2 - Actual data of all files Since data1 and data2 archive binaries are compressed with the AT7 compression algorithm, the archives must be decompressed before any data can be extracted.īut here's how the decompressed data1 and data2 files are structured:

The files, data1 and data2 are archive binaries, the "XXXX" indicated in the file name, is the game code for the files, which can vary depending on the version (eg. Pokémon Mystery Dungeon (WiiWare) data1_XXXX.bin and data2_XXXX.bin archive information
