[help] gzipped .tabb file from DHBM

[xixeworoj]

Hello,

I've been trying to get content of a few data files from Disney Heroes: Battle Mode. I found this forum by googling internet for anyone who could face a similar issue and I found this thread viewtopic.php?f=9&t=8588 I was not able to contact the author nor proceed further and I doubt that the author was successful.

About the problem:

The game has several data files in a plaintext tab format. From a certain version a game developer gzipped a few important files which I'm trying to read. I know that those files are a gzip and I was even able to partially gunzip one with a message about "trailing garbage". The output was not clean plain text but it looked as a corrupted half binary, half plaintext file.

I attached both files (plaintext original and a new gzipped version). I'm not a compression expert so I tried decompressing this file in different languages (c++, java) or with different programs in a hope that something does an additional step - no luck, always trailing garbage warning. I re-compiled game source code to add a few logs and there seems to be no additional conversion step. From a game code standpoint, everything ends up at java InputStream and ByteBuffer with this exact file. There are also various checks that file is really valid but I was not lucky enough to modify smali code to get the content of these gzipped files.

Would anyone happen to have a tip what additional step I should take to get a clean plaintext file?

[aluigi]

This script for quickbms decompresses the tabb file and parses its content:
http://aluigi.org/bms/disney_heroes_tabb.bms

You can't reimport the edited strings in case you want to mod it (it would be possible but requires more steps).

[xixeworoj]

Thank you for giving it a shot but I'm not able to produce a clean output visible in unit_abilities.tab when I run your script on unit_abilities.tabb. I'm getting the exact output which I get by running gunzip shell in terminal and then removing all unreadable characters:

Code: Select all

gunzip -c unit_abilities.tabb > unit_abilities.tab

The problem is that output is messed up, some text is missing and for a different *.tabb file it will fail completely with zero readable content. For example, this is an error message from a different https://www.dropbox.com/s/6p82id8mhmmyhe1/friendship_campaign.tabb?dl=1 file that will not produce any readable output:


This is a head of friendship_campaign.tabb file in hex:

[aluigi]

It's not a fault of the script, the format is different in this file.

unit_abilities.tabb:

Code: Select all

  b5 7a 75 00 b1 02 00 00 01 01 01 01 01 01 01 01   .zu.............
  01 01 01 02 02 02 02 03 03 03 03 03 03 03 03 03   ................

friendship_campaign.tabb:

Code: Select all

  b5 7a 75 00 03 00 00 00 a8 0c 00 00 01 01 01 01   .zu.............
  01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01   ................

[xixeworoj]

What could game dev do with the file content to make it impossible to cleanly gunzip?

[wilc0]

This script for quickbms decompresses the tabb file and parses its content:
http://aluigi.org/bms/disney_heroes_tabb.bms

hi aluigi, i’ve been trying to solve the .tabb issue for a couple of days now. it seems the .bms file you have is producing inaccurate output when the (before compression) approach by perblue versus compressed format now for the unit_abilities.tabb file. I am curious if you know of a simple way to identify if the gunzipped .tabb file is in some particular binary format i could import or if there is an encryption applied to it to jumble up the table of data. at first I thought it was an excel output but now I’m not so sure.

your thoughts?

you’ll note in the example data file above, the problem is presented wuite well. the unzipped output of the .tabb file should looke similar to the .tab file but does not.

[aluigi]

Unfortunately I didn't continue to work on this but I trust the analysis I did weeks ago, so I have no other ideas.

[wilc0]

thanks. I'll take a look and see if there might be another approach. It seems the information should be rendered into four columns, yet only two seem to be happening and not as columns but rather as separate sections, which makes it challenging to rebuild into a simple text file.