Cracking “qshs”: Extracting Vendor-Modified SquashFS from Embedded Firmware

Key Findings

• Vendor-modified magic bytes (“qshs”) defeated all standard extraction tools — but are a permutation of standard SquashFS bytes, not encryption
• LZMA compression in a SquashFS v3 container compounds the extraction barrier — standard unsquashfs cannot handle this combination even with a patched magic
• Five security findings were hidden behind the obfuscation — empty root password, hardcoded SSH key, default SNMP communities, extractable network identity credentials, and obsolete cryptography
• The magic byte modification delayed extraction by ~30 minutes — not days. It is obfuscation, not security.

1. Introduction

1.1 The Problem

Firmware analysis is a cornerstone of embedded systems security research. The standard workflow — dump flash, run binwalk, extract filesystems, analyze binaries — depends on tools recognizing the format signatures (magic bytes) embedded in the firmware image. When a vendor modifies these signatures, the entire automated extraction pipeline fails silently, and the analyst must diagnose and overcome the obstruction manually.

This is not encryption. It is not even obfuscation in a cryptographic sense. It is closer to a “lock” that only stops people who don’t know how locks work. But it is remarkably effective at raising the barrier to entry: an analyst who doesn’t understand filesystem internals will be stopped cold, while one who does can overcome it in minutes. This makes vendor-modified magic bytes an excellent subject for security education — the technique is pedagogically rich while being technically tractable.

1.2 Target Device

The Motorola/ARRIS SURFboard SB6141 is a DOCSIS 3.0 cable modem built on the Texas Instruments Puma 5 SoC (TNETC4830, ARM1176JZ-S, ARMv6, big-endian). The device uses a Macronix MX25L6406E 8 MB SPI NOR flash. The firmware was extracted via SPI flash dump using an Attify Badge programmer. The dump was verified with redundant reads (SHA-256: a98b4e20e15bb9323705f8ca1df01b2b34fc1993ace76f4b3f0c42cd7177ae6e).

1.3 Scope and Ethics

All work described here was performed on a personally owned, decommissioned device as part of the VCA-RE-101 Reverse Engineering of Embedded Systems curriculum at Virtus Academy. No active network connections were used. No ISP equipment was involved. The device was acquired at retail and is no longer in service. The SB6141 was discontinued by ARRIS/Motorola and is no longer manufactured or sold; ISPs stopped provisioning DOCSIS 3.0-only modems as networks transitioned to DOCSIS 3.1. The firmware analyzed dates from 2013-2016 and is no longer deployed on active cable networks.

2. Background: SquashFS Format Fundamentals

SquashFS is a compressed read-only filesystem widely used in embedded Linux devices. Understanding its structure is essential to recognizing and recovering vendor-modified variants.

2.1 Magic Byte Conventions

SquashFS uses a 4-byte magic value at offset 0 of the filesystem image to identify itself:

All four are permutations of the same four bytes {0x68, 0x71, 0x73, 0x73}. The vendor-modified magic is not random — it is a deliberate rearrangement of the standard bytes, presumably chosen so that a text search for “sqsh” or “hsqs” will fail while still being identifiable by the vendor’s own build tools.

2.2 Superblock Structure (SquashFS v3.x)

Immediately following the 4-byte magic:

2.3 Compression in SquashFS v3

Standard SquashFS v3.x uses gzip (zlib) compression. However, several embedded SDK vendors — notably Broadcom, Texas Instruments, and their downstream OEMs — patched the SquashFS tools to use LZMA compression instead. These patches were never upstreamed. The resulting images have standard SquashFS v3 superblocks but LZMA-compressed data blocks, which causes standard unsquashfs to fail with “gzip uncompress failed” even when the superblock is recognized.

3. Methodology

Our approach follows five phases. Each phase produces a specific artifact that feeds the next.

Phase 1: Identification — Is There a SquashFS?

Tool: binwalk (signature scanner)

Binwalk maintains an extensive signature database that includes standard and many non-standard filesystem magics. Even when the exact magic is not in the database, binwalk’s entropy analysis and heuristic matching can flag candidate regions.

binwalk firmware.bin

In our case, binwalk correctly identified the SquashFS:

