ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Fri Jan 19, 2018 1:51 pm

All times are UTC




Post new topic  Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Mon Oct 31, 2016 7:42 pm 

Joined: Tue Mar 15, 2016 3:38 pm
Posts: 67
Samples here:
https://mega.nz/#!joh3VAbI!1IPoP8PEw7iK ... 0uEI1p5cqs
Thanks!

P.S Extracted from 1.5.6 Verison for Android.


Top
   
PostPosted: Tue Nov 01, 2016 5:07 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7447
Script 0.1.1:
http://aluigi.org/bms/jurassic_world.bms


Top
   
PostPosted: Tue Nov 01, 2016 8:33 pm 

Joined: Tue Mar 15, 2016 3:38 pm
Posts: 67
aluigi wrote:

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!


Top
   
PostPosted: Wed Nov 02, 2016 12:27 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7447
I can't help on the content of the files but maybe some other user will like to check them.


Top
   
PostPosted: Sat Dec 31, 2016 12:52 am 

Joined: Mon Oct 24, 2016 3:23 am
Posts: 15
Has anyone had any findings with the extracted .dat files for this? Please and thank you.


Top
   
PostPosted: Thu Nov 23, 2017 9:50 am 

Joined: Thu Nov 23, 2017 9:38 am
Posts: 3
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!


Top
   
PostPosted: Thu Nov 23, 2017 1:05 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7447
Script 0.1.2, the problem was the different starting offset that depends by the version of the format (4:0x100, 6:0x30)


Top
   
PostPosted: Thu Nov 23, 2017 8:46 pm 

Joined: Thu Nov 23, 2017 9:38 am
Posts: 3
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)


Top
   
PostPosted: Thu Nov 23, 2017 10:13 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7447
I have made another update but I'm not sure if it's 100% correct for all the archives.


Top
   
PostPosted: Thu Nov 23, 2017 10:54 pm 

Joined: Thu Nov 23, 2017 9:38 am
Posts: 3
Yes. A new version works fine with all packages what I have.
Thank you very very much!


Top
   
PostPosted: Fri Nov 24, 2017 3:39 am 

Joined: Thu Nov 23, 2017 12:30 am
Posts: 23
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.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 11 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited