Andriod Forensics

“ANDROID ON THE LOOSE; Andrew Hoog unveils Google’s new mobile operation system, showings us exactly what’s important for forensic investigators.”

Digital Forensics Magazine | supporting the professional computer security industry.

There has been a lot of interest in Android Forensics and one important component is an open source framework to provide such an application.  If sufficient interest and development is generated, it will be an extremely value tool to forensic investigators.  Now, we just need some forensic geeks with Java experience to join.  The project is hosted on Google Code.

A sign of things to come…Android is going to be significant.  If you need tools and techniques for the forensic analysis of these phone, please visit our Android Forensics page which has links to training, out mailing list and information on how to subscribe to our AFWiki.

As of December 2009, the research firm's survey shows that 4% of all smartphone owners now use a phone running some version of the Android OS. That's an increase of 200% since the previous survey released in September.

via Android Usage Increased 200% Over Past 3 Months.

The Nook from B&N runs Android.  The folks over at nookDevs has taken the device apart, figured out how to get root (I wish it was that easy on Android phones!) and is deep into it now.  We’ve long told folks that listen that Android is much more than a mobile phone OS.  From a law enforcement/forensics standpoint, you can’t ignore that illegal information may exist on an Android book reader, set top box or whatever the next device will be.  So you have to understand Android from the ground up.  Oh, and as for the last sentence the in quote below, I might just fit the bill!

If you tear open a Nook (which the team has done) you’ll find that the Android operating system is contained on a microSD card (separate from the microSD expansion slot). From here, it’s a simple matter of using a card reader to mount this card on your computer and changing a single word in the init.rc file (the file that’s in charge of which services are begun at startup, similar to a Linux boot).

This single hack will let you plug the Nook into your computer (once you have reassembled it) and access the OS, using the freely available Google Android developers kit. Right now you’ll have to be a hardcore nerd to make much use of this…<snip>

via Nook Torn Open, Hacked, Rooted | Gadget Lab | Wired.com.

Made me smile to find the directory /data/dontpanic on Android phones.

I can image people reading much into this…could Google/Android be the ultimate guide to our universe?  Since we already know The Answer to the Ultimate Question of Life, the Universe, and Everything, maybe it’s simply a place to store dumps from the system:

    # Create dump dir and collect dumps.
    # Do this before we mount cache so eventually we can use cache for
    # storing dumps on platforms which do not have a dedicated dump partition.

    mkdir /data/dontpanic
    chown root log /data/dontpanic
    chmod 0750 /data/dontpanic

    # Collect apanic data, free resources and re-arm trigger
    copy /proc/apanic_console /data/dontpanic/apanic_console
    chown root log /data/dontpanic/apanic_console
    chmod 0640 /data/dontpanic/apanic_console

    copy /proc/apanic_threads /data/dontpanic/apanic_threads
    chown root log /data/dontpanic/apanic_threads
    chmod 0640 /data/dontpanic/apanic_threads

    write /proc/apanic_console 1

    # Collect ramconsole data
    copy /proc/last_kmsg /data/dontpanic/last_kmsg
    chown root log /data/dontpanic/last_kmsg
    chmod 0640 /data/dontpanic/last_kmsg

I played around with Google Goggles today and was quite impressed.  Like any good forensic geek, I wanted to understand better what happened behind the scenes.  Below are some observations from the data the app persisted on the NAND:

• Application data is stored in /data/data/com.google.android.apps.unveil
• Following directories exist: cache, databases, files, lib, shared_prefs
• Last picture I took was stored in ./files/lastimage.jpeg (see bottom of post for the image…which found Barbara’s Books site immediately)
  • I have not had time to see if I could carve or otherwise extract previous images from the YAFFS2 data partition
• ./cache/webviewCache contained 2 files (referenced in the webviewCache.db database); one was a jpg (122eefe1) and the other a png (f0277abc).  The jpg contained a logo from a previous Goggle search I did so there was some residual data there
• ./databases contained 2 databases, webviewCache.db and webview.db
  • webviewCache.db contained references to the 2 cached files mentioned above.  It at least tells us the order (although file system date/time can do the same).  It also tells you when the content expires so you could probably calculate a decent time from that through testing…or at least get the general idea.
  • webview.db looked more like the android browser database but was unpopulated except for a cookie entry for .google.com

Not quite a revealing as Google Maps Navigation (see my previous post) but still insightful.  Oh, and it’s a really, really cool app.  I’ll use it more and report back at some point.

lastimage.jpg

I was taking a look at the /data/data/ directory on the Droid and here are some interesting items:

Contact database

