Archive for the ‘File System Forensics’ Category


Imaging an OLPC (One Laptop Per Child) XO-1

September 28, 2010


In July 2010, a team from the Computer Investigations and Forensics Division assisted with a search warrant of a residence. Prior to arrival at the location it was known that the suspect had above average knowledge of computer systems.

The team located an OLPC XO-1 computer that was still running during execution of the warrant. The suspect stated that he runs various versions of Linux on the system from SD cards and USB devices ranging in size from 512 MB to 32 GB. Upon seizure the team learned that the suspect had obtained an OLPC developer key that he used to customize the OLPC Linux OS. He was booting the system from an 8 GB SD card.

The OLPC has no internal memory except 1 or 2 GB (depending on the model of the OLPC) of NAND flash memory for the onboard operating system. The objective was to find a way to obtain a forensically sound image of the NAND flash memory. This paper walks through the steps taken in order to accurately obtain a forensic image of the internal flash memory.

Description of the device to be imaged:

OLPC  is an acronym for “One Laptop Per Child.” OLPC Inc. is a non-profit organization that provides children in underdeveloped countries with these basic computing devices. The idea behind manufacturing and distributing these inexpensive computers is that these devices will allow students to connect to the internet to download books and other educational materials.  Extended battery life and optional solar chargers are designed to make the devices easier to operate in remote areas.

The only external ports found on the OLPC are SD card and USB. Internal data storage consists of either  1 GB or 2 GB of NAND flash memory.  It has proprietary BIOS and is capable of booting to an OS on the NAND memory or to an OS on a USB drive or SD card. The  internal operating system is a Linux OS (Sugar[1]) installed on the NAND memory using the JFFS2[2] file system.

OLPC Opened and Booting

OLPC Opened and Booting


Our goal was to obtain a forensically sound image of the onboard NAND Flash Memory from the OLPC. This white paper will walk through the step by step process that we took to forensically image the device.


When the system was confiscated during the search warrant, there was an 8 GB SD card found in the OLPC. The suspect stated that he was booting to an OS on the SD card. We first obtained an image of the SD card using Encase. We then restored the operating system on to one of our own forensically sterile 8 GB SD Cards. The O.S. on the SD card was a version of Ubuntu Linux that the suspect had developed using his developer key.  The system was running a Linux flavor known as Sugar on the NAND Memory as the default O.S if a memory card wasn’t present during boot.

The tools we were expecting to use were: the OLPC machine to be imaged, the restored O.S. that the suspect was using, and a forensically sterile USB thumb drive where we saved the forensic images we obtained.   It is important to note that without a developer key the OLPC will not boot to a USB or SD device.  Our subject stated that he had been developing OS’s for the OLPC and had installed the developer key on his OS devices.  This paper does not address building a bootable OS and obtaining a developer key.

Step 1: We first booted into the proprietary BIOS of the system.  We found and ran a help command to familiarize ourselves with the commands for the OLPC . We learned that the default boot path was “SD:/boot/vmlinuz.” We were also able to determine that the BIOS was addressing the USB drive as “u:/” and the SD card drive as “SD:/”.

HELP Command Screen

“HELP” Command Screen

While in the Linux BIOS we made a back up of the NAND memory. The command used was:   “save-nand u:\nand.img”.  This provided us with a logical back up of the memory.  The file was in a proprietary format and we were unable to mount the file.  This gave us nothing of readable value.

Step 2: We first booted into the operating system, which had been restored onto an 8 GB SD Card. We were able to boot straight to the SD card by holding down “O” on the keyboard. The default user name for an OLPC is “OLPC” and the default password is “olpcolpc.” We were able to gain root access using the default password and user name through “su sudo” at a command prompt.  Our version booted into the xcfe environment.

Booting the OLPC to the Restored O.S.

Step 3: We were then ready to obtain a physical and logical image of the NAND memory.  It is important to point out that we did several online searches in an attempt to determine the mount point on the OLPC for the onboard flash memory.  While attempting to mount the image of the NAND memory, we learned that the file system used was the JFFS2 file system.  By passing the “-t JFFS2” option attempting to mount the image, we found a command, “mount –t JFFS2 /dev/mtdblock0” referring to NAND memory.  While we were unable to mount the backup image, we were able to mount the physical device, “mtdblock0”.

To obtain a physical image we first mounted our own wiped USB device.. This USB device was formatted with a FAT 32 files system. We then ran a hash of the physical NAND (mtdblock0). Next we imaged the NAND memory, writing it to our USB drive, and then hashed the image to verify its integrity. Below are the commands as they pertain to these steps:

Physical image:

  • mount /dev/sda /usb {mounted our USB in FAT32}
  • md5sum /dev/mtdblock0 {md5 of the physical NAND}
  • dd if=/dev/mtdblock0 of=/usb/nand.img {imaged}
  • md5sum /usb/nand.img {verified}

We also wanted to obtain a logical image of the NAND flash memory. We already had our USB device mounted, so we did not need to repeat that step. We first mounted the NAND flash memory and then copied the files logically over to our USB drive. We got an error saying , ”no symbolic link,” which we determined was because the NAND memory had a JFFS2 file format and we were mounting to a device that was formatted with FAT 32. The commands used were:

