Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

how to determine the end of gzipped image

RCE of Linux tools and programs.
Locked
dion
Member
Posts: 61
Joined: Tue Jul 31, 2007 8:38 am

how to determine the end of gzipped image

Post by dion »

hello,

i've a difficulty in finding the end of gzipped image binary. it was a compressed linux kernel (i knew because it took random size, and unpack it though it showed an error). i knew that the crc and isize are supposed to placed in the end. but how do you know if it was it?

i was trying to read about how the crc calculated, i mean from where to where, but, i don't really get it after reading the gzip source code.

the image itself was placed in middle of another binary, which i'm not sure what it is yet. i tried with the longest size before another obvious border (another compressed image), but still can't get a good result.

regards
naides
Posts: 1655
Joined: Sat Jan 12, 2002 12:00 pm
Location: Planet Earth

Post by naides »

Look at here:

http://www.gzip.org/zlib/rfc-gzip.html

My guess is that the next compressed file header, which is easily recognizable by the magic number structure 0x1f,0x8b sits right after the previous compressed file end. Also with the structure of the footer in mind (8 bytes, 4 for the CRC 32, next 4 for the size of the compressed payload) you could code a small heuristic program that scans the file:

while not eof{
read 4 byte integer;
if integer == distance from previous header (+/- 4 byte cushion)
then found;
else
file_ pointer ++;
}
dion
Member
Posts: 61
Joined: Tue Jul 31, 2007 8:38 am

Post by dion »

nope.

i think there is a bit wrong with your code.

about the CRC and ISIZE, it's right placed in the end/footer.
but ISIZE is not the size of the image itself (which is compressed). it is the size of the image that has been uncompressed/input size hence named isize.

updated: i figured out that the crc is also, a whole uncompressed image crc.

about the border, i had tried that to block all the way until the next compressed, but gzip unpack give err and produce just 1kb which is bad. (the other one i tried that also give error but produced 1MB, give good result as i see many recognized strings all over).
Locked