Abstract

Embedded devices are becoming more and more pervasive in the daily affairs of the average individual. Modern appliances from coffee pots to refrigerators and even washing machines are now running on embedded systems, sometimes operating trimmed down versions of familiar Linux distributions. Perhaps the most iconic and ubiquitous of these embedded systems is the cell phone which has evolved into a powerful handheld computing platform, now in the hands of nearly __% of the world’s population.  Mobile phones became the progenitors of the tablet, driving the modern computing use cases – a shift away from desktops and towards other mobile computing solutions. Amongst the many innovative systems spawned in this rapid growth is the Amazon Kindle e-reader. Designed in part to replace the need to carry around a multitude of novels, this device is capable of much, much more. These capabilities will be explored through research about the Kindle’s undocumented features and the acquisition & analysis of a Kindle 2 International (K2i) which has been populated with data. Through this process, the provenance of forensic evidence sources and pitfalls accompanying investigation of a Kindle will be scrutinized.

 

Background/Research

Determining Device Capabilities

Since its initial release, the Amazon Kindle has gone through a significant metamorphosis, adding different features, storage sizes, and other nuances with each iteration. Determining which Kindle is being dealt with is important to properly securing the device prior to imaging. On the back of the device is a Model number, in this case it was “D00701” which correlates to the Kindle 2 International. The difference between the U.S. version and the international is the type of cellular communications supported. This device particular device has 2 GB of internal memory.

WhisperNet

One reason that illustrates the important of knowing the version is that some of the devices are connected over cellular infrastructure to the Amazon network known as “Whispernet.” This is used to surf the web, sync the device to the users amazon account, and perform system updates, The service is provided for free, and comes on all 3g enabled Kindles.

A Glimpse Under The Hood // ;debugOn

