Search This Blog

Sunday, December 12, 2010

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:


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.


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.

Time Perspective

Time Perspective Telling time in forensic computing can be complicated. User interfaces hide the complexity, usually displaying time stamp...