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 http://www.laptop.org/en

Sugar Labs. (2009). Sugar Labs Home. Retrieved August 2010, from Sugar Labs: http://www.sugarlabs.org

Wikipedia. (2010, August). Wikipedia: The Free Encyclopedia. Retrieved August 2010, from OLPC XO-1: en.wikipedia.org/wiki/OLPC_XO-1

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

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)

%d bloggers like this: