Please use the filecutter script to upload only a part of the file, open it with notepad and use 16 where it's written "math MEGABYTES = 2": http://aluigi.org/bms/filecutter.bms
struct RPKGResources { uint32_t int dwType; uint32_t int dwReferencesChunkSize; uint32_t int dwStatesChunkSize; uint32_t int dwDataSize; uint32_t int dwSystemMemoryRequirement; uint32_t int dwVideoMemoryRequirement; };
Files data can be also compressed. I have tryed comtype_scanner but without good results. Real size can be found in resource table for each entry. Actually i do not know how to interact with that table and get headers for each files.
aluigi wrote:Please use the filecutter script to upload only a part of the file, open it with notepad and use 16 where it's written "math MEGABYTES = 2": http://aluigi.org/bms/filecutter.bms
aluigi wrote:In my opinion there is no compression. What's there looks like a xor with an 8 bytes key that changes for every file.
I found only encryption for config files (packagedefinition.txt and thumbs.dat). It's XTEA. But I'm not sure that the same algorithm is used for encryption data in archives.
There is also this Thumbs.db file which appears to be a sort of a config file according to someone who has been digging. It maybe possible to enable the console through that file.
biosmanager wrote:I tried the scripts from http://zenhax.com/viewtopic.php?t=1201 but unfortunately they didn't work. It seems they changed the archive format.
@Ekey I guess it's a custom obfuscation because the sequence of bytes remains almost the same except for some few bytes that change, look at offset 0x350290. That's not possible with XTEA or other block ciphers where the whole block changes when the input changes.
We have a chance to find a data obfuscation algorithm by hooking API functions CreateFileA, CreateFileW, ReadFile, SetFilePointer and etc. Actually decryption/deobfuscation algorithm are close to these API. API Monitor v2 is great tool but it not displays the address where called from HITMAN.exe. Maybe there are similar tools with this capability?
aluigi wrote:In my opinion there is no compression. What's there looks like a xor with an 8 bytes key that changes for every file.
Why do you think it changes? As I can see, its always dc45a69cd3724cab
The illusion of it changing is only because all the files start with different offset. But all the files in this first 16M cut are xored with the same key
idstring "GKPR" get FILES long get OFFSET long get SIZE long for i = 0 < FILES get HASH longlong get OFFSET longlong get SIZE long putarray 0 i OFFSET next i get OFFSET asize putarray 0 i OFFSET for i = 0 < FILES getarray OFFSET 0 i math i + 1 getarray SIZE 0 i math SIZE - OFFSET encryption xor "\xdc\x45\xa6\x9c\xd3\x72\x4c\xab" log "" OFFSET SIZE next