This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=2179

Kawasuzu, posted Tue Mar 01, 2016 2:43 am (11703)

---

It seems like the current CPK quickbms script doesn't work with this cpk file completely. The script crashes after extracting for a while, and it can't extract the file names.

I have uploaded the first 16 MBs and the last 16 MBs of the cpk file.

First 16 MBs: http://puu.sh/nqrOi/3c211ff1e2.cpk
Last 16 MBs: http://puu.sh/nqspW/cf7e232c86.cpk

aluigi, posted Tue Mar 01, 2016 6:57 pm (11721)

---

The crash may be caused by the usage of the decompression function on non-decompressed data.
It happened with some xfbin files that reported an extract_size bigger than file_size which usually identifies a compression, but no compression was used.
There is not much I can do, for the xfbin files I simply checked if the data at the file offset was "CPK " (this is a work-around).
Here I don't know what non-compressed files are set as compressed because it's all ok in the first 16 megabytes you provided.

Kawasuzu, posted Thu Mar 03, 2016 5:10 am (11738)

---

Huh. I'll post the actual CPK here then. Hopefully you'll be able to figure out what's causing the crash. (and the script not outputting the file names)

https://mega.nz/#!u4pl2KrD!Go_tsjL7pBA4 ... FhhMgisUow

aluigi, posted Thu Mar 03, 2016 7:28 pm (11749)

---

This CPK seems very different than the others.
The offset and size reported by the tool are mathematically "correct" (in the sense that 0x23040600 48880 is the end of the archive) but they are all totally wrong and not point to the real data.
Currently I no longer support cpk.bms except for small fixes but in this case it seems that the "FileOffset" value (used in query_utf) doesn't exist at all.