GPK
Used in the following game(s):
- Schooldays HQ
Structure
Header | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Size | Content | Description | ||||||||||||
5120 Bytes | Unknown | Microsoft.Net assembly *.EXE | ||||||||||||
? Bytes | Data | full archive data | ||||||||||||
12 Bytes | Unknown | |||||||||||||
4 Bytes | Unknown | |||||||||||||
16 Bytes | Unknown |
Research
Strange format... First 5120 bytes looks like program code but is the same code for every archive. Data itself might not be protected but index data, including offsets are. game engine might have anti-debugger functions. Something to do with exceptions. Passing the ones that come up to the application rather than the debugger seems to solve the issue for now.
read fileSize-16
read fileSize-32
read fileSize - (4byteValue@fileSize-24) for 4byteValue@fileSize-24
The program reads a number that appears to be the size of a protected area. It loads this protected area into memory. In memory, it XOR's each byte of the protected data by 0x82. It then reads the first 4 bytes of the memory that was just XOR'ed and reads it as a 4 byte integer. It then uses this number for something. The program than uses the rest of the memory but excludes the first 4 bytes so the memory space it is working with is 4 bytes less now. Holy shit, wtf am I reading? Is this really that complex? I managed to see the unprotected filenames a few times and appear to be store as a wide width string. However, how it's actually being processes is unknown yet. There is no pattern in the protected versions of the memory to suggest all that white space between characters. The first 4 bytes could actually be the uncompressed filesize of the rest of the data. Which... yeah. This is fucking annoying.