(In case this wasn't obvious by now, this thread is in the wrong forum, SPC is an archive format, not graphics)
I don't think DRV3 .SPC files use the same compression algorithm as OPBB .SCZ. I attempted to get the OPBB executable to decompress a file from an .SPC by replacing the first chunk in an .SCZ in the game's memory before decompression (adjusting the sizes in said .SCZ's TOC entry accordingly) and only got garbage back.
I've attached another sample compressing a file of a more or less well-known format (CRIWARE ACB).
The entry of the first (and only) file in that archive starts at 0x50.
0x50-0x51 (here:
02 00) identify the compression algorithm. Some .SPC's I've looked at contain uncompressed files, for which that number is
01 000x52-0x53 (here:
04 00) is of currently unknown purpose. I've also seen it be
01 00 and (IIRC)
08 00 in other files. For the uncompressed file I've looked at this is also
04 00.
0x54-0x57 and 0x58-0x5B are the compressed and uncompressed file size, respectively.
0x5C-0x5F are the file name length, though the actual file name field is padded to 16 bytes.
After that, a bunch of null bytes, then the file name field, so the compressed data goes from 0x70 to (in this case) 0x57636.
Other recent Spike Chunsoft games use either no compression (inside the CPKs) or what looks like OPBB's compression. I've run this through the comtype scanner and nothing worked. So at this point I believe this is a new, original compression algorithm.
Analysing those without access to (de)compression code - there's currently no way to decrypt PS Vita game executables requiring firmware 3.61 or higher - is out of my league, but if anyone wants a challenge, we'd appreciate the help