Amazon has seemingly been relaxed in taking steps to prevent modification of their device, perhaps intentionally so. One example of this is easy access to a poorly documented debug function. By navigating to the home screen and pressing the “del” button to bring up a search prompt, one can enter the phrase “;debugOn” to enable debugging mode (conversely, “;debugOff” disables debug mode).  Enabling debug mode also enables verbose logging. From this mode, there are a variety of otherwise “private” commands that can be entered in order to perform somewhat lower-level activities. These commands are inaccessible when not in debug mode, and the syntax of the commands as well as the commands themselves vary by OS version. On the Kindle 2.X.X devices and below the command escape character that precedes every command is a back-tick ( ` ), however on the 3.X.X and above the escape character is a tilde ( ~ ).  A list of supported commands on the Kindle being investigated can be obtained by returning to the main “home”  screen,  opening the search prompt, enabling debug (;debugOn),  reopening the search prompt, and entering the private command `help. This should open a dialog with a list of supported commands for the Kindle version. Fairly ubiquitous and important commands include:

`usbNetwork – this command disables the mass storage driver and instead uses an Ethernet based driver to pass IP traffic over the USB bus. This effectively crestes the ability to scan and interact with the Kindle as though it were a remote network host, but through USB.

 ‘Log611 – This enables the logging of cellular towers on 3g enabled Kindles, effectively creating a coarse positioning system. Unfortunately for investigators, this is not enabled by default and so has limited usefulness.[1]

Ease of Root

As will be demonstrated earlier, there is an active mobile community for the Kindle devices which have developed packages to allow unfettered access to the device. The packages are incredibly easy to install and exist for every current Kindle version.

Acquisition

Logical

Although this section is entitled logical, it referrers to the imaging of a partition which included the file system and unallocated space, so more accurately it is a “partial physical” image. When the device arrived, it was initially powered off, but furthermore, the battery was completely discharged. Connecting it to the examining station via the provided USB cable also yielded no results. After eventually obtaining and maintaining enough of a charge to power on, the device negotiated drivers with the Windows 7 Examiner’s station and recognized as a mass storage device. The accessibility of this and other partitions on the device from Windows was tested by navigating to disk management and observing the listed device and its partition(s). In this case, a single visible FAT32 partition appeared available on the Kindle. FTK Imager was then used to acquire the partition. The process for this is well –documented elsewhere, but in short consists of the following:

1. 1.       Navigated to File > Create Disk Image… | Next
2. Selected Physical Drive radio button | Next
3. Selected the drive from the drop down | Finish
4. Selected “Add” followed by the Raw “dd” radio button | Next
5. Filled out the appropriate case information | Next
6. Set image fragmentation size to zero, set the destination, and named the image appropriately | Finish

Note: This particular model has 3g coverage, so in order to disable the wireless, the menu button was pressed and the top option “Wireless Off” was selected.

Recovery Mode

On the K2i it was as simple as . As a cautionary aside, the method of entering Recovery mode and even the support for it varies by Kindle model, so it is prudent to identify the Kindle model and method before attempting to power-on or attach the device. This mode will allow access to the user data partition in a lot of cases regardless of failed software updates, etc. It also does not perform a full boot in this case, potentially sparing some additional evidence destruction. Ideally this mode would be used in conjunction with a hardware/firmware write blocker to acquire the physical image of the data partition.

Physical

After obtaining the logical which was only ~1.6GB in size, it became obvious that this was simply a user data partition which was being exposed. One of the tell-tale signs of this was the fact that, upon powering the Kindle and attaching it to the examining computer, a message is displayed that states if the user wishes to interact with the device while charging it via USB attached to a computer, it must first be ejected from said computer, ergo the partition must be un-mounted so that the Kindle’s OS can remount it and allow the user to interact with the data.

When the device is placed in usbNetwork mode (discussed previously in the “A Glimpse Under the Hood” section) this message is not displayed, furthering the hypothesis. Many modern devices such as Windows/Android mobile phones utilize the Media Transfer Protocol (MTP) to avoid the need to expose the entire partition to the user while retaining the ability to transfer select data to and from the device by exposing what equates to a “network share” over USB. A more direct comparison might be current TomTom GPS’s which install as USB Ethernet adapter instead of a mass storage driver (just like the Kindle’s usbNetwork mode) and offer their services via a webserver hosted on the GPS and available over the USB interface.

Opening the logical copy, it became evident that the operating system files were not present, and that the missing ~0.4 GB of storage was actually being used to store Kindle’s OS. At this point, the idea of rooting became a more attractive option, but before considering this, the usbNetwork mode was explored further, in the hopes that a management interface may be available. This was examined via the following steps from within an Ubuntu VM:

1. Gave the usb0 interface an IP address in the 192.168.15.1
   1. Ifconfig usb0 192.168.15.1
2. Ping scanned the 192.168.15.0/24 subnet to identify Kindle
   1. Nmap -sn -e usb0 192.168.15.0/24
3. A cursory nmap TCP scan via the following command did not yield any results:
   1. Nmap  -Pn -sS -sV -O -p – -e usb0 192.168.15.244
4. Nor did a followup UDP scan:
   1. Nmap  -Pn -sU -p – -e usb0 192.168.15.244
   2. Note: the OS version detection and service versioning was left off in an attempt to speed up the detection process

Left with time constraints and few other readily identifiable courses of action, the process of physical acquisition now turned to rooting.

The Premise of Rooting the Kindle

Rooting the device through exploits published by the mobile hacking community was left as a last resort for a series of reasons:

• Rooting alters the operating system and this case, the data partition as well
• Rooting requires a reboot, thus destroying any chance for meaningful volatile memory analysis
• The goals of rooting in the hacking community vs. the Forensic/IR community are markedly different – added functionality instead of minimized footprint

Note: With this in mind, it is advisable to first perform an acquisition of the user data partition if a physical block device acquisition is also desired.

Despite these cautions, rooting the Kindle through the streamlined process developed by the mobileread community was incredibly simplistic. The “patches” were downloaded from the Mobileread sticky on Kindle jailbreaks. There were two files:

• The first one was the root patch
• The second one was an extension to the usbNetwork feature which made it more useful, and installed some system binaries to the user partition which were accessed after obtaining root access in order to install an SSH server and more fully featured BusyBox version ( BusyBox is a suite of simplified versions of common, useful Linux utilities into a single binary).

After downloading and decompressing the jailbreak archives, it was discovered that each extracted folder had a series of bin files named according to Kindle version. The correct version of the jailbreak was selected and uploaded to the base directory of the user data partition, and the Kindle was disconnected from the examiner’s computer.  On the Kindle, pressed the “MENU” button and selected the “Settings” option. Pressed “MENU” again and selected the “Update your Kindle” option.  The device “updates” with the custom bin file, and reboots with root permissions achieved. (Note: In the 2.X.X OS versions, the update will fail with a U006 error code, which is intentional and anticipated). These steps were then repeated for the correct usbNet bin.

At this point, the device was placed into usbNetwork mode by entering the following commands into the Kindle searchbar from the “home” screen:

1. ;debugOn
2. `usbNetwork
3. ;debugOff

The Kindle was then attached to the examiner’s computer and connected to an Ubuntu VM. Since it was in usbNetwork mode, it presented a usb0 Ethernet USB interface to the VM. This interface was configured with a static IP address of “192.168.2.1” because the usbNetwork bin executed earlier assigned the Kindle’s interface to “192.168.2.2.” This address is configurable when the Kindle is in mass storage mode in the file usbnet/etc/configuration.

Performed the following actions from the Ubuntu VM’s commandline:

1. Ifconfig usb0 192.168.2.1
2. Route add –host 192.168.2.2 dev usb0
   1. This step may be unnecessary, but was done to ensure the ssh command would go over usb0
3. ssh root@192.168.2.2
   1. When prompted for a password, left it blank.

This presented a root shell on the Kindle, allowing full access to the device. At this point, the “df” command was executed to see what devices / partitions were mounted:

Filesystem           1k-blocks      Used Available Use% Mounted on

/dev/mmcblk0p1          407661    325978     65299  83% /

tmpfs                    63564        28     63536   0% /dev

shm                      63564         0     63564   0% /dev/shm

rwfs                     32768       740     32028   2% /mnt/rwfs

rwfs                     32768       740     32028   2% /var

/dev/mmcblk0p2           23797      1572     20997   7% /var/local

fsp                    1561564     12632   1548932   1% /mnt/us

/dev/loop/0            1561564     12632   1548932   1% /mnt/base-us

 

Copying persistent storage device over usbNetwork [DD + SSH]

This process was slightly convoluted. The Netcat distribution that comes with the BusyBox install in the usbNet bin update that was applied earlier does not have the capability to listen as a server, so SSH was used instead. This provides no advantage when transferring data over the USB interface, but should SSH over wireless be enabled, this will encrypt the traffic to hide it from prying eyes. Effectively this is done by SSHing to the Kindle and then sending dd over SSH back to the examiner’s machine:

1. Executed a command from the Kindle’s console to send dd of block device over USB Ethernet
   1. dd if=/dev/mmcblk0 | ssh root@192.168.2.1 “dd of=/media/DATA/Kindle_mmcblk0.dd”

Volatile Memory Acquisition [or lack thereof]

Volatile memory was not collected from the Kindle because root access and a method of transferring data to the Kindle were required. This is not a problem if the user has already rooted the Kindle; however, in this case (most likely the predominant use case), the Kindle was stock and not rooted. This means that in order to acquire the root access necessary to copy volatile memory, a malicious firmware update which reboots the device was required, thus nullifying the ability to collect meaningful data from volatile memory (let alone the process of updating which would have overwritten a large component of the volatile memory space as it is). The process of scanning the ports of the device with nmap performed earlier also introduced contamination into the equation of volatile memory analysis, let alone the operating system’s continued normal functions.

Still, had the device been rooted with the stock usbnet hack, an unauthenticated ssh shell could have been acquired. Considering the prolonged battery life of Kindle devices, some very interesting or historic artifacts may be resident in volatile memory. In that circumstance, the examiner may have chosen to use the Linux Memory Extractor (LiME) to acquire volatile memory. LiME supports the ARM architecture and is the “go-to” tool for android and embedded Linux main memory acquisitions. Volatility also supports the analysis of LiME memory captures.

Analysis

Tools

FTK Imager – While not open-source, the free tool FTK Imager is simple, case-oriented, graphical, and invaluable to simple acquisitions from a Windows-based examiner’s station. It was used to acquire the “logical” (really more nearly physical) image of the user data partition.

Autopsy 3 – An open source analysis alternative to FTK which has begun a complete rejuvenation lately. Autopsy (or more accurately Sleuthkit which is powering it) was used to cross reference findings with that discovered in FTK.

HxD – HxD was used to for more granular exploratory analysis of a file at the hex level than is offered by FTK Image which can be somewhat cumbersome in that aspect.

VMware Workstation – this was used in conjunction with an Ubuntu Virtual Machine (VM)  in order to perform Linux oriented tasks and further analysis of the device. Nearly all usbNetwork operations were exclusively performed in the Ubuntu VM.

Search Method

The first approach to searching the evidence was to analyze the “logical” user data partition image. This presented the best view of the data prior to any alterations made in the rooting process. At this point, the hope was that all of the relevant user data resided on this partition, so that rooting a stock Kindle would not be as necessary in future investigations. If the user only has access to this partition, and the device is not repartitioned, then all available user data, whether present or deleted, might be accessible from this partition alone. After that, the Linux OS will be explored with a focus on /var for temporary data and anything amazon specific for the likelihood that it may contain user data.

Data Partition

The data partition accounts for about 1.6 GB of the 2 GB of internal storage. Despite this fact, the amount of data on this partition, in this particular case, was relatively small, weighing in at a mere 12.3 MB in use, leaving not much data to be analyzed in this aspect. Indeed, the only mildly advantageous tradeoff to the small disk usage is that there is increased preservation of deleted items which can be carved from unallocated space as a result. Still, within this relatively diminutive data set, there are a few salient points which will now be enumerated.

User Documents

The Kindle User Data partition is simply mounted as USB storage, meaning that it can easily be used for storing non-standard files, which may be of interest. There is also the files managed by the Kindle that exist in the Documents, Music, and Audible folders. While perhaps not smoking guns in their own right, they can serve to establish a user’s current interests or predispositions which may in fact be of value to a case. Take, for instance, a preponderance of books related to medical affairs, homosexuality, and relationships between men and boys that was found in the home of John Wayne Gacy.[2] Considering that Amazon’s ebook sales had already passed print sales two years ago[3], similarly relevant ebooks are even more likely to be found now.

Index.db

This file is located in the “system/Search Indexes” folder of the user data partition. Unlike many other embedded devices, such as Android and IOS devices, the Kindle does not seem to make use of SQLite 3 databases. This database appears to operate on the same premise – being a single, portable, binary database file. While not knowing the format makes a good portion of the file unintelligible, it appears to act as a log for files which are added to the Kindle, appending new entries to the end of the file.[4] This was not the case, however, on the Kindle which was reviewed.

Reader.pref

This file contains the last book which was read and timestamps associated with that, along with some other metadata about the formatting. This can possibly be used to identify when the user was last using the Kindle, or establish that a user has accessed particular content. Reader.pref is located in system/com.amamzon.ebook.blooklet.reader:

#User preferences for Reader Booklet

#Fri Nov 4 12:18:00 CDT 2011

FONT_SIZE=31

DICTIONARY=The New Oxford American Dictionary

JUSTIFICATION=full

LAST_BOOK_READ=/mnt/us/documents/The Prince-asin_B000JML9AY-type_EBOK-v_0.azw

HORIZONTAL_MARGIN=40

 

Userannotlog

This file which is located in /system also has interesting data related to the last few books a user has viewed. It appears to keep track of the position, timestamp, name of the book, and a state amongst a couple of other keys, providing even more complimentary detail to the Reader.pref file.

[Sample entries with truncated state for readability]

<book key=”ThankYouLetter_A1F83G8C2ARO7P” type=”PSNL” version=”0″ guid=”Welcome_Letter:2FFF232A”>

<last_read action=”create” begin=”2113″ pos=”2113″ timestamp=”2013-10-11T10:49:49″ state=”444…005″ /></book>

<book key=”B002VWLMDO” type=”FEED” version=”2814″ guid=”Free_Kindle_-Few_Other_Tips:E8074592″>

<last_read action=”create” begin=”177″ pos=”177″ timestamp=”2013-10-11T10:51:08″ state=”444…dea” /></book>

 

Unallocated Space

The unallocated space on the user data partition is a treasure trove of deleted files. This included initial setup and test files, a deleted e-Book, and what appeared to be deleted indicies. Presumably if a user were to have used the device for temporary file storage, or Kindle managed content like screensaver images/photographs were used and later deleted, they may alson be recoverable from this space. Access to unallocated space on the user partition really makes this closer to a physical acquisition than a logical one, even though the Flash Transition Layer is not captured (which would be difficult because there is a separate microcontroller for managing this) and the full block device is not captured.

Summary

Despite a relatively modest size, there are still some points of usage information directly available from the user data partition such as recently viewed items. This partition is also unmounted from the Kindle OS in USB mass storage mode, exposing the entire partition, including unallocated space, to the investigator. Therefore, it may be possible to recover user’s files which they have stored on the Kindle and deleted.

 

System Partition // User Data

Despite the fact that it is significantly smaller than the data partition, there is actually a significantly greater concentration of content on the system partition, leading to the possibility of additional significant sources of data.

 

Web Data: Browser Cookies & Bookmarks

As discussed briefly before, the Kindle possesses a fully functional web browser that is easily accessible to the user. As a result, there are artifacts stored on the system partition in the /var folder in the form of cookies. As with any other investigation, this can be of significant interest to the investigator.

These files are located in /var/log/java/browser & /var/log/java/cookies.

 

802.1x information

One other very intriguing find is the wpa_supplicant log for the wireless interface which logs SSIDs the wireless interface has authenticated against and associated to. This file is located at /var/logs/wpa_supplicant.wlan0. Unfortunately, the Kindle being analyzed did not appear to have connected to any access points. This, combined with the relatively few books, timestamps from 2011, the exceedingly few entries in index.db, the large amount of unallocated space, and the presence of setup files within unallocated space seems to suggest the device was not used heavily before being phased out.

 

/var/log/java/prefs Files

Reginfo – Registration information, including the user’s name, the device name, and a user alias:

[Edited for privacy concerns]

<response>

<user_device_name>P*****’s Kindle</user_device_name>

<global_device_name>NOT_USED</global_device_name>

<given_name>P******</given_name><name>P****** K****</name>

<alias>k****1</alias>

</response>

 

DevicePassword.pw – while the subject being analyzed did not have a password lock, apparently this file contains hints pertaining to a locked password. The file was not present.

 

com.amazon.ebook.booklet.home/com.amazon.ebook.booklet.home.prefs – This file (in this instance) contained the user’s full contact information – name, address, and phone number.

[Sanitized for privacy concerns]

#Thu Jan 01 14:31:14 CST 1970

PERSONAL_INFO=p**** k***\r\n3** t**e\r\nb*. **. 6*****\r\n8**.***.****

VERSION=1

 

Further Analysis

At the end of the day, Kindle devices are much like the plethora of other embedded devices in that they are running Linux on an ARM processor. While slimmed down, these are largely fully functioning versions of Linux, providing a wealth of temporary data , configurations, and logs. Given additional time it is incredibly likely that even more pieces of data could be used to support timeline construction and user behavior analysis.

 

Conclusions

With Kindle sales predicted to tip the scales at $4.5 billion[5] this year, it has become and currently remains a popular embedded device. Despite the fact that it is marketed as an e-Reader, the Kindle possesses a host of capabilities that make it much, much more. While it is by no means a smoking gun, the fact that it allows users to browse the web, download content, store content, play games, make annotations, and more means that it can be an invaluable part of an investigation. By collecting a pseudo-physical acquisition of the data partition before rooting a stock device to acquire a full physical acquisition, it is possible to gain insights into the files previously stored on the device, the last book which was read, and the beginnings of a profile on the user based on their recent book and audio choices. Because of its mass storage capability, a Kindle may also house more sinister data that should be also be looked for. The fact that the system partition runs Linux also makes even more evidence available such as the bookmarks and cookies from browsing sessions, and SSIDs that the device authenticated against. Like many other embedded devices, the Kindle is continuing to evolve and add more features, and it is likely that its continued analysis will provide even more sources of evidence going forward.

 

Sources

Reed, B. (2013, August). Amazon’s annual Kindle sales estimated at $4.5 billion. Retrieved from http://news.yahoo.com/amazon-annual-kindle-sales-estimated-4-5-billion-011530328.html

Thompson, M. (2011, September). Introduction to Kindle Forensics. Retrieved from http://practicaldigitalforensics.blogspot.com/2011/09/introduction-to-kindle-forensics.html

Miller, C. C. & Bosmon, J. (2011, May). E-Books Outsell Print Books at Amazon. Retrieved from http://www.nytimes.com/2011/05/20/technology/20amazon.html

Stott, A. (2011, June).  Amazon Kindle Forensics. Retrieved from http://www.blog.asafewebsite.com/2011/06/amazon-kindle-forensics.html

Dr. Infosec. (2009, June).  . Retrieved from http://inforensics.vidocrazor.com/2009/06/26/forensics-beyond-the-hard-drive-kindle-2-logging/