This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=3333

FZFalzar, posted Thu Nov 03, 2016 4:11 am (18521)

---

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:

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:

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, posted Thu Nov 03, 2016 10:48 am (18525)

---

No it doesn't work:

Code:

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, posted Thu Nov 03, 2016 11:15 am (18527)

---

aluigi wrote:

No it doesn't work:

Code:

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, posted Thu Nov 03, 2016 5:33 pm (18532)

---

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:

FZFalzar, posted Thu Nov 03, 2016 7:35 pm (18536)

---

Some more progress, hooray for XVI32 and Windows Calc



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

aluigi, posted Fri Nov 04, 2016 6:18 am (18547)

---

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

FZFalzar, posted Fri Nov 04, 2016 7:12 am (18548)

---

aluigi wrote:

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, posted Fri Nov 04, 2016 8:30 am (18551)

---

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

FZFalzar, posted Fri Nov 04, 2016 9:33 am (18552)

---

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, posted Fri Nov 04, 2016 11:42 am (18554)

---

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, posted Fri Nov 04, 2016 10:39 pm (18563)

---

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, posted Sat Nov 05, 2016 8:16 am (18568)

---

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, posted Sat Nov 05, 2016 9:14 am (18572)

---

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

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