Forensic analysis of Google Maps Navigation – Motorola Droid – viaForensics

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…