Transcription

[Raspberry Pi Forensics]02/16/2016175 Lakeside Ave, Room 300APhone: (802)865-5744Fax: (802)865-6446http://www.lcdi.champlain.edu

Disclaimer:This document contains information based on research that has been gathered by employee(s) of The SenatorPatrick Leahy Center for Digital Investigation (LCDI). The data contained in this project is submittedvoluntarily and is unaudited. Every effort has been made by LCDI to assure the accuracy and reliability of thedata contained in this report. However, LCDI nor any of our employees make no representation, warranty orguarantee in connection with this report and hereby expressly disclaims any liability or responsibility for lossor damage resulting from use of this data. Information in this report can be downloaded and redistributed byany person or persons. Any redistribution must maintain the LCDI logo and any references from this reportmust be properly annotated.ContentsIntroduction . 2Background: . 2Purpose and Scope:. 3Research Questions: . 3Terminology: . 4Methodology and Methods . 4Data Collection: . 6Analysis . 8Results . 9Conclusion . 10Further Work. 11References . 12Raspberry Pi ForensicsPage 1 of 13

IntroductionThe Raspberry Pi 2 Model B is a compact, programmable microcomputer designed to promote the education of basiccomputer science skills. Multiple input/output pins allow the Raspberry Pi to control other pieces of hardware.The goal of this project is to evaluate the digital forensic capabilities of these new computers by using them as portableimaging devices. An image, as it pertains to digital forensic investigation, is a method of replicating a computer’s harddrive by copying it into a series of files that reflects its contents. Forensic images come in two varieties: physical imagesthat include the drive’s unallocated space and are usually as large as the total capacity of the drive, and logical imagesthat only copies the active data on the drive and is often much smaller in size.Imaging the contents of a computer is an essential part of any digital forensic investigation because perusing the targetdrive directly will manipulate the data it contains and compromise the integrity of the evidence. Therefore, a mobileworkstation would be an invaluable asset to analysts in the field, providing them with the ability to obtain data on-sitethat can be examined while remaining admissible in a court of law.The Raspberry Pi 2 Model B is a programmable single card computer or “microcomputer.” This allows a compact andmobile programming solution. It was designed with the intention of promoting basic computer science skills ineducation. The card features multiple I/O pins that allow the card to control other hardware.To accomplish our goal, the Raspberry Pi 2 Model B will be used to create a portable imaging device. In digital forensicsan “image” most often refers to a copy of a hard drive, or disk image that is compressed into a series of files. A physicalimage includes unallocated space and results in an image roughly the same size as the drive itself. A logical image copiesthe portion of the drive with active data and creates an image smaller than the original drive. A device like this isparticularly useful in a digital forensics environment, as imaging computers is essential when conducting digital forensicresearch and analysis. Obtaining an image of drive is crucial when looking for forensic artifacts on a hard drive becausemodifying the original drive would cause the evidence on that drive to become inadmissible in the court of law. Thisdevice would allow an investigator to obtain an image of a client’s media without collecting the evidence.Background:Forensic images are usually made on one of several programs generally accepted as by the digital forensic industry, suchas FTK Imager by AccessData and Guidance Software’s EnCase. Researchers have also been able to utilize commandsbuilt into Linux operating systems to create an image of a drive. These techniques have been proven as effective throughextensive assessment, but there is little exploration of applying them to a device such as the Raspberry Pi that supportsonly limited computation power. Through our preliminary research, we found several technical setbacks that prevent usfrom approaching these programs contemporarily: the Raspberry Pi’s chipset architecture and processor areincompatible with the command line version of FTK Imager. The Pi’s small number of USB ports (four on the model usedin the project) presents problems as well, as it limits its potential data transfer speed and the small amount of powerallocated to each port has the potential to cause problems during testing.Research was also done into prior studies of mobile imaging, which proved largely fruitless. Very little study has beenconducted on imaging with low-power machines, so we shifted our focus towards identifying methods most compatiblewith the specifications of the Raspberry Pi.Raspberry Pi ForensicsPage 2 of 13

