Difference between revisions of "GPK"
| Line 21: | Line 21: | ||
==Research== | ==Research== | ||
Strange format... First 5120 bytes | Strange format... First 5120 bytes look like program code but is the same code for every archive. Data itself might not be protected but index data, including offsets are. There may be some anti-debugging code. If the debugger eats up the exception that it throws, the program never catches it so it knows it's being debugged and exits. Passing the exception to the program appears to get around this. | ||
When loading a archive, the game does the following... | |||
read fileSize- | reads the last 16 bytes in the file (read offset(fileSize - 16) for 16 bytes). | ||
read | reads 16 bytes, 32 bytes before the end of the file (read offset (fileSize - 32) for 16 bytes). | ||
The last 4 bytes of the data that was just read is a number, that number is the size of the protected space that is at the end of the file - 32 bytes. | |||
The program | The program then tries to process the protected area. It XOR's the protected space in memory by a number that might change for each byte. Once that is done, the first 4 bytes is a number the program uses for an unknown purpose. It always appears larger than what the protected space is so chances are, it could actually be compressed/encoded data and the number at the front is really just the uncompressed size. Needs more research. | ||
Revision as of 02:29, 7 July 2015
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 look like program code but is the same code for every archive. Data itself might not be protected but index data, including offsets are. There may be some anti-debugging code. If the debugger eats up the exception that it throws, the program never catches it so it knows it's being debugged and exits. Passing the exception to the program appears to get around this.
When loading a archive, the game does the following...
reads the last 16 bytes in the file (read offset(fileSize - 16) for 16 bytes).
reads 16 bytes, 32 bytes before the end of the file (read offset (fileSize - 32) for 16 bytes).
The last 4 bytes of the data that was just read is a number, that number is the size of the protected space that is at the end of the file - 32 bytes.
The program then tries to process the protected area. It XOR's the protected space in memory by a number that might change for each byte. Once that is done, the first 4 bytes is a number the program uses for an unknown purpose. It always appears larger than what the protected space is so chances are, it could actually be compressed/encoded data and the number at the front is really just the uncompressed size. Needs more research.