SquashFS is a widely used file system in embedded Linux devices; in fact, it is probably one of the most commonly used file systems among Linux based consumer products.
While many devices use standard SquashFS file systems that can be extracted using the unsquashfs tools provided in the firmware mod kit, you will inevitably encounter some implementations that are…special.
Perhaps the vendor simply changed the SquashFS signature, or maybe they modified something in the de/compression code, but for one reason or another, none of the unsquashfs tools will work.
The D-Link DIR-320 is special.
Upon first inspection of the DIR-320 firmware image, it appears that we have a normal, standard SquashFS image inside the firmware update file:
embedded@ubuntu:~/DIR320$ binwalk DIR-320A1_FW121WWb03.bin DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------- 96 0x60 LZMA compressed data, dictionary size: 8388608 bytes, uncompressed size: 2240512 bytes 720992 0xB0060 PackImg Tag, size: 3157248 bytes 721024 0xB0080 Squashfs filesystem, little endian, version 2.0, 2960636 bytes, 984 inodes, blocksize: 65536 bytes, created: Tue Nov 23 01:18:41 2010
But alas, running unsquashfs against the extracted SquashFS image results in a segmentation fault:
embedded@ubuntu:~/DIR320$ dd if=DIR-320A1_FW121WWb03.bin bs=1 skip=721024 count=2960636 of=dir320.squashfs 139136+0 records in 139136+0 records out 139136 bytes (139 kB) copied, 0.407625 s, 341 kB/s embedded@ubuntu:~/DIR320$ /opt/filesystems/squashfs/unsquashfs-2.1-r2-lzma dir320.squashfs Segmentation fault
Since the parsed header information from binwalk looked legitimate, let’s take a quick look at a hexdump from the SquashFS image:
00000000 68 73 71 73 d8 03 00 00 fc 2c 2d 00 f4 2c 2d 00 |hsqs.....,-..,-.| 00000010 f8 2c 2d 00 4e f5 2c 00 e6 0d 2d 00 02 00 00 00 |.,-.N.,...-.....| 00000020 b1 c6 10 00 40 01 01 f1 86 eb 4c 76 19 77 10 00 |....@.....Lv.w..| 00000030 00 00 00 00 00 01 00 2f 00 00 00 f0 2c 2d 00 37 |......./....,-.7| 00000040 7a 69 70 00 1e 1d 0a 43 df 5a 7f 1e 0d a3 a0 de |zip....C.Z......| 00000050 e8 9c 48 47 c7 41 74 56 1d 95 b2 45 21 9b 24 5d |..HG.AtV...E!.$]| 00000060 44 8c d4 aa d9 3d 19 82 a5 72 62 a4 ec 7a 5d f2 |D....=...rb..z].| 00000070 b1 8b ab 99 c2 ab cc ca f3 7d fb f2 4f bb a7 a2 |.........}..O...| 00000080 9e 0b 14 7f 27 f4 2f 98 60 95 10 cd c5 d2 d7 31 |....'./.`......1| 00000090 79 dd 2e 06 07 93 34 1f ef 31 da cd c2 8f db 35 |y.....4..1.....5|
One thing that you’ll notice is that the string ’7zip’ keeps popping up all over the file system image. Although 7zip is associated with LZMA compression (suggesting that the SquashFS data blocks are in fact LZMA compressed), the 7zip string is certainly not a standard part of LZMA compression.
In times of trouble, source code is your best friend. Although not widely advertised on D-Link’s sites, source for the DIR-320 is available (warning: slow download).
First, let’s locate the SquashFS utilities in the DIR-320 GPL release:
embedded@ubuntu:~/DIR320/dir320$ find . -name *squashfs* ./kernels/bcm5354/include/linux/squashfs_fs_sb.h ./kernels/bcm5354/include/linux/squashfs_fs.h ./kernels/bcm5354/include/linux/squashfs_fs_i.h ./kernels/bcm5354/fs/squashfs ./tools/squashfs-tools-3.0 ./tools/squashfs-tools-3.0/mksquashfs.c ./tools/squashfs-tools-3.0/mksquashfs.h ./tools/squashfs-tools-3.0/squashfs_fs.h ./tools/squashfs-tools-3.0/unsquashfs.c ./tools/squashfs-tools ./tools/squashfs-tools/squashfs_fs_sb.h ./tools/squashfs-tools/mksquashfs.c ./tools/squashfs-tools/mksquashfs.h ./tools/squashfs-tools/squashfs_fs.h ./tools/squashfs-tools/squashfs_fs_i.h
Let’s look through the SquashFS tools included with the GPL code for references to the ’7zip’ string we saw in our hex dump earlier:
embedded@ubuntu:~/DIR320/dir320/tools/squashfs-tools$ grep -R 7zip * lzma/SRC/7zip/Compress/LZMA_Alone/AloneLZMA.dsp:# Begin Group "7zip Common" lzma/SRC/7zip/Compress/LZMA_Lib/ZLib.cpp: strcpy((char*)dest,"7zip"); lzma/SRC/7zip/Compress/LZMA_Lib/ZLib.cpp://+++ I add "7zip" id to make kernel can check if use 7zip to decompress. ---// lzma/SRC/7zip/Compress/LZMA_Lib/ZLib.cpp: if ( strncmp((char*)source,"7zip",4) == 0 ) lzma/lzma.txt:SRC/7zip/Compress/LZMA_Alone lzma/lzma.txt: 7zip - files related to 7-Zip Project lzma/lzma.txt: SRC/7zip/Compress/LZMA_C lzma/lzma.txt:You can find C/C++ source code of such filters in folder "7zip/Compress/Branch" Makefile:LZMAPATH = ./lzma/SRC/7zip/Compress/LZMA_Lib Makefile: make -C ./lzma/SRC/7zip/Compress/LZMA_Lib Makefile: make -C ./lzma/SRC/7zip/Compress/LZMA_Alone Makefile: cp -f ./lzma/SRC/7zip/Compress/LZMA_Alone/lzma ./lzma Makefile: make -C ./lzma/SRC/7zip/Compress/LZMA_Lib clean Makefile: make -C ./lzma/SRC/7zip/Compress/LZMA_Alone clean
There is a block of code in the ZLib.cpp file that does a string comparison against the ’7zip’ string and includes a comment about using ’7zip’ to decompress data.
Looking at the DIR-320′s ZLib.cpp file, it appears that the LZMA library has been modified to look for a ’7zip’ string at the beginning of a compressed data block, and if it exists to simply skip over the ’7zip’ string:
//+++ add by siyou ---//
//+++ I add "7zip" id to make kernel can check if use 7zip to decompress. ---//
ZEXTERN int ZEXPORT uncompress OF((Bytef *dest, uLongf *destLen,
const Bytef *source, uLong sourceLen))
{
if ( strncmp((char*)source,"7zip",4) == 0 )
{
source += 4;
sourceLen -= 4;
}
orig_uncompress(dest,destLen,source,sourceLen);
return Z_OK;
}
This looks to be our culprit and is a relatively simple modification. We’ll add this code to the LZMA library included with the firmware mod kit and re-build the SquashFS tools (a patch file has been submitted to the FMK project and can be downloaded here):
embedded@ubuntu:~/firmware-mod-kit/trunk/src$ patch -p1 < lzma7zip.patch patching file src/lzma/C/7zip/Compress/LZMA_Lib/ZLib.cpp embedded@ubuntu:~/firmware-mod-kit/trunk/src$ make clean && make ... wrt54gv5_img.cpp: In function ‘int FixImage(const char*)’: wrt54gv5_img.cpp:653: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ wrt54gv5_img.cpp:658: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ make[1]: Leaving directory `/media/Storage/MORE_BACKUPS/Projects/firmware-mod-kit-orig/trunk/src/wrt_vx_imgtool'
Let’s try extracting the files in the SquashFS image again, this time with our patched binaries:
embedded@ubuntu:~/DIR320$ ../firmware-mod-kit/trunk/src/squashfs-2.1-r2/unsquashfs-lzma dir320.squashfs created 825 files created 56 directories created 103 symlinks created 0 devices created 0 fifos embedded@ubuntu:~/DIR320$ ls squashfs-root/ bin dev etc home htdocs lib mnt proc sbin sys tmp usr var www
Success! Not terribly complicated, but necessary, and now we are free to further examine the binaries and PHP files used by the DIR-320.
nice one , really liked all articles but the “mod-ed” ones are really usefull.
i have a firmware that is driving a little crazy .
the file itself seems not to be common .
after upgraded the modem i :
cat /proc/mtd
[root@modem ~]# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 “boot”
mtd1: 00100000 00004000 “Kernel 1″
mtd2: 00e00000 00004000 “Root 1″
mtd3: 00200000 00004000 “Conf”
mtd4: 00100000 00004000 “Kernel 2″
mtd5: 00e00000 00004000 “Root 2″
and then
cat /dev/mtd* > /tmp/mtd*
but analyzing boot (mtd0) with binwalk it reports nothing at all .
any idea ?
the file is here
http://www.gennetsa.com/firmware/gennet-RFA14000.W-GEN01_5.0.0-ka2011051119.fw.zip
@ikrepirdhu:
After examining the kernel from the firmware image you linked to, there is a reference to RedBoot, so if I had to guess I’d say it’s probably using the RedBoot bootloader.
Have you run strings against the mdt0 file you obtained from the live system? Is there a serial port that you can connect to and see boot messages?
If you can provide the mtd0 file, I can take a look at it if you’d like.
@Craig
sorry for the mistake .
the live system is using another firmware (older version) not the link i provided on the first post .
uploaded here
http://www.mediafire.com/?efugu29nxzq0z44
you can find
mtd* files
dmesg output
the correct firmware
running strings on the boot file i see some reference for PP BOOT but cant find s.th useful on google except
http://wiki.openwrt.org/doc/techref/bootloader/pp_boot
also the company has made the kernel/apps available at
http://broadband.gennetsa.com/gpl/tellas-20090712/
but i think they are old and not specifically for this system , since the company sells different kind of routers
the system i have is a Conexant CX 94610-11Z
[root@modem ~]# cat /proc/cpuinfo
Processor : ARM1026EJ-Sid(wb)B rev 2 (v5l)
BogoMIPS : 263.78
Features : swp half thumb fastmult edsp java
CPU implementer : 0×41
CPU architecture: 5TEJ
CPU variant : 0×0
CPU part : 0xa26
CPU revision : 2
[root@modem ~]# cat /proc/meminfo
MemTotal: 29200 kB
( continued )
the system doesn`t have a serial console
there are some pins that seems for the console marked
JIH in a 4×2 formation . but i dont know for sure the pinout/voltages
So, I probably should have asked this in the first place, but what exactly are you trying to do with the boot loader? Are you trying to replace it, or modify it, or just figure out how it works?
The 4×2 header is probably the serial console. Identifying the pins is usually pretty easy with a multimeter if you have one.
modify and replace it mostly , just for fun .
also adding some other packages i.e
asterisk
quagga
tcpdump
maybe maybe later adding a lcd module in order to display infos i.e
wan speed
connected pc/users
etc
It sounds like you’re more interested in modifying the file system rather than the boot loader itself then, correct?
From what I’ve seen of this firmware the file system is JFFS2, so any changes you make to the JFFS2 partition (presumably the entire file system is JFFS2?) will be persistent across a reboot. Since you seem to have a root shell on the device already, you should be able to cross-compile some tools and just copy them to the device using any wget/netcat/ftp/tftp/scp/sftp client programs that are already on the device.
To verify, run the ‘mount’ command, it should tell you what file systems are in use and where they are mounted in the file system.
yes thats correct
the filesystem is jffs2 and i have a root shell.
also i successfully cross-compiled some programs i found on the packages here http://broadband.gennetsa.com/gpl/tellas-20090712/ and the famous hello-world
the live system is with rw access on all partitions.
[root@modem ~]# mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (rw,noatime)
proc on /proc type proc (rw,nodiratime)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/usb type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /var/run type tmpfs (rw,noatime,nodiratime)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/mtd/params-block on /etc/params type jffs2 (rw,noatime,nodiratime)
and the default disk usage is
[root@modem ~]# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 14.0M 11.5M 2.5M 82% /
tmpfs 128.0K 0 128.0K 0% /dev/usb
tmpfs 8.0M 88.0K 7.9M 1% /tmp
tmpfs 16.0M 208.0K 15.8M 1% /var/run
/dev/mtd/params-block
2.0M 152.0K 1.9M 7% /etc/params
memory usage
[root@modem ~]# free
total used free shared buffers
Mem: 29200 23564 5636 0 0
Swap: 0 0 0
Total: 29200 23564 5636
Hey Craig,
I’ve enjoyed reading your blog, and I’ve tried binwalk out on various router firmwares. I was able to extract the dir-330′s filesystem thanks to binwalk’s identification of it as cramfs.
However, running binwalk against the dir-655 firmware comes up with nothing at all: ftp://ftp.dlink.com/Gateway/dir665/Firmware/dir665_fw_100NA.zip
Do you have any ideas how this is compressed?
Hi SD,
IIRC the DIR-655′s are based on Ubicom processors which have their own architecture, Ubicom32, which according to Ubicom is unique and not a subset of MIPS/ARM/etc.
I don’t know what compression their firmware uses – it may be custom – and without knowledge of the underlying CPU architecture it would probably be pretty difficult to figure out.
Thanks for the quick reply!
I’m not sure if this comment section is the right place to ask this, but I’ve pulled open the dir-600 firmware and I’m wondering what type of password hash this is:
Admin:iCDxYDfeF4MZL.H3/:10933:0:99999:7:::
It looks kind of like crypt(3) but those are 13 characters and this is 17 characters, with what seems to have several salt characters at the end
Hmmm, I can’t say I know what that hash is off hand, and john doesn’t recognize it as a valid hash either. I doubt it’s actually used, as the admin hash is usually stored in NVRAM and the passwd file is usually located on a non-writable file system. Still would be interesting to know what it is…I’ll keep looking. Let me know if you figure it out!
I don’t know whether this is the right place to ask… but I’m trying to dissect a firmware which is jungo’s openrg based. Have you guys dealt with those kind of firmwares ? Any plans to add them in the future to firmware-mod-kit ? Thanks.
acki
PS: If you want me to, I can upload a firmware sample for you to take a look (out of curiosity, of course).
Pingback: /dev/ttyS0 » Blog Archive » Exploiting Embedded Systems – Part 1
I’ve successfully unpacked the Dir-320′firmware ver_1.21 but when added 2 extra php files, after building the firmware, the router can’t be flashed with it.
The Error Message: The chosen file is not a valid firmware image file.
Question: How to build the right the firmware?
Thank’s in advance.
Marcel,
You likely need to modify the firmware header, there is probably a checksum value there. How did you re-build the firmware? DId you look at the GPL code, I believe there is a mkimage script in there somewhere.
Craig, thanks for the reply.
Unpacking and building I have made with the help of ng-extract and ng-build
When building the firmware there’is a checksum error + unsupported header message.
I’m novice in Linux….i have only changed the very important TriplePlay option (php) which is available on the older firmware but not in the new one
If you have some time there is a link to the firmware. Please have a look:
http://ftp.dlink.ru/pub/Router/DIR-320/Firmware/DIR-320A1_FW121WWb03.bin
Just for test …try to unpack and pack the firmware
Thank’s in advance.
Marcel, I’ve identified most of the header info and have narrowed down the checksum to two possible fields. I’ll post more once I have it working.
Very good news. Thanks! Waiting…
.
Marcel,
You should be able to build a valid firmware image using the utilities available in the GPL code; specifically, the v2image binary located in dir320/tools/buildimg directory of the GPL code should build a valid header for you. I’m working on adding support for this header type to the firmware mod kit, but until then you can do:
$ dd if=[modified firmware image] bs=$((0×60)) skip=1 of=image.raw
This will remove the existing header from the new firmware image. Now you can run the image.raw file through v2image to build a new header for it:
$ ./v2image -v -c -i image.raw -o new_fw.img -d /dev/mtdblock/2 -s wrgg27_dlwbr_dir320
You should now have a valid firmware image that you can upload to the router. Note that I haven’t tested this, other than verifying that doing the above process on the original factory firmware produced an identical file. So it should work, but tread with caution!
Oh God! Thanks Craig. Good job. But, It’s too difficult for me. I’ll try to learn all these things…(how to build).
It would be nicer to have a firmware-mod-kit patch for dir-320 because I’m not so good at programming, just enthusiast.
Haha, no problem Marcel, I’ll let you know when it’s working.
At the beginning “dd” Something got wrong (error token is “×60″) – something with syntax. What could be?
The “$((0×60))” syntax is just so that bash will interpret hexadecimal values. Hex 0×60 is the same as decimal 96, so if this is giving you issues the following command is equivalent:
$ dd if=[modified firmware image] bs=96 skip=1 of=image.raw
bs=$96 is better, because more bytes are processed. I can upload the firmware but with no avail. The router recognizes and uploads he firmware but after that drops to SAFE MODE. It means that there’s something wrong with the firmware itself.
Marcel,
My guess is that the Linux kernel is expecting the squashfs image to have the ’7zip’ strings, as described above. The mksquashfs for the FMK doesn’t currently support this, though I think it could be added without much trouble.
Does the DIR320′s safe mode provide a Web interface to restore the firmware? Hopefully you should at least be able to get the original firmware back onto the device so you don’t have a brick.
Yes. It provides the web interface – so called SAFE MODE.
Marcel and Craig,
Any news a about header problem?
No, at the moment no news. I’m waiting for firmware-mod-kit building patch for D-link DIR-320.
Hello,
Great tutorials! I was wondering if anyone could point me in the proper direction towards extracting:
Squashfs filesystem, big endian, lzma signature, version 3.1.
I seem to have missed the ship with the firmware modification toolkit since they support v3.0. Therefore, I have attempted to compile squashfs with LZMA support enabled, but it errs with:
Reading a different endian SQUASHFS filesystem on rootfs-sized.squashfs
Parallel unsquashfs: Using 2 processors
lzma uncompress failed with error code 7
read_block: failed to read block @0x8ef841
FATAL ERROR aborting: uncompress_directory_table: failed to read block
Yet, unsquashfs appears to have the proper decompressor, and the file system extracted from my original image seems to have a valid superblock:
Decompressors available:
gzip
lzma
xz
Reading a different endian SQUASHFS filesystem on rootfs-sized.squashfs
Found a valid big endian SQUASHFS 3:1 superblock on rootfs-sized.squashfs.
Creation or last append time Thu Mar 20 03:49:07 2011
Filesystem size 9152.87 Kbytes (8.94 Mbytes)
Block size 131072
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Check data is not present in the filesystem
Duplicates are removed
Number of fragments 78
Number of inodes 1000
Number of uids 1
Number of gids 0
Any ideas?
Thanks!
Andrew
If you can provide a link to the firmware or the squashfs image I can take a look at it. They may have modified the lzma compression or something along those lines. :\
Hi Craig,
Thanks for your reply! For some reason the squashfs-tools compiled by members of the SLAX project for Windows (http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip via http://www.slax.org/forum.php?action=view&parentID=28069) properly extracted the squashfs rootfs. It did a great job of recreating the file system, with exception to converting symbolic links into Windows .lnk files and failing on a console block device. This seems to lead me to a brick wall when it comes to re-compressing the file system, my next mission.
The Windows version looks like: unsquashfs version 3.4 (2008/08/26). If I try to recreate this environment within Linux, do you think it’s possible to make a valid image? I did not see any options where mksquashfs allows for different endianness (ARMEB arch), which does not seem promising for repacking it.
In the mean time, I’ll have to check about sharing the image…
Thanks again,
Andrew
hi.
great article, though unliked regualr embedded systems i have a question regarding Android.
before version 4.1 and maybe 4.03 it used the yaffs. i tried to find a kernel driver for regualr linux 2.6 kernel (for ubuntu) and Fs tools to i can mount using loop images i compile or extract from devices.
Do you know any such tools, i was really unable to find any, i didn’t try to compile the original source from the yaffs site.
I haven’t dealt with YAFFS myself, but this looks relevant.
Hey Craig,
I appreciate all the hard work you and the others put into this blog! I had a quick question I wanted to run by you since I wasn’t sure how else to contact you.
I’m trying to extract a squashfs filesystem just to poke around (not modify, etc.). Here are the details:
It’s a Squashfs filesystem, little endian, version 1.0. Unsquashfs had no luck with it, and I think this is due to support for version 1.0 being depreciated in kernel 2.6.29 (read this in a blog). I’ve tried firing up an old VM with a 2.6.12.* kernel and following instructions to add LZMA support with no luck also.
Any ideas about how you would go about extracting an older filesystem like this?
Fascinating article, which I came across while trying to rebuild the DNS-325 firmware, and ran immediately into squash problems.
However the 325 image does not have any 7zip strings, and the DNS package doesnt have the mksq… and unsq… tools.
7zip will uncompress the images,
I am not familiar with the squash system, and don’t know where else to look!
Also the v2.xx firmware for the DNS-320 doesn’t have 7zip tags!
Could you offer any pointers please?
Vendors often muck about with the SquashFS implementation. Have you tried the squashfs utilities in the firmware-mod-kit? Have you tried looking at the GPL release for the DNS-325 to see if a) it includes the squashfs tools and b) the squashfs tools can extract the image?