LZSS wrong implementation in QuickBMS?

[RetroHelix]

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: Select all

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]

Code: Select all

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]

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

[aluigi]

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]

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