This topic was archived here:

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

Doprond, posted Mon Oct 31, 2016 7:42 pm (18504)

---

Samples here:
https://mega.nz/#!joh3VAbI!1IPoP8PEw7iK ... 0uEI1p5cqs
Thanks!

P.S Extracted from 1.5.6 Verison for Android.

aluigi, posted Tue Nov 01, 2016 5:07 pm (18512)

---

Script 0.1.1:
http://aluigi.org/bms/jurassic_world.bms

Doprond, posted Tue Nov 01, 2016 8:33 pm (18513)

---

aluigi wrote:

Script 0.1.1:
http://aluigi.org/bms/jurassic_world.bms

Thanks a lot Luigi,work fine.
But after unpacking i get a lot of .dat,vap (and many others) files.Can you take a look?
https://mega.nz/#!jpQDjBII!oIZ0c13Q977N ... dxOmqcfrJk
Thanks!

aluigi, posted Wed Nov 02, 2016 12:27 pm (18518)

---

I can't help on the content of the files but maybe some other user will like to check them.

SickAlice, posted Sat Dec 31, 2016 12:52 am (19854)

---

Has anyone had any findings with the extracted .dat files for this? Please and thank you.

NickJun, posted Thu Nov 23, 2017 9:50 am (30226)

---

Luigi, seems script is doing something wrong.
I checked samples in this post and I see unpacked files are corrupted.
Can you fix this script?

Here is test pack that contains files in known format (pvr):
https://fex.net/#!222895451879

Thanks for your great work!

aluigi, posted Thu Nov 23, 2017 1:05 pm (30239)

---

Script 0.1.2, the problem was the different starting offset that depends by the version of the format (4:0x100, 6:0x30)

NickJun, posted Thu Nov 23, 2017 8:46 pm (30254)

---

aluigi wrote:

Script 0.1.2, the problem was the different starting offset that depends by the version of the format (4:0x100, 6:0x30)

Thanks a lot! Seems this format isn't simple. Pvrs unpacked fine but I tried to unpack another pack with tables and script did it wrong.
Can you check it?

https://fex.net/#!576218100605 (look to the end of 00000003.dat and the beginning of 00000004.ber)

aluigi, posted Thu Nov 23, 2017 10:13 pm (30258)

---

I have made another update but I'm not sure if it's 100% correct for all the archives.

NickJun, posted Thu Nov 23, 2017 10:54 pm (30260)

---

Yes. A new version works fine with all packages what I have.
Thank you very very much!

BSM, posted Fri Nov 24, 2017 3:39 am (30265)

---

I was bored and played a bit with the files you linked.
I can give you some tips to deal with some of the file contents, but first I should note that the way you are 'extracting' data maybe is not very helpful for that.
It seems the .dhr files are some kind of HeadeRs for the .dsb or .dab files, containing the needed info to extract data in a way that maybe you could find more handy.
I'm not used yet to QuickBMS, so what I can do is to explain here my findings, and maybe you will be able to make the rigtht .bms scripts.

All these 3 file formats (.hdr, .dsb, .dab) shares a common start of 12 bytes.

Code:

short Version (Little Endian)
short Version (Big Endian)
idstring "LPKG"
short Dummy (It varies from files, but mostly just a few different values seen in all files; the purpose is unknown for me)
short Dummy (It varies from files, but mostly just a few different values seen in all files; the purpose is unknown for me)

Then follows a block that usually starts with "HDR\0" for .hdr, "SDAT" for .dsb, or "ADAT" for .dab

Code:

