unsquashfs problem

Discussion in 'General Discussion' started by Jim Holsenback, Jul 23, 2011.

  1. Jim Holsenback

    Jim Holsenback Networkin' Nut Member

    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!
  2. mstombs

    mstombs Network Guru Member

  3. Jim Holsenback

    Jim Holsenback Networkin' Nut Member

    Thanks for taking the time to reply!

    Had already tried Jeremy's firmware modkit and it didn't give me any joy either ... ended up being able to mount the filesystem through a console port on the device. Copied the files to another location, made the change, and remade the filesystem using v4.2 tools, then reinserted the new filesystem back into the image. Not exactly what the client wanted at first ... it only took a little persuasion to convince them that it was a more easily supported solution, as I didn't think I'd be able to reproduce the original incantation.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice