This topic was archived here:

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

BCGhost, posted Sat Dec 16, 2017 5:37 am (30792)

---

Hi everyone!

I've encountered some unknown compression algorithms when dealing with files from Ben 10 Alien Force: The Rise of Hex Xbox Live Arcade/WiiWare.
At first I was just working on the WiiWare's .wad file using ShowMiiWads to extract and decompress the U8 & LZ77-compressed data, but the results didn't seem decompressed correctly.

I thought it was the tool I used that got wrong so I switch to the XBLA version and used wxPirs for unpacking which however gave me similar results as the WiiWare version.(correct me if I did it wrong)

I guess they need further decompression but I had no luck verifying the algorithm.

Here're some samples from the XBLA version:

The .xpf files which should contain models all share a same 0x1B-byte-long header. However from the not-compressed file catalog.cat we can learn that the first compressed string is actually "E.n.g.i.n.e"
followed by "G.a.m.e.P.r.o.p.s", and "BA DB EE F1" might just be the magic number. So the data is supposed to be compressed from at least before 0ffset 0xA.

Code:

ben.xpf(compressed)
 
FF BA DB EE F1 02 00 06 00 7F 45 00 6E 00 67 00    ..........E.n.g.
69 90 00 DF 65 00 00 00 1B 30 01 0E 00 7F 09 00    i...e....0......
47 00 61 00 6D 10 01 FF 50 00 72 00 6F 00 70 00    G.a.m...P.r.o.p.
F5 73 30 01 02 30 01 49 00 E9 00 7F 08 00 4F 00    .s0..0.I......O.

Code:

catalog.cat(not compressed)

BA DB EE F1 00 00 00 00  00 00 00 00 00 00 00 7D   ...............}
00 0E 00 62 00 74 00 61  00 66 00 5F 00 66 00 61   ...b.t.a.f._.f.a
00 64 00 65 00 72 00 2E  00 67 00 66 00 78 02 00   .d.e.r...g.f.x..
06 00 45 00 6E 00 67 00  69 00 6E 00 65 00 00 00   ..E.n.g.i.n.e...
1A 00 00 00 03 00 09 00  47 00 61 00 6D 00 65 00   ........G.a.m.e.
50 00 72 00 6F 00 70 00  73 00 00 00 02 00 00 00   P.r.o.p.s.......

I'd tried aluigi's comtype scanner on every possible start offset of the data, from zero to 0xA but still no progress.

Any help will be greatly appreciated!

BCGhost, posted Tue Dec 19, 2017 3:10 pm (30890)

---

Reuploaded samples.

BCGhost, posted Thu Dec 28, 2017 11:00 am (31079)

---

Looks like the data is compressed since offset 0, and by decompressing with LBALZSS2 / LBALZSS2X compression,
the second string is decompressed correctly, the only one though.

This is the best result that I got, which shows some extra info(the character name "BigChill") that help determine whether the data make sense:



And I also found some bytes that seem to be face indicies in the output, but unfortunately only limited to this file. Is it possible that the
raw data is encrypted after being compressed, but still contain a few recognizable bytes? Or does the output results need further decompression?

Here I attached the orignal file hoping somebody gets some clue about it.

aluigi, posted Sat Dec 30, 2017 6:04 pm (31131)

---

Have you already tried to post on https://encode.ru/forums/2-Data-Compression ?
They already solved some unknown algorithms in the past.

BCGhost, posted Sun Dec 31, 2017 3:07 pm (31146)

---

aluigi wrote:

Have you already tried to post on https://encode.ru/forums/2-Data-Compression ?
They already solved some unknown algorithms in the past.

Finally got a reply after so many days! I really appreciate it.

Gotta look around that site before I start a new post. Thank you very much aluigi!