This topic was archived here:

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

theunholyone, posted Tue Mar 30, 2021 2:37 pm (63135)

---

Hi, I was trying to decompress a Minecraft XBOX 360 Edition region file (which are compressed with xmem) and ran into an issue when using the Linux version of quickbms (I suppose it's also the case with Mac and non-XDK implementations on Windows).

The error is: the uncompressed data (-1) is bigger than the allocated buffer (164580)
It usually means that data is not compressed or uses another algorithm

On the Windows version (I used wine in my case) it outputs the file without problem.
The script is the following:

Code:

endian big
comtype xmemdecompress

get ZSize long
get Size long
math ZSize &= 0x7fffffff
clog result Offset ZSize Size

I have attached the problematic file, which to my understanding does not use native compression.
I'd appreciate any help although it seems the only solution would be to use the official XmemCompress API.

aluigi, posted Tue Mar 30, 2021 6:40 pm (63138)

---

Ah, that's simply because it was not available in quickbms for linux.
I added support for it in the beta of quickbms.
I plan to release the official new version next week

theunholyone, posted Tue Mar 30, 2021 10:42 pm (63140)

---

Thanks!
But I don't see any changes regarding xmemcompress in the latest 0.11.0 beta. As far as I'm concerned compression/unmspack.c is untouched and the logic in unz.c is still the same. I can't test if it works because I'm unable to compile the source code in the beta release.

Also shouldn't the error message then be "Error: XMemDecompress is implemented only on Windows"?

I'm looking forward to the release!

aluigi, posted Wed Mar 31, 2021 9:11 am (63147)

---

The update is in src/unz.c:

Code:

int unxmemlzx(u8 *in, int insz, u8 **ret_out, int *ret_outsz) {
#ifdef WIN32
    ...
#else
    return appDecompressLZX(in, insz, *ret_out, *ret_outsz);
#endif
}

theunholyone, posted Wed Mar 31, 2021 2:11 pm (63149)

---

Isn't that already on 0.10.1? I am able to decompress some files but not this one particularly.

aluigi, posted Wed Mar 31, 2021 3:23 pm (63150)

---

Ops correct, I forgot it was already available, I didn't understand that some files are ok and others fail.

So basically the code used in quickbms is exactly the same one also used in umodel and it's the standard code of libmspack (as written in the initial comment of the source file unmspack.c):

Code:

lzxd_init(&lzxSys, (void *)&src, (void *)&dst, 17, 0, 256*1024, UncompressedSize, 0);

It's quite simple but the function returns a MSPACK_ERR_DECRUNCH with that file.

I already tried to play with the window_bits and input_buffer_size arguments but the function fails every time.
Honestly I don't know what else to do but I'm open to suggestions.

theunholyone, posted Sun Apr 18, 2021 9:28 pm (63441)

---

At the time being I've managed to get a reduced file (55 bytes) that still trigger the issue. Maybe with this we could manually search for lzx blocks? I'm not sure but probably the compressor I used (not quickbms) just outputs uncompressed blocks.