Binwalk 0.5 Release

In celebration of the world not ending, a new version of Binwalk has been released. Notable changes:

  • Much improved signatures for several common file types, particularly JFFS2
  • Smart signature” keyword support, for more reliable and faster scans
  • Ability to invoke external applications to process extracted files

The latter feature is probably of most interest, and is implemented as an extension of the pre-existing –dd option:

$ binwalk --dd='gzip:gz:gunzip %e' firmware.bin

The above command instructs Binwalk to extract any file whose description contains the text ‘gzip’, save it to disk with a ‘gz’ file extension, and to then run the ‘gunzip %e’ command (the %e is a placeholder that will be replaced with the actual name of the extracted file). This allows for auto extraction and decompression of gzipped files.

Although multiple –dd options may be specified, there are probably several common file types that you always want to be extracted whenever they are encountered. Binwalk 0.5 allows you to place multiple –dd arguments into the $HOME/.binwalk/extract.conf file:

# Extract and decompress gzip and lzma files
gzip:gz:gunzip %e
lzma:7z:7zip -d %e

# Extract private keys, but don't run anything
private key:key

The extract rules from this file are applied whenever the –extract option is specified:

$ binwalk --extract firmware.bin

There are several default extract rules that come with Binwalk by default. These are stored in /usr/local/etc/binwalk/extract.conf, and will be updated whenever the –update option is specified. Note that many of these extract rules expect the firmware-mod-kit to be installed to /opt/firmware-mod-kit, but these rules can be overridden by those in the $HOME/.binwalk/extract.conf file.

This means that a Binwalk scan can now not only identify embedded files, but also extract and decompress them for you automatically:

$ binwalk --extract firmware.bin 

0         	0x0       	TRX firmware header, little endian, header size: 28 bytes,  image size: 13533184 bytes, CRC32: 0x15289B44 flags/version: 0x10000
28        	0x1C      	gzip compressed data, was "piggy", from Unix, last modified: Mon Dec  3 13:09:06 2012, max compression
2005108   	0x1E9874  	Squashfs filesystem, little endian, non-standard signature,  version 3.1, size: 11525877 bytes, 2743 inodes, blocksize: 131072 bytes, created: Mon Dec  3 13:49:31 2012 

$ ls
1C  1E9874.squashfs  firmware.bin  squashfs-root/
$ ls squashfs-root
bin  dev  etc  home  JNAP  lib  libexec  linuxrc  mnt  opt  proc  root  sbin  sys  tmp  usr  var  www
Bookmark the permalink.

