This topic was archived here:

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

Anexenaumoon, posted Wed Mar 15, 2017 1:46 am (21468)

---

Hey! So, I'm not a total noob in writing and reversing archives at this point, but this little portion's been stumping me.

Here's the code what I have right now for the archive:

Code:

get NULL long
get FCOUNT long
get NULL long

for i = 0 
get FNAMELENGTH long
getdstring NAME FNAMELENGTH
callfunction skip
get OFFSET long
get SIZE long
get NULL long
log NAME OFFSET SIZE


next i

startfunction SKIP
   do
    get NULL byte
    while NULL == 0
    savepos CUROFF
    math CUROFF - 1
    goto CUROFF
endfunction

The issue is though, that the skip function throws a script error, and that's due to the incorrect positioning of the current offset going backwards when a 0 value is included in the offset long value. I can't figure out a workaround, and could use some help if anyone could help me . I've included a filecutted version of the table as that's the information that's important. the location of the offset changes a certain number of bytes after the name string. Thanks for the help in advance!
~Anexenaumoon

aluigi, posted Wed Mar 15, 2017 2:18 pm (21479)

---

It's just padded/aligned data, so you have to replace "callfunction skip" with "padding 4"

aluigi, posted Wed Mar 15, 2017 2:20 pm (21480)

---

Ah, FYI, the third field is probably the compressed size:

Code:

get ZERO long
get FILES long
get ZERO long
for i = 0 < FILES
    get NAMESZ long
    getdstring NAME NAMESZ
    padding 4
    get OFFSET long
    get SIZE long
    get ZSIZE long
    if ZSIZE == 0
        log NAME OFFSET SIZE
    else
        clog NAME OFFSET ZSIZE SIZE
    endif
next i

Anexenaumoon, posted Wed Mar 15, 2017 9:19 pm (21495)

---

Oh, haha, didn't know about padding . Silly me, thanks as always aluigi! Turns out, it's not a compressed size, it throws an error. But, it's no issue it seems :p

Anexenaumoon, posted Wed Mar 15, 2017 9:34 pm (21496)

---

Sorry for the double post, the script breaks around towards the backend, and I have no clue why. Could it be that the padding changes? If you could, can you take a look at these sets of entries? I don't know if it would help, I've been trying to crack at this thing for ages and really appreciate the help. Thanks again!

aluigi, posted Thu Mar 16, 2017 6:15 am (21513)

---

What's the exact error you get?
The format is correct.

Anexenaumoon, posted Thu Mar 16, 2017 9:20 pm (21543)

---

This is the error I get when I run the script:

Code:

 offset   filesize   filename
--------------------------------------
  000d4000 212        ANIMATION\2D\COSTUME_OUTLINE_FLASHER.DAT

Error: the compressed zlib/deflate input is wrong or incomplete (-3)
Info:  algorithm   1
       offset      000d4000
       input size  0x0000003b 59
       output size 0x000000d4 212
       result      0xffffffff -1

Error: the uncompressed data (-1) is bigger than the allocated buffer (212)

Last script line before the error or that produced the error:
  14  clog NAME OFFSET ZSIZE SIZE

Could it be maybe that it's a different comtype?

aluigi, posted Fri Mar 17, 2017 8:14 am (21551)

---

Upload that archive.

Anexenaumoon, posted Fri Mar 17, 2017 7:36 pm (21576)

---

It's 1.8 gb, but here it is I appreciate it:

https://mega.nz/#!9ssVDA4Q!g2F0npejdhRf ... KFXRrD-6Bo

aluigi, posted Fri Mar 17, 2017 7:47 pm (21577)

---

Use this script and upload the first file it generates (the one with "_0_" in the filename):
http://aluigi.org/bms/filecutter.bms

Anexenaumoon, posted Fri Mar 17, 2017 8:16 pm (21578)

---

Here we go!:
Filecutted
https://mega.nz/#!x5lR2DwL!u3b8E7dxOPH4 ... ryYxo3wZNo

aluigi, posted Fri Mar 17, 2017 8:43 pm (21580)

---

ok the compression algorithm is lzss0:
http://aluigi.org/bms/american_idol.bms

Anexenaumoon, posted Fri Mar 17, 2017 9:08 pm (21582)

---

works like a charm, thanks for the help! How'd you go about knowing it was lzss0? I'm interested to see if you don't mind .

aluigi, posted Sat Mar 18, 2017 8:52 am (21592)

---

Usually it works in this way, first you have to locate a file that is made with a known format or contains text strings, the VMS files were the good option.
Then you can try to recognize the format of the compressed file with some experience (take a look here) or you can opt for the comtype_scan2 solution.
If lzss works but you see a lot of 0x20 bytes with the hex editor in the decompressed file, then it's probably lzss0

Anexenaumoon, posted Sat Mar 18, 2017 6:33 pm (21610)

---

Ah, that makes sense. Thanks a bunch for the help.