Squashfs As A Forensic Container

“Every program has (at least) two purposes: the one for which it was written and another for which it wasn’t.”

– Alan J. Perlis

Alexandre Dulaunoy a@foo.be

version 1.0 - 2017-02-12

Digital forensic incident response (DFIR) is a critical field in the process of incident response. Analysing disks, removal devices or memory can be a long and tedious process but provide insightful information to better under the course of action of an incident along with the impact on the systems. When performing regular digital forensic, you know that the acquisition process and the storage of the evidences are important steps to ensure smooth, quick and accurate results. While reading the excellent book of Bruce Nikkel “Practical Forensic Imaging: Securing Digital Evidence with Linux Tools” there is a chapter dedicated to the use of “squashfs” as a forensic evidence container. The squashfs filesystem is often known by forensic examiners as used for embedded systems. But using it as forensic container is quite nifty (compared to other forensic containers), I decided to share my notes on how to use squashfs¹ as an evidence container.

Why using another forensic format?

Many forensic investigators used (knowing or not knowing about the underlying formats) existing forensic formats (from open and free standard up to proprietary format used by a single vendor). There are notorious open formats like “The Advanced Forensic Format” (AFF²) which provides a complete set properties recommended for storing forensic evidences and keeping the associated metadata. AFFv3 supports encryptions and digital signature on-the-fly while allowing to keep a single file for the forensic data and metadata. Many of tools require additional libraries or even proprietary software which is counter productive in an auditable DFIR software stack. AFFv3 and AFF4 are quite good candidates as forensic container. I did use some of these but there is major drawback is the ability to use all standard DFIR tools (from dc3dd, dcfldd to any obscure DFIR tools relying solely on raw images) without needing to install additional libraries to support access to the forensic containers.

Interesting Forensic Properties of squashfs

• squashfs is an append-only read-only file-system. A property required for archiving and especially forensic containers.
• squashfs provides a flexible and speedy seek-enabled archiving format. (think of a compressed tar file that you can mount)
• Compression is efficient compared to other solutions (everything is compressed from data, inodes to directory structure, block size can be customized to achiever better compression ratio and recent version supports fragment blocks).
• Duplicates are automatically detected and removed.
• a squashfs can be mounted as a loopback device and used transparently by any DFIR tools including Sleuthkit.

Practical usage

An issue when doing disk forensic is the capacity of your DFIR workstation. Acquired raw disks can take space and create significant challenges while performing analysis. Many acquired raw disks have usually very good compression ratio. It’s really where squashfs can help any forensic investigator especially to save time and space in your analysis process. As an example, I have acquired a flash card from a camera:

[adulau:~/disk-image] 130 $ hashrat -sha1 camera.dd 
hash='sha1:90b7e3f68eb91338b4adfb930f0c618514e83657' type='file' mode='100644' uid='1000' gid='1000' size='128450560' mtime='1486909752' inode='7342242' path='camera.dd'

Then if you add it in a squashfs container with mksquashfs:

[adulau:~/disk-image] 1 $ mksquashfs camera.dd evidence.shfs
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on evidence.shfs, block size 131072.
[==================================================================================================================================================================================================================|] 980/980 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments, compressed xattrs
        duplicates are removed
Filesystem size 5617.54 Kbytes (5.49 Mbytes)
        4.48% of uncompressed filesystem size (125444.05 Kbytes)
Inode table size 121 bytes (0.12 Kbytes)
        3.04% of uncompressed inode table size (3986 bytes)
Directory table size 29 bytes (0.03 Kbytes)
        93.55% of uncompressed directory table size (31 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 0
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 1
Number of uids 1
        adulau (1000)
Number of gids 1
        adulau (1000)
[adulau:~/disk-image] $ hashrat -sha1 evidence.shfs 
hash='sha1:034e5e62f69f3dc428fe29382d5a3da05932bf2e' type='file' mode='100644' uid='1000' gid='1000' size='5754880' mtime='1486909902' inode='7342598' path='evidence.shfs'

The evidence.shfs contains the original evidence and is 5.5MB large instead of 128MB. The container can be mounted back as a loop device:

[adulau:~/disk-image] 1 $ sudo mount -t squashfs evidence.shfs ./evidence-dir
mount: warning: ./evidence-dir/ seems to be mounted read-only.
[adulau:~/disk-image] $ cd evidence-dir/
[adulau:~/disk-image/evidence-dir] $ hashrat -sha1 camera.dd 
hash='sha1:90b7e3f68eb91338b4adfb930f0c618514e83657' type='file' mode='100644' uid='1000' gid='1000' size='128450560' mtime='1486909752' inode='1' path='camera.dd'

Now as the raw images are mounted via the squashfs, you can freely use your favourite forensic tools:

[adulau:~/disk-image/evidence-dir] $ mmls camera.dd 
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
     00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
     01:  -----   0000000000   0000000096   0000000097   Unallocated
     02:  00:00   0000000097   0000250879   0000250783   DOS FAT16 (0x06)
[adulau:~/disk-image/evidence-dir] 1 $ fls -o 97 -r camera.dd 
r/r 3:  CANON_DC    (Volume Label Entry)
d/d 4:  DCIM
+ d/d 517:  111___06
++ r/r * 1029:  _MG_0125.JPG
++ r/r 1030:    IMG_0126.JPG
+ d/d 518:  CANONMSC
++ r/r 183301:  M0111.CTG
v/v 4011523:    $MBR
v/v 4011524:    $FAT1
v/v 4011525:    $FAT2
d/d 4011526:    $OrphanFiles

This offers an endless door of opportunities especially that the DFIR investigator can continue to append evidences to the squashfs file like other memory or disk acquisitions, trusted timestamping notes or information. You can also easily share the squashfs container with other investigators (even on the same DFIR workstation) and ensuring a consistent investigation workflow.

Bruce Nikkel did a helper script called sfsimage to support the use of squashfs in forensic acquisition. It’s up to the investigator to decide if they want to use the standard tools or to make his own script. As the format is the same, you can safely use the script or/and rely solely on the squashfs tools.

References

• Practical Forensic Imaging by Bruce Nikkel

Footnotes