Author
|
Topic: Extracting GBA LZSS compressed data without uncompressing it. is it possible? (Read 2 times)
|
Solid One
Guest
|
 |
« on: January 21, 2008, 12:09:07 pm » |
|
Well, I have a GBA game which most graphics are compressed in LZ77 (SS). I can easily offsets of compressed data, and then uncompress it using programs like GBADecomp, GBAmdc, GBACrusher, unLZ-GBA or GByeBye. piece of cake.
with most of those programs, it's possible to recompress and reinsert data too. and then, editing GBA compressed graphics in LZ is a very easy task to do.
I've read in a topic about GByeBye, that all LZSS compressed data begins with a header. it's a set of 4 bytes, where the first one have value $10, and the other three bytes specifies the size of uncompressed data. that header is essential for extraction/insertion, I suppose.
my question is: Anyone know a way to extract those LZ data WITHOUT uncompressing it? Put another way, I just need to know the original size of these compressed data. It probably'll be useful if there's a way to do it.
|
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #1 on: January 21, 2008, 02:21:28 pm » |
|
I'm no expert on LZ, but I recently had to decompress it to get a peek at some GSF (gameboy advance music) files. Even if you had a stored size of the decompressed data, it wouldn't be guaranteed that the buffer you decompress it to would be large enough (maybe the size was written down wrong). I was doing my work haphazardly, so I just made a buffer that was far larger than I would ever need (something like 32 megabytes for a 16 megabyte file). However, if you look at most LZ libraries, they give you examples on how to code with dynamic memory allocation so that you won't have to worry about running out of space in your allocated buffer.
|
|
|
|
« Last Edit: January 21, 2008, 04:14:03 pm by MathOnNapkins »
|
|
|
|
Parasyte
Guest
|
|
« Reply #2 on: January 21, 2008, 03:24:09 pm » |
|
The method I typically use to retrieve the size of uncompressed data is running a "mock" decompress algorithm over the data. Instead of outputting any data, the algorithm simply records the number of bytes which would be output.
And yes, I agree with MON: Do not trust a header to tell you the size of a buffer that you will need. That's how buffer overflow security holes are introduced into modern software.
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #3 on: January 21, 2008, 05:06:22 pm » |
|
You don't need to uncompress them directly. However, there is no "end" signal in the Lz-"Stream", so you'll have to count up the uncompressed bytes (the bytes you would get if you uncompressed the data) and then do until that is either equal or greater as the size specified in the header
cYa,
Tauwasser
|
|
|
|
|
|
RHDN Forum Archive