We decided to abandon Windows operating systems during this phase because we needed an OS that allowed the Linuxcommands to be issued to the microcomputer, and we could not allocate the time to solve the numerous compatibilityissues. The lack of prior research to reference meant that much of the project was based on experimentation andhypotheses which were tested largely through trial and error.Extensive research has been done on creating forensic images through software such as AccessData’s FTK Imager andGuidance Software’s EnCase, two popular programs in this field. There are many sources that describe how to use Linuxcommands to properly make forensic images from a command line interface but little exploration has been done in howthese processes would run on the limited computing power of the Raspberry Pi. One thing that was discovered throughthe research was the inability to run command line FTK Imager on the Raspberry Pi due to incompatibilities with theprocessor and chipset architecture type. Another major setback is the lack of ports on the Raspberry Pi; it only has 4 USB2.0 ports, limiting the speed for data transfer. Combined with the lack of power available to the ports can causeproblems.Our research in to mobile imaging was fairly short, as we could find very little reference online to alternate methods ofimaging on a smaller, homebrew style device. Our research mainly consisted of identifying operating systems withRaspberry Pi compatibility and Linux commands used on a desktop environment for the creation of images. Thisresearch helped us toss the idea of working with Windows, simply due to the time constraint and compatibility issueswith the Raspberry Pi. Due to the lack of previous research in this field, there were large portions of the project thatwere based entirely on our own hypothesis and were tested through trial and error.Purpose and Scope:This project was designed to examine the newest technologies in the current market and attempt to use them asinnovations to the digital forensics industry. A mobile imager made from a Raspberry Pi could potentially redefine howdigital forensic investigations are conducted by adding a new level of affordability and simplicity to the process.Therefore, over the course of this project we prioritized our efforts towards designing an imaging method that thehardware and software of a Raspberry Pi machine could utilize effectively while maintaining its forensic authenticity.The purpose of this project is to look at the capabilities of new technology as forensic tools. The first part of this projectis exploring evidence imaging. The most important part of this project is to ensure that the images being created by theRaspberry Pi’s are forensically sound.There are several benefits of creating a mobile imaging unit based around the Raspberry Pi. This device is on theextreme low end of the pricing range for computing units, thus reducing costs to users. It is also very small, fitting easilyin the palm of a hand. The size and pricing have the potential to make it a reasonable alternative for incident responseteams. This tool would also allow forensic investigators to image digital evidence without taking the device from theuser. With the addition of the touchscreen and executable script, this tool could also be easier for new users to quicklyadapt to.Research Questions:1. Will a mobile imaging unit expedite the imaging process?2. Which Raspberry Pi operating system will produce the best performance?3. How practical is a mobile imaging unit, opposed to conventional ways?4. Which data connection to the drive will produce the best results?Raspberry Pi ForensicsPage 3 of 13

