From what I gather:
0x08 - amount of files
0x0C - block/sector size
0x18 - TOC length?
0x28 - header size
0x2C - body size
0x40 - archive name
TOC:
0xA0 - null
0xA4 - offset (with the header size subtracted)
0xA8 - size
0xAC - uncompressed size / null if not compressed
...
If this may be important, in every other fpk archive the TOC starts at 0x80, and 0xXC value indicates the file type instead of uncompressed size.
So I used this caveman-made script to dump the contents of image.bin:
Code: Select all
goto 0xA0
for i = 0 < FILES
get DUMMY long
get OFFSET long
math OFFSET + 0x4800
get SIZE long
get DUMMY long
log "" OFFSET SIZE
next i
However, the majority of fpk archives contained there are compressed like so:
Which seems to be LZO(1x?) algorithm + some sort of 0x2D-long header (contains: 0x08 - size, 0x0C - csize), but I didn't get a match after manually trying to decompress them
both headered and with the header stripped, and comtype_scan2 gets stuck on these files without the ability to Ctrl+C & N circumvent the hang-up.
Edit: Managed to run comtype_scan all the way through and it didn't result in compression algorithm matches.
If anyone could look into making a script for handling the archive or even tackling the compression alone, I would be eternally grateful. Thank you for your time, and sorry for the bother as always.
Here's a couple of compressed and uncompressed fpk samples and a full image.bin (919 MB) just in case.