problem using unsquashfs

  • J Holsenback
    J Holsenback

    I'm having some troubles extracting the files from a squashfs v1.0 filesystem using the latest (v4.2) unsquashfs. This filesystem was lifted from a router firmware image. The filesystem is somewhat of a black box to me, in that I'm not sure what compression was used when it was created, or what files are in the image. Given the version of the filesystem, an educated guess /might/ be that it used gzip compression, but I know that some earlier variants (branches or customizations) used lzma compression.

    Here's what I've learned about the filesystem from information gained using v4.2 tools, and some information gained through direct examination (hexdump and a small c program that was cobbled together):

    ./unsquashfs -s ../../filesystem.bin
    unsquashfs: read_bytes: reading from position 0x0, bytes 96
    unsquashfs: read_bytes: reading from position 0x0, bytes 119
    Found a valid little endian SQUASHFS 1:0 superblock on ../../filesystem.bin.
    Creation or last append time Fri Oct 16 23:07:09 2009
    Filesystem size 3299.28 Kbytes (3.22 Mbytes)
    Block size 32768
    Filesystem is not exportable via NFS
    Inodes are compressed
    Data is compressed
    Check data is not present in the filesystem
    Duplicates are removed
    Number of inodes 1670
    Number of uids 2
    Number of gids 0 ?
    unsquashfs: sBlk.s.inode_table_start 0x3343d3
    unsquashfs: sBlk.s.directory_table_start 0x3365b2
    unsquashfs: sBlk.uid_start 0x338d1b
    unsquashfs: sBlk.guid_start 0x0

    I have #define SQUASHFS_TRACE 1 set in squashfs_fs.c to give a little bit more information …

    Notice that it properly identified that my filesystem image is version 1.0 compressed data and inode table … however when I try to extract the files from the image I get a fatal error:

    ./unsquashfs -ll ../../filesystem.bin
    unsquashfs: read_bytes: reading from position 0x0, bytes 96
    unsquashfs: read_bytes: reading from position 0x0, bytes 119
    Parallel unsquashfs: Using 2 processors
    unsquashfs: MY: read_uids_guids: no_uids 2, no_guids 0
    unsquashfs: read_bytes: reading from position 0x338d1b, bytes 8
    unsquashfs: read_fragment_table
    unsquashfs: uncompress_inode_table: start 3359699, end 3368370
    unsquashfs: uncompress_inode_table: reading block 0x3343d3
    unsquashfs: read_bytes: reading from position 0x3343d3, bytes 2
    unsquashfs: read_block: block @0x3343d3, 2261 compressed bytes
    unsquashfs: read_bytes: reading from position 0x3343d5, bytes 2261
    gzip uncompress failed with error code -3
    read_block: failed to read block @0x3343d3
    FATAL ERROR aborting: uncompress_inode_table: failed to read block

    What this seems to be telling me is that gzip is having some difficulties reading the first block of data, but has successfully identified the start and end of the first block.

    Something else I noticed (refer to first session transcript): from unsquashfs -s is that the Number of gids reported is "0" and later on … unsquashfs: sBlk.guid_start 0x0. This is also verified through direct examination of the super-block, where at offset 0x000026, it indeed is set to zero!

    Could this be the bigger problem. I don't think I've heard of any unix/linux system that would allow a file or directory without having some sort of group affiliation, or could it be that the super-block information is corrupted somehow! At this point I'm thinking what compressor was used when the filesystem was created is the least of my worries.

    Insights appreciated!