Terminology:Image - In digital forensics, this term refers to a copy of the hard drive that is compressed into a series of files. Physicalimages include all information (ones and zeroes) on the hard drive whether the space is being used or not and theresulting image is near the same size as the actual hard drive itself. A logical image only acquires the parts of the harddrive that have active data and dismisses the rest of the drive. A logical image can be the same size or smaller than theoriginal depending on the amount of data stored.FTK Imager - A free extension of FTK 4.1, this tool is a powerful imaging program used to create forensic images of adrive that can be processed by most forensic examination software.Write Blocker - A tool used to disable write permissions to a hard drive to prevent data destruction, alteration orcontamination of data during the acquisition of a hard drive.Kali Linux - A Debian-derived Linux distribution designed for digital forensics and penetration testing.Methodology and MethodsThree drives of varying capacity were procured for testing of the Raspberry Pi imager - 80GB, 500GB, and 1TBrespectively. Each drive was formatted and given a clean install of a Windows operating system prior to their use in theproject. The team’s first step was to generate data onto the drives by surfing the web, creating documents anddownloading files. Next, the drives were imaged with FTK Imager 3.1 (creating MD5 hash values to reference later) andassigned to separate LCDI workstations via write blockers connected by either eSATA or USB 3.0, allowing teammembers to begin testing.Several operating systems were tested, including several variations of the Raspberry Pi’s standard OS, Raspbian Wheezy,and a Kali Linux distribution designed for the Pi. We also explored the possibility of a Windows OS, which would enableus to use the GUI version of FTK Imager; however, further testing showed that only a mobile Windows OS wascompatible with the Raspberry Pi’s ARM processor, and we concluded that this operating system did not have thecapabilities to handle programs that utilize full-size architectures, like desktop file systems.The imaging was done using command line tools based on GNU dd which can be utilized to create rudimentary images ofdrives in .raw format. These variants, such as dcfldd and dc3dd, add enhanced functionalities to the command thataddress some of its shortcomings when compared to modern imaging software. For example, both allow synchronoushashing while images are being created, post-image verification and external logging, features dd did not have originally.Improvements like these will allow the Raspberry Pi imager to use more lightweight software to carry out its objectivewhile still retaining an acceptable level of data assurance and admissibility in a court of law.The 80GB drive was imaged using the command dcfldd, an alternate version of the older dd framework that is notinitially available offered in the Kali Linux distribution designed for use with a Raspberry Pi. This was installed to themachine through the command line. The drive was attached to an external dock, then connected to an active writeblocker and using a USB connection to interface with the Raspberry Pi.Next, the command was executed and the resulting hash value was compared to one created earlier by the FTK Imagerfiles. In order to develop the best syntax that produced consistent results, multiple subsequent tests were run. Aftereach image was created, the drive containing the image was connected to the lab computer to store the test’s log. Theevolution of the syntax is shown in the logs, which are attached below. Tests 11, 15, 16, 19 and 20 provide no final timeRaspberry Pi ForensicsPage 4 of 13

in the command prompt; however, tests 7 and 15 did because they were executed in FTK Imager, which has progressstatistics built in. We also used dcfldd to test the 500GB drive, but also decided to explore dc3dd, a patch of the ddcommand that updates in conjunction with it (as opposed to a spin-off of the antiquated original version, like theframework of dcfldd).After learning about dc3dd, we attempted to switch over to it fully in order to compare the results to the outcome ofthe dcfldd tests. Although the forensic soundness of dc3dd is well-known, our experimentation with it only produced asingle matching hash value, while running Kali Linux and using the internal hard drive in a dock. The lack of successfulresults leads us to consider this testing inconclusive.Raspbian Wheezy was the OS chosen for the 1TB drive. We tried dd, dc3dd and dcfldd to image it, in order to directlycompare the results of all three base commands. When writing to anything besides an internal drive on a workstation,an external dock is required to power a destination of this size because of the Raspberry Pi’s inability to divert enoughpower to its connections. Tests 4, 5 and 6 were conducted on both the designated 1TB project drive as well as theinternal 1TB drive of an LCDI lab computer.The three drives tested were initially forensically wiped and given a clean install of a Windows. They were then utilizedin a controlled environment in order to generate data similar to that of the average user; web traffic, downloaded filesand a variety of document types, the purpose of this was to provide a reasonably similar drive to one that might befound in the field.All three of the testing drives were first imaged through FTK Imager 3.1, the standard imaging software installed on theLeahy Center for Digital Investigation workstations. They were then connected to a write blocker via a powered SATAconnection and the write blocker was connected to the lab computer by either eSATA or USB 3.0. After generating ahash value for comparison, each of the drives was be given to a team member to test within their setup. The operatingsystems we selected to test a Kali Linux distro specifically designed for the Raspberry Pi and several variants of theRaspbian Wheezy, the standard Raspberry Pi operating system. We investigated the possibility of attempting to runWindows in order to utilize the GUI version of FTK Imager, but it was concluded that the version of Windows designedfor ARM does not have the processing capabilities to run programs designed for traditional desktop Windowsarchitecture.The 80GB drive was tested on a Raspberry Pi using Kali Linux using the dcfldd command. This utility is not installed onthe version of Kali Linux distributed for Raspberry Pi and must be downloaded through the command line. The 80GBdrive was connected to a powered write blocker using USB 2.0 to interface with the Raspberry Pi. The destination mediawas mounted on an external dock connected to the Raspberry Pi through USB 2.0. The external dock is a hardwaredevice that an interface to mount and power a standard hard drive. The command was then tested and the hash valuescompared. After the image was created, the destination drive was then connected to a lab machine in order to processthe log and compare it to previous results.Subsequent tests were done to insure consistent results and develop the best syntax. As seen in the test logs below, thesyntax was continuously evolving. For tests 11, 15, 16, 19 and 20 there was no time flag included in the commandprompt and no time is provided. Tests 7 and 15 include times as they were done through FTK Imager whichautomatically includes progress statistics.The 500GB drive was tested with both dcfldd and dc3dd. Once we learned about dc3dd we switched over and startedrecording all data that we could about dc3dd. This allowed us to test dcfldd versus dc3dd. All of the recorded tests forthis drive were done with dc3dd and FTK imager. Although dc3dd is known to be forensically sound, we were only ableto get 1 matching hash. The matching hash was when we used the internal hard drive in a dock with Kali. Because wewere only able to get a matching hash once with this drive, we consider this series of tests inconclusive for the 500GBdrive.Raspberry Pi ForensicsPage 5 of 13

