Carved files are often equal in size to the original file

I have experienced this a couple times.

I will use binwalk to analyze a memory image or unknown data blob. When it carves files, the files are often close to the file from which they were carved in size, even if there are so many valid detections that is is simply not possible for all carved data to fit in the original file.

For example, I have a file – x that is 1.3 GB. x contains several contiguous zlib-compressed blobs. Binwalk will carve out that many _unextracted_ blobs, but all between 1.0 GB and 1.3 GB.

Unfortunately, I cannot share file x.

[E3V3A]

@CoffeeExpress Why was this issue closed? It doesn’t seem to have been fixed…

# mkdir testcarv
# cd testcarv/
# dd if=/dev/zero of=head bs=1 count=512
# dd if=/dev/zero of=junk bs=1 count=512000
# wget https://www.debian.org/logos/openlogo-100.jpg
# cat head openlogo-100.jpg junk > full
# ls -alh

-rw-rw-rw-+ 1 xxxx xxxx 509K Oct 19 08:20 full
-rw-rw-rw-+ 1 xxxx xxxx 512 Oct 19 08:19 head
-rw-rw-rw-+ 1 xxxx xxxx 500K Oct 19 08:19 junk
-rw-rw-rw-+ 1 xxxx xxxx 8.3K Jun  1 07:50 openlogo-100.jpg

# binwalk -z -C demo -D 'jpeg:jpg' full

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
512           0x200           JPEG image data, JFIF standard 1.02
1074          0x432           JPEG image data, JFIF standard 1.02

# ls -alhR demo/

-rw-rw-rw-+ 1 xxxx xxxx 509K Oct 19 08:20 200.jpg
-rw-rw-rw-+ 1 xxxx xxxx 508K Oct 19 08:20 432.jpg

[malaterre]

For anyone reading this, you need to use a recent p7zip implementation. binwalk expect the unzip implementation to read a file from the start, while some are reading file starting from the end. Leading to odd behavior. See for more info here.