• /data/data/com.android.providers.contacts/database/contacts2.db (thank goodness it’s not contacts1.db)
  • Combines data from Google, Exchange, Facebook and more
  • table status_updates has date/time and status update from contacts in your Contact list and Facebook
  • table raw_contacts has info about source of contact and other items
  • Is a fairly normalized database *until* you look at table data which has columns data1 – data15!
  • Call logs are stored in Calls table

Motorola and passwords

• Kudos to Motorola for being one of the few companies that do not seem to store passwords in plain text.  Example is /data/data/com.motorola.calendar/databases/motosync.db which has account info but Exchange password in not in plain text (maybe just a by product of the ActiveSync protocol?)

Geolocation

• Table /data/data/com.android.browser/app_geolocation/CachedPosition.db does just what you think it does (if the user gives permission).  Provides latitude, longitude, altitude, accuracy, altitudeAccuracy, heading, speed and time stamp (gotcha).  the altitude, speed and heading were not populated.
  • I was going to post the longitude/latitude but then I checked it and, wow, was it accurate.  So, you’ll just have to wonder where I (i mean my phone) was last night at 1260500133.
  • Oddly enough, the time stamp has 3 extra digits form the standard Unix Epoch…have to figure out why.
  • Only 1 records was allocated in the database so apparently it only holds on the the last one.  I’ll have to check the database for deleted records.

Exchange attachments

• Attachments from Exchange seem to be stored internally vs. the SD Card.  Found mine at /data/data/com.android.email/databases/1.db_att as numbered files.  I had 3, a PDF, vCard and a .wav file.

Who else is tracking you…besides Google?

• I’m now seeing a database in several applications (not to pick on the apps because they are really good but they are NewsRob and Twidroid) called google_analytics.db.  The database contains what I suspect it the application providers Google Analytics ID.  I don’t know how I feel about this…Google gets enough about me but I wonder what they or the app provider are tracking…maybe it’s all generic.  Below are the columns in the database so you can see the information stored is pretty detailed:
  • CREATE TABLE events ( ‘event_id’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, ‘user_id’ INTEGER NOT NULL, ‘account_id’ CHAR(256) NOT NULL, ‘random_val’ INTEGER NOT NULL, ‘timestamp_first’ INTEGER NOT NULL, ‘timestamp_previous’ INTEGER NOT NULL, ‘timestamp_current’ INTEGER NOT NULL, ‘visits’ INTEGER NOT NULL, ‘category’ CHAR(256) NOT NULL, ‘action’ CHAR(256) NOT NULL, ‘label’ CHAR(256),  ‘value’ INTEGER, ’screen_width’ INTEGER, ’screen_height’ INTEGER);

Bone-head security award goes to /data/data/com.android.email/databases/EmailProvider.db

• OK, now I’m really ANNOYED.  So, /data/data/com.android.email/databases/EmailProvider.db has your Exchange password in plain text.  Nice.  Lots of other email content in there (and that’s fine),  But. really, plain text guys?

User Dictionary

• User dictionary stored at /data/data/com.android.providers.userdictionary/databases/user_dict.db and could be useful in some investigation.

Device/User settings

• Lots of user/devices settings in /data/data/com.android.providers.settings/databases/settings.db

If you made it this far, thanks for bearing with my brain stream.  I didn’t have much time to spend on this right now so I just grabbed a few interesting ones.  We’re developing techniques to do more structure analysis on the data, applications, etc. so stay tuned.  You can sign up for updates on our Android Forensics page.  Also, we offer training so drop us a line if interested.

I’m pleased to announce the release our of comprehensive Android Forensics training course which will fully prepare examiners for the Android platform. The course will provide participants with the tools, techniques and analysis methods needed to effectively investigate an Android device.

This training course is for law enforcement or government employees only. Participants must bring a laptop to the training and should have an expert level knowledge of forensics (no prior Android knowledge required). Register now as space is limited.

Also, our Android Forensics white paper is nearly complete. That and other updates (including magazine articles, interviews, mailing list archives, blog postings and more) will be updated soon on our Android Forensic page.

Hope to see you in St. Louis.

Late last week, Lee Whitfield (of Forensic 4Cast) and I spoke for a while about Android Forensics.  The whole program is interesting…I believe my interview starts around 45:40.  Check it out at Episode 25 – The Little iPhone Worm That Could.

While we continue our R&D on getting a full dd image from a Motorola Droid, I thought it would be interesting to do a quick write up on Google Maps Navigation artifacts.  Since we don’t yet have full access to the system, this preliminary analysis focuses on the residual data left on the SD Card.

SD card info

After grabbing an image of the SD card, I took a quick look with mmls (TSK rocks) and saw that the first 4MB of the card are unallocated leaving the FAT32 partition to start at sector 8192:

ahoog@wintermute:/mnt/readonly-fs/google_maps_navigation/cache$ mmls ~/droid/sd/viaforensics/droid/item001-awh123/item001-awh123.dc3dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

 Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000008191   0000008192   Unallocated
02:  00:00   0000008192   0031326207   0031318016   Win95 FAT32 (0x0C)

Obviously there is various user and application data on the drive but that will be for later posts.  The Navigation app stores data the directory google_maps_navigation on the root of the SD.  Inside that directory, there are two more directories, cache and debug.  I’ll have to figure out how to turn debug on but for now, no data was written to that directory.

.Wav files

The cache folder has 2 SQLite 3 databases, tilecache_ImageTileStore.db and tilecache_VectorTileStore.db.  Also, there are hidden .wav files following this naming convention:

._speech_nav_N.wav

where N is an incrementing number starting at 0.  There are some great things about these files for a forensic examiner:

1. They are dated!
2. They are standard .wav files (RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 16000 Hz)
3. They contain the speaking from the application, complete with expressways, turns, etc.

Here’s what it looks like after I took a 25 mile trek back from a north Chicago suburb:

ahoog@wintermute:/mnt/readonly-fs/google_maps_navigation/cache$ ls -la
total 1184
dr-xr-xr-x 2 root root  32768 2009-11-16 15:32 .
dr-xr-xr-x 4 root root  32768 2009-11-16 13:31 ..
-r-xr-xr-x 1 root root  66476 2009-11-16 15:20 ._speech_nav_0.wav
-r-xr-xr-x 1 root root 142252 2009-11-16 15:19 ._speech_nav_1.wav
-r-xr-xr-x 1 root root 142380 2009-11-16 15:18 ._speech_nav_2.wav
-r-xr-xr-x 1 root root  73644 2009-11-16 15:15 ._speech_nav_3.wav
-r-xr-xr-x 1 root root  60460 2009-11-16 15:15 ._speech_nav_4.wav
-r-xr-xr-x 1 root root 107948 2009-11-16 15:15 ._speech_nav_5.wav
-r-xr-xr-x 1 root root  96300 2009-11-16 15:20 ._speech_nav_6.wav
-r-xr-xr-x 1 root root   6144 2009-11-16 13:31 tilecache_ImageTileStore.db
-r-xr-xr-x 1 root root 281600 2009-11-16 15:32 tilecache_VectorTileStore.db

So for anyone wanting to follow my long drive back Skokie, IL, they could see the date, time and even hear the directions.

On a less positive note, the files from my drive *to* Skokie a few hours earlier are not there.  So it seems each navigation overwrites the previous (will experiment and confirm later).  That could be interesting if 1 trip about 30 directions and another only had 5.  Also, I will have to see how many my trip really had so I can determine if the there is a fixed about of cached voice directions.

SQLite info

As mentioned earlier, there are two SQLite databases and but my tilecache_ImageTileStore.db is currently empty.  So, on to tilecache_VectorTileStore.db which has plenty of data.  Here’s the table schema:

sqlite> .schema
CREATE TABLE android_metadata (locale TEXT);
CREATE TABLE cache_table (key INTEGER NOT NULL PRIMARY KEY, data BLOB);
CREATE TABLE last_use_table (key INTEGER NOT NULL PRIMARY KEY, last_use INTEGER NOT NULL);
CREATE TABLE metadata (data_version INTEGER NOT NULL,schema_version INTEGER NOT NULL);

And the two tables with data are cache_table and last_use_table.  The blob in the cache is likely a .PNG image cache from the application (like the iPhone) but I have to work on this further.  The last_use_table has the same key (which seems to be a simple incrementing integer) and a date/time stamp in Unix epoch.  Since both tables have exactly 81 records on my database, I suspect I will be able to correlate the exact date/time the phone was located at a particular GPS coordinate.

Conclusion

Android is going to be an exciting, every developing platform which is already widely in use.  Since Android is predicted to overtake the iPhone by 2012, the forensics community needs to invest neurons into the platform.  Like previous smart phones, the Android platform promises to deliver a wealth of data about its use.  This is great news for the forensic analyst…but maybe few others.

If you are interested in Android Forensics, sign up for our forthcoming Android Forensics White Paper.  We are currently testing the following products and techniques:

• Cellebrite
• Oxygen Forensic Suite 2010
• Paraben
• .XRY
• Hoog Method (full dd image)

As with out iPhone Forensics white paper, we will test each product technique are report on the results.  Also, we hope to publish a book in the near (or distant) future.  If your organization is encountering Android phones or wants to prepare for the inevitable, drop us a line.  On supported phones, the Hoog Method will allow for the full recovery of deleted files, data and more.  Several training classes are in development and will be ready before the end of the year.  If you are interested in an outline of the course or the details about the on-going access to our R&D you will receive, let me know.  Exciting times…