This topic was archived here:

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

RetroHelix, posted Sun Jun 21, 2015 5:13 pm (5834)

---

Hi,

I tried to decompress a LZSS (LZ10) compressed file with QuickBMS and got the wrong output. Maybe I'm doing something wrong. Here is the script I used. The bytes 1 till 5 should be the size of the decompressed file (2997632 dec) and I use the the ASIZE - 5 as the compressed filesize.

Code:

comtype NitroSDK #or LZSS
goto 0x01
get SIZE long
set ZSIZE long 0
math ZSIZE = ASIZE - 5
clog test 5 ZSIZE SIZE

Here is the compressed and the decompressed file: https://mega.co.nz/#!DBI2zRiZ!y8RZWlYzK ... 5Exc1neMxI
I tried three tools and they get the output right: http://www.romhacking.net/utilities/826/, DSDecmp and Nintenlords Compressor. Only QuickBMS does not decompress it right.

Maybe I'm doing something wrong. Could you take a look please?

aluigi, posted Mon Jun 22, 2015 10:24 pm (5846)

---

Code:

comtype NitroSDK
get ZSIZE asize
goto 1
get SIZE long
clog test 0 ZSIZE SIZE

The Nitro SDK doesn't seem to have ways to reallocate the output buffer to that "goto 1; get SIZE long" is necessary.

RetroHelix, posted Wed Jun 24, 2015 4:59 pm (5895)

---

I don't get it all but it works this way. Thank you.

aluigi, posted Wed Jun 24, 2015 7:52 pm (5899)

---

Basically NitroSDK reads the first byte and then choose the relative compression algorithm so you have to decompresse the whole file from offset 0, but the uncompressed size is located at offset 1 and NitroSDK doesn't increase the output buffer if it's not big enough, so you have first to read this value to specify the correct output size.
Maybe in the next version of quickbms I can force the tool to read that 32bit automatically instead of doing the operation manually in the script.

aluigi, posted Thu Jun 25, 2015 9:31 pm (5922)

---

Ah, note that the nintendo compressions are handled also by other comtypes, for example lz77wii in which the allocation of the output is automatic.