Helldorado

[Kataah]

The contents of this post was deleted because of possible forum rules violation.

[aluigi]

extracting the files is ok, the only problem is retrieving their names.
I have made only a quick external analysis of the archives but I guess that if the names are really stored in them they are located in the bytes between the offset/size table and the first file in a compressed form.
the following is the quickbms script for extracting the files without names:

Code: Select all

idstring "SBPAK V 1.0\r\n\0\0\0"
get DUMMY long  # ever the same
get DUMMY long  # ever the same
filexor 0x08

get DUMMY long
get DUMMY long
get DUMMY long
get FILES long
get DUMMY long
get BASE_OFFSET long
get TOTAL_SIZE long

for i = 0 < FILES
    get SIZE long
    get OFFSET long
    get DUMMY long
    get DUMMY long
    math OFFSET += BASE_OFFSET

    log "" OFFSET SIZE
next i

[Kataah]

Thx Bugtest

[asmxtx]

Yes, the only - and biggest - problem is to retrieve the filenames. They seem to be encrypted in a special way.
Also, the whole file seems to be XORed with 0b6h - but according to a flag somewhere. I haven't been able to analyze this further...

[aluigi]

an idea for catching the right XOR byte can be the reading of the byte at offset 0x18 which is 0xff in clear mode so it's enough to xor it with 0xff to get the right xor value.
the only problem is that now the Filexor command uses a fixed number/string as argument while in the past it used a variable so now I need to re-introduce that old argument type for allowing the usage of dynamic xor values

*edit* I have figured the filenames encryption

[Kataah]

Great work as always Bugtest.
Can it be handled with a BMS script?

[aluigi]

sure and indeed I have already written the script yesterday but the dynamic xor value has been re-introduced in the new version that I will release tomorrow.
so you need only to wait some hours :)

[aluigi]

as promised:
http://aluigi.org/papers/bms/helldorado.bms

remember to update QuickBMS!

[asmxtx]

@bugtest:
I was using your BMS-script and it is able to recover the file structure properly. Evaluating it I found out that lines 7...9 are not necessary, because the XOR-value is 0xB6 in any case (it is EXE-hard-coded).
But that's not the problem.
The actual problem is that not the whole PAK-file is XORed. Certain files are stored in their original form (like BIK-videos, WAV-sounds and maybe other files which format I don't know.)
I tried to analyze the PAK-structure but I am overextended to find a solution.
There must be a XOR-flag somewhere...

[aluigi]

from what I have understood (I don't have all the files or the full game) and verified with the demo only some types of files are not xored, like BIKs.
so seems extension-based because the other fields (like the 2 DUMMYs in the table) have a content which is not constant also for the bik files.

so, resuming, here after having checked the content of data.pak of the demo I have seen only the bik files which don't use the xor obfuscation while all the other files are correct.
have you verified if there all the wav files don't use xor or only some of them?

[asmxtx]

After investigating extracted files I can confirm that only BIK-files seem to be stored without XORing (maybe for performance reasons).
Comparing with the extension ".BIK" to make a XOR-decision might be sufficient, I think.

[drevil]

I can not use helldorado.bms unpack a locale language file(ZH.PAK ia a chinese)
I put in
http://cid-12e5359bddd15270.skydrive.li ... _v1.01.rar
please help me unpacker it
thanks!

[aluigi]

well finally we know when it's used the additional xoring I saw in the code :)
redownload my script and go down until you see the message "# uncomment the following 5 lines if you get wrong filenames!" and remove the # char in the lines which follow it:

Code: Select all

    if XBYTE & 1
        math BYTE ^= 0x6e
    else
        math BYTE ^= 0x65
    endif

now you can extract the files from zh.pak without problems.
indeed 0x6e and 0x65 are the "en" string so I guess that in other country based paks will be needed to change it.
for example in the german demo that value was set to "de" (0x65 0x64) but as far as I know it wasn't used while in an hypothetic italian version it will be 0x74 0x69

at the moment I have not found a way to implement this check automatically at runtime in the script, so the manual editing of the script is necessary

[Mr.Mouse]

Nice going bugtest!

[Alek Sander]

Hey guys! I used the script posted here. In misc.pak file there is a small program packed inside called "sbpacker.exe", which can create, list and unpack pak-files for the game. It extracts all the data including folders. It's the official tool, I guess...