1

I was able to download Linksys E1200 router firmware, which I would like to reverse engineer. I believe it is running some sort of Linux/Unix based firmware and may be running on an ARM CPU. I have run binwalk against it but I'm not sure what to do next.

This is the output I get:

32            0x20            TRX firmware header, little endian, image size: 7684096 bytes, CRC32: 0xB533F216, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x14FF20, rootfs offset: 0x0
60            0x3C            gzip compressed data, maximum compression, has original file name: "piggy", from Unix, last modified: 2016-07-13 03:17:53
1376064       0x14FF40        Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 6307458 bytes, 1721 inodes, blocksize: 65536 bytes, created: 2016-07-13 03:23:19
  • 1
    You should be able to dump all data out of the squashfs part of the firmware and then analyze the output as you'd like. – NirIzr Jun 26 '17 at 16:59
  • 1
    devttys0.com/category/tutorials – julian Jun 26 '17 at 17:18
  • not sure if it helped, but Linksys router have provided the source code for how the firmware is built. For your E1200 router the GPL source is available here: linksys.com/us/support-article?articleNum=114663. And oh yes, it is definitely linux based, as most router are also built based on Linux, and similarly most router provide source code as part of GPL license requirement. – Peter Teoh Apr 29 at 2:51
1

The next step is extraction of the kernel and squashfs filesystem using the -e option when using binwalk. These extracted files can then be further analyzed. Running binwalk with the -A option on the bootloader and kernel files will provide clues about the instruction set architecture of the firmware. Performing an entropy scan with -E can be done to gain insight into the structure of the extracted files and is useful for identifying compressed or encrypted regions.

A variety of tools exist for the purpose of squashfs filesystem extraction, such as squashfs-tools and sasquatch .

A good example of the methodology employed in firmware analysis can be found here: Reverse Engineering Firmware: Linksys WAG120N

Update after firmware download link was made available:

To ensure that binwalk can properly extract SquashFS filesystem images, follow these steps:

  1. Install squashfs-tools:

    sudo apt-get install squashfs-tools

  2. In ~, clone sasquatch from github:

    git clone https://github.com/devttys0/sasquatch.git

  3. In ~/sasquatch, execute build.sh (check README.md to make sure all the dependencies are installed)

Also check the version of binwalk installed locally:

$ binwalk

Binwalk v2.1.2b
Craig Heffner, http://www.binwalk.org

Extraction

Compute md5sum of firmware binary:

$ md5sum FW_E1200v2.0.7.005_US_20160713_code.bin 
eb3752a5b72ccb0c9a92079fab88663e  FW_E1200v2.0.7.005_US_20160713_code.bin

Run binwalk signature scan to confirm output:

$ binwalk FW_E1200v2.0.7.005_US_20160713_code.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
32            0x20            TRX firmware header, little endian, image size: 7684096 bytes, CRC32: 0xB533F216, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x14FF20, rootfs offset: 0x0
60            0x3C            gzip compressed data, maximum compression, has original file name: "piggy", from Unix, last modified: 2016-07-13 03:17:53
1376064       0x14FF40        Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 6307458 bytes, 1721 inodes, blocksize: 65536 bytes, created: 2016-07-13 03:23:19

Output appears to match output in the original post.

Extraction:

$ binwalk -e FW_E1200v2.0.7.005_US_20160713_code.bin 

Files are extracted to directory _FW_E1200v2.0.7.005_US_20160713_code.bin.extracted/:

$ file *
14FF40.squashfs: data
piggy:           FoxPro FPT, blocks size 0, next free block index 15993608
squashfs-root:   directory 

Inside squashfs-root is the extracted filesystem:

$ ll squashfs-root/
total 88
drwxrwxrwx 13 user01 user01  4096 Jul 12  2016 ./
drwxr-xr-x  3 user01 user01  4096 Jun 26 15:16 ../
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 bin/
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 dev/
drwxrwxrwx  4 user01 user01  4096 Jul 12  2016 etc/
drwxr-xr-x  3 user01 user01  4096 Jul 12  2016 lib/
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 mnt/
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 proc/
drwxr-xr-x  2 user01 user01 12288 Jul 12  2016 sbin/
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 sys/
drwxr-xr-x  2 user01 user01  4096 Jul 12  2016 tmp/
drwxrwxrwx  6 user01 user01  4096 Jul 12  2016 usr/
lrwxrwxrwx  1 user01 user01     7 Jun 26 15:16 var -> tmp/var
drwxr-xr-x 32 user01 user01 28672 Jul 12  2016 www/

piggy

Running file against piggy produces a false positive:

piggy:           FoxPro FPT, blocks size 0, next free block index 15993608

Running binwalk against piggy suggests that it contains Linux kernel code:

$ binwalk piggy 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
2617344       0x27F000        Linux kernel version "2.6.22 (zhang@sw3) (gcc version 4.2.3) #5 Tue Jun 7 18:33:13 HKT 2016"
2641040       0x284C90        CRC32 polynomial table, little endian
2656556       0x28892C        CRC32 polynomial table, little endian
2852300       0x2B85CC        Unix path: /usr/gnemul/riscos/
2854956       0x2B902C        Unix path: /usr/lib/libc.so.1
2927975       0x2CAD67        Neighborly text, "NeighborSolicitsts"
2927999       0x2CAD7F        Neighborly text, "NeighborAdvertisementsmp6OutDestUnreachs"
2928200       0x2CAE48        Neighborly text, "NeighborSolicitsirects"
2928228       0x2CAE64        Neighborly text, "NeighborAdvertisementssponses"
2930275       0x2CB663        Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"

An entropy plot produced by binwalk -EJ piggy reveals a large contiguous area with an entropy of roughly .68:

piggy entropy

This level of entropy is consistent with what is expected of regions containing object code.

We can make an educated guess about what the instruction set architecture of the binary is by running binwalk with the -A argument:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1788          0x6FC           MIPSEL instructions, function epilogue
2636          0xA4C           MIPSEL instructions, function epilogue
4540          0x11BC          MIPSEL instructions, function epilogue
4932          0x1344          MIPSEL instructions, function epilogue
6092          0x17CC          MIPSEL instructions, function epilogue
6476          0x194C          MIPSEL instructions, function epilogue
6952          0x1B28          MIPSEL instructions, function epilogue
7040          0x1B80          MIPSEL instructions, function epilogue
8024          0x1F58          MIPSEL instructions, function epilogue
8392          0x20C8          MIPSEL instructions, function epilogue
9532          0x253C          MIPSEL instructions, function epilogue
9840          0x2670          MIPSEL instructions, function epilogue
12552         0x3108          MIPSEL instructions, function epilogue
12682         0x318A          MIPS instructions, function epilogue
12836         0x3224          MIPSEL instructions, function epilogue
13364         0x3434          MIPSEL instructions, function epilogue

The ISA is likely MIPS little-endian.

  • I ran binwalk -e (with sasquatch installed) and it created a directory. I entered into the directory and got two two files called 14FF40.squashfs and piggy. What should I do from here? I opened the 14FF40.squashfs file in nano and it started with shsq ^F^@^@^@^@^@^@^@^@^@^@^@^@^@^E^@^@^@^@^@^@^@^@^C^@^@^@]. – John Doe Jun 26 '17 at 18:14
  • I edited the 14FF30.squashfs file to start with sqsh instead of shsq and I got this output when I ran file against it. 14FF40.squashfs: Squashfs filesystem, big endian, version 768.0, -5438845162455356928 bytes, -1190789120 inodes, blocksize: 0 bytes, created: Wed Dec 31 19:00:00 1969 – John Doe Jun 26 '17 at 18:32
  • @JohnDoe try running sasquatch against it. This should extract the filesystem into a directory called squashfs-root – julian Jun 26 '17 at 18:39
  • Should I change the s14FF40.squashfs file beck to shsq or should I leave it with the change? – John Doe Jun 26 '17 at 18:45
  • @JohnDoe I doubt it matters. You should try both just to see what happens. If you have further issues, share the firmware file and take a look at this: Extracting Non-Standard SquashFS Images and Mucking About With SquashFS – julian Jun 26 '17 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.