In the previous demo,
we used Binwalk's native ‑e option to extract the entire contents
of the firmware image file in one big blob,
but we might not always want to extract the entire image.
So in this demo,
we'll look at another technique to carve out the
Squashfs and LZMA segments separately.
When we run Binwalk against the extracted firmware file,
it identifies the number of bytes into the file at which that segment starts.
The boot segment starts at 53,536 bytes and runs to 66,048 bytes.
The LZMA partition starts at 66,048 bytes and so on.
Incidentally, it makes you wonder what's in that first 53 KB,
but that's 1 for another day.
We can extract specific sections of the firmware file using the dd command.
Dd is a NICs‑based utility for converting and copying files.
We begin with dd followed by if to specify the input file as our firmware image.
We then specify the skip option to jump to the segment at
which the Squashfs filesystem starts.
If we don't specify the number of bytes to read using count,
then dd will read to the end of the file,
which is what we need here.
We'll see how to use count when we extract the LZMA compressed data.
Next,
we specify the name of the output file as Linux because we expect to get
a Linux file system tree and set the block size to 1,
which means we want dd to read 1 byte of the image at a time.
And in just under 10 seconds, we get a compressed squashfs filesystem,
which we can very quickly unsquashfs.
We get a few errors because we didn't run unsquashfs,
a super user, however, we can safely ignore them for the purposes of this demo.
Changing into the squashfs‑root directory,
we see that we have the Linux file tree we obtained using Binwalk's ‑e option.
Progressing once again into the etc directory,
we find the interesting sounding passwd.bak file.
In an earlier demo,
we looked inside the passwd.bak file and found a username and
password hash combination that we could try to crack.
Let's try running John the Ripper against the password file.
John the Ripper is an open source password security auditing and password
recovery tool available for most operating systems.
John is highly configurable,
but we can try its default crack mode by calling john
followed by the password file name, and in just a few seconds,
John has cracked the admin password 1234.
There is more we can explore in the Linux file system,
but we'll come back to that later.
Let's take a look at how we can carve out a segment
that's in the middle of a file.
The LZMA compressed data section starts after the bootloader
section at byte 66,048 and continues to the start of the
Squashfs filesystem at about 1 MB.
A quick calculation shows that the LZMA compressed
data section is 982,528 bytes long.
However, that's not to say there is 982,528 bytes of data,
that's just the amount of space available for data to be stored.
There'll likely be a bunch of junk data after the legitimate LZMA data,
and we'll need to find a way to trim that out.
We call dd as we did before using if to specify the input file name and skip to
specify the starting byte of the segment we want to extract.
We then set the count option to specify the number of bytes we want to extract,
the number we calculated in the previous step.
Finally, we specify the output file name as something.lzma,
and again, set the block size to 1 to specify a byte‑wise copy.
I mentioned earlier that we know where the LZMA data starts,
but we don't know where it ends.
However,
we can use the LZMA command followed by ‑d for decompress
and pass it to something.lzma file.
We can then output it as another file,
which will cause it to discard any trailing garbage in the file.
We get a message stating that the compressed data is corrupt,
but it's not so we can ignore that.
Running binwalk against the newly decompressed file,
we see a number of different segments.
We have some small segments at the beginning with kernel and
error‑checking data followed by some xd compressed data,
which may be worth looking at in more detail.
We then have some ASCII cpio archive files.
CPIO files are used to back up and restore files and ASCII
versions have human‑readable header information,
meaning that if the file has been archived are also ASCII,
then the whole archive is ASCII.
Let's analyze the information entropy of the file to see what this means.
Now sure enough, the majority of the latter parts of the file,
the region where the ASCII cpio archive files reside,
show an entropy value well below 0.7 suggesting that,
for the most part these regions are not obfuscated.