Finally I can replicate the issue with the archive and I confirm what I wrote few posts above:
Quote:
- lz4 requires that the specified compressed/uncompressed size perfectly match the available data
Now the technical explanation:
quickbms uses the following code for performing the decompression:
Code:
size = LZ4_decompress_safe_partial(in, out, zsize, size, *outsize);
where size is the expected decompressed size (for example 0x4189 in your case) while *outsize is the size of the output buffer that can be any number bigger than size (for example 0x41ad).
lz4 doesn't have a termination bit so it continues to extract data till the result is:
Code:
targetOutputSize >= result < dstCapacity
Code:
/*!
LZ4_decompress_safe_partial() :
This function decompress a compressed block of size 'srcSize' at position 'src'
into destination buffer 'dst' of size 'dstCapacity'.
The function will decompress a minimum of 'targetOutputSize' bytes, and stop after that.
However, it's not accurate, and may write more than 'targetOutputSize' (but always <= dstCapacity).
@return : the number of bytes decoded in the destination buffer (necessarily <= dstCapacity)
Note : this number can also be < targetOutputSize, if compressed block contains less data.
Therefore, always control how many bytes were decoded.
If source stream is detected malformed, function returns a negative result.
This function is protected against malicious data packets.
*/
LZ4LIB_API int LZ4_decompress_safe_partial (const char* src, char* dst, int srcSize, int targetOutputSize, int dstCapacity);
Your reimported file DOES NOT have the matching compressed size 0xa97, it has something smaller like 0xa8d but still lz4 will decompress bytes which means also all the padded data between 0xa97 and 0xa8d till the dstCapacity is full.
That's why you see the zeroes in your reextracted file.
quickbms is perfectly correct in what it does, indeed your game isn't able to load the edited file due to the unmatching compressed size.
End of the technical explanation.