neo2271 / firmware-mod-kit

Automatically exported from code.google.com/p/firmware-mod-kit
0 stars 0 forks source link

Firmwares larger than original due to squashfs-lzma not being detected by Binwalk #103

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Due to a failure to detect some or all squashfs-lzma filesystems as using LZMA, 
squashfs-gzip ends up being used. This causes rebuilt firmwares to be 
substantially larger than their squashfs-lzma counterparts.

Binwalk issue:
https://code.google.com/p/binwalk/issues/detail?id=57

Original issue reported on code.google.com by jeremy.collake@gmail.com on 10 Jun 2013 at 3:35

GoogleCodeExporter commented 8 years ago
It sounds like there is also a bug in the FMK scripts too, as this should never 
happen. The extract script saves off the unsquashfs version (to include 
compression type) that was used to extract the squashfs image, and this is used 
by the rebuild script to re-build the image; the rebuild script never sees the 
binwalk output. This is out of necessity, as on most versions of squashfs 
(i.e., anything prior to squashfs 4.0) there is no way to reliably determine 
which compression type was used (except for trial and error). Further, some 
vendors swap the compression definitions in the squashfs headers (they report 
gzip when they really used lzma and vice versa).

So if the scripts were able to extract the image, they should be able to 
rebuild. Of course, I'm sure there's a bug in my code somewhere that's 
preventing this... :\

Original comment by heffne...@gmail.com on 10 Jun 2013 at 7:17

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I see what you mean now with unsquashfs-all! Fixing all this up now.

Original comment by jeremy.collake@gmail.com on 11 Jun 2013 at 7:47

GoogleCodeExporter commented 8 years ago
It appears for squashFS versions 4.x, where the compression type can be 
specified via -comp to mksquashfs, the failure to save the compression type in 
FS_TYPE causes it to use gzip instead of lzma. Older squashfs versions aren't 
affected, as unsquashfs-all properly detects the squashfs lzma variant.

Further, the -comp switch isn't being properly applied to all mksquashfs 
versions.

All fixing in the next commit (trying to make a single one this time ;p)

Original comment by jeremy.collake@gmail.com on 11 Jun 2013 at 8:02

GoogleCodeExporter commented 8 years ago
I mean FS_COMPRESSION not FS_TYPE .. all fixed now.

Original comment by jeremy.collake@gmail.com on 11 Jun 2013 at 8:07

GoogleCodeExporter commented 8 years ago
This issue was closed by revision d20640c26dbf.

Original comment by jeremy.collake@gmail.com on 11 Jun 2013 at 8:08