Sleepwaking

No, the title of this post is not in error.  I don't mean "sleepwalking."  I meant what I said: sleepwaking.

Those who know me know I am a proponent of "previewing" computers for content before conducting a full forensic exam.  There are many reasons for this including the most common purpose: triage.  Previewing entails booting the computer with a forensic boot disc such as CAINE which prevents writes to the media being examined, and examining the file system(s) on the attached storage devices for evidence related to the investigation.

There are, of course, limitations to Previewing approach that I won't discuss here, But there is a danger that I feel must be discussed: Previewing the computer that is in a sleep or hibernated state which is commonly (but not exclusively) found in laptop computers.  Dropping a forensic boot disc into the CD drive (or using a USB incarnation) will not prevent the computer's operating system from running and changing data on storage device.  So, what is a person to do?

For sake of this discussion, envision a laptop computer with a single internal hard disk drive with an Windows operating system in a hibernated state.  Booting the computer after inserting a forensic boot disc will NOT preserve the data on drive, because the BIOS detects the hibernated state and begins restoring the contents of the hyberfil.sys file to RAM and restores the operating system to a running state.  If you interrupt this restoration, quickly enough, you will find that the data on the hard disk drive hasn't changed, but metadata (access times) will be changed.  Depending on the version of Windows installed, you still may not get a boot selection screen the next time you boot (Windows 7 comes to mind).

The best practice in my experience is as follows:

1. remove the hard drive from the computer.
2. insert your forensic boot disc .
3. boot the computer and access the BIOS or boot selection menu (ensure you can select the boot disc as the boot device)
4. reinstall the hard disk drive.
5. reboot the computer and boot into your forensic environment.  The BIOS will not now automatically attempt to restore the resident OS from hibernation.

And don't forget that the hibernated system has saved what is essentially a RAM image in the hyberfil.sys.  I guess that's what you call a "twofer."  It takes a different shape in Macintosh and Linux systems, but RAM contents are available in those hibernated operating systems, too.

Of course, true "sleeping" is different than hibernation, though the line has been blurred since Windows Vista.  A true "sleep" state suspends the computer, preserving the running state by providing power to RAM in order to retain data.  It is usually indicated by a flashing power light and the data disappears scant seconds after loss of power.  On the other hand, Windows Vista introduced "Fast Sleep" that also saves the RAM content to hard disk in conjunction with providing power to the RAM.  The investigator will have to make his/her own decisions based on the details of the investigation on how to handle a sleeping computer (e.g, wake it and save volatile memory before shutting down the system or abandoning the RAM contents by pulling the drive).

Garmin GPS: What you don't know can track you!

Garmin GPS devices track their position by default (caveat: at least every device I have been given to examine!).  They will do so, approximately every 30 seconds, when powered on.  Notice I said nothing about navigating.  Simply powering the devices causes them to start logging their location.  While this feature can be disabled, it is buried in the settings and I suspect that most users are not even aware of it.

The data is stored in a GPX file, also know as the Global Positioning Satellite (GPS) Exchange Format.  The most current track, appropriately named "Current.gpx," is stored in the "/Garmin/GPX" directory on the device.  Older tracks are stored in "/Garmin/GPX/Archive" directory.  The archives take on the name ".gpx," e.g,. "1.gpx," "2.gpx," etc.  I have never seen more that 17 archived files, but I don't know if this is a system limitation or just a coincidence that I have seen it more than once.  The history can cover quite a time span: my most recent examination revealed a history of 6 months!

GPX files are in xml.  The Current.gpx file can have interesting entries, including the "Home" address of the device owner.  I have used this setting to reunite stolen devices with their owners or thieves back to their homes. But the most interesting information is the device track, which consists of a series of GPS waypoints or "trackpoints" recorded by the device.  Here is a sample from an archive file:

There are many ways to handle a GPX file, but I have found it is most useful to convert it to a KML, or Key Hole Markup Language, file for use with Google Earth.  While I know that Google Earth is not an open sourced application, and other tools like "gpxviewer" can map the GPX file directly, most of the people I support are Windows users that have experience with Google Earth.

There are two methods I am aware of for creating KML files.  The first is using an online resource, like GPSVisualizer.  Just complete the online form and upload your file to make a map that meets your requirements.  Other formats, besides Google Earth, are possible, including Google Maps, JPG, PNG, SVG, and text.

I don't like to rely on websites, however, because Internet connectivity is never assured.  Enter GPSBabel.  GPSBabel is a command line tool (gui available) to convert over 100 different types of GPS data formats.  A basic conversion can be as simple as:

gpsbabel -i gpx -f input.gpx -o kml -F output.kml

There are numerous options, that I won't cover here, to customize your output file.  They include labeling the way points with the date and time they were created, allowing you to easily visualize the track.  I'd recommend the use of a GUI to familiarize yourself with the customization options, though be aware that the GUIs seldom provide all available options.

I have used Garmin GPX files to map a suspects' travels and place him them at crime scenes.  I hope with this information you will be able to do so, too!

Sleuthkit 3.2.0 Released

A new version of The Sleuth Kit (TSK), a command line forensics tool set for both Linux and Windows, was released a few days ago.  This release brings new automation tools that can greatly speed processing.  Brian Carrier, the developer, describes the release thusly:

New features include:
   • New tsk_recover tool that extracts files from an image to a local directory.
   • New tsk_loaddb tool that dumps file system metadata to SQLite database.
   • New tsk_getimes tool that collects MAC time data on all file systems (equivalent to fls -m on a series of volumes)
   • New tsk_comparedir tool that compares a directory to an image to detect rootkits.
   • New C++ TskAuto class that makes it easier to create automated tools that analyze all files.
   • Name cleanup out of libraries and into tools.
   • img_cat -e and -s flags.
   • Changed how default NTFS $Data attribute is named.
   • HFS+ Case sensitive flag in fsstat.

Bug fixes include:
   • FAT performance
   • Crash fix for corrupt NTFS file
   • Adding attribute runs on fragmented files with multiple attributes of the same type.

I can personally attest to the benefits of the tsk_loaddb tool.  It very quickly creates a sqlite database containing file system metadata for each volume in the forensic image.  The database can be queried for any data sought in a fraction of the time it takes to read a file system itself.

A knowledge of  basic sqlite commands is essential to take advantage of the database, but with that knowledge, it is quite easy to script tools for your use.  For example, I wrote a shell script that reads the database and automatically mounts all the partitions read-only for quick evaluation.  This, of course, is only one small way that data can be used.

For a concise overview of all the tools that TSK has to offer, take a look at the wiki located here.