Dissidia Final Fantasy

[Gyproc]

Hello there!

Some members of a community and I would like to request some help in data-mining (or reverse-engineering) an Dissidia Final Fantasy Opera Omnia. So far we managed to reach a point where we need to unpack a .g1m.dz file, unfortunately Dzip cannot unpack this so we would like to know which program is able to unpack this. Thanks in advance!

P.S.: I don't know if this is the right place to post this, I apologize.

[aluigi]

Upload the file

[Gyproc]

https://mega.nz/#!mEx1XDgA!4Y7WHB4BRMTCD2-zd1JjNYIEQMuObjIwGVPFJTuL96A

[asuna222]

Thanks in advance for taking a look at the file Aluigi, I tried TRID to associate the filetype through command prompt and it doesn't seem right.

https://imgur.com/a/HNYql

[aluigi]

Do you have also a bigger dz file?
Like about one megabyte.

Because I "suspect" that the format may change based on the size of the file (splitted in chunks).

[aluigi]

Problem solved, I was right
Script 0.1.1:
http://aluigi.org/bms/dissidia.bms

[Gyproc]

Thank you so much!

We were able able to make a step further : ) But now we are facing 2 dilemmas, we do not know how to open the g1m file inside it and we need the tool to convert the g1t file to png, if you could help us again we will be so grateful! I will attach the link to both files.
https://mega.nz/#F!a81jjbLL!v7A77CygjpsA-9jNTeGXdw

[aluigi]

For g1t files search the following on google: "GT1G0600"
Or just go here http://forum.xentax.com/viewtopic.php?p=123534#p123534
Acewell is an user of zenhax too

While for the BIN files I have update my script to version 0.1.2 since they are just archives and their files can be extracted easily.

[Rem]

Thanks for adding the bin archive extraction!

Could we bother you with one more request?
I've found another type of bin file which I've struggled to find any clues to its nature.

Comparing two different files got me what might be the full header but that's as far I got.

Code: Select all

58 4C 13 00

My poor knowledge is telling me that the remaining hex numbers next to the header might be the size or the type of the file?
Since I found another file with same filename prefix as a json file, there's a probability that it is a json file too.

Could I please have your input on that file?

[aluigi]

I don't know what's that file.

[Rem]

Alright. Thanks for your help so far!

[Rem]

Hello everyone,

I came across a few files that couldn't be decoded with the current DZ BMS script and was hoping to get help again.

This time, I spent a bit of time to figure out what was going wrong and there don't seem to be any big changes to the compression method used. There's only a small change to the files that couldn't be decoded:

The last few bytes of data don't have a recognizable chunk like the rest of the file, which breaks the script when it's about to handle the last chunk. Thus, it fails to produce a fully readable file.

I'm including two sample here, one is the same type of file that can still be decoded with the script, while the other cannot.

Thanks for the help!

[aluigi]

Script 0.1.3:
http://aluigi.org/bms/dissidia.bms

Basically the last chunk wasn't compressed, there is no flag telling that so I had to compare the expected chunk zsize with the one read from the chunk itself

[Rem]

Thanks for the quick update!

[Rem]

There seem to be an issue with the script, it's not decoding the files.
Isn't only the last chunk that is not compressed, so the earlier chunks should be getting decompressed, but it's not happening.

The result is the same file as the input.

[aluigi]

You are right, script 0.1.4

[Rem]

Thanks, it's working great!