reverse engineering the archive from Brutal legends

[Aidan729]

Hello everyone,

I'm new to the site, and thought I would turn to you, for some advice on where to go from the point I'm at now.
I'm not new to programming/reverse engineering of executable... and I am also not new to the concept of reverse
engineering Archives, I have done some simple things in the past. But I would still consider myself quite "newbie" at this concept,
This was a project i took on for myself and would appreciate any advice I can get.

First thing I did when I was inspecting the archive (which btw is the ps3 archive .~p which i believe just stores basic assets. textures, models, scripts, etc)
was look at the Compression, I have worked with zLib in the past so recognized the start of the file. (0x78, 0xDA)



so from there I created a simple tool to load files that have been compressed with zlib, and decompress them.
This is what the decompressed data looks like.



Now I know this was decompressed correctly (I hope) because I can recognize patterns. And here is where the issue lies.

I have no real idea of where to go from this point, What should i start looking for next ?

the goal of this was to compile a complete structure of this file, and publish my findings.

One last note, One of the other archives names was the exact same but the extension was ".~h"




and the data for the most part is readable, still I do not have any idea where to go from this point.

any advice / help would be very appreciated thanks for your time !

[aluigi]

Brutal Legend is not the most easy archive format for sure
As you can see from my old script http://aluigi.org/papers/bms/others/brutal_legend.bms there are various 24 bit fields (threebyte) in place of the most common 32bit ones, with the effect of requiring an alignment like the shift left 5 of the offset.
Very strange is the ZSIZE field (the compressed size) that requires to loose the first bit and even more strange is that "and 0x800000 ... - 0x800000" operation you can see at line 46.

In my opinion the format has been deliberately made "complex" by the developers because there are no advantages in these weird solutions they adopted.

Usually when you want to reverse engineer file formats that use the zlib compression, even if you don't know if it's used, a good starting point is running offzip -S -x on the archive to locate the offset/zsize/size fields that you can use to understand the structure of the index table containing the information of each file.
In some situations it really makes the difference.

[Aidan729]

Brutal Legend is not the most easy archive format for sure
As you can see from my old script http://aluigi.org/papers/bms/others/brutal_legend.bms there are various 24 bit fields (threebyte) in place of the most common 32bit ones, with the effect of requiring an alignment like the shift left 5 of the offset.
Very strange is the ZSIZE field (the compressed size) that requires to loose the first bit and even more strange is that "and 0x800000 ... - 0x800000" operation you can see at line 46.

In my opinion the format has been deliberately made "complex" by the developers because there are no advantages in these weird solutions they adopted.

Usually when you want to reverse engineer file formats that use the zlib compression, even if you don't know if it's used, a good starting point is running offzip -S -x on the archive to locate the offset/zsize/size fields that you can use to understand the structure of the index table containing the information of each file.
In some situations it really makes the difference.

Thank you very much ! this gives me somewhere to go. I appreciate the reply thank you!