Extracting Non-Standard SquashFS Images

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 

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*

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:  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;
    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.

Bookmark the permalink.

53 Responses to Extracting Non-Standard SquashFS Images

  1. ikrepirdhu says:

    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 ?

  2. Craig says:


    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.

  3. ikrepirdhu says:

    sorry for the mistake .
    the live system is using another firmware (older version) not the link i provided on the first post .

    uploaded here
    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


    also the company has made the kernel/apps available at
    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 : 0x41
    CPU architecture: 5TEJ
    CPU variant : 0x0
    CPU part : 0xa26
    CPU revision : 2

    [root@modem ~]# cat /proc/meminfo
    MemTotal: 29200 kB

  4. ikrepirdhu says:

    ( 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

  5. Craig says:

    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.

  6. ikrepirdhu says:

    modify and replace it mostly , just for fun .
    also adding some other packages i.e

    maybe maybe later adding a lcd module in order to display infos i.e
    wan speed
    connected pc/users

    • Craig says:

      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.

  7. ikrepirdhu says:

    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
    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

  8. SD says:

    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?

    • Craig says:

      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.

  9. SD says:

    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:


    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

    • Craig says:

      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!

    • Kamil says:

      hi. Did you found a solution? With this “iCDxYDfeF4MZL.H3”?
      I think that the pass might be a “1337” 😉

  10. acki says:

    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.


    PS: If you want me to, I can upload a firmware sample for you to take a look (out of curiosity, of course).

  11. Pingback: /dev/ttyS0 » Blog Archive » Exploiting Embedded Systems – Part 1

  12. Marcel says:

    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.

  13. Craig says:


    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.

  14. Marcel says:

    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:

    Just for test …try to unpack and pack the firmware

    Thank’s in advance.

  15. Craig says:

    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. 🙂

  16. Marcel says:

    Very good news. Thanks! Waiting… :).

  17. Craig says:


    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=$((0x60)) 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! 🙂

  18. Marcel says:

    Oh God! Thanks Craig. Good job. But, It’s too difficult for me. I’ll try to learn all these things…(how to build). 🙂

  19. Marcel says:

    It would be nicer to have a firmware-mod-kit patch for dir-320 because I’m not so good at programming, just enthusiast. 🙂

  20. Craig says:

    Haha, no problem Marcel, I’ll let you know when it’s working.

  21. Marcel says:

    At the beginning “dd” Something got wrong (error token is “×60”) – something with syntax. What could be?

    • Craig says:

      The “$((0x60))” syntax is just so that bash will interpret hexadecimal values. Hex 0x60 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

  22. Marcel says:

    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. 🙁

  23. Craig says:


    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.

  24. Marcel says:

    Yes. It provides the web interface – so called SAFE MODE.

  25. snd says:

    Marcel and Craig,

    Any news a about header problem?

  26. Marcel says:

    No, at the moment no news. I’m waiting for firmware-mod-kit building patch for D-link DIR-320.

  27. Andrew says:


    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:

    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?


    • Craig says:

      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. :\

      • Andrew says:

        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,

  28. Eyal says:

    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.

  29. Jordan says:

    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?

  30. Brighton Guy says:

    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?

    • Craig says:

      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?

  31. numind says:

    I did stuck with some custom squashfs method, I can extract part of data with offzip because is zlib (78 DA) but I am looking for root file system.. here can check with hex dump

    00520000 68 73 71 73 32 01 00 00 4c 61 85 50 00 00 02 00 |hsqs2…La.P….|
    00520010 04 00 00 00 01 00 11 00 c0 00 01 00 04 00 00 00 |…………….|
    00520020 3b 04 24 08 00 00 00 00 0f 4d b5 00 00 00 00 00 |;.$……M……|
    00520030 07 4d b5 00 00 00 00 00 ff ff ff ff ff ff ff ff |.M…………..|
    00520040 3f 34 b5 00 00 00 00 00 20 3f b5 00 00 00 00 00 |?4…… ?……|
    00520050 08 4a b5 00 00 00 00 00 f9 4c b5 00 00 00 00 00 |.J…….L……|
    00520060 78 da a4 bd 0d 78 54 c7 75 37 7e f6 ee 4a 5a 84 |x….xT.u7~..JZ.|
    00520070 30 57 62 11 8b 11 78 57 ba 5a c9 48 b6 05 91 5d |0Wb…xW.Z.H…]|
    00520080 c5 51 9c b5 24 3e 8c 94 64 01 d9 21 2d 09 42 1f |.Q..$>..d..!-.B.|
    00520090 18 62 01 32 92 6d 9c 38 f6 5a c8 8e 9a 6e 56 32 |.b.2.m.8.Z…nV2|
    005200a0 a1 09 6d dc 74 23 90 4d 12 45 02 8c 6d da ba 89 |..m.t#.M.E..m…|

    similar header appears few offset below..

    007a0000 68 73 71 73 36 01 00 00 02 92 ff 50 00 00 02 00 |hsqs6……P….|
    007a0010 05 00 00 00 01 00 11 00 c0 00 01 00 04 00 00 00 |…………….|
    007a0020 b3 04 42 08 00 00 00 00 c6 c8 b6 00 00 00 00 00 |..B………….|
    007a0030 be c8 b6 00 00 00 00 00 ff ff ff ff ff ff ff ff |…………….|
    007a0040 1a b0 b6 00 00 00 00 00 5f bb b6 00 00 00 00 00 |…….._…….|
    007a0050 50 c6 b6 00 00 00 00 00 b0 c8 b6 00 00 00 00 00 |P……………|
    007a0060 78 da a4 bd 0d 78 54 c7 75 37 7e f6 ee 4a 5a 84 |x….xT.u7~..JZ.|
    007a0070 30 57 62 11 8b 11 78 57 ba 5a c9 48 b6 05 91 5d |0Wb…xW.Z.H…]|
    007a0080 c5 51 9c b5 24 3e 8c 94 64 01 d9 21 2d 09 42 1f |.Q..$>..d..!-.B.|
    007a0090 18 62 01 32 92 6d 9c 38 f6 5a c8 8e 9a 6e 56 32 |.b.2.m.8.Z…nV2|
    007a00a0 a1 09 6d dc 74 23 90 4d 12 45 02 8c 6d da ba 89 |..m.t#.M.E..m…|
    007a00b0 e2 10 d7 6d 68 4b 53 9a c7 ed eb 36 bc 8d 9d b8 |…mhKS….6….|

    so, what the hell?

    • Craig says:

      Interesting…it’s uncommon to see vendors mess with squashfs images that use deflate compression (historically the most common reason vendors modify the squashfs standard has been to add LZMA support which was not officially supported until version 4.0). Do you have a link to the firmware?

      • Marco says:

        Hi Craig,!
        How can I extrac cramfs files?
        I try to use uncramfs tools,but failure!
        Could you have some idean for it?

        thank you!

        • Craig says:

          You should be able to mount cramfs directly on any standard Linux system (if the cramfs image is big endian, you’ll probably need to byte-swap it to little endian first using the cramfsswap tool).

  32. Pingback: Decompiling Router Firmware: Beginners Guide | Blog : Logan Diomedi

  33. Pingback: Mucking About With SquashFS - /dev/ttyS0

  34. ronit yadav says:

    im getting this error “Can’t find a SQUASHFS superblock on firmware.squashfs” ….please help

    • Craig says:

      firmware.squashfs is either not a squashfs image, or it is a modified squashfs image that your tool doesn’t understand. What tool are you using? Unsquashfs? Sasquatch?

  35. ronit yadav says:

    im sorry for late rplying actually i was researching about this issue but found nothing im using firmware mod kit

  36. Kaiser says:

    Hello Craig,
    I am having a slight problem with a Billion 7800 image file. I have extracted the CFE, ROOTFS, KERNEL and TAG file from the image and have made modifications to the ROOTFS. I then repack the ROOTFS using squashfs4.3 and the Broadcom tools. After I upload the new image I get this message:

    *** Press any key to stop auto run (1 seconds) ***
    Auto run second count down: 0
    Booting from only image (0xb8010000) ...
    Code Address: 0x80010000, Entry Address: 0x8030e340
    Linux file system CRC error.  Corrupted image?

    I have tried many ways to fix this problem at first I thought it was something to do with lzma compression but that’s not it then I checked whether it had something to do with big endian and little endian so I repacked using both methods still no success.
    I saw a file in the rootfs system called cfg_checksum so possibly an algorithm that checks for any changes during boot time so deleted it and repacked the rootfs system still no luck. I am out of ideas need some help…
    Here is link to the firmware and extracted files.

  37. venkat says:

    Hello Craig
    Iam having a problem with the file https://www.dropbox.com/s/psw2lsnpqgcqm6s/2.fs?dl=0 when trying to unsquashfs. This is the error iam getting.
    Filesystem on 2.fs is (24919:29335), which is a later filesystem version than I support!
    Any thoughts or hints what the issue could be?

  38. Chris says:

    Hello, could you check this file? I tried with unsquashfs with lzma but I get an error.


    I need to extract the firmware to add a custom line to the conf when booting.


Leave a Reply

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