778064  0xBDF50  SquashFS file system, big endian, version: 3.1,
                 compression: unknown, inode count: 402,
                 block size: 131072, image size: 2333794 bytes

Key observation: Binwalk identified the SquashFS despite the non-standard magic. It did this by matching the superblock structure (version fields, block size, inode count in plausible ranges) rather than relying solely on the magic bytes. However, it reported “compression: unknown” — a signal that something is non-standard.

Artifact: Offset and approximate size of the SquashFS region within the firmware image.

Phase 2: Extraction — Carve the Filesystem Image

Tool: dd or binwalk -e

Carve the SquashFS region from the firmware dump:

# If the SquashFS is inside a uImage Multi-File container,
# the offset is relative to the multi-file data start
dd if=Multi_Image_File.bin bs=1 skip=$((0xBDF50)) of=squashfs.img

Verify the carved image:

ls -la squashfs.img     # Should match binwalk's reported image_size
xxd -l 16 squashfs.img  # Examine the first 16 bytes

Artifact: A standalone SquashFS image file.

Phase 3: Magic Analysis — What Makes It Non-Standard?

This is the diagnostic phase. Examine the first 4 bytes:

xxd -l 4 squashfs.img
# Output: 71 73 68 73  "qshs"

Compare against the known SquashFS magic values:

magic = open('squashfs.img', 'rb').read(4)
print(f"Observed magic: {magic.hex()} ({magic})")

standards = {
    b'hsqs': 'SquashFS v4 LE (standard)',
    b'sqsh': 'SquashFS v3 BE (standard)',
    b'shsq': 'SquashFS v2 BE (legacy)',
    b'qshs': 'UNKNOWN — vendor modified',
}

if magic in standards:
    print(f"Identified: {standards[magic]}")
else:
    # Check if it's a permutation of the standard bytes
    standard_set = set(b'hsqs')
    if set(magic) == standard_set:
        print("Magic is a PERMUTATION of standard SquashFS bytes")
    else:
        print("Magic does not match any known SquashFS variant")

Key insight: If the observed magic is a permutation of {0x68, 0x71, 0x73, 0x73}, it is almost certainly a vendor-modified SquashFS. The vendor changed the byte order to break tool compatibility but kept the same bytes, presumably for easy identification by their own build system.

Artifact: Identification of the specific magic variant and confirmation that it is a permutation of standard SquashFS bytes.

Phase 4: Characterization — What’s Inside?

Before attempting extraction, characterize the superblock to understand what extraction tools will need to handle.

4a. Patch the magic and parse the superblock

Temporarily patch the magic to the standard value and use unsquashfs -s (superblock dump):

# Create a copy with patched magic
cp squashfs.img squashfs_patched.img
printf '\x73\x71\x73\x68' | dd of=squashfs_patched.img bs=1 count=4 conv=notrunc

# Dump superblock
unsquashfs -s squashfs_patched.img

Our result:

Found a valid big endian SQUASHFS 3:1 superblock
Creation or last append time Tue Feb 16 01:00:35 2016
Filesystem size 2333794 bytes (2279.10 Kbytes / 2.23 Mbytes)
Block size 131072
Inodes are compressed
Data is compressed
Fragments are compressed
Number of fragments 41
Number of inodes 402
Number of uids 1
Number of gids 0

This confirms: SquashFS v3.1, big-endian, 131 KB blocks, 402 inodes. The superblock is structurally standard — only the magic is modified.

4b. Identify the compression algorithm

Attempt extraction with the patched image:

unsquashfs -d rootfs squashfs_patched.img
# Expected failure: "gzip uncompress failed with error code -3"

The failure message “gzip uncompress failed” tells us the data blocks are NOT gzip-compressed. Examine the first data block (typically starts at offset 0x78 for SquashFS v3):

xxd -s 0x78 -l 8 squashfs.img
# Output: 5D 00 00 02 00 ...

The byte 0x5D at the start of a data block is the LZMA properties byte:

• 0x5D = lc=3, lp=0, pb=2 (standard LZMA defaults)
• Following 00 00 02 00 = dictionary size 0x00020000 = 131,072 bytes = block size

This confirms LZMA compression. The SquashFS v3 container uses LZMA instead of the standard gzip — a patch commonly applied in Broadcom and TI embedded SDKs.

