I realize this is an old topic, but I recently went through the decompression routine via the use of a debugger and thought I'd contribute. In general, there are several cycles of decompression, each usually dealing with up to 0x800 bytes of (decompressed) data. Each cycle also has its own pair tabl...

I'm actually not especially interested in the game, but I did do some digging because I was curious and thought I'd at least have it documented somewhere. Folder structure is visible in the user folder. Most TPK files (at least the ones that start with ZZZ0) are compressed with zlib. First word cont...

Man, KCAP is wild . Depending on what's in the 4th int (the one you have as unk2), it's possible that there is no file table at all (example: the msh files) and of course, as the language keep file demonstrates, a KCAP can be a container for other KCAPs. Also, both BTX are the same file format, unk2...

I hate to revive such an old thread, but several people PM'd me already about the CCS2OBJ tool (since the link is long dead), so I'm reattaching it here.
No progress on it since the last post though.

I'm just grasping at straws here, but have you tried looking at a memdump to see if the image is in there and looks normal? (If you didn't know already, load up the game in PCSX2, get to a point with text, save via F1, look in the sstates folder, extract the newly created *.p2s with winrar, eeMemory...

Well damn, the actual algorithm (in Java) is: private static final int ITERATIVE_SEED = 0x3D; public static void decryptREV(byte[] data, byte[] key) { byte iterativeKey = ITERATIVE_SEED; for (int i = 0; i < data.length; i++) { byte dataKey = (byte) ((iterativeKey--) ^ (key[i % key.length])); data[i]...

From what I´ve seen, only the header and some other specific file parts are encrypted, I also got the key from one of the files (which is 0x500 bytes long, btw. Basically xores and then decreases, eight times, and then jumps to xor a random value twice, then starts decreasing again...). Not quite. ...

Indeed, it's a xor based encryption, but I don't think it's that simple. The key is not fixed and has to be calculated for each byte. I got the algorithm for vs01000000.rev, but if I run it on other files, they're either still garbage (like vs00title0.rev) or only partially decrypted (strings like &...

The contents of this post was deleted because of possible forum rules violation.

The contents of this post was deleted because of possible forum rules violation.

I only tried dsdecmp and it worked like a charm. There's no compressor, though. (do tell if you find a decent one)

Since there's some space issues which I can't quite fix, I'll just post what I have: Edit: see below posts for link What you need: static.arc and darchD.exe 1. static.arc can be extracted from the iso via WiiScrubber. darchD.exe is a *.arc packer/unpacker that comes with the Wii SDK. Use google. (Yo...

The compression is just a normal 0x11 type lzss one, but the problem I'm having is getting the decompressed file size. (lzss normally seem to store it in byte 2-4, but that's not the case here) Edit: Now I see, the size is indeed stored in bytes 2-4 (little endian), but each file in the pk is compre...

Since there's still no news of localization, I've decided to write my own text extractor/inserter and if it goes well, search for a translator. Thanks for documenting the bdat file format, you saved me a lot of time. Did you ever get to start translating the menu? All google has yielded me was an it...

It seems that the rest of the files are encrypted. May I know how much of the fsd file was used to break the pkg file into smaller files? Also, why are the total filesizes different after extraction? The file table starts at 0x72C in the fsd, I have no idea what the data before it is. Each file occ...