idstring variable, being "HDR\0" for .hdr, "SDAT" for .dsb, or "ADAT" for .dab
long Dummy (surely a GUI, some kind of identifier for the data)
short Dummy
short Dummy
long Dummy (another GUI)
long SingleOrDoubleBlock (if 0, 16 bytes follows; if 0x10000000, 32 bytes follows; usually 32 bytes for .hdr and 16 for the others. 
long Dummy
long Dummy
long Dummy
long Dummy
if SingleOrDoubleBlock == 0x10000000
   long Dummy
   long Dummy
   long Dummy
   long Dummy
endif
These bytes contains some GUIs, and some of these are common between the .hdr and the corresponding .dsb

Then more data follows, and here is where maybe my findings could help.

Structure of the header in .hdr files

Code:

long HdrOffset
long HdrLength
long DataOffset1
long DataLength1
long DataOffset2
long DataLength2
long DataOffset3
long DataLength3
long   long   long   long -> 16 bytes GUI, also found the same values inside the counterpart
long   long   long   long -> always seen as zeroes
long CounterPartFileSize
long   long   long -> another 12 zeroes
long   long   long   long -> another 16 zeroes

Then data follows, as pointed by HdrOffset, HdrLength

Code:

long ChunksAmount
long Dummy (always seen as zeroes)
for i = 0 < ChunksAmount
   long Dummy (some Gui)
   long Dummy (some Gui)
   long Dummy (zeroes)
   long Dummy (zeroes)
   long CounterPartOffset[i]
   long CounterPartLength[i]
next i
End of Data, padded with zeroes until End of File if needed

If you extract the files inside the .dsb by using the offsets and lengths specified in the corresponding .hdr file, then maybe you can easier study the contents, as the format varies depending on the type of content.
For example, inside the "local_gamedata.dsb" you can find 12 files, each one with different content type, but all them related to strings (text), while inside the "logo.dsb" file you can find 35 images "PVR" (all them based on the same logo, but with different resolutions and maybe using different languages; in the first one I can read "Teenage Mutant Ninja Turtles" and "Legend" both in english and spanish, however the pixels are interlaced and I have not studied it much to convert to an usable format).

Some tips to deal with the texts.
It seems most tables uses a similar header structure, like the LPKG, but some of them contains header texts while other contains just headers. For example, the last file inside "local_gamedata.dsb" is just headers, but the previous block contains both headers and strings.
The structure for the headers of these files varies depending on the file type, but some of them (containing strings) uses a header structured simiar to the Table of Contents (the first chunk, usually starting at 0x00000030, but always pointed inside the .hdr) inside the "SDAT":

Code:

long TablesCount
for i = 0 < TablesCount
   long Dummy (some GUI)
   long ContentType
   long Offset (usually 0x00000010, so pointing to the next byte)
endif
long ContentChunksCount
for i = 0 < ContentChunksCount
   long Dummy (some GUI)
   long ContentType
   if ContentType < 4
      long Offset
   else
      long Dummy (some other kind of data
   endif
endif

Take note that all offsets are counted from the start of each chunk, not from the start of the LPKG. Also, all kind of data is padded to long, so a 3 chars null terminated string is 4 bytes, but a 4 chars null terminated string is 5 bytes but padded to 8 bytes.

I hope that helped a bit.

lpriefer01, posted Sat Mar 06, 2021 12:29 am (62708)

---

so is there actually a way to get these models from the apk or are we at a dead end

jwtg, posted Thu Dec 23, 2021 1:21 am (68437)

---

Thanks for providing this amazing tool.
I'm using the jurassicworld.bms script to do some extractions against these files
It seems to correctly extract a few PVR texture files but fail for all others. It generates many 8kb PVR files that I cannot open or preview(all-white empty image).
Is it possible to get the script updated after so many years? Thanks!

aluigi, posted Thu Jan 06, 2022 4:49 pm (68756)

---

The extracted content seem correct since it matches the size of the archive.
I can't help much on the content but I guess those many small files of less than 100 bytes are probably metadata or something similar, it happens when the file is a resource (collection of information and data) rather than an archive (collection of files).

jwtg, posted Thu Jan 13, 2022 11:25 pm (69066)

---

aluigi wrote:

The extracted content seem correct since it matches the size of the archive.
I can't help much on the content but I guess those many small files of less than 100 bytes are probably metadata or something similar, it happens when the file is a resource (collection of information and data) rather than an archive (collection of files).

Thank you for the reply!
Hundreds of 8kb PVR texture files were extracted, they look quite unusual. (Please see the attached screencast)
Can you please shed light on what's going on and how to proceed from here?

jwtg, posted Sat Apr 09, 2022 11:15 pm (70993)

---

Forget my question above. Those 8kb PVR texture files are valid, but compressed and can be decompressed using PVRTexTool. Those a few 200kb PVR files are there probably because the dev accidentally forgot to compress them.