Artifact: Complete characterization: SquashFS v3.1, big-endian, LZMA compression, 131 KB blocks, vendor-modified magic “qshs”.

Phase 5: Extraction — Build the Right Tool

Standard unsquashfs (shipped with squashfs-tools 4.x) cannot handle this combination because:

1. It does not recognize the “qshs” magic
2. Even with a patched magic, it cannot decompress LZMA in SquashFS v3 images (LZMA support was only added for v4+)

The solution is sasquatch — a patched version of squashfs-tools maintained by devttys0 (Craig Heffner) specifically for firmware analysis. Sasquatch adds:

• Auto-detection of non-standard magic bytes (including “qshs”)
• Multiple LZMA decompressor variants
• Automatic compression detection (tries gzip, then LZMA, then others)
• Big-endian/little-endian auto-detection

5a. Build sasquatch

git clone https://github.com/devttys0/sasquatch.git
cd sasquatch
./build.sh

GCC 14+ compatibility note: The sasquatch codebase (based on squashfs-tools 4.3) requires patches for modern compilers:

1. Signal handler signatures — GCC 14 enforces -Wimplicit-function-declaration as an error:

// error.h: change
void sigwinch_handler();
// to
void sigwinch_handler(int sig);
// Same for sigalrm_handler

2. Multiple definition of verbose — GCC 14 defaults to -fno-common:

// error.h: change
int verbose;
// to
extern int verbose;
// Add in unsquashfs.c:
int verbose = 0;

3. Linker flags — Remove -Werror from Makefiles, add -no-pie to LDFLAGS if DT_TEXTREL errors occur.

These fixes are mechanical and do not affect functionality.

5b. Extract

sasquatch -d rootfs squashfs.img

Output:

SquashFS version [768.256] / inode count [-1845428224] suggests a different endianess
Non-standard SquashFS Magic: qshs
Reading a different endian SQUASHFS filesystem
Trying to decompress using default gzip decompressor...
Trying to decompress with lzma...
Detected lzma compression
362 inodes (374 blocks) to write
created 280 files
created 40 directories
created 80 symlinks
created 2 devices
created 0 fifos

Sasquatch’s output reveals its detection process:

1. Reads the superblock, notices the non-standard magic and endianness mismatch
2. Switches to different-endian mode
3. Tries gzip decompression (fails)
4. Tries LZMA decompression (succeeds)
5. Extracts the full filesystem

Artifact: Complete extracted root filesystem — 280 files, 40 directories, 80 symlinks, 2 device nodes.

4. Results

4.1 Extracted Filesystem Overview

The extracted rootfs is a complete embedded Linux system built on the TI DSDK (DOCSIS Software Development Kit) v1.0.6.16:

4.2 Security Findings Enabled by Extraction

None of the following findings were discoverable without extracting the SquashFS. The vendor-modified magic was the sole barrier between the analyst and these results.

Finding 1: Empty root password.
/etc/shadow (via var.tar): root::10063:0:99999:7::: — the empty second field means no password is required. Combined with the serial console (/etc/inittab: tts/0::askfirst:-/bin/sh), physical access to the UART provides an unauthenticated root shell.

Finding 2: Hardcoded SSH host key.
/etc/rsa_key.priv is baked into the read-only SquashFS image. Every SB6141 unit running this firmware version shares the same RSA host key. An attacker who extracts this key from any unit can MITM SSH connections to all other units with the same firmware.

Finding 3: Default SNMP community strings.
/etc/agent_cm.cnf: read-community public, write-community private. SNMP v2c with these default communities gives any LAN-connected device read/write access to the modem’s DOCSIS configuration — frequency plans, power levels, provisioning parameters.

Finding 4: DOCSIS BPI+ private keys.
The JFFS2 config partition (separately extracted) contains the device’s DOCSIS BPI+ private key (dl_cm_key_priv.bin, 672 bytes). This key, combined with the X.509 certificate in the same partition, constitutes the device’s network identity credentials. Extraction of these credentials has implications for device authentication integrity across the DOCSIS BPI+ trust model.