The 1TB drive was tested on Raspbian Wheezy, the standard Raspberry Pi operating system, using dd, dcfldd, and dc3dd.This drive was one of the base drives to test the functionality of the different commands. The drive was tested using awrite blocker and the lab computers through an eSATA connection, or using the Raspberry Pi and the write blocker towrite to an external drive. Due to the inability to use an external drive without power, (Raspberry Pi cannot provide thepower needed for the drive) a dock is needed to mount the destination drive we are using to move the image to. Fortests 4, 5, and 6, we used both the 1TB test drive and the 1TB internal drive from lab computer #7 to image the userfolders on each drive.Data Collection:Table 1: Equipment UsedQuantityTypeDetails2Internal Drive1 TB Western Digital Caviar Black SATA drive 64MB [email protected] 7200 RPM(DataGen)1Internal Drive1TB Seagate Barracuda SATA drive 32MB [email protected] 7200 RPM1Internal Drive500Gb Drive Western Digital SATA drive 16MB [email protected] 7200 RPM (DataGen)1Internal Drive80Gb Western Digital SATA drive Specs UNKNOWN (DataGen) (Failed)2Internal Drive80Gb Western Digital SATA drive 8MB [email protected] 7200 RPM (DataGen)2External DriveSanDisk Ultra 32Gb USB 3.0 Flash Drive1External DriveWestern Digital My Passport Black 2TB USB 3.0 (WDBY8L0020BBK-01)3Write BlockerWiebeTech Forensic UltraDock v5 - storage controller - ATA / SATA 3Gb/s - e4Raspberry PiCanaKit Raspberry Pi 2 Ultimate Starter Kit1External DockMasscool SuperSpeed USB 3.0 SATA Hard Drive Dock For 2.5 inch and 3.5 inch drives.8LabWorkstationIntel Core i7-3770K CPU at 3.5GHz, 16 Gb of Memory, NVIDIA GeForce GTX 660 Ti, 64bit Microsoft Windows 74OperatingSystemKali Linux by Offensive Security, Raspberry Pi 2 version Model BOperatingSystemRaspbian Jessie by the Raspberry Pi Foundation, based on Debian JessieOperatingSystemRaspbian Wheezy by Raspberry Pi Foundation, based on Debian WheezyRaspberry Pi ForensicsPage 6 of 13

OperatingSystemMicrosoft Windows 7SoftwareFTK Imager 3.1 by AccessData, Windows and Command Line editionsSoftwareVmware Workstation 12.0.0 ProCommandsdcfldd command line utility - based off the dd command and developed by theDepartment of Defense Computer Forensic Lab (DCFL)Commandsdc3dd command line utility - an updated version of dd with many other optionsCommandsdd command line utility - the base-line tool to copy large folders and files from onelocation to anotherCommandsmd5sum dcfldd parameter - adds a md5 log to the image creation file after the image isdoneTable 2: Data CollectedTest #Test TypeDrive Size1ImageCreationImageCreationFTK eationFTKCompression Test (5)FTKCompression Test (7)Pi ImageCreationPi ImageCreation234567891011Image TimeMD5 HashNotes1TBDestination DriveSize2TBN/AFailure1TB2TB3h 13m 52s500GB1TB1h 36m 29s1TB - UserFolder1TB - UserFolder1TB - UserFolder80GB2TB2m fb2dfN/A500GB1TBN/AN/AFailed - ComputerBlue bde79b46715e19dd7a1aa749c0a9d243026a2c8cdFailed - writepermission errorTime not included inparametersRaspberry Pi ForensicsMatchBaseline imageNo appdata ormetadataNo appdata ormetadataNo appdata ormetadataFirst HashFailed - User did nothave accessPage 7 of 13

121314151617181920CommandTestPi ImageCreationTestDc3ddCommandTestPi ImageCreationPi Test32GB2TB15m 32sN/AN/A80GB1TB3h 22m00fb1fb64dedbdbb12eb3c6c2bd03d12N/A500GB1TB5h 18ma99b58f9bc035faeb9fc4eb1af597860dc3dd imaged driveswith matching cd7b68610cf421d9fa94b1e1d81e04c3bfb8cTime not included inparametersDid not create a logfile80GB1TB43mN/A500GB2TB5h 11m e647d0d5151763e4dPi ImageCreationPi dd imaged - nonmatching md5 caused by change incommandTime not included inparametersTime not included inparametersAnalysisIn this experiment, we used three different commands (dd, dcfldd, and dc3dd), to test the ability of a Raspberry Pi 2 tobecome a mobile imaging unit. We started by imaging the drives using the LCDI Workstations through a write blockerwith FTK Imager. This gave us the initial hash value that we compared the rest of the values to. The write blockersensured that the original hash value were accurate based on the data gen. Then each of the team members obtainedone of three hard drives, (1TB, 500GB, 80GB), and completed their own work on the Pi and on image creation. Theyutilized the commands listed above to create the images using a write blocker, the subject drive, the destination drive,the Raspberry Pi, and a hard drive dock. Two of the Raspberry Pi’s have Kali Linux installed on them, and one Pi hasRaspbian (the base operating system of the Raspberry Pi). By testing both Kali and Raspbian operating systems, we wereable to test different environments to determine which was more successful.We know that the Raspberry Pi will be slower than a normal computer based on the low memory and smaller hard drivesize, so we are not expecting it to be as quick as one of the lab computers, but the hope is that it will work fast enoughto be practical in a law enforcement environment. We are also constricted to using USB 2.0 (60 MBps max speed)connection with the Raspberry Pi, compared to the eSATA connection (3Gbps max speed) on the lab computers. That iswhat two members used for a data connection. One tested the possibilities of moving their data to an external drivedirectly in order to test the alternate setup and investigate the possibility of reducing the amount of hardware involved.Raspberry Pi ForensicsPage 8 of 13

