This topic was archived here:

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

dragonttk2, posted Fri Jan 16, 2015 1:48 pm (2705)

---

Does anyone have a script for either of these games if you do can you please post it / link me it thank you!

edit:
I tried one extracting program on here for the forest and it only got me .mat files.

aluigi, posted Fri Jan 16, 2015 6:15 pm (2710)

---

What extracting program/script you tried?
If you extract some files and their total size is major/equal than the original archive, it means it's ok.

hhrhhr, posted Sun Jan 18, 2015 11:35 pm (2737)

---

...\H1Z1\Resources\Assets\*.pack

Code:

// Big-Endian !!!

// .pack header
uint32 magic; // \x00\x00\x00\x00
uint files_num;

{
    uint name_lenght;
    char name[name_lenght];
    uint offset; // absolute
    uint size;
    uint crc32;
} // * files_num

// .pack data
// ...

aluigi, posted Mon Jan 19, 2015 12:38 am (2738)

---

With an "endian", "for", "log" and "next" commands you can use that code directly in quickbms:

Code:

endian big // Big-Endian !!!

// .pack header
uint32 magic; // \x00\x00\x00\x00
uint files_num;

for i = 0 < files_num {
    uint name_lenght;
    char name[name_lenght];
    uint offset; // absolute
    uint size;
    uint crc32;
    log name offset size
next i //} // * files_num

// .pack data
// ...

michalss, posted Mon Jan 19, 2015 7:10 am (2743)

---

yeah easy format, i can write repacker but i guess it does not really make any sence does it ?

aluigi, posted Mon Jan 19, 2015 1:34 pm (2748)

---

If the crc32 field is handled by the game then it's necessary a rebuilder to modify the files.

aluigi, posted Fri Jan 29, 2016 9:56 pm (11116)

---

After having reviewed the files, my opinion is that everything is
perfectly normal and the script is correct.
Those missing bytes from the archive are probably caused by how the
archives are updated and this is visible in Assets_113.pack between
offset 0x9c8c which is where the file to extract finishes and offset
0x9cc5 where the next file starts.
That zone of data looks exactly like a previous version of the file
that was bigger than the current one, so the developers simply injected
the new updated file at its original place and then they modified the
size value in the index.

Code:

                                      0x9c8c
                                      |
  6f 72 52 75 6e 74 69 6d 65 3e 0d 0a 3d 22 30 22   orRuntime>..="0"
  20 2f 3e 0d 0a 20 20 20 20 3c 44 65 63 61 6c 54    />..      69 6e 74 54 72 61 6e 73 6c 61 74 69 6f 6e 73 20   intTranslations
  2f 3e 0d 0a 3c 2f 41 63 74 6f 72 52 75 6e 74 69   />..  6d 65 3e 0d 0a 44 4d 4f 44 04 00 00 00 37 02 00   me>..DMOD....7..
                 |
                 0x9cc5