Open
Description
I have a sample with a non-standard signature (shsq):
binwalk 25a0cda1e50cf11d5f05067db815b91874d1518a.shsqv4
Squashfs filesystem, little endian, non-standard signature, version 4.0, compression:gzip,
size: 4148014 bytes, 3077 inodes, blocksize: 65536 bytes, created: 2016-11-30 21:07:07
If we put the right signature (hsqs), we get:
file 25a0cda1e50cf11d5f05067db815b91874d1518a.hsqsv4
Squashfs filesystem, little endian, version 4.0, zlib compressed, 4148014 bytes,
3077 inodes, blocksize: 65536 bytes, created: Wed Nov 30 21:07:07 2016
Neither the original sasquatch, this fork, or unsquashfs can extract them:
sasquatch 25a0cda1e50cf11d5f05067db815b91874d1518a.shsqv4
SquashFS version [4.0] / inode count [3077] suggests a SquashFS image of the same endianess
Non-standard SquashFS Magic: 'shsq'
FATAL ERROR: Block size or block_log too large. File system is corrupt.
sasquatch 25a0cda1e50cf11d5f05067db815b91874d1518a.hsqsv4
SquashFS version [4.0] / inode count [3077] suggests a SquashFS image of the same endianess
Failed to read compressor options
This is the header structure:
struct squashfs4_super_block:
- s_magic: b'shsq'
- inodes: 0xc05
- mkfs_time: 0x583f3f7b
- block_size: 0x10000
- fragments: 0x3f
- compression: 0x1
- block_log: 0x10
- flags: 0x63f
- no_ids: 0x1
- s_major: 0x4
- s_minor: 0x0
- root_inode: 0x5b3f0b3f
- bytes_used: 0x3f4b2e
- id_table_start: 0x3f4b26
- xattr_id_table_start: 0x3f3f3f3f3f3f3f3f
- inode_table_start: 0x3f5c70
- directory_table_start: 0x3fbadf
- fragment_table_start: 0x3f3401
- lookup_table_start: 0x3f4b00
They seem to be coming from a custom implementation of SquashFS from Broadcom, used by Netgear (see https://poppopret.org/2012/04/18/netgear-unsquashfs-c-version-1-3/), and Cisco (https://sandeen.net/wordpress/computers/uncompressing-cisco-x2000-firmware-images/) among others.
Blog posts are quite old and point to really old versions of squashfs, this one is the same non-standard signature but for squashfs version 4.0