This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=7214

Gyproc, posted Sun Jan 14, 2018 10:56 am (31527)

---

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, posted Sun Jan 14, 2018 11:07 am (31528)

---

Upload the file

Gyproc, posted Sun Jan 14, 2018 11:11 am (31529)

---

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

asuna222, posted Sun Jan 14, 2018 11:14 am (31530)

---

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, posted Sun Jan 14, 2018 3:57 pm (31534)

---

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, posted Sun Jan 14, 2018 5:56 pm (31537)

---

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

Gyproc, posted Sun Jan 14, 2018 8:16 pm (31542)

---

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, posted Sun Jan 14, 2018 8:24 pm (31543)

---

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, posted Mon Jan 15, 2018 1:32 am (31548)

---

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:

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, posted Mon Jan 15, 2018 8:57 am (31551)

---

I don't know what's that file.

Rem, posted Mon Jan 15, 2018 12:23 pm (31562)

---

Alright. Thanks for your help so far!

Rem, posted Mon Oct 29, 2018 9:52 am (39948)

---

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, posted Mon Oct 29, 2018 3:15 pm (39955)

---

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, posted Tue Oct 30, 2018 9:50 am (39973)

---

Thanks for the quick update!

Rem, posted Tue Oct 30, 2018 9:27 pm (39980)

---

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, posted Wed Oct 31, 2018 7:57 am (39986)

---

You are right, script 0.1.4

Rem, posted Thu Nov 01, 2018 3:33 pm (40027)

---

Thanks, it's working great!