Skip to content
View in the app

A better way to browse. Learn more.

ResHax

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.
Help us keep the site running.

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

Featured Replies

  • Author
  • Localization

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.
  • Author
  • Localization

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.
  • Author
  • Localization

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!
  • Author
  • Localization

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)
  • Author
  • Localization

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)
  • Author
  • Localization

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.
  • Author
  • Localization

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!
  • Author
  • Localization

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.
  • Author
  • Localization

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
  • Author
  • Localization

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!
  • Author
  • Localization

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).
  • Author
  • Localization

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?
  • Author
  • Localization

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.
Guest
This topic is now closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.