GPK - Revision history

Orin at 18:55, 15 April 2020

2020-04-15T18:55:23Z

← Older revision		Revision as of 18:55, 15 April 2020
Line 57:		Line 57:
	4/12/2020		4/12/2020

	Gonna revisit this format. Seems interesting. I have a few environments setup for reversing programs. I just need to figure out how index structure. If data itself is uncompressed and unprotected, no point in using compression on index only... Hopefully it's not some weirdly complicated format that doesn't really use file names but instead a compiled processes with hashes or something.		Gonna revisit this format. Seems interesting. I have a few environments setup for reversing programs. I just need to figure out how index structure. If data itself is uncompressed and unprotected, no point in using compression on index only... Hopefully it's not some weirdly complicated format that doesn't really use file names but instead a compiled processes with hashes or something. Looking at the BGM.GPK, I can see all the OGG format headers so data is probably not protected... at least this one. Found 63 headers in that one so might have 63 files or could have other, non-ogg files. Not sure. I'll keep looking at it.

Orin at 18:52, 15 April 2020

2020-04-15T18:52:16Z

← Older revision		Revision as of 18:52, 15 April 2020
Line 54:		Line 54:

	ToDo: Run test on post XOR data to check if it's really just compressed.		ToDo: Run test on post XOR data to check if it's really just compressed.

			4/12/2020

			Gonna revisit this format. Seems interesting. I have a few environments setup for reversing programs. I just need to figure out how index structure. If data itself is uncompressed and unprotected, no point in using compression on index only... Hopefully it's not some weirdly complicated format that doesn't really use file names but instead a compiled processes with hashes or something.

Orin: /* Research */

2015-07-08T18:05:49Z

Research

← Older revision		Revision as of 18:05, 8 July 2015
Line 52:		Line 52:

	...actually... Found the source for a program that might help by searching for the identifiers on google. XD		...actually... Found the source for a program that might help by searching for the identifiers on google. XD

			ToDo: Run test on post XOR data to check if it's really just compressed.

Orin: /* Research */

2015-07-07T04:54:02Z

Research

← Older revision		Revision as of 04:54, 7 July 2015
Line 50:		Line 50:

	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		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

			...actually... Found the source for a program that might help by searching for the identifiers on google. XD

Orin at 04:51, 7 July 2015

2015-07-07T04:51:20Z

← Older revision		Revision as of 04:51, 7 July 2015
Line 15:		Line 15:
	\| ? Bytes \|\| Index \|\| Protected Space		\| ? Bytes \|\| Index \|\| Protected Space
	\|-		\|-
	\| 12 Bytes \|\| ~~Magic2?~~ \|\| ~~Format identifier?~~		\| 12 Bytes \|\| Identifier \|\| "STKFile0PIDX"
	\|-		\|-
	\| 4 Bytes \|\| File Size \|\| Size of the protected space		\| 4 Bytes \|\| File Size \|\| Size of the protected space
	\|-		\|-
	\| 16 Bytes \|\| ~~Magic1?~~ \|\| ~~Format identifier?~~		\| 16 Bytes \|\| Identifier \|\| "STKFile0PACKFILE"
	\|}		\|}

Orin: /* Structure */

2015-07-07T04:50:03Z

Structure

← Older revision		Revision as of 04:50, 7 July 2015
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 \|\|

	\|}		\|}

Orin at 04:46, 7 July 2015

2015-07-07T04:46:19Z

← Older revision		Revision as of 04:46, 7 July 2015
Line 34:		Line 34:

	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.		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

Orin: /* Structure */

2015-07-07T02:32:15Z

Structure

← Older revision		Revision as of 02:32, 7 July 2015
Line 5:		Line 5:
	==Structure==		==Structure==
	{\| class="wikitable"		{\| class="wikitable"
	!colspan="15"\|~~Header~~		!colspan="15"\| Temp
	\|-		\|-
	! Size !! Content !! Description		! Size !! Content !! Description
Line 12:		Line 12:
	\|-		\|-
	\| ? Bytes \|\| Data \|\| full archive data		\| ? Bytes \|\| Data \|\| full archive data
			\|-
			\| ? Bytes \|\| Index \|\| Protected Space
	\|-		\|-
	\| 12 Bytes \|\| Unknown \|\|		\| 12 Bytes \|\| Unknown \|\|

Orin at 02:29, 7 July 2015

2015-07-07T02:29:48Z

← Older revision		Revision as of 02:29, 7 July 2015
Line 21:		Line 21:

	==Research==		==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~~.		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.

	~~read fileSize-16~~		When loading a archive, the game does the following...

	read fileSize-32		reads the last 16 bytes in the file (read offset(fileSize - 16) for 16 bytes).

	read ~~fileSize -~~ (~~4byteValue@~~fileSize-24) for ~~4byteValue@fileSize-24~~		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 ~~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~~.		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.

Orin at 02:20, 7 July 2015

2015-07-07T02:20:06Z

← Older revision		Revision as of 02:20, 7 July 2015
Line 28:		Line 28:

	read fileSize - (4byteValue@fileSize-24) for 4byteValue@fileSize-24		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.