Binwalk v0.4.2 has just been released. One of the major drawbacks to binwalk in the past has been scan time, which can take quite a while on larger files. Thanks to some user-supplied suggestions, I’m happy to say that scan times have been improved by several orders of magnitude; scans that previously took 10+ minutes now finish in just 30 seconds!
Some new search options have been added as well, one of my favorites being –raw-bytes. This option allows you to specify a sequence of bytes to search for without having to create a custom entry in the magic file:
$ binwalk --raw-bytes="abcdefg" firmware.bin
$ binwalk --raw-bytes="\x00\x01\x02\x03" firmware.bin
Get the 0.4.2 release here.
When analysing the firmware of my wireless camera, I’ve got a file with this
6157564 0x5DF4FC gzip compressed data, has CRC, was "\217\305S\226\212}"\310\262\372\361\203u\203\3442322\2622\332\314\30215\213 5Fz^1\355\372\3751f\3611z9\367I\333\326\243\251Y+\34632\341\377J5\2523\330\316z02\273\256Y\305", last modified: Sat Feb 14 23:54:16 2015Extracting that part (with dd) and then trying to decompress it fails. I guess it is because of an encoding error (cf the CRC).
Is it a problem with binwalk or the binary file ?
Binwalk does a pretty good job of filtering out false positive matches, but some will make it through.
Given the fact that this supposed gzip compressed file had a previous file name that is gibberish (“\217\305S\226…”) and it was last modified several years in the future, it is almost certainly a false positive result.