TinyCore: A Mighty Platform (Part 2)

TinyCore Linux is an ideal platform for building a light weight forensics distribution with the purposes I have in mind (See Part 1 of this post).  It is only a 10mb download for the base distribution and boots to a simple GUI desktop.  It boots and loads entirely into a ram disk as small as 48mb, but allocates as much ram as possible.  The ram disk makes TinyCore very fast because the entire operating system resides in ram and there are no drive seek time delays.

TinyCore uses a modern kernel with good hardware support and an xvesa video driver which all but insures a working GUI.  Applications are installed as modules (called extensions) that can be run at boot time or on demand.  The root file system and the applications are read-only and are renewed on every boot eliminating file corruption that can creep into installed software.

The Basic Structure

At its most rudimentary level, TinyCore consists of two files, the kernel (bzimage) and a compressed file system (tinycore.gz).  Add to that a means to boot the operating system, such as isolinux, and your full file tree is a simple:

./boot
./boot/isolinux
./boot/isolinux/isolinux.cfg
./boot/isolinux/isolinux.bin
./boot/isolinux/f4
./boot/isolinux/f2
./boot/isolinux/boot.msg
./boot/isolinux/f3
./boot/isolinux/boot.cat
./boot/bzImage
./boot/tinycore.gz

Making the Read-Only Environment

Attached storage devices detected by the kernel are identified by the udev daemon. Udev applies rules to the devices based on their type.  In the case of TinyCore, udev calls the /usr/sbin/rebuildfstab script to build the /etc/fstab file which contains the mounting options for the attached devices.  When the device is subsequently mounted (devices are not automatically mounted in TinyCore when attached), the mount options in the fstab file are applied.  One need only modify rebuildfstab mounting options to make the system mount devices read-only.

I have been able to modify the rebuildfstab file to mount devices read only and address other forensic mounting issues, like mounting ext3/4 devices as ext2 to avoid any possible journal changes and mounting physical devices as loopback devices to avoid attempted repairs of corrupted file systems on mount.

The process of modifying, adding, or removing files in the core file system is well documented here.  It involves decompressing the tinycore.gz file extracted from a TinyCore iso, making the desired changes, and zipping it back up.  The new tinycore.gz can then be remastered into a new iso.

Making Application Modules (Extensions)

Though new applications can be remastered into the core file system, I favor the modular approach implemented by the TinyCore developers.  Applications are compiled and the stored in a read-only squashfs file system.  The application, when installed, is mounted into the core file system.  Applications can be triggered to mount at boot time, or on demand.  On demand ensures quicker boot times and frees more space in the ram disk if the application is not needed in the session.  Though there is not gui method for this, installed applications can be "uninstalled" in the middle of the session by simply unmounting them and thus freeing ram allocated to them.

Though TinyCore has some suitable modules for forensics, like foremost for example, it lacks libraries and application such as libewf (Expert Witness imaging format), afflib (Advanced Forensics imaging Format), and sleuthkit (disk investigation tool) that a forensics practitioner would desire.  If you are familiar with building application from source, however, then building TinyCore application modules is a snap.  I have already built libewf, afflib, aimage, and sleuthkit modules and will submit them to the repository once I complete testing.  You can take a look at the building method here.

Persistence

Everything I've mentioned about TinyCore so far mentions "read-only."  The rebuildfstab script can be modified to ensure devices are mounted read-only, a must for live forensic examinations.  The core file system and application modules are mounted read-only ensuring a "clean" operating system and software environment with each boot.  But how does a user save evidence from examinations?

TinyCore allows the home directory to be saved to a storage device.  On shutdown, user data is written to the storage device designated by the user.  A boot option allows the device to be specified on the next boot to restore the user data, or it can be loaded after boot.

Putting it All Together

If you read Part 1 of this post, you know that my goal is the creation of a bootable disc/USB that an investigator with average computer skills (not a computer forensics practitioner) could use to search for and seize evidence from digital storage devices.  TinyCore, in my estimation, has it all:

