Add support for non-standard SquashFS

[wcampbell0x2a]

unblob supports some non standard squashfs binaries, we should also.

https://github.com/onekey-sec/unblob/tree/main/tests/integration/filesystem/squashfs

They have a fork of sasquash for adding support https://github.com/onekey-sec/sasquatch

[qkaiser]

Don't hesitate to reach out if you want some samples or support with this. I shared a table with squashfs v2, v3, v4, and non-standard format in our last talk (slide 35 at https://www.blackalps.ch/ba-22/files/talks/BlackAlps22-Kaiser.pdf).

[wcampbell0x2a]

Thanks! I'll see when I get around to this. But looks like a never ending adventure.

[wcampbell0x2a]

Some TP-Link gpl code has the following patch to the kernel

$ diff -bur ./fs/squashfs ~/projects/linux/fs/squashfs > patch

--- /fs/squashfs/xz_wrapper.c	2021-11-09 09:57:38.000000000 +0000
+++linux/fs/squashfs/xz_wrapper.c	2023-01-17 04:18:38.293147873 +0000
@@ -39,10 +39,8 @@
 };

 struct comp_opts {
-	__le32 flags;
-	__le16 bit_opts;
-	__le16 fb;
 	__le32 dictionary_size;
+	__le32 flags;
 };

 static void *squashfs_xz_init(struct squashfs_sb_info *msblk, void *buff,

[wcampbell0x2a]

@qkaiser starting to look into supporting custom compression algorithms. Do they use the same custom compression for everything, as in all data and metadata blocks?

[qkaiser]

@qkaiser starting to look into supporting custom compression algorithms. Do they use the same custom compression for everything, as in all data and metadata blocks?

As far as I remember, yes. The only place we've seen something different is when they encrypt/obfuscate headers. So yeah, same compression applied to both data and metadata blocks.

[wcampbell0x2a]

Some TP-Link gpl code has the following patch to the kernel

$ diff -bur ./fs/squashfs ~/projects/linux/fs/squashfs > patch

--- /fs/squashfs/xz_wrapper.c	2021-11-09 09:57:38.000000000 +0000
+++linux/fs/squashfs/xz_wrapper.c	2023-01-17 04:18:38.293147873 +0000
@@ -39,10 +39,8 @@
 };

 struct comp_opts {
-	__le32 flags;
-	__le16 bit_opts;
-	__le16 fb;
 	__le32 dictionary_size;
+	__le32 flags;
 };

 static void *squashfs_xz_init(struct squashfs_sb_info *msblk, void *buff,

This is an openwrt patch: https://github.com/openwrt/openwrt/commit/f97ad870e11ebe5f3dcf833dda6c83b9165b37cb. Looks like that... mistake is now fixed and that patch not active: https://github.com/openwrt/openwrt/tree/master/tools/squashfs4/patches.

[qkaiser]

Looks like I need to add OpenWRT to the queue.

Is there a way to differentiate between a filesystem built with the patch and a filesystem built without the patch ? Any heuristics that you can use ?

[wcampbell0x2a]

Yep, its a different block length