7 Responses to Binwalk 0.5 Release

  1. Matt says:

    System: ReadyNAS Ultra 6 Netgear Server
    Can you help with this compile error?
    ~/src/binwalk-0.5.0/src# make
    gcc -Wall -g -O2 -c nargv.c
    gcc -Wall -g -O2 -DEXTRACT='”/usr/local/etc/binwalk/extract.conf”‘ -c dd.c
    gcc -Wall -g -O2 -c common.c
    gcc -Wall -g -O2 -c md5.c
    gcc -Wall -g -O2 -c mparse.c
    gcc -Wall -g -O2 -c filter.c
    gcc -Wall -g -O2 -c smartsig.c
    gcc -Wall -g -O2 -c update.c
    gcc -Wall -g -O2 -DMAGIC='”/usr/local/etc/binwalk/magic.binwalk”‘ -DMAGIC_CAST='”/usr/local/etc/binwalk/magic.bincast”‘ -DMAGIC_ARCH='”/usr/local
    /etc/binwalk/magic.binarch”‘ -DEXTRACT='”/usr/local/etc/binwalk/extract.conf”‘ binwalk.c -o binwalk *.o -lcurl -lpthread -lmagic
    binwalk.c: In function ‘main’:
    binwalk.c:84: error: ‘MAGIC_NO_CHECK_TEXT’ undeclared (first use in this function)
    binwalk.c:84: error: (Each undeclared identifier is reported only once
    binwalk.c:84: error: for each function it appears in.)
    binwalk.c:84: error: ‘MAGIC_NO_CHECK_ENCODING’ undeclared (first use in this function)
    make: *** [binwalk] Error 1

    • Craig says:

      The MAGIC_NO_CHECK_TEXT and MAGIC_NO_CHECK_ENCODING should be defined in the magic.h file from the libmagic library. Binwalk uses these to disable text and encoding checks in libmagic, as doing so significantly speeds up scan times.

      Since you didn’t get any warnings/errors about missing libmagic, I assume that libmagic is installed on your system. What I suspect is happening is that the libmagic installed on your ReadyNAS is a stripped down version that does not support text or encoding checks, and therefore does not define MAGIC_NO_CHECK_TEXT and MAGIC_NO_CHECK_ENCODING.

      You can try commenting out line 84 and running make again; hopefully, this is the only discrepency in the ReadyNAS’s libmagic library, and everything else will work fine.

      The other option is to install the full version of libmagic by downloading, compiling and installing the file utility (which includes the full libmagic library) on your ReadyNAS.

      Let me know if either of these options works (or doesn’t).

      • Matt says:

        I followed both suggestions and both worked. I believe you are correct. The installed version of libmagic is incomplete. Thanks for responding so quickly, you are the best.

        I installed binwalk to see if it could sniff anything from my VPD file – no luck. This file contains my serial and model number along with other OEM data. It is hidden in a SMI Flash memory area along with the kernel and initrd.gz. The SMI is not accessible after boot.

        I know the file is encrypted or uniquely structured. It is read at boot by the Netgear patched kernel.

        If the flash becomes corrupted, the ReadyNAS does not know anything about itself if the VPD is lost. My goal is to figure out how to reconstruct the file from scratch without waiting two weeks (or longer) for Netgear Tech Support.

        Second goal, switch OS from ReadyNAS (aka Front View) with an Intel compatible version from QNAP or Sonology. Both offer more features than the ReadyNAS.

        CPU: Intel E7600
        OS: Debian Etch (I know, so old)
        Any recommendations?

        • Craig says:

          Thanks for the feedback; I’ve updated the code in the subversion repository to check for those definitions before using them at compile time, so you shouldn’t have that issue in future builds.

          Binwalk doesn’t have much crypto signatures in it, but since your target is intel based, you might want to give signsrch a try.

          I assume the 2-week wait is for a GPL release from Netgear? I’d initiate one anyway if you haven’t already; depending on the complexity of what you are dealing with, it might take you 2 weeks (or more) to reverse the file anyway. OTOH, the GPL release might not give you any of the relevant code (specifically, I’m thinking they may have implemented this bit of code in a kernel module, and you only get a pre-built module with the GPL release instead of the source code to it).

          The good news is that even if they’ve used good strong crypto, at least in theory, if the kernel can decrypt the file then so can you. You will likely need to figure out where the code that accesses the VFD file is and then reverse it.

          The first thing you want to probably try though is to see if the file is in fact encrypted. Check for obvious stuff, like strings, and do some entropy measurements (high entropy, of course, is typically a sign of encryption/compression).

          • Matt says:

            Thanks for the suggestions; will definitely look into signsrch and entropy measurements. I’m surprised to find that the Kernel source [RNDP6xxx_4.2.22_WW_src] and Netgear kernel patch [] are currently available for their x86 server series. The kernel ( is not the most current, but I think you are spot on that the VPD file is probably destructured by a kernel module. After doing a Google search on VPD, It seems they are more common than I thought and saves production time and $ because OEM’s do not need to burn serial numbers or specs into Flash/bios chips. It seems to be especially useful when hardware is identical, but product pricing is differentiated by software features. I’ll start looking in the directions you pointed out, to see if anything turns up.

            Thanks, again.

  2. Matt says:

    I’ve compiled the latest version of, but using ‘binwalk –update’ erases my signature files:

    404 Not Found

    Not Found
    The requested URL /svn/trunk/src/magic.binwalk was not found on this server.

  3. The squashfs file system is case sensitive (i.e. teSt.bin ! = test.bin) and adheres to EXT2 naming rules. To support proper extraction of the file system, the working directory should be on a case sensitive file system and support symbolic links. The scripts will warn you if you attempt to use as working directory on a case INsensitive file system. You’ll see a number of errors if you extract to a file system that doesn’t support symbolic links.

Leave a Reply

Your email address will not be published. Required fields are marked *