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 dataMany 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/srunning “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 databut 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 dataSo 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.outFrom 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/sExtracting 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 0and 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.cgi8: default passwd resolv.conf svn.info udhcpc.script version
9: group ppp restore_config.cgi syslog.conf udhcpc.wizard.script
Very good information. Thanks a lot. Could you please look at that:
ReplyDeletehttp://forum.samygo.tv/viewtopic.php?p=20464#p20464
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