This command dcfldd was used in conjunction with the Raspberry Pi and the Kali Linux operating system. The evidencedrives used was a 80GB, a 500GB and a 1TB Western Digital SATA drive along with a 32GB SanDisk flash Drive. In testingthis command, experimentation had to be done to establish the exact syntax that would yield the desired result. It wasimportant to make sure the entire drive was imaged, not just a single partition. If not paid careful attention to, thissingle parameter has the potential to create a different image and thus different hash. This initially caused confusion inour testing until the proper input file was noted. The command we found to be successful was:time dcfldd if /evidencedrive of /destinationpath/filename.dd hash md5md5log /logfilepath/logname.ddThis command was originally deemed of interest as it allows for on the fly hashing of the data, as indicated by the“hash md5” option. The command generates a separate text file containing the hash to be checked against the originalhash generated by FTK Imager. There is also the option to generate sha1 hashes; however we chose to focus on md5.The “time” parameter of dcfldd was included in the final syntax for the purpose of tracking progress and having anunderstanding of how long the Raspberry Pi was taking to generate the imaging. This command allowed us to leave theworkstation and have a detailed report on the time taken for each step in the imaging process.The dc3dd command was tested with Raspbian Jessie, Raspbian Wheezy and Kali Linux. Both versions of Raspbian werenot a good match because they weren’t compatible NTFS file system.As a result of this we had to install a NTFS driver on the system. This method was unreliable and slow. Kali has built insupport for this file system, allowing it to work with all drives. At the end of the project we figured out how to use anexternal hard drive with the Raspberry Pi. Initially we had many problems with the Pi not being able to put enoughpower out to the USB ports. After combining research from Rageweb.Info and Raspberrypi.org, we found a way to getthe power to 1.2Amps instead of 600mA in Raspbian but not Kali. Kali has the file that is similar to a BIOS under ahidden unmounted partition. We found this and with the code max usb current 1 and this changed the availablecurrent from 0.6A to 1.2A. We also included safe mode gpio 4 because the forum on raspberrypi.org also included it.ResultsThe results of our tests show that it takes an average of 3 hours and 20 minutes to image and hash an 80GB drive, aboutthree times as long as it would take using FTK Imager. One important discovery we made is, while constructing thesyntax for the command-line imager, we were to specify imaging the entire physical drive and not reference anypartitions. Potential complications with hardware, along with the large amount of time it takes to successfully image adrive, mitigates the effectiveness of the mobile imager as it stands at the conclusion of this project. We were able topartially attribute the speed issue to the lack of strong data connections available on the Raspberry Pi itself. Since all ofthe data was being pushed through the Pi for processing, the imaging process was being slowed by its USB 2.0connections, which are limited to a 60 Mbps maximum data transfer speed, while the other devices utilized in theimager’s hardware setup were able to take advantage of an eSATA connector that hosts transfer speeds of up to 3Gbps.Until these issues are rectified, the Raspberry Pi cannot be called a practical imaging device on its own.Larger drives proved troublesome to image. The 500GB drive tests showed discrepancies in the resulting hashes whileusing dc3dd as well as miscellaneous file system errors. We were able to verify that the hardware was not the cause ofthe different hash values but were unable to ascertain where the issue stemmed from. The 1TB drive tests were rarelycompleted without issue. During the first baseline tests on the lab workstations, FTK Imager was unable to complete itsprocesses, resulting in us not having an original hash value. Further, the images that were produced during these testsRaspberry Pi ForensicsPage 9 of 13

did not reflect any user folder data, leaving us with little information to work with on a forensic level. After moving on totesting with the Raspberry Pi imager, we received read/write file system errors that we could not address, barring usfrom creating a hash value for the image.The syntax for a final command to create a forensically sound image using dc3dd was never decided on, because it wasnot the main focus of the project team. The imager’s setup was originally configured with a Raspbian operating system,but file system incompatibilities led us to replace this with Kali Linux. This change showed the least amount ofcomplications over the course of further testing, thus driving us to conclude that the Kali Linux distribution would be themost efficient OS in a mobile imager at this time.Through several tests it was established that 3 hours and 20 minutes was an average length of time for creating animage and hash of an 80GB drive using this command. This is roughly three times lon

the research was the inability to run command line FTK Imager on the Raspberry Pi due to incompatibilities with the processor and chipset architecture type. Another major setback is the lack of ports on the Raspberry Pi; it only h