GPK: Difference between revisions

From Game Research Wiki
Jump to navigation Jump to search
No edit summary
Line 5: Line 5:
==Structure==
==Structure==
{| class="wikitable"
{| class="wikitable"
!colspan="15"| Temp
!colspan="15"| Overall
|-
|-
! Size !! Content !! Description
! Size !! Content !! Description
Line 15: Line 15:
| ? Bytes || Index || Protected Space
| ? Bytes || Index || Protected Space
|-
|-
| 12 Bytes || Unknown ||
| 12 Bytes || Magic2? || Format identifier?
|-
|-
| 4 Bytes || Unknown ||
| 4 Bytes || File Size || Size of the protected space
|-
|-
| 16 Bytes || Unknown ||
| 16 Bytes || Magic1? || Format identifier?
|}
 
{| class="wikitable"
!colspan="15"| Protected Space
|-
! Size !! Content !! Description
|-
| 4 Bytes || Unknown ||
|-
| ? Bytes || Unknown ||  
 
|}
|}



Revision as of 04:50, 7 July 2015

Used in the following game(s):

  • Schooldays HQ

Structure

Overall
Size Content Description
5120 Bytes Unknown Microsoft.Net assembly *.EXE
? Bytes Data full archive data
? Bytes Index Protected Space
12 Bytes Magic2? Format identifier?
4 Bytes File Size Size of the protected space
16 Bytes Magic1? Format identifier?
Protected Space
Size Content Description
4 Bytes Unknown
? 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.

Managed to find unprotected file list while debugging however unsure of structure yet. Lots of unknown data and some could be junk. Looks like it's full width characters (2 bytes per character) for file names. Possibly found offset which is first number after the file name string.


Fuck this format... seriously... All the "tools" I found to see if anyone else managed ended up being a simple program that searches for common headers. Putting this format aside for now. Might return someday... narrowed it down to one gigantic sub routine though. XD With the usage of anti-debugger tricks, who knows what other bullshit is put into this. Could just be a lot of nothing to just confuse people dissembling things... or actually compression. O.o