Logical image

  • mount –o ro –t jffs2 /dev/mtdblock0 /nand {mounted the NAND in read only mode to a directory we created called “/nand”}
  • cp –r /nand/ /usb/nand/ {recursively copy all files logically}
    • Numerous errors were generated for “no symbolic link” – our target file system FAT32 has no support for symbolic links

Step 4: Reviewing the Image.  We brought the USB device over to a forensic machine and added both the logical and physical images in to EnCase and FTKImager. The physical image had no readable data – neither forensic tool has support for JFFS2. The logical image did have readable data that could be used for analysis.  The logical files had a structure that was clearly an Ubuntu iteration – the “Sugar OS”.


We were able to obtain a copy of both the physical and logical NAND flash memory. For best practices, we would suggest that in future cases, the device used to save the images to should be in ext2/3 file format. This would prevent the “no symbolic link” errors we generated. It is a possibility that when we booted to the restored copy of the suspects OS we altered the NAND memory.  Overall, we were able to obtain a verified image of the suspects NAND memory that can be forensically analyzed.

We would also recommend that an examiner obtain a developer’s key from the OLPC project and create a sterile build of an operating system.  Using the suspect’s operating system to access the device leaves a number of questions unanswered: is it mounting the NAND memory, is it set to wipe the NAND, what if any changes will it make to the NAND?  These questions can be controlled using a custom built operating system by the examiner.


One Laptop Per Child. (n.d.). One Laptop Per Child. Retrieved August 2010, from

Sugar Labs. (2009). Sugar Labs Home. Retrieved August 2010, from Sugar Labs:

Wikipedia. (2010, August). Wikipedia: The Free Encyclopedia. Retrieved August 2010, from OLPC XO-1:

Woodhouse, D. (2003, July 09). JFFS2: The Journalling Flash File System, version 2. Retrieved August 2010, from Sourceware:

Analyst Team:

Team consisted of Paradigm Solutions Analysts Jeff Hamm, Kathryn Kendricks and Gaylon Thompson.

[1] Sugar is an Operating System based on Ubuntu. (Labs, 2009)

[2] JFFS2 is the Journaling Flash File System version 2. It was designed and optimized for flash media.  Currently many forensic tools lack support for JFFS2.  (Woodhouse, 2003)


exFAT 1.5

June 1, 2010

Additional information available in embedded tables.


Upcoming Engagements

May 20, 2010

I’ll be presenting the material found in the exFAT paper at:

Summerlin, Nevada
26 May, 2010 1400 hrs
* This will include a hands on exercise throughout the presentation to help illustrate the behavior of the files system.

SANS Forensic and Incident Response Summit 2010
Washington, DC
9 July, 2010 1050 hrs
* This will be co-presented with Robert Schullich, ISO



EnCase 6.14.3

December 30, 2009

EnCase 6.14.3 sees exFAT logically. Some initial issues:

– The starting extent (cluster) is not parsed out correctly on the FAT. Correct on the cluster location of a file (noted in EnCase as {volume}-C{cluster}.
– Dates and times are reported in LOCAL MACHINE TIME.
– exFAT time zones not reported.
– Incorrect interpretation of deleted folders.


Extended FAT (exFAT)

December 10, 2009

UPDATED: Time Zones Decoded on exFAT

The work herein is an excerpt from a Microsoft File Systems class being developed by Jeff Hamm for Paradigm Solutions and its clients.  Many examiners have had exposure to the FAT and NTFS file systems, but few have had training on Microsoft’s newest file system, Extended FAT (exFAT).  This information is provided as a base line to showcase the file system and explain the significance it will have in the computer forensic community.

The material provided was designed as a three hour presentation to be used in conjunction with progressive live demonstrations.  Time constraints will limit – and may exclude – the ability to effectively provide a series of live demonstrations of the file system.

At the time of this writing, AccessData and Guidance Software – the developers of the two highest profile forensic tools – do not have their forensic suites capable of viewing exFAT logically.  The tools will view the file system as an unallocated area or as free space.  WinHex is able to recognize the file system but will not display the logical folder structure.  Because of the efficiency of exFAT in maintaining contiguous files whenever possible, the examiner will have luck in retrieving file artifacts by data carving on an exFAT drive.  A need to show intent to possess, for a time line of a file, or for any other file system metadata to be presented as evidence will require an examiner to rebuild these file systems manually (for now).

The presentation and this paper begins with the history of the file system, discusses the reasons the examiner needs to be aware of the file system, details the forensic implications, and finally examines the technical details of the file system.  An appendix containing the compiled tables for locating data manually on the file system is also attached.  These tables are designed to be a quick reference resource for an examiner.

Much of the information was ascertained through research and testing by the author with additional research conducted by fellow examiners working alongside the author.  The Microsoft patent application for the file system was an invaluable tool to validate research and theories.  Finally, the independent research conducted by Jared Myers of the DCFL was critical in developing this material in the most complete and accurate fashion.

Click here to view the entire exFAT excerpt:  exFAT Excerpt 1.4