sofent / firmware-mod-kit

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

Use installed version of binwalk instead of outdated packed ones. #98

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
firmware-mod-kit is using packed and outdated versions of binwalk.
I personally think it is better to use binwalk as a dependency and delete the 
unused files in src/binwalk*.

Here is a patch for working with the installed version of binwalk.

diff --git a/shared-ng.inc b/shared-ng.inc
index c059dd4..80bc6f0 100644
--- a/shared-ng.inc
+++ b/shared-ng.inc
@@ -8,4 +8,4 @@ FSIMG="$IMAGE_PARTS/rootfs.img"
 HEADER_IMAGE="$IMAGE_PARTS/header.img"
 FOOTER_IMAGE="$IMAGE_PARTS/footer.img"
 FWOUT="$DIR/new-firmware.bin"
-BINWALK="./src/binwalk-1.0/src/bin/binwalk-script -v -m 
./src/binwalk-1.0/src/binwalk/magic/binwalk"
+BINWALK="binwalk -v"
diff --git a/unsquashfs_all.sh b/unsquashfs_all.sh
index 08bf2d7..8694442 100755
--- a/unsquashfs_all.sh
+++ b/unsquashfs_all.sh
@@ -82,7 +82,7 @@ DIR=$(readlink -f $DIR)
 cd $(dirname $(readlink -f $0))

 DEST="-dest $DIR"
-MAJOR=$(./src/binwalk -m ./src/binwalk-*/src/magic.binwalk -l 1 "$IMG" | head 
-4 | tail -1 | sed -e 's/.*version //' | cut -d'.' -f1)
+MAJOR=$(binwalk -l 1 "$IMG" | head -4 | tail -1 | sed -e 's/.*version //' | 
cut -d'.' -f1)

 echo -e "Attempting to extract SquashFS $MAJOR.X file system...\n"

Original issue reported on code.google.com by antoniov...@gmail.com on 30 May 2013 at 1:25

GoogleCodeExporter commented 9 years ago
Craig Heffner maintains both the Binwalk project and its integration into the 
Firmware Mod Kit. I would be inclined to believe that this is a reasonable 
idea, despite theoretical concerns over interoperability, but should be 
provided only as an option. I will take a look into it adding such an option if 
I get a chance.

One thing to note is that it doesn't matter much. The FMK can only rebuild 
*some* file systems, and it's unlikely that any recent changes to Binwalk would 
be advantageous, though they may, and may in the future, particularly when it 
comes to identification and extraction.

Original comment by jeremy.collake@gmail.com on 30 May 2013 at 11:45

GoogleCodeExporter commented 9 years ago
I'm inclined to agree with Jeremy that using a more recent binwalk wouldn't do 
much for FMK. If you look at the extraction script that invokes binwalk, it 
only cares about squashfs and cramfs signatures, which have not changed in 
binwalk for some time. Yes, others could be added in the future (especially WRT 
squashfs), but if they change in binwalk they would probably change in FMK too 
since I would be the one making the changes. :) The main advantages for this 
are that it is one fewer required dependency for end users, and we can be sure 
that there aren't any changes in binwalk's output that would break the extract 
script (admittedly this is unlikely).

With that said, I think that using the installed version of binwalk if it 
exists and falling back to the one in src/ would be acceptable.

Really, we need to replace all the code in the extract script that deals with 
parsing binwalk's text output with a python script, since binwalk is now 
scriptable. I'll get on this...

Original comment by heffne...@gmail.com on 2 Jun 2013 at 1:50

GoogleCodeExporter commented 9 years ago

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