Finding 5: Obsolete cryptography.
OpenSSL 0.9.8 (EOL December 2015, over 100 CVEs including Heartbleed-era vulnerabilities in the 0.9.8 branch), uClibc 0.9.29 (no security updates ever), Linux 2.6.18 (2006 kernel, hundreds of known CVEs across privilege escalation, memory corruption, and information disclosure classes). The entire software stack predates modern exploit mitigations (ASLR, stack canaries, SMEP/SMAP, seccomp).

4.3 What the Vendor Magic Obfuscation Achieved

The modified magic byte succeeded in:

• Causing unsquashfs (standard) to fail completely
• Causing sasquatch (pre-installed on many analysis distros) to fail if it was not built from source with SquashFS v3 LZMA support
• Raising the barrier from “run binwalk -Me” (5 seconds) to “diagnose, build tool, extract” (~30 minutes for an experienced analyst)

It did NOT:

• Encrypt any data
• Prevent extraction by anyone who understands SquashFS internals
• Resist automated tools that try multiple magic permutations
• Protect the security findings listed above from disclosure

5. Generalized Methodology

The five-phase approach described here applies to any vendor-modified filesystem, not just SquashFS. The key principles:

5.1 Trust Your Tools’ Structural Detection Over Magic Matching

Binwalk identified our SquashFS despite the non-standard magic because it matched the superblock structure — version fields, block sizes, inode counts in plausible ranges. Tools that rely solely on magic bytes will miss vendor-modified formats. Tools that validate structural consistency are more robust.

5.2 Magic Modification is Usually a Permutation, Not Invention

Vendors rarely invent entirely new magic values. They permute or rotate the standard bytes because this is the minimal change needed to break tool compatibility while still being machine-identifiable by their own build system. When you encounter an unknown magic near a suspected filesystem, check if the bytes are a permutation of a known magic.

5.3 Patch, Characterize, Then Build

Don’t try to extract with a patched magic and hope for the best. First patch the magic to parse the superblock (Phase 4a), identify the compression algorithm (Phase 4b), then select the right tool for the specific combination of format version + compression + endianness (Phase 5). This avoids the frustrating trial-and-error of running different tools blindly.

5.4 The Magic is Not the Only Obstruction

In our case, even after patching the magic, extraction failed because the compression was LZMA in a SquashFS v3 container. The magic modification masked a second non-standard feature (LZMA instead of gzip). Always characterize fully before attempting extraction.

5.5 Decision Tree

Firmware dump
  → binwalk identifies "SquashFS" with "compression: unknown"
      → xxd first 4 bytes
          +-- Standard magic ("hsqs" / "sqsh") → try unsquashfs
          |   +-- Succeeds → done
          |   +-- Fails ("gzip uncompress") → LZMA/LZO compression
          |       → Build sasquatch → extract
          +-- Non-standard magic (permutation of standard bytes)
              → Patch magic to standard → unsquashfs -s (superblock)
                  +-- Superblock parses → filesystem structure is standard
                  |   → Check compression (examine first data block)
                  |       +-- 0x5D at data start → LZMA
                  |       +-- 0x1F 0x8B → gzip
                  |       +-- Other → LZO, ZSTD, or unknown
                  |   → Build sasquatch (handles magic + compression) → extract
                  +-- Superblock fails → deeper modification (custom layout)
                      → Requires reverse engineering the vendor's mksquashfs

6. Tool: sasquatch

6.1 What It Is

Sasquatch is a patched version of squashfs-tools 4.3 maintained by Craig Heffner (devttys0) for firmware reverse engineering. It is the de facto standard tool for extracting non-standard SquashFS images from embedded firmware.

Repository: github.com/devttys0/sasquatch

6.2 What It Handles

• Standard SquashFS v1, v2, v3, v4 (both endiannesses)
• Non-standard magic bytes (auto-detected, including “qshs”, “shsq”, and others)
• LZMA compression in SquashFS v3 (not supported by standard unsquashfs)
• LZO compression variants
• Automatic endianness detection and correction
• Automatic compression detection (tries each decompressor in sequence)

6.3 Building on Modern Systems

The build script ./build.sh handles dependency installation and compilation. On modern systems (GCC 14+, 2025+), the compatibility patches described in Section 3, Phase 5a are required. A Docker container with an older GCC (12 or below) may avoid these issues.

6.4 Limitations

• Sasquatch cannot handle truly proprietary filesystem formats — only standard SquashFS with modified magic and/or non-standard compression.
• Some vendors modify the superblock layout itself (not just the magic). These require reverse engineering the vendor’s mksquashfs from the GPL source release.
• Sasquatch does not support SquashFS v4 with non-standard compression (e.g., vendor-patched ZSTD). Standard squashfs-tools 4.x handles most v4 variants.

7. Prevalence: Where This Technique Applies

Vendor-modified SquashFS is common across the embedded device landscape. Known instances include:

The “qshs” magic appears to be specific to the Motorola/ARRIS DOCSIS modem firmware line. It may have been introduced by TI in the Puma 5 SDK, or by Motorola in their customization layer — the GPL source for squashfs-tools would confirm this, but was not available at the time of this writing.

8. Recommendations

For Analysts

1. Always examine the first 4 bytes of any suspected filesystem image before concluding it is corrupted or unknown.
2. Build sasquatch from source and keep it in your toolkit alongside standard unsquashfs. The two-minute build time saves hours of frustration.
3. When binwalk reports “compression: unknown”, treat it as a strong signal that vendor-specific tooling is needed — not that the data is corrupted.

For Vendors

1. Magic byte modification is not a security control. It delays extraction by minutes, not days. If the goal is to protect firmware contents, use authenticated encryption of the filesystem image.
2. LZMA compression in SquashFS v3 is a maintenance liability. It requires custom build tools, custom extraction tools, and creates long-term GPL compliance challenges. Standard SquashFS v4 supports LZMA natively.
3. The security findings we discovered (empty passwords, hardcoded keys) are not protected by magic obfuscation. They are design flaws that exist regardless of whether the rootfs is easy or hard to extract.

For Educators

This sequence — automated tool failure → manual investigation → tool adaptation → successful extraction → security findings — is an ideal laboratory exercise. It teaches:

• Filesystem format internals (not just tool invocation)
• The difference between obfuscation and encryption
• Tool building from source (essential for any RE practitioner)
• The reward structure of embedded analysis (security findings are behind extraction barriers)

9. Conclusion

The “qshs” vendor-modified SquashFS magic on the Motorola/ARRIS SB6141 is a representative example of a common embedded firmware obfuscation technique. Our five-phase methodology (identification, extraction, magic analysis, characterization, tool adaptation) provides a systematic approach that generalizes beyond this specific device. The key insight is that vendor magic modification is almost always a permutation of standard bytes — recognizing this pattern reduces the problem from “unknown format” to “build the right tool.” The sasquatch project by devttys0 remains the most effective general-purpose extraction tool for these scenarios, though it requires source-level patches for modern compiler compatibility.

The security findings enabled by extraction — empty root password, hardcoded SSH key, default SNMP communities, extractable network identity credentials — underscore that firmware obfuscation without encryption provides no meaningful security. The magic byte change delayed our extraction by approximately 30 minutes. The security vulnerabilities it concealed have been present in deployed devices since at least 2013.

References

1. Heffner, C. “sasquatch: A set of patches to the standard unsquashfs utility that enable extraction of all types of vendor firmware images.” github.com/devttys0/sasquatch
2. Lougher, P. “squashfs-tools: Userspace tools for creating and extracting SquashFS filesystems.” github.com/plougher/squashfs-tools
3. Costin, A., Zaddach, J., Francillon, A., Balzarotti, D. “A Large-Scale Analysis of the Security of Embedded Firmwares.” USENIX Security Symposium, 2014.
4. Shoshitaishvili, Y., Wang, R., Hauser, C., Kruegel, C., Vigna, G. “Firmalice — Automatic Detection of Authentication Bypass Vulnerabilities in Binary Firmware.” NDSS, 2015.
5. Chen, D.D., Woo, M., Brumley, D., Egele, M. “Towards Automated Dynamic Analysis for Linux-based Embedded Firmware.” NDSS, 2016.
6. Rodrigues, B. “ARRIS Cable Modem has a Backdoor in the Backdoor.” w00tsec.blogspot.com, November 2015. w00tsec.blogspot.com
7. Magasweran, L. “Flashing forceWare on SB6141.” Hackaday.io. hackaday.io/project/20063
8. SquashFS specification (informal): dr-emann.github.io/squashfs/