Using RegRipper inside Encase Enterprise

May 31, 2011

By now I am sure everyone has heard about the registry parsing tool RegRipper that uses plugins to parse through predetermined registry paths to pull out relevant information. Normally to use RegRipper you must locate your registry hives, blue-check within Encase Enterprise and then copy them out to an export folder. Then launch Regripper and browse over to the hive files and run the tool then open the resulting report. There is another way of using this tool inside of Encase without having to copy anything out of Encase and it is not necessary to mount the image as a mounted drive. In order to do this you need to use the 3rd party viewer inside of Encase. I have created a batch file for each current plugin that RegRipper uses and placed those in the RegRipper folder on my hard drive. I then created a command line inside of Encase telling Encase I want the command prompt to open to “C:\RegRipper” and execute a particular plugin against the highlighted hive file that I have highlighted and create a report based upon that plugin and place the report in the “C:\Temp\[plugin_name.txt.”

In other words the application path would show “C:\Windows\System32\cmd.exe” and the command line shows: ” /S /D /K c:\\regripper\\bat_files\\aim.bat [file] This opens the command prompt and runs the aim plugin. The corresponding batch file looks like this:

cd \
cd \regripper\
rip.exe -r %1 -p aim >> c:\temp\aim.txt

What this allows an examiner to do is run one particular plugin against a given hive file without having to copy anything out and without having to run all the plugins for that particular hive file and then dig through a text report for the information you are looking for. If you feel this is something you would like to try out then please do so and provide some feedback on your thoughts.

I have uploaded all the batch files and the .ini viewer configuration file from Encase to the following link: http://www.box.net/shared/7pppe36n5g.

Place the “bat” files in a directory call “Bats” into your regripper folder and place the viewer.ini file into the “Program Files\Encase\Config\.” This is setup with the assumption that your Regripper folder is in the root of your “C:\” drive and that you have temp directory in the root of your “C:\” drive as well. If you have those folders someplace else then you will need to update the ini file and the batch file for each plugin.

I am sure there are easier ways of doing this and maybe the scripting can be better but either way leave your comments here. Also remember if you come up with additional plugins that would be beneficial to the rest of us please pass them along to everyone.
If you would like the batch files and ini files mentioned you can contact me through my email address: of markmorgan@paradigmsolutions.com.


Digital Smoke, The Art of Incident Response, Part II

January 6, 2011

The first installment of the series Digital Smoke: The Art of Incident Response discussed the modern threat environment. The analysis of the threat environment was juxtaposed with the traditional methodology of responding to a scene where there is a running computer, namely, pulling the plug. The conclusion of the first installment was that the modern threat environment is such that pulling the plug on a running computer is not only undesirable but may inadvertently destroy any chance of obtaining the information needed from the computer.

This, the second installment of the series, will address the issue of defining incident response. Although the term incident response appears self explanatory, its meaning within the field of computer forensics and cyber-based investigations is anything but clear. The purpose of this article is to define the incident response space, in an effort to enable forensic professionals, law enforcement and responders to better prepare for the inevitability of responding to a scene with a running computer. To fully define incident response it must be differentiated from the terms with which it is often used interchangeably. Therefore, this article will examine the terms, forensic preview, triage, and incident response and the characteristics that constitute them.

Forensic Preview

The process of viewing files on the subject’s computer in it’s native environment constitutes a preview. A forensic preview is one which uses forensically sound bootable media on the subject’s computer to view the files on the computer without making any changes to the data (Lewis, 2008). The process of using bootable media to conduct a forensic preview indicates that if the computer is running, it must be restarted with the forensic media inserted. Forensic Preview’s are often conducted in eDiscovery or administrative environments.

Characteristics of Forensic Preview

The Forensic Preview process can best be characterized as a sterile environment. The environment is made sterile by booting from a forensically validated media source that contains trusted tools or an entire integrated user interface. Typically Forensic Preview tools provide features for viewing, searching, hashing, exporting and reporting. Therefore, there is little risk for the responder to inadvertently change or alter data contained within the target machine. In addition, the Forensic Preview is designed to provide a speedy, albeit relatively cursory, insight into the whether or not the allegations are supported and further action warranted. Lastly, the Forensic Preview does not require a high level of computer expertise or in-depth training for the responder to perform.


Triage is the process whereby time sensitive evaluations (made so by an imminent danger or threat) are conducted resulting in the establishment of work priorities (Lewis, 2008). The most critical of tasks is promoted to the top of the priority list and so on in descending order. It is this critical nature of triage that is the most overlooked aspect in differentiating terminology in the field of computer forensics. Therefore, many processes for the responder are termed as triage, however, upon closer examination, triage for the responder to a running computer occurs only during the initial contact, whereby the destruction of data, either intentionally or unintentionally, is likely to occur and immediate action to counteract the destruction must be taken.

Characteristics of Triage

The environment for triage is stressful in that every moment of indecision can have disastrous consequences. Given the time sensitive nature and severity of the situation, responders must be well versed in the methodologies for interrupting data destruction as it is occurring on a running computer. However, additional specialized training is not a requisite for the responder to be successful. Traditionally, the method of pulling the plug on a running system is the fastest and safest way to stop destructive activity, however, there are a number of alternatives that may be warranted in other situations. Lastly, there are no specialized tools for triaging a running computer to stop destructive activity, therefore, manual procedures are the only viable alternative.

Incident Response

For the purpose of this article, incident response is defined as those actions taken on a running computer to obtain volatile and critical data and to prepare it for further forensic examination (Lewis, 2008). In other words, incident response is an approach, containing a series of actions, specifically designed to capture data that will become unavailable once the computer is powered off.

Characteristics of Incident Response

Incident response is characterized by a dynamic environment that requires a high level of technical skill to successfully negotiate. Responders performing incident response must be versed in triage methodologies, be prepared to act according to the status of the computer, transition smoothly into data capture, provide documentation of findings and prepare the computer for possible removal from the scene and transport to a forensic laboratory for an in-depth analysis.

There are two methodologies for incident response, which are not entirely mutually exclusive, manual and automated. The capturing of volatile and critical data manually can be time consuming and prone to errors. Likewise, the automated approach cannot possibly account for every scenario that will confront the responder. Therefore, the responder should ideally be well versed in the manual procedures and have access to a variety of automated tools.

As discussed in Part 1 of the series, the threat environment is substantial. The training of the responder should be inextricably linked to the threat environment. The well trained responder therefore should have a base understanding of computer networks, encryption, computing processes, various operating systems and much more.

General Response Strategies

Triage Phase

It is imperative that some form of incident response be performed on-scene whenever there is a running computer. As such, broad guidelines can be established. Assuming officer safety has been accounted for, the on-scene assessment must be made to determine the necessary course of action. This is similar to emergency medical personnel arriving at the scene of an accident. The medical personnel use the “ABC” (airway, breathing and circulation) acronym to assess injuries and establish priorities of work (triage). In a digital crime scene, the priority of work is focused on preserving potential evidence. By following the acronym “STU” responders of the digital crime scene now have an approach to effectively control the situation – stop destructive activity, take volatile and critical data and unplug the system for removal to a lab for further analysis (Lewis, 2009).

The actions the responder takes to stop the destructive activity (triage) depend on the type of activity taking place. If the destruction is intentional, the only viable option may be to pull the plug on the system. If the destructive activity is unintentional, it may be as simple as stopping running processes, removing a network cable or even removing liquid spilled on the computer. Once the destructive activity as been stopped, and if the computer is still running, the responder has a chance to capture volatile and critical data.

Incident Response Phase

Capturing volatile data on a system can be accomplished manually or through automated tools. As previously mentioned both manual and automated responses have their achilles heel. A combination of automated tools and manual processing, provides the best chance for successfully capturing volatile and critical data in the digital crime scene. However, tools and techniques for capturing data should coincide with the expected lifespan of data chart (Farmer and Venema, 2004, p. 6). By considering the Order Of Volatility (OOV) Farmer and Venema (2004) have created a template based on the likelihood of the data remaining viable for capture. Aside from network and system processes, additional data should, depending on the circumstances, also be captured. Generally, data that resides on the hard drive is left for the in-depth forensic examination likely to occur in a laboratory environment. However, organizations and responders thereof, should consider the potential that the data on the drive may become inaccessible once the drive is powered off. Two major reasons data can become inaccessible after a drive is powered off is encryption and hardware malfunction. Therefore, if during the incident response data capture process, the responder can capture data that would be considered critical to the case, it would be prudent to do so. For example, if the case centered around a set of images, it is possible to capture the images or the entire folder containing the images, for use as best evidence should the hard drive later become inaccessible. Lastly, there should be a procedure in place for the responder to formalize a report and prepare the computer assets for transportation to forensic laboratory.


In this article the terms Forensic Preview, Triage and Incident Response have been defined and characterized. The differences between these terms and what constitutes them should enable organizations to plan for education and training of their responders, purchase necessary tools, and develop appropriate response strategies. By being prepared for the modern threat environment, responders will enable organizations to achieve a greater success rate in obtaining the requisite information to move their investigations forward.


Farmer, D, & Venema, W. (2004). Forensic Discovery. Addison-Wesley, Upper Saddle River, NJ.
Lewis, A. (2008). Hybrid Theory Forensics. High Tech Criminal Investigator’s Association (HTCIA), Atlantic City, NJ.
Lewis, A. (2009, July-December). Digital Smoke: The Art of Incident Response. The Informant, 6(2), 26-27.


Digital Smoke: The Art of Incident Response Part I, by Al Lewis

December 10, 2010

The following article is one in a series of articles I am writing on Incident Response, titled, “Digital Smoke, the Art of Incident Response”. This series was condensed into an article published in the July-December 2009 issue of the Informant Magazine. However, due to size constraints the series of articles was never published nor completed. Therefore, I will deconstruct the article and publish the series, as was originally intended, to this blog. The main components will include, the Threat Environment, Defining Response and its characteristics, Response Strategies, and Responding to a Live Macintosh Computer. The first installation in this series addresses the Threat Environment.


Law enforcement officers seek to locate the proverbial “smoking gun” as a means to close each investigation. The”smoking gun” is the one item that proves, without a doubt, the party responsible for the crime. In the cyber world, the computer is analogous to the gun. Therefore, forensic examiners have naturally focused their considerable skills on possessing the computer. Possession of the computer does not necessarily equate to possession of information critical to the investigation. Unlike the gun, where ballistics can tie a bullet to a specific gun barrel, there is information on a computer that cannot be attributed to the computer (or even discovered) once the computer is powered off, or in some cases, once the state of the system is altered. Therefore, forensic examiners must not look to the physical possession of the computer as the investigative goal. Rather these examiners must seek the data, specifically the active and volatile data rather than seeking mere possession.

Traditional Methodology

The traditional method of minimizing loss of data and possessing the computer has been for the examiner to pull the power plug from the actively running machine. In doing so, the examiner does not unnecessarily alter data on the computer. Additionally, the examiner, or responder (as is often the case) need not possess any special skills when seizing a computer. The ability to deploy untrained personnel to a scene containing computers is critical to many organizations in that there are far more incidents with computers than most have the trained personnel to respond. The need for response and lack of properly trained personnel has been a major impetus in policy development concerning incident response (a topic that will be addressed in a later installment).

As vital as possessing the computer is to the forensic process, pulling the plug on a running computer is no longer a sustainable preference. In fact, given the modern threat environment, pulling the plug on a running system that is not actively destroying data borders on malfeasance. The data that is lost when pulling the plug can be the difference between catching the criminal of having him walk free. Similarly, pulling the plug may destroy exculpatory information, such as processes running on the system that the owner was unaware of and/or had no control over.


Moore’s Law (Webster’s Online Dictionary, 2010) provides the most easily recognized definition for the rapid pace at which technology changes. Simply stated technology (although Moore was referring specifically to processor chip technology) doubles every 18-24 months. The rapid change of technology is problematic for law enforcement and forensic professionals alike. There is a symbiotic relationship between technology implementation and security exploits. As new technologies are implemented new security vulnerabilities are discovered. “According to the researchers, an unpatched Windows PC connected to the Internet will last for only about 20 minutes before it’s compromised by malware, on average” (Loney, 2004). It is important to note that the relationship of technology to vulnerability is not one-to-one, rather it is one-to-many. “As I see the kind of threat today, there is so much more malware out in the environment. There is so much more expertise behind the top attack vectors than we have seen in many years leading up to this point” (Bordwine, 2010). The proliferation of malware, combined with poorly written applications make the environment rife with danger. The fact that numerous exploits can exist for a single technology makes it extremely difficult for law enforcement, security or forensic professionals to keep pace.

The User

Today’s computer users can be characterized by the following: they have computers that are more powerful than the computers used to put a man on the moon, they have no computer security training, they use 3-4 applications, have multiple computing devices, freely publish personal information through a wide variety of data repositories using technologies they do not understand, and are connected to the Internet via a high speed connection. In essence today’s computer users are easy targets.

Threat Actors

There are seven categories of threat actors, Advanced Warfare States, Industrial States, Organized Criminal Groups, Developing States, Terrorist, Hacker Groups and Individuals. Hacking groups and Individuals focus their attacks primarily on product vulnerabilities, whereas the remaining groups are characterized by targeted attacks. Although each Threat Actor classification has its own objectives and all warrant further discussion, this paper will address the criminal element of as a whole.

The Cyber Criminal

The modern criminal has an opportunity previously unimaginable, a worldwide playground. Criminals are opportunistic and like all predators, they will seek the easy target. In the cyber world, that easy target is the vast majority of users on the Internet. The fact that smart phones and wireless devices have become ubiquitous has only emboldened today’s criminal, as they represent more ways to exploit both the user and the technology.

Motives. According to Britz (2004), there are six motives for the modern cyber criminal; boredom, intellectual challenge, revenge, sexual gratification, economic and political. The six motives of the cyber criminal are not necessarily mutually exclusive. Threat actors have demonstrated the ability to leverage various motives to recruit and exploit those needed to achieve their goals. An example of cross pollination of motives is obtaining the services of a disgruntled employee to gain access to systems from which data can then be obtained for monetary gain.

Methods. As mentioned previously, there are two main categories of exploitation, however, there are an unlimited number of methods to implement the type of attack. Generally the methodologies for cyber attack can be divided into three distinct groups; social engineering, technical exploitation and  physical disruption and/or a combination of the three.

Adaptation. Historically all criminals adapt to new environments with surprising rapidity, however, none compare to the modern cyber criminal. One reason for the cyber criminal’s amorphous nature lies within the creation of the Internet as a whole. The Internet was created to share information and some of its most influential contributors started as hackers. The pioneers of the Internet demonstrated inherent weaknesses within the Internet itself but largely were not criminally motivated, rather the emphasis was to bend technology to their will, thus creating new capabilities and technologies in the process. The technologically minded with less pure motives began to see the possibilities of the Internet as a way to safely commit criminal acts. For example a bank robber, prior to the Internet had to physically go into a bank and steal money; a very risky adventure to say the least. However, the same crime, conducted electronically can not only be safer but have an exponentially higher payoff as more locations can be exploited. In the end, the exploitation of technology has created not only its own criminal element, it has also created an entire black market economy, one that has matured from a product-based economy to a service-based economy (Berinato, 2007).

A Connected World


As human beings we have an undeniable need for social interaction. The need for people to be apart of a group has driven social networking sites become the favored communication medium for millions world-wide. The need for interaction combined with the speed and convenience of the Internet has paved the way for a world in which all can be connected. Although the idea of a connected world resonates with our very nature, it can also be exploited by those with less honorable intentions.

Today’s workforce and family style has become preoccupied and mobile. The separate from family, the increased pressures of the workplace and the need for interaction has driven technology to toward mobility and convenience. The invention and subsequent proliferation of wireless networks has become the epicenter of modern connectivity. However, convenience and speed are not without a price. The price for the speed and convenient access to others is a failed security model. In fact it is often touted by security professionals that there is no such thing as a secure network, let alone a secure wireless network.

Online Data Repositories

The need for connectivity has created the demand for access. A mobile world is of no value if a person cannot access their data. Therefore, data has become geographically disassociated from the owner. This creates a problem for law enforcement and the forensic professional in that it is increasingly difficult to collect and collate all the data associated with a person. Similarly, this remote data repository model has granted a potential safe haven for criminals to anonymously store information while providing data centers with millions of records of data waiting to be harvested.

Network Shares

Network shares are an issue for law enforcement and forensic professionals if they fail to recognize them on a running system. A network share can contain some or all of the relevant information pertaining to a crime and will not be accessible once the computer is powered off. Therefore, law enforcement and forensic professionals must be cognizant of the potential data sources contained in network shares.



There are many applications focused on providing the data owner with security. However, applications that secure data can be used by criminals in an attempt to prevent attribution. The most common forms of security applications are encryption, steganography and biometrics. Encryption is denying access to information through use of encoding information, rendering it unreadable to anyone without the correct decode key. Biometrics is similar to encryption whereas it focuses on denying access to the information, in this case, through use of biometric verification. Steganography is different in that its focus is on hiding the data. Steganography typically uses audio and/or images to hide data by inserting it into areas that cannot be heard normally or that the naked eye cannot differentiate (often referred to as the “least significant bit”. Regardless, of the security application, these tools present significant challenges to law enforcement and forensic professionals, as they were designed specifically to deny access or hide information from anyone but the owner.



Anti-forensics refers to the practice of circumventing successful forensic processes. There are many forms of anti-forensics, however, it is critical to understand that anti-forensics is more of a mindset than a particular tool. Although there are tools to wipe data, insert false data and even specifically target data, anti-forensics in and of itself supersedes the application layer. Law enforcement and forensic professionals are the target of anti-forensics and as such as susceptible to booby-trapped computer systems, command aliases aimed at destroying data and the removal of user and operating system artifacts, creating a virtual minefield for the responder. Therefore, anti-forensics must be a consideration with regards to any on scene scenario.



Traditionally the computer housed the majority of data. Floppy diskettes and the occasional CD-ROM were routinely seized with a computer as they were co-located with the computer. However, the environment has changed significantly. Today, data physically resides on smart phones, USB Flash drives, laptop and tablet computers, Personal Digital Assistants (PDAs), Netbooks and a variety of other hardware devices. Unlike the desktop computer, these devices were built with mobility in mind. Therefore, the responder need be very diligent in locating any device that contained electronically stored media. As for law enforcement, these types of devices must be explicitly stated within the warrant and should be a routine part of a subject interview.

The Responder

The Responder, for the purpose of this paper, is the first person on scene where there is a running computer. The actions of the responder are critical to any investigation involving a live computer. However, the difficulties many organizations face is their inundation of response to which there is a live computer. In face of overwhelming incidents, it is not practical for many organizations to train and educate enough responders to expertly handle the variety of scenarios they are likely to face. In addition to lack of training and budget, there are surprising few tools capable of handling the complex live environments posed in the majority of responses. Therefore, the responder as a whole can be characterized as under trained, overworked and lacking the necessary tools to perform optimally in a live response scenario.


The modern threat environment is more complex and dangerous than ever. The lack of recognition and subsequent adaptation pertaining to the evolved threat can have devastating consequences. The traditional method of pulling the plug will get the “gun”, or computer in this case, but unfortunately, in today’s investigations, the “smoke” (volatile data) can be more important than the gun. Herein lies the art of incident response and when done correctly, the “smoke” may end up blowing right back in the criminal’s face.


Berinato, S. (2007). Hacker Economics 1: Malware as a Service. CIO Magazine. Retrieved October 11, 2007 from http://www.cio.com/article/print/135500

Bordwine, J. (2010). The STAND Cybersecurity. Washington Technology. Retrieved December 7, 2010, from http://washingtontechnology.com/Microsites/2010-The-Stand/Cybersecurity-May/Question-1-Changing-Threats.aspx

Britz, M. (2004). Computer Forensics and Cyber Crime, An Introduction. Pearson Education Inc., Upper Saddle River, NJ. Pearson and Prentice Hall.

Lewis, A. (2009, July-December). Digital Smoke: The Art of Incident Response. The Informant, 6(2), 26-27.

Loney, M. (2004). Study: Unpatched PCs Compromised in 20 Minutes. CNet News. Retrieved December 7, 2010, from http://news.cnet.com/2100-7349_3-5313402.html

Webster’s Online Dictionary (2010). Speciality Expressions: Moore’s Law. Retrieved December 6, 2010, from
http://www.websters-online-dictionary.org/definitions/Moore%2527s+Law? cx=partner-pub-0939450753529744%3Av0qd01-tdlq&cof=FORID%3A9&ie=UTF-8&q=Moore%27s+Law&sa=Search#922


Computer Forensic Training

October 1, 2010

If you are looking for a good place to check on computer forensic training options, head to the Wiki site; Training Courses and Providers. It’s organized in sections; On-going / Continuous Training; Non-Commercial Training; Tool Vendor Training and Commercial Training. It’s cross-referenced to the training link found on the side bar for this blog; Computer Forensic Training List.


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)


NIST Colloquium Series: Digital Forensics

September 28, 2010

I found the link to this video in Forensic Photoshop by Jim Hoerricks. Great video featuring Dr. Hany Farid on authenticating images. It’s a little over an hour long but very worth your time. Some of the math reminds me of my days in Collision Reconstruction 🙂

From the YouTube Post: Dr. Hany Farid, a distinguished professor at Dartmouth College and the “father” of digital image forensics, is an expert on authenticating images. His most famous analysis: a photograph of Lee Harvey Oswald holding a rifle and newspaper. Dr Farid concluded the photo was not altered. In this NIST Colloquium Series presentation, he discusses the impact that camera manipulation and alteration have caused.


Adobe PDF Portfolio

September 14, 2010

At the recent DSI conference, I was asked to give two presentations, “Even Geeks Can Speak” and “$0 to $700 in 60 Minutes”. As with most conferences, they wanted student material and a copy of my slides to hand out to the conference attendees. I have been experimenting with Adobe Portfolio on computer, audio/video forensic reporting this past year and thought it would work great on this project.

What is Adobe PDF Portfolio?

Think of PDF Portfolio as a container. This container can hold numerous formats, such as Word Docs, Spreadsheets and of course PDF files. In this case, I used the container to organize my two class slide’s (which I had converted into pdf’s) and student resource material. As with normal PDF operations, the creator can open, read, edit and format each file individually. Another nice benefit (that has been in PDF files for a while) is the ability to secure my files. For example, I could have given the students permission to view the files but not copy or print them. Adobe PDF Portfolio was included in Adobe Acrobat 9 or Acrobat 9 Pro Extended.

Acrobat Users.com has a good tutorial on the individual steps. In my case, the students saw the following splash screen when they double clicked on my class Portfolio;

Clicking on the “Get Started” button gave the students access to the material in my Portfolio.

The slides for the class were easy to access and follow.

For more information on Adobe PDF Portfolio: About PDF Portfolios