Rubbing Sticks: Lighting The Kindle Fire

I recently obtained a Kindle Fire on which to experiment.  It was booted to the operating system and unlocked.  Naturally, I thought, "Enable USB Debugging and have a go at it with adb."  I looked at the settings and to my surprise: no USB debugging option!  A little research revealed that USB debugging is enabled by default on the Kindle Fire and it runs on a custom Android 2.3.  "Fantastic!" I thought, "This is going to be a piece of cake."

Dashed Hopes

Boy was I wrong.  It's not that the Kindle Fire is particularly hard to deal with, it's just very different from my normal Android experience.  Normally, for the Android Debug Bridge (adb) to connect to an Android device in Linux, the vendor ID needs to be defined in a udev rule.  A quick look at the vendor IDs listed on the Android Developer site reveals the definite lack of a definition for the Kindle.  So, how do we find one?

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 004: ID 1949:0005 Lab126

The lsusb command displays information about USB buses on the system.  From the output, we see the vendor ID for the Kindle Fire is 0x1949.  Yes, that "Lab126" is the Kindle and yes, the ID is hexadecimal.  And in the event you were wondering, the second hex value after the colon, 0x0005, is the Prodoct ID.

False Hopes

OK, now we're in business, right?  I append the Kindle Fire to my android.rules file in /etc/udev/rules.d/ with the following lines:

#Amazon Kindle
SUBSYSTEM=="usb", ATTR{idVendor}=="1949", MODE="0666"

Now I start the adb server and read the device with:

$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

Nothing!  How can that be?  I've added every new device in this way!  I should see the serial number of the device or at least a series of question marks (indicating I need to restart the server as root because I lack permission to read the device).

Discovering Fire

It took some poking around and some experimentation, but it turns out the only way I could get adb to see the Kindle fire was to add the Vendor ID to the adb_usb.ini file.  "An '.ini' file?  Isn't that for Windows?" you ask.  In a strict sense, an ini file is a text file used for application settings, and it is commonly found on Windows systems, but not exclusively so.

You may recall that when you installed the Android SDK, you launched the android application in the ./android-sdk-linux/tools/ directory.  When you selected and installed the "Android SDK Tools" and "Android SDK Platform Tools", a hidden .android directory was created in your user account, or in the root user account if you ran the tool as administrator (recommended).  In the directory is the adb_usb.ini file, which by default, or after an android update usb command, has the following content:

# cat /root/.android/adb_usb.ini
# ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT.
# USE 'android update adb' TO GENERATE.
# 1 USB VENDOR ID PER LINE.

To connect to the Kindle Fire with adb, we need to append the Vendor ID, as a hexadecimal expression, to the adb_usb.ini file:

# echo 0x1949 >> $HOME/.android/adb_usb.ini

You can see the effect of your command with 'cat':

# cat adb_usb.ini
# ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT.
# USE 'android update adb' TO GENERATE.
# 1 USB VENDOR ID PER LINE.
0x1949

Now, to connect the Fire, all that remains is to restart the adb server:

# adb kill-server
# adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
0123456789ABCDEF device

Success!  

To recap, the udev rule does not help us in the case of the Kindle Fire.  The presence of the Vendor ID in the rule or lack there of has no effect on connecting to the device with the Android Debug Bridge in Linux.  The only effective method for connecting to the Fire is to place the Vendor ID in the adb_usb.ini file.

Facebook Search History

A digital forensics investigator is often asked to answer the question, "What did the user search for?"  Usually, the question revolves around Internet search engines, and producing a list depends on the browser in play as much as the search engine.  With the 250+ search engines and the 130+ Internet browsers referenced in Wikipedia, where you will find these histories and in what format can vary wildly.  Add to that the various tool bars that maintain data independent of the browser, and you're probably ready to surrender jump to another post on a topic less daunting!

But, you probably figured out from the title of this post that I'm not going to discuss the over 33,800 browser/search engine possibilities you need to consider when producing a "search term" history.  Instead, I'm going to discuss something I just discovered, Facebook search history.  And like so many web browsing sessions, I begin the discussion with a Google search....

Google Instant Predictions

I'll wager that most Internet users that have conducted an Internet search in the last two years have done so at least once using Google.  If so, they have likely experienced Google Instant Predictions. Launched around September, 2010, Instant Predictions produces "instant" search results as you type.  Search results begin populating based on Google's prediction of your search terms as you type them.

From a forensics point of view, this produces a lot more Internet history.  Every time Google populates results, its sending a webpage and elements.  And unless the connection is slow or the typist is particularly fast, Google refreshes the search results page for every letter typed by the user!  Consider a Google search using the Safari web browser for the term: "car wash" (obtained from the Safari Cache.db).

http://clients1.google.com/complete/search?client=safari&q=c
http://clients1.google.com/complete/search?client=safari&q=ca
http://clients1.google.com/complete/search?client=safari&q=car
http://clients1.google.com/complete/search?client=safari&q=car+
http://clients1.google.com/complete/search?client=safari&q=car+w
http://clients1.google.com/complete/search?client=safari&q=car+wa
http://clients1.google.com/complete/search?client=safari&q=car+was
http://clients1.google.com/complete/search?client=safari&q=car+wash

It is easy to see that an html page was cached for each of these URLs!  What can be interesting, and entertaining, is that you can even follow typing errors such as typos, spelling errors, and the resulting backspaces!

Facebook Type Ahead Search

I've recently discovered that Facebook produces a similar URL history for searches conducted through its website.  Observe the following:

http://www.facebook.com/ajax/typeahead/search.php?__a=1&value=sl&viewer=##########&filter%5B0%5D=page&filter%5B1%5D=user&context=mentions&dark_launch=true&rsp=mentions
http://www.facebook.com/ajax/typeahead/search.php?__a=1&value=slo&viewer=##########&filter%5B0%5D=page&filter%5B1%5D=user&context=mentions&dark_launch=true&rsp=mentions
http://www.facebook.com/ajax/typeahead/search.php?__a=1&value=slo.&viewer=##########&filter%5B0%5D=page&filter%5B1%5D=user&context=mentions&dark_launch=true&rsp=mentions
http://www.facebook.com/ajax/typeahead/search.php?__a=1&value=slo.sl&viewer=##########&filter%5B0%5D=page&filter%5B1%5D=user&context=mentions&dark_launch=true&rsp=mentions
http://www.facebook.com/ajax/typeahead/search.php?__a=1&value=slo.sleuth&viewer=##########&filter%5B0%5D=page&filter%5B1%5D=user&context=mentions&dark_launch=true&rsp=mentions

The response speed of Facebook does not appear to be that of Google, but again, it is easy to see that facebook sent several responses that were cached by Safari related to a single search by way of the "typeahead" mechanism.

Now, Facebook searches might be recorded in browser history databases, but consider that these databases may be destroyed through anti-forensics techniques or otherwise.  Searching for URLs might be the only method at your disposal for producing search term histories.  And now, like me, you know what to seek to reconstruct Facebook searches!

Mate: Your Forensics Desktop Buddy

There has been a casualty in the Linux Desktop over the past year or two: forensics.  Now, I'm not saying forensics can't be conducted from a modern Linux desktop environment like Gnome3 or Unity, but those environments do make it more difficult.  First, they are less configurable and second, they make it difficult to display more than one window at a time.  What might be a simple, clean interface to a desktop user is a hindrance to a forensics practitioner.

As a result, I switched to XFCE.  It's always been attractive to me because of its simplicity and size, and it does a lot of things right.  But it's a little rough around the edges.  The various settings windows are not well integrated, and a new user can easily become lost and frustrated.  More importantly, Thunar, the default file manager, is a little weak for exploring file systems from digital discovery point-of-view.  While

Meet Mate

Fortunately, forensics gurus are not the only people dissatisfied with the direction of the Linux desktop.  Gnome2 was a staple for many users, and it was common on Linux forensics boot disks, too.  The Mate project arose from the ashes of Gnome2 and serves as a drop in replacement for the popular but deprecated classic.

If you are a longtime or former Ubuntu user, Mate will look very familiar.  There is a little bit of translating to do, however, as some of the application names to which you've grown accustomed:

	MATE	GNOME 2	Type	Notes
	Atril	Evince	Document viewer	“lectern, reading desk”
	Caja	Nautilus	File manager	“box”
	Engrampa	File-Roller	File archive manager	“clip together”
	Eye of MATE (EOM)	Eye of GNOME (EOG)	Image viewer
	Marco	Metacity	Window manager	“framework, frame”
	MateCalc	gcalctool	Calculator
	MateConf	GConf	DE configuration system
	MateDialog	Zenity	GTK+ command-line dialog boxes
	MDM	GDM	Display manager (graphical login)
	Mozo	Alacarte	Menu editor
	Pluma	Gedit	Text editor	“pen”

The application gconf-editor was default GUI settings editor for Gnome2.  It was an important tool to know, because with it, the forensicator could configure his/her system to not automount devices.  The table above and a wiki entry at the Mate website indicate that gconf-editor will be replaced with, predictably, mateconf-editor, but as of Mate v1.40, no such application exists.

Configuring Mate

This brings me to the purpose of this post.  There is a command line tool that can be used to configure the Mate desktop environment called mateconftool-2, but its use is not intuitive.  I'll demonstrate its use to alter the media auto-mount setting.

First, its important to understand that the Mate settings expressed as key-value pairs and are stored in a series of XML files.  Editing the XML files directly is not recommended (settings are read and applied by the mateconfd daemon), and if you try, you'll see its quite difficult to chase down the correct file.  The mateconftool-2 tool makes navigating and editing the settings straight forward.

If you choose to think of the settings as being stored in a file system-like hierarchy, and I think you'll have little problem.  Observe, to view the settings directories at the root of the settings tree, issue the command:

$ mateconftool-2 --all-dirs /
 /system
 /desktop
 /schemas
 /apps

We see that there are settings in four categories: system, desktop, schemas, and apps.  We are seeking to change the behavior of the caja application, the file manager responsible for mounting attached devices.  We can see that the caja settings are not the only Mate desktop environment settings that can be configured:

$ mateconftool-2 --all-dirs /apps
 /apps/mate-dictionary
 /apps/procman
 /apps/mate-system-log
 /apps/timer-applet
 /apps/control-center
 /apps/pluma
 /apps/marco
 /apps/panel
 /apps/baobab
 /apps/engrampa
 /apps/caja
 /apps/mate-terminal
 /apps/mate-screenshot
 /apps/mate-screensaver
 /apps/notification-daemon
 /apps/eom
 /apps/mate-session
 /apps/mate-power-manager
 /apps/mate_settings_daemon
 /apps/mate-search-tool
 /apps/stickynotes_applet
 /apps/mate-volume-control

To review the caja settings, we examine the categories with the all-directories option and learn there is a preferences directory.  To view the preferences key-value pairs, we switch to the all-entries option:

$ mateconftool-2 --all-entries /apps/caja/preferences
 ...
 media_automount = true
 search_bar_type = search_by_text
 media_autorun_never = false
 media_autorun_x_content_start_app = [x-content/software]
 mouse_back_button = 8
 show_image_thumbnails = local_only
 desktop_is_home_dir = false
 media_autorun_x_content_ignore = []
 start_with_sidebar = true
 thumbnail_limit = 10485760
 directory_limit = -1

Now, this might seem cumbersome.  That's because it is.  If you know the path to the setting in which you are interested, you can address it directly:

$ mateconftool-2 --get /apps/caja/preferences/media_automount

true

To change a setting, you must specify its type: integer, boolean, float, or a string.  In our case, its pretty evident that we are dealing with a boolean value, and we want to set it to "false".  We must specify the action (set) and the type (false).  Silence means success, but we follow our change by reading the key for verification:

$ mateconftool-2 --set --type=bool /apps/caja/preferences/media_automount false

$ mateconftool-2 --get /apps/caja/preferences/media_automount

false

Now, when a device is plugged into the a Linux system running the Mate desktop, it will not be auto-mounted.  This is particularly important in Linux forensic boot discs designed to be inserted in the device to be examined/imaged or where a write-blocker is not an option or available.  None-the-less, we'll all  be happier when mateconf-editor GUI is added to the Mate line-up!