This topic was archived here:

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

GHANMI, posted Wed Aug 07, 2019 8:39 am (50188)

---

Hi and hopefully this isn't too much trouble for everyone looking at this.
I'm not very well experienced at this, and solved some issues with other games before by looking up raw graphical data in tile editors, or hex editors, but wish to learn more about how to deal with completely unknown formats.

The game is Monster Boy in Cursed Kingdom, Steam version.
It heavily makes use of packs. I want to figure out their format, or get help about that (tools would be welcome, but even tips and the know-how)

https://mega.nz/#F!Cpt2EarQ!7r_D1t1dPEMLiAyQN3inOQ


1. Other PACK files
Added two examples under "other pack samples".
They come as:
[*]PACK3.S (smaller version, probably has indexes for the bigger one but its internal structure is too confusing)
[*]PACK3.T (bigger version, probably is the assets, but compressed as compressing it further with 7zip gives no size change)
[*]LQ/PACK3.T (bigger version but with a slightly smaller size, may be for the low quality setting)
[*]PACKS (for once, has somewhat clearer 4 byte headers, but then is encrypted/scrambled just like the rest)
[*]PACK5.SP and PACK104.M (come in addition to the .S file, with a similar size)


2. The FONT_PACK files
They come as single files with no extension. I'm interested in those.

My observations:
- They don't compress well. That means they're already compressed somehow. Tried giving it to 7Zip to decompress with no avail.
- They should contain fonts, but the raw graphical data has nothing much.
- Game has a dll named GAFramework64, in addition to other dlls for video / audio decoding (the game has video/opus files that are broken on MPC)

Any help about that? Thanks a lot.

aluigi, posted Mon Sep 30, 2019 6:15 am (51163)

---

Definitely compressed but I have no clear idea about what algorithm it is.
Can't scan the algorithm because there is no decompressed size, I guess it's the big endian 32bit after the first 0x82.
Anyway this is the idea of script lacking the decompression algorithm as a work-in-progress for the future:

Code:

comtype ???
get FILES short
get DUMMY long
for i = 0 <= FILES  # includes the limit
    get OFFSET long
    putarray 0 i OFFSET
next i
for i = 0 < FILES
    getarray OFFSET 0 i
    math i   1
    getarray SIZE   0 i
    math SIZE - OFFSET
    clog "" OFFSET SIZE SIZE
next