Android use is growing exponentially, with nearly 200,000 devices activated daily and more than 12 million Android phones in use around the world. Android core applications allow us to do things like send text messages, download and send media, take photos and videos, and much more. But what happens when something we need goes missing or is accidentally or maliciously deleted?

The good news is that Android does a good job of storing and backing up data on the device and most deleted data, including deleted text messages, are recoverable. However, there are some basic steps that you need to do to ensure that the deleted data is not lost forever:

1. Stop using the phone immediately! The actual text message still exists on the device until the space is needed for something else so by not using the phone you will prevent it from being overwritten.
2. Place the device into Airplane Mode and shut it down. This ensures that no new messages or data content is downloaded to the device
3. Contact a forensic expert who can recover the data. We use various techniques including:
• Forensic imaging of the entire device and SD card (admissible in court if needed)
• Recovery of deleted and non-deleted items in various databases on device – including text messages (sms/mms), phone history, emails, web history, pictures, videos, notes, voicemails, WI-FI information, FaceBook info, YouTube info, and much more.
• Full indexed search of the entire user data partition using advanced forensic tools.
• Backup file examination (if available)
• Advanced NAND memory access techniques

Time is critical when looking to recover deleted items. We guarantee success in recovering deleted items if the above steps are taken shortly after the item is deleted.

Sometimes we are approached by a client looking to recover a deleted text message from several months ago on a phone still in active use. Although this is not impossible, the probability of full recovery of the message decreases significantly. If full recovery is not possible we can almost always recover at least a portion of the message.

Recovering deleted sms/mms (text messages) and other data on Android phones requires advanced tools and techniques not accessible to everyday users. As pioneers in smart phone forensics research, viaForensics has performed hundreds of recoveries on various Android phones including the G1, MyTouch, Samsung Galaxy and Fascinate, Motorola Droid and Droid X, HTC Droid Eris and Incredible among others. We train and consult with law enforcement and attorneys, as well as private clients who need to recover deleted data.

If you require professional Android data recovery, contact us to discuss your specific case.

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.

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…

I really like my Droid…and I know it will continue to improve.  But since there are plenty of people proclaiming it’s greatness, I’ve decided to post my top complaints after a few days of use:

1. If you type in a phone number, it does not lookup the contact until I make call.  Sometimes I type numbers manually and in my previous 2 Android phones, as soon as I type the final digit, it pops their name if they are in my contact list.  So I know I typed it correct.
2. I could not accept an MS Outlook/Exchange invite…this is just annoying.  I had to accept on my iPhone…that’s not cool.
3. I cannot create an email signature for my Exchange account.  Apparently this is known by Motorola…let’s hope they fix it soon.
4. I occasional have sync issues…the iPhone or Outlook will show a message and Droid sits around for a while.  This does not happen too often.

There are some many little things that were thought of, though, which means I’m still a happy Droid user…I just hope they fix these in the next release.