1. Small size, loads entirely into ram, and fast with a simple GUI
2. Easily modified and remastered as a read-only environment
3. Easily add and created application modules with minimal ram impact
4. Means for easy creation and restoration of persistent storage

If one adds to the base a decent file browser, like ROX (I'll explain why I think this file browser is great option for forensic examination another time), a word processor (Abiword) with decent file format support, an audio/video player (VLC), and maybe a few other applications, and you have a light-weight, fast, and safe operating system that an investigator with basic computer skills can use to advance his case.

I have a basic version of this concept in place and am currently testing and refining.  I plan to host it on Google Code to get community feedback and to publish the changes I make to the core operating system.  I'll also host the modules I build there (at least until they are accepted into the TinyCore repository).  As always, I welcome any feedback.

TinyCore: A Mighty Platform (Part 1)

Last week I rediscovered TinyCore Linux.  I had taken a look at it about 6 months ago and was intrigued, but didn't have the time to explore it further.  However, I have been seeking a small Linux distribution on which to build a specialized forensics distro, and last week I gave TinyCore another look.

Background

I believe there is a need in computer forensics for an investigator with limited training to be able to search for and seized digital evidence from storage devices.  Some of the reason's I believe this are:

1. There are not enough trained forensic computer examiners to keep pace with the number of cases involving digital evidence.
2. The backlog created by a lack of examiners means cases don't get filed for month or even years after the discovery of the crime.  Meanwhile, the perpetrator is free to commit more crimes.
3. Prosecutors are less likely to pursue older cases, in part because witness recall becomes unreliable.
4. The majority of charges filed against perpetrators are settled out of court through plea bargaining.  

Therefore, in most circumstances digital storage devices are taken to computer forensics laboratories to search for evidence to support a filing of criminal charges.  But the labs are too busy to get to the examinations very quickly, and by the time they do, Prosecutors are reluctant to file charges because of the delayed filing and/or the perpetrators have been committing additional crimes.  I know this doesn't describe all situations, but it should ring true with most people in some manner.

Solution

The obvious solution is to increase the number of forensic computer examiners and computer forensics laboratories.  However, that isn't going to happen, at least not in the near and not-so-near futures.  And, since I'm a "work with what I've got" kind of guy, I've been working on another solution:

Criminal investigators need simple but effective tools to search for and seize evidence from digital storage devices.  The tools need to be forensically sound, i.e., they do not alter the original media in any way, but easy enough to use that a basic computer user can feel comfortable and conduct effective examinations.

Think about it this way: If a criminal investigator could retrieve his own digital evidence, he could file charges immediately, and most of the cases filed would be settled without the need of further forensic computer examination.  In cases that do not settle because the digital evidence is disputed, the storage devices could be sent to the computer forensics labs for more traditional analysis.

More cases filed, more perpetrators convicted, less workload at the lab!

But how do we create such tools?  Forensic boot discs like CAInE are great for experience investigators, and the latest version contains nautilus scripts to make live examinations like I'm contemplating here possible.  But the operating system is resource heavy, slow to boot from CD, and still to complicated for basic criminal investigators (for example, it is confusing and difficult for most basic users to mount a storage device read-write to collect evidence because the CAInE mounting policies rightly auto-mount devices read-only).  In other words, CAInE and other existing boot discs are not the right tool for users with limited computer forensics training.

TinyCore

I believe the best tool for criminal investigators with basic computer skills will:

1. Boot quickly (Criminal investigators may be in the field without the luxury of time.
2. Work in nearly any machine (basic video drivers, e.g., xvesa)
3. Not alter the media being examined (i.e., mount devices read-only)
4. Create an writeable storage location automatically (no command line or confusing the evidence device for the storage device)
5. Contain programs or scripts that are easily accessible to find evidence files (e.g., nautilus-scripts)
6. Create reports about files saved as evidence containing file metadata (so evidence can be commented upon by trained investigators, if needed)
7. Allow for the creation of forensic images (in the event the device cannot be seized).

TinyCore linux appears to be an ideal platform from which to build this tool.  And, I'll explain why in Part 2...