ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Tue Apr 20, 2021 5:45 pm

All times are UTC




Post new topic  Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Tue Mar 30, 2021 2:37 pm 

Joined: Fri Mar 19, 2021 6:47 pm
Posts: 4
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.
:)


Attachments:
compressed_chunk.dat [1.29 KiB]
Downloaded 9 times
Top
   
PostPosted: Tue Mar 30, 2021 6:40 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 12096
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 ;)


Top
   
PostPosted: Tue Mar 30, 2021 10:42 pm 

Joined: Fri Mar 19, 2021 6:47 pm
Posts: 4
Thanks! :D
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! :)


Top
   
PostPosted: Wed Mar 31, 2021 9:11 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 12096
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
}


Top
   
PostPosted: Wed Mar 31, 2021 2:11 pm 

Joined: Fri Mar 19, 2021 6:47 pm
Posts: 4
Isn't that already on 0.10.1? I am able to decompress some files but not this one particularly.


Top
   
PostPosted: Wed Mar 31, 2021 3:23 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 12096
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.


Top
   
PostPosted: Sun Apr 18, 2021 9:28 pm 

Joined: Fri Mar 19, 2021 6:47 pm
Posts: 4
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.


Attachments:
compressed.dat [55 Bytes]
Downloaded 1 time
Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 7 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited