Wednesday, August 17, 2011

firmware reversing : Netgear DG834PN

Another approach with a different firmware this time, I choose netgear’s DG834PN wireless dsl routers’ firmware. The firmware, DG834PN_V1.03.39.img can be found at netgear’s website for download.
Starting as before, I used binwalk to identify the sections on the image.
   1: root@system:~/DG834PN# binwalk DG834PN_V1.03.39.img 
 
   2:  

   3: DECIMAL         HEX             DESCRIPTION

   4: -------------------------------------------------------------------------------------------------------

   5: 4177            0x1051          LZMA compressed data, properties: 0xA4, dictionary size: 285474816 bytes, uncompressed size: 256 bytes

   6: 7951            0x1F0F          LZMA compressed data, properties: 0xC2, dictionary size: 556793856 bytes, uncompressed size: 67108881 bytes

   7: 8087            0x1F97          LZMA compressed data, properties: 0x82, dictionary size: 556793856 bytes, uncompressed size: 67108881 bytes

   8: 8227            0x2023          LZMA compressed data, properties: 0xC2, dictionary size: 556793856 bytes, uncompressed size: 67108881 bytes

   9: 8371            0x20B3          LZMA compressed data, properties: 0x82, dictionary size: 556793856 bytes, uncompressed size: 67108881 bytes

  10: 10563           0x2943          LZMA compressed data, properties: 0xDF, dictionary size: 555220992 bytes, uncompressed size: 167272448 bytes

  11: 65792           0x10100         Squashfs filesystem, big endian, version 2.0, 3226978 bytes, 1227 inodes, blocksize: 65536 bytes, created: Thu Aug 14 07:06:38 2008

  12: 2639186         0x284552        bzip2 compressed data

  13: 2643350         0x285596        bzip2 compressed data

  14: 2659059         0x2892F3        bzip2 compressed data

  15: 2683869         0x28F3DD        bzip2 compressed data

  16: 2885101         0x2C05ED        bzip2 compressed data

  17: 2916750         0x2C818E        bzip2 compressed data

  18: 2927300         0x2CAAC4        bzip2 compressed data


Many lzma headers one squashfs and some bzip2 compressed data. The squashfs partition should be the filesystem located on the router, the lzma data should contain the loader, so how about the bzip2 compressed data…


Starting ( wrong as proven later ) from the bzip2 headers, I thought of extracting the last part to check on the data.



   1: root@system:~/DG834PN# dd if=DG834PN_V1.03.39.img bs=1 skip=2927300 of=unknown.bz2

   2: 1021244+0 records in

   3: 1021244+0 records out

   4: 1021244 bytes (1.0 MB) copied, 112.083 s, 9.1 kB/s


running “file” command on the extracted contents the command responds identifying the data as proper bzip2 compressed file.

   1: root@system:~/DG834PN# file unknown.bz2 

   2: unknown.bz2: bzip2 compressed data

but this is not correct,



   1: root@system:~/DG834PN# bunzip2 unknown.bz2 

   2: bunzip2: unknown.bz2 is not a bzip2 file.


“file” command will identify any file containing “BZh.” header in the start as bzip2 compressed document, an example below will demonstrate it. A text file with the name false_bz is created and the “file” command identifies it as bzip2 compressed data.


   1: root@system:~/DG834PN# echo "BZh.test" > false_bz

   2: root@system:~/DG834PN# file false_bz 

   3: false_bz: bzip2 compressed data

So this is definitely not the way to go. The sections are not properly identified.


Back to the start then, hexdump and strings commands will be proven again valuable and I believe that’s the proper way to start always.



   1: root@system:~/DG834PN# hexdump -C DG834PN_V1.03.39.img > hex.out

   2: root@system:~/DG834PN# strings DG834PN_V1.03.39.img > strings.out



From the hexdump we can see the loader that is used for the image,



   1: root@system:~/DG834PN# less hex.out 

   2: 00000000  10 00 02 78 00 00 00 00  00 00 00 00 00 00 00 00  |...x............|

   3: 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

   4: *
   5: 00000200  10 00 04 05 00 00 00 00  00 00 00 00 00 00 00 00  |................|

   6: 00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

   7: *

   8: 00000280  10 00 03 f0 24 1a 00 10  00 00 00 00 00 00 00 00  |....$...........|

   9: 00000290  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  10: *

  11: 00000300  10 00 03 d2 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  12: 00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  13: *

  14: 00000380  10 00 03 b4 24 1a 00 20  00 00 00 00 00 00 00 00  |....$.. ........|

  15: 00000390  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  16: *
  17: 00000400  10 00 03 96 24 1a 00 28  00 00 00 00 00 00 00 00  |....$..(........|

  18: 00000410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  19: *

  20: 00000480  10 00 03 78 24 1a 00 30  00 00 00 00 00 00 00 00  |...x$..0........|

  21: 00000490  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  22: *


  23: 000004e0  43 46 45 31 43 46 45 31  00 00 00 00 00 00 00 00  |CFE1CFE1........|

  24: 000004f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

  25: 00000500  10 00 03 5b 00 00 00 00  43 46 45 31 43 46 45 31  |...[....CFE1CFE1|

  26: 00000510  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|



string CFE1CFE1 is a clear mark of CFE loader ( http://melbourne.wireless.org.au/files/wrt54/cfe.pdf )


Going straight now for the filesystem I needed tools to work with squashfs, first choice was the firmware mod kit,  ( http://www.bitsum.com/firmware_mod_kit.htm ) that contains many different filesystem decoders like cramfs, various versions of squashfs and others. Later through the tests I found more useful the unsquashfs provided by the squashfs-tools on debian/ubuntu systems.




   1: root@system:~/DG834PN# dd if=DG834PN_V1.03.39.img bs=1 skip=65792 of=squash.fs              

   2: 3882752+0 records in

   3: 3882752+0 records out

   4: 3882752 bytes (3.9 MB) copied, 117.184 s, 33.1 kB/s


Extracting the squashfs system and after identifying it properly with unsquashfs I was able to mount the extracted filesystem and browse the files.




   1: root@system:~/DG834PN# unsquashfs -s squash.fs 

   2: Reading a different endian SQUASHFS filesystem on squash.fs

   3: Found a valid big endian SQUASHFS 2:0 superblock on squash.fs.

   4: Creation or last append time Thu Aug 14 07:06:38 2008

   5: Filesystem is not exportable via NFS

   6: Inodes are uncompressed

   7: Data is compressed

   8: Check data is not present in the filesystem

   9: Fragments are not present in the filesystem

  10: Always_use_fragments option is not specified

  11: Duplicates are removed

  12: Filesystem size 3151.35 Kbytes (3.08 Mbytes)

  13: Block size 65536

  14: Number of fragments 0

  15: Number of inodes 1227

  16: Number of uids 1

  17: Number of gids 0



and finally the extracted filesystem,



   1: root@system:~/DG834PN# mount -t squashfs -o loop squash.fs /tmp/mnt1/   


   2: root@system:~/DG834PN# cd /tmp/mnt1/

   3: root@system:/tmp/mnt1# ls

   4: bin  dev  etc  lib  proc  sbin  tmp  usr  var  www  www.deu  www.eng  www.fre  www.ita

   5: root@system:~/DG834PN# cd usr/etc

   6: root@system:/tmp/mnt1/usr/etc# ls
   7: crontab  hosts   rcS                 setup.cgi    udhcpc.fix.script     upgrade_flash.cgi
   8: default  passwd  resolv.conf         svn.info     udhcpc.script         version

   9: group    ppp     restore_config.cgi  syslog.conf  udhcpc.wizard.script

2 comments:

  1. Very good information. Thanks a lot. Could you please look at that:

    http://forum.samygo.tv/viewtopic.php?p=20464#p20464

    ReplyDelete
  2. Hi, i gave it a look it seems that it's binary file for ARM, with some sort of encryption/compression. None of the tools are able to identify it properly, neither binwalk or sigsearch. The bzip2 headers and the others are false positive.

    ReplyDelete