onekey-sec / sasquatch Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU General Public License v2.0
sasquatch's People
Contributors
Watchers
sasquatch's Issues
cannot extract v4 big endian filesystem on little endian machine
SquashFS version [1024.0] / inode count [1761607680] suggests a SquashFS image of a different endianess
Reading a different endian SQUASHFS filesystem on /tmp/filesystem.image
FATAL ERROR: Block size and block_log do not match. File system is corrupt.
Incorporate upstream changes from 4.5.1
While I was working on creating an upstream package in NixOS, I was wondering how hard it would be to get it in sync with current squashfsTools there.
I created onekey-sec/sasquatch/4.5.1-sasquatch branch rebased on that release. I thought that rebasing, though more work than merging in upstream, it would result in clearer picture on what changed.
There is a fixed CVE that would warrant for the update as well: CVE-2021-41072
There is one notable change in functionality, that upstream moved lzma decompressor priority to the bottom.
How should we handle the update? push 4.5.1 overwriting the previous one?
Missing support for non-standard signature
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
sasquatch can't handle version 2 with non-standard (sqlz) magic
The attached sample (09bc2ac3b35d7475f6d2e2283c73ea275a9d6876.zip) comes from a TrendNet firmware.
When trying to extract it with sasquatch, we get the following output:
sasquatch -be /tmp/sample.sqlz
Non-standard SquashFS Magic: 'sqlz'
Reading a different endian SQUASHFS filesystem on /tmp/sample.sqlz
FATAL ERROR: Can't find a valid SQUASHFS superblock on /tmp/sample.sqlz
The old sasquatch version running on squashfs-tools 4.3 can extract the sample. We need to investigate which patch made it stop working and find a fix. Probably similar to #18
Reported by @m-1-k-3
Missing support for non-standard squashfs v4 big endian
By definition, squashfs version 4.0 is fixed little-endian. However, some implementations do not follow the standard and use big-endian. We'd like to add support for such non-standard filesystems.
A sample is available if you want, ask for 4e3fd06476376ec13c101d0362e06b6758288220
Lack of support for LZ4 compression
Came upon this sample during testing:
file f119d0e499e8350d6aa2c1ee0842f9fa5c2b4aee.squashfs.v4.lz4
Squashfs filesystem, little endian, version 4.0, lz4 compressed, 30152011 bytes, 1343 inodes, blocksize: 131072 bytes, created: Thu Apr 26 09:23:33 2018
sasquatch does not seem to be supporting LZ4 at this time:
sasquatch f119d0e499e8350d6aa2c1ee0842f9fa5c2b4aee.squashfs.v4.lz4
SquashFS version [4.0] / inode count [1343] suggests a SquashFS image of the same endianess
Filesystem uses lz4 compression, this is unsupported by this version
Trying to decompress with lzma...
Trying to decompress with lzma-adaptive...
Trying to decompress with lzma-alt...
Trying to decompress with lzma-ddwrt...
Trying to decompress with lzo...
Trying to decompress with xz...
read_block: failed to read block @0x1cc1524
FATAL ERROR - Failed to read xattr id table block 0, from 0x1cc1524, length 0. File system corrupted?
Would be nice to add support for it :) I can send the sample to anyone who asks.
squashfsv4 extraction incomplete on old dlink DIR firmwares
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 v
ad81bc6 - 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
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.