Destiny Child KR PCK files [Android, ARM]

[FZFalzar]

Hi, I'm trying to extract/decompress this game's PCK files that doesn't seem to be standard across the existing PCK formats
The apk's id is com.NextFloor.DestinyChild

The header for this particular PCK is

Code: Select all

50 43 4B 00 CD CC CC 3E

So far, what I've gathered from looking at the PE using IDA is that it seems to use LZO1X but that's as far as I got
My guess is that either audio or lua script files are stored within

It seems to reference a AES byte key using ECB for possibly encrypted(?) PCKs which is the following:

Code: Select all

key = new Buffer([b]REMOVED!/b])

The game's lib and sample PCK files can be downloaded at [b]REMOVED!/b]
Within the archive are compressed and uncompressed(?) PCK files

Good luck!
-Falz

[aluigi]

No it doesn't work:

Code: Select all

comtype lzo1x
idstring "PCK\0"
get DUMMY long
get DUMMY long
for
    get DUMMY threebyte
    getdstring DUMMY 5
    get ZIP byte    # 3
    get OFFSET long
    get ZSIZE long
    get SIZE long
    get DUMMY long

    encryption aes "\x37\xEA\x79\x85\x86\x29\xEC\x94\x85\x20\x7C\x1A\x62\xC3\x72\x4F\x72\x75\x25\x0B\x99\x99\xBD\x7F\x0B\x24\x9A\x8D\x85\x38\x0E\x03"
    clog "" OFFSET ZSIZE SIZE
next

[FZFalzar]

No it doesn't work:

Code: Select all

comtype lzo1x
idstring "PCK\0"
get DUMMY long
get DUMMY long
for
    get DUMMY threebyte
    getdstring DUMMY 5
    get ZIP byte    # 3
    get OFFSET long
    get ZSIZE long
    get SIZE long
    get DUMMY long

    encryption aes "\x37\xEA\x79\x85\x86\x29\xEC\x94\x85\x20\x7C\x1A\x62\xC3\x72\x4F\x72\x75\x25\x0B\x99\x99\xBD\x7F\x0B\x24\x9A\x8D\x85\x38\x0E\x03"
    clog "" OFFSET ZSIZE SIZE
next

Yeah I assumed it wouldn't be that easy, there are multiple codepaths that use the same class and some are encrypted and compressed, some are just compressed and some are pure unencrypted so yeah

[FZFalzar]

Ok I have abit of progress, it seems the top part of the PCK is a "table" of sorts, which usually should contain offset of the data, length of this data and a name/identifier? But otherwise:

1478194099231.jpg

[FZFalzar]

Some more progress, hooray for XVI32 and Windows Calc



I'm guessing the next 4 bytes beside the blocksize is the uncompressed size

[aluigi]

The "table" part is already covered by the script perfectly.
The missing part is the encryption/compression, just that.

[FZFalzar]

The "table" part is already covered by the script perfectly.
The missing part is the encryption/compression, just that.

I've tested it with a quick C# prog, some blocks are decryptable using that key while others are either decompressed or something else. The first 9 bytes after the total entries is what I'm trying to find out though, I'm guessing that's a CRC hash or some flag to indicate what type of processing to perform (like decoding or decompression etc.)

[aluigi]

Well, you can ever extract the non-encrypted files... better than nothing
http://aluigi.org/bms/destiny_child_kr.bms

[FZFalzar]

Haha thanks for the script ., but I need the encrypted bits more kek

So far I've determined that for example:
BF 0B 00 1F D1 FF 4F 61 03 01 6A 00 00 70 00 00 00 8C 00 00 00 0E 00 00 00

BF 0B 00 1F D1 FF 4F 61 -> 8 bytes, possibly a CRC or a compressed string of a filename
03 ->1 byte, Compression flag, 0x00 = uncompressed, 0x02 and 0x03 is compressed (with what, idk)
01 6A 00 00 -> 4 bytes int32, Start address to seek
70 00 00 00 -> 4 bytes int32, Size to read
8C 00 00 00 -> 4 bytes int32, decompressed size
0E 00 00 00 -> 4 bytes int32, unknown

By performing AES-ECB(or rjindael) decrypt with key on the block (start addr + size), you can see that some data is retrieved although the rest of the file is a mess. So I personally feel that this is either Read->Decompress->Decrypt OR Read->Decrypt->Decompress

example:


Right now I'm having trouble to get LZO1X to decompress on C#, and there's also a chance Yappy could be used too (https://github.com/inikep/lzbench/blob/master/yappy), sadly Yappy is too unknown so there's no implementations for quick use

[aluigi]

Script 0.2
The problem was only a typo in the key I used in the script, yeah lot of troubles for a typo.

[FZFalzar]

I tried the script on pack.pck, seems to crash on decompression (uncompressed size > allocated buf size)

Is there a quick way to just read X bytes out without looping through the whole file in BMS? Was thinking of manually checking the buffer to see if the compression type is correct first

[aluigi]

It's impossible that you get an error using that script on pack.pck.
I have the same file with the same script 0.2 and the same quickbms 0.7.6a, and everything works perfectly.

[FZFalzar]

Dang, I was an idiot, didn't check my version of quickBMS before using

Thanks a lot .! Was struggling to implement in C++/CLI