onekey-sec/unblob

Helping the user to identify "wrong" version of sasquatch

mzpqnxow opened this issue · 2 comments

mzpqnxow commented

Is your feature request related to a problem? Please describe.

A problem, caused by my own mistake (seems very unique to me, based on the fact that there seem to be no other users encountering this...)

I have several versions of sasquatch on my system, from years of handpatching as well as rebuilding from different branches of upstream repositories. I have kept most of the executables around, at least, but it's easy to forget which one I currently have the sasquatch in my $PATH symlinked to. Recipe for problems

I was reminded of this after experiencing a failure to unpack a squashfs-based file. The logs were very helpful thankfully and the issue was simple - the version of sasquatch that was currently "active" on my system (via my hacky solution of symlinking to whichever version is working best for my needs at the time) didn't support the -no-exit-code flag

Describe the solution you'd like

I'm not convinced this is worth the effort, so please feel free to close it - I'm just imagining less savvy users encountering this and possibly thinking there was some more esoteric issue causing unpacking to fail

It would be great to considering extending --show-external-dependencies such that it can perform additional validation - for example, checking the version output of tools where applicable, or checking for certain flags that may bubble up through mistakes such as the one I made

It's difficult for me to say what might be checked - perhaps -version / --version / -V or whatever, depending on the tool. In tools I've developed for personal use in the past, I've actually resorted to strings | grep _some_feature_name in a few cases - not a very elegant solution, but very reliable when the command-line output / behavior doesn't offer what you need

$ grep -q no-exit-code $(which sasquatch) || echo "U R DUM U NO FOLLOW INSTRUCTIONS? GET BETTER SASQUATCH THX"

^-- not a serious suggestion for an implementation

Anyway, do with this what you will. It may be best to close it until such a time other users encounter issues like this

Describe alternatives you've considered

The user should simply not be stupid and careless :)

Additional context

Here's my unblob output, it's from master as of a few weeks ago if I recall correctly:

11:19:12 › unblob --version
24.6.10
11:19:06 › unblob --show-external-dependencies
The following executables found installed, which are needed by unblob:
    7z                          ✓
    debugfs                     ✗
    jefferson                   ✓
    lz4                         ✓
    lziprecover                 ✓
    lzop                        ✓
    sasquatch                   ✓
    sasquatch-v4be              ✓
    simg2img                    ✓
    ubireader_extract_files     ✓
    ubireader_extract_images    ✓
    unar                        ✓
    zstd                        ✓

In case someone has this issue as well, here's what I saw in unblob.log

2024-09-06 15:05.56 [error    ] Extract command failed         command=sasquatch -le -no-exit-code -f -d '/path/to/some.bin_extract/12345-5678.squashfs_v4_le_extract' exit_code=0x1 pid=730078 severity=<Severity.WARNING: 'WARNING'> stderr=SYNTAX: sasquatch [options] filesystem [directories or files to extract]
	-v[ersion]		print version, licence and copyright information
	-d[est] <pathname>	unsquash to <pathname>, default "squashfs-root"
	-n[o-progress]		don't display the progress bar
	-no[-xattrs]		don't extract xattrs in file system
	-x[attrs]		extract xattrs in file system (default)
	-u[ser-xattrs]		only extract user xattrs in file system.
				Enables extracting xattrs
	-p[rocessors] <number>	use <number> processors.  By default will use
				number of processors available
	-i[nfo]			print files as they are unsquashed
	-li[nfo]		print files as they are unsquashed with file
				attributes (like ls -l output)
	-l[s]			list filesystem, but don't unsquash
	-ll[s]			list filesystem with file attributes (like
				ls -l output), but don't unsquash
	-f[orce]		if file already exists then overwrite
	-s[tat]			display filesystem superblock information
	-e[f] <extract file>	list of directories or files to extract.
				One per line
	-da[ta-queue] <size>	Set data queue to <size> Mbytes.  Default 256
				Mbytes
	-fr[ag-queue] <size>	Set fragment queue to <size> Mbytes.  Default
				256 Mbytes
	-r[egex]		treat extract names as POSIX regular expressions
				rather than use the default shell wildcard
				expansion (globbing)

	-trace			Enable verbose trace output
	-lc <value>		Set the lzma-adaptive lc parameter [0-4]
	-lp <value>		Set the lzma-adaptive lp parameter [0-4]
	-pb <value>		Set the lzma-adaptive pb parameter [0-8]
	-dict <value>		Set the lzma-adaptive dictionary size
	-lzma-offset <value>	Set the lzma-adaptive LZMA data offset
	-major <version>	Manually set the SquashFS major version number
	-minor <version>	Manually set the SquashFS minor version number
	-be			Treat the filesystem as big endian
	-le			Treat the filesystem as little endian
	-c[omp] <decompressor>	Specify the decompressor to use

Decompressors available:
	gzip
	lzma
	lzma-adaptive
	lzma-alt
	lzma-ddwrt
	lzo
	xz

The fix is to use the correct fork/build of sasquatch

I couldn't tell you which one I switched to as I had 3 of them in /opt/sasquatch/bin that I alternate between as needed, but I bet following the instructions from the start and not having any additional copies of sasquatch on your system would be sufficient to solve your problem

Thanks for your work on this project, really nice to see with binwalk on life support, hanging by a fork

nyuware commented

Hey @mzpqnxow,
First of all, thank you for the kind words!

An easy solution to your problem would be to use our docker image you can find here : https://github.com/onekey-sec/unblob/pkgs/container/unblob and use it as follow

docker run \
  --rm \
  --pull always \
  -v /path/to/extract-dir/on/host:/data/output \
  -v /path/to/files/on/host:/data/input \
ghcr.io/onekey-sec/unblob:latest /data/input/path/to/file

This way you wouldn't have to worry about your system dependencies as everything is already up to unblob standard inside the container

I hope this helps :)

  • 👍1
mzpqnxow commented

Hey @mzpqnxow,

First of all, thank you for the kind words!

An easy solution to your problem would be to use our docker image you can find here : https://github.com/onekey-sec/unblob/pkgs/container/unblob and use it as follow


docker run \

  --rm \

  --pull always \

  -v /path/to/extract-dir/on/host:/data/output \

  -v /path/to/files/on/host:/data/input \

ghcr.io/onekey-sec/unblob:latest /data/input/path/to/file

This way you wouldn't have to worry about your system dependencies as everything is already up to unblob standard inside the container

I hope this helps :)

It's good advice and I've been stubbornly ignoring the possibility of using Docker for several different projects (not only binwalk, unblob, etc.)

Perhaps it's time I listen and save us all the time and trouble

Thanks for the advice, seems I needed to hear it

  • ❤️1