squashfsv4 extraction incomplete on old dlink DIR firmwares

[qkaiser]

The sample available at https://ftp.dlink.de/dir/dir-655/driver_software/DIR-655_fw_revc_302b05_ALL_de_20141121.zip is fully extracted by unblob but the content of extracted file is not right.

Steps to reproduce the behavior:

$ unblob -v -e /tmp/out -f -k /mnt/host/DIR-655_fw_revc_302b05_ALL_de_20141121.zip
$ file /tmp/out/DIR-655_fw_revc_302b05_ALL_de_20141121.zip_extract/DIR-655_fw_revc_302b05_ALL_de_20141121/DIR655C1_FW302B05.bin_extract/1441792-10207232.squashfs_v4_le_extract/sbin/arpping 

/tmp/out/DIR-655_fw_revc_302b05_ALL_de_20141121.zip_extract/DIR-655_fw_revc_302b05_ALL_de_20141121/DIR655C1_FW302B05.bin_extract/1441792-10207232.squashfs_v4_le_extract/sbin/arpping: empty

Expected behavior
The file should not be empty. They should be valid ELF binaries.

This is the actual content as extracted by a compiled version of unsquashfs provided by dlink within their GPL archive:

file squashfs-tools/squashfs-root/sbin/arpping 

squashfs-tools/squashfs-root/sbin/arpping: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

Environment information (please complete the following information):

• OS: Ubuntu 22.04, unblob vad81bc6
• running on dev env

Additional context
This behavior is observable on Ubuntu 22.04LTS and Kali 2023.1 but not on Kali 2022.1, which seems to indicate a regression introduced either in squashfs-tools or sasquatch.

Initially reported by @m-1-k-3

[qkaiser]

There is a discrepancy between squashfs-tools v4.3 used by the original sasquatch project and our fork of sasquatch that we rebased onto squashfs-tools v4.5.1.

Specifically in handling lzma-adaptive compression.

Output with 4.3:

./sasquatch -f -d /tmp/out/squashfs-root /tmp/sample.sqsh4
SquashFS version [4.0] / inode count [1218] suggests a SquashFS image of the same endianess
Parallel unsquashfs: Using 1 processor
Trying to decompress using default lzma decompressor...
Successfully decompressed with default lzma decompressor
1121 inodes (1470 blocks) to write
--snip--
Trying to decompress with lzma-adaptive...    <--- here LZMA adaptive detection works
Detected lzma-adaptive compression [65536]
created 815 files
created 97 directories
created 248 symlinks
created 0 devices
created 0 fifos

Output with our fork on 4.5.1:

SquashFS version [4.0] / inode count [1218] suggests a SquashFS image of the same endianess
Trying to decompress using default lzma decompressor...
Successfully decompressed with default lzma decompressor
Parallel unsquashfs: Using 1 processor
1121 inodes (1164 blocks) to write
--snip--
Trying to decompress with lzma-adaptive... <--- here LZMA adaptive detection fails
Trying to decompress with lzma-alt...
Trying to decompress with lzma-ddwrt...

It looks like we introduced a regression when applying the sasquatch patches back to v4.5.1. Probably a mismatch between LZMA patches and the updated squashfs-tools API.

If anyone wants to dig into this, that's where I would start: https://github.com/onekey-sec/sasquatch/pull/12/commits

Sadly a git bisect won't help us here because the entire sasquatch history is rebased on squashfs-tools v4.5.1 so we can't go back to a commit that relied on a previous version of squashfs-tools.

[qkaiser]

The sample is properly extracted in branch 4.3-sasquatch so it's definitely our move to 4.5.1 that broke it.