TMNT: Legends (2016) .dab,dsb,dhr

[Doprond]

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

P.S Extracted from 1.5.6 Verison for Android.

[aluigi]

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

[Doprond]

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]

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

[SickAlice]

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

[NickJun]

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]

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

[NickJun]

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]

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

[NickJun]

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

[BSM]

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: Select all

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: Select all

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: Select all

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: Select all

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: Select all

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]

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

[jwtg]

Thanks for providing this amazing tool.
I'm using the jurassicworld.bms script to do some extractions against these files

jwtg_dinoportraits.zip

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]

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]

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]

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.