Google Drive Forensics
Google Drive has some very useful artifacts that help identify not only what a user may have pushed to the cloud, but also what they have pulled and stored on the current system. The three main files we will be looking at are:
- System Drive/Users/(Username)/AppData/Local/Google/Drive/snapshot.db
- System Drive/Users/(Username)/AppData/Local/Google/Drive/sync_config.db
- System Drive/Users/(Username)/AppData/Local/Google/Drive/sync_log.txt
These three files have an enormous amount of information that can help aid in both user identification as well as user interaction. So what’s the first question? Well, how do we open this? Luckily the Google Drive database files can be opened with any SQLite 3 compliant software. I used SQLite Expert to open the database file. No other work needed.
Of these six relations, there are two that may have immediate useful information.
The cloud entry contains quite a bit of gold. The resource_id(folder:root) attribute contains a unique identifier that defines the file stored in the cloud. From what I experienced, the first half of the string is constant which tells me it’s unique to the user and defines the account that is being synchronized. The second half of the string changes which appears to be the file identifier. The next attribute is the filename. TestDoc.docx was created and is stored in the cloud. Next is the modified time(null) which is stored as unix time. This example was modified on 1381393779. Be aware, this modified time is based on the modified time in the cloud. If a file is sitting on the local system in the google drive folder but has NOT been synched, you may find some conflicting information. The next attribute to note is the URL. This is the location of the file for Google Drive to keep itself updated. You can see above that the unique identifier from the resource_id is in there. The last two attributes are the size and the MD5 Hash(checksum).
In the local_entry, we only get a few attributes. The inode_number has something to do with the pointer reference of the file. This may be in the cloud itself or possibly used for local purposes, however, I’m not confident enough to confirm exactly what it is. The bigger thing I would like to point out is the modified time. This is a locally stored modified time and may conflict with the cloud_entry relation. Do not assume that these modified times should match between relations and they will also help you confirm which is the more recently modified file. Lastly again is the size and the checksum.
The next database file to open up is the sync_config.db.
There’s only one relation in this database but the information it contains is important.
The identifiers in this relation are more focused on the tuple than they are the attribute. From top to bottom, the tuples that were interesting start with the feature_switch. This is a large Base64 encoded string. From what I could tell, this had some things such as version identification of Google Drive. The next tuple is the highest_app_version which also identifies the version of Google Drive. Tango_storage I found reference to in a string of the registry and was another Base64 encoded string. I’m not sure on exactly what it is used for but it may be some part of authentication. Lastly is user_email. This WILL tell you what e-mail address is being used to synch to this specific Google Drive instance.
The Sync_log is exactly what it sounds like. It’s generally a decent sized text file that contains created/modified information of anything that interacts with the Google Drive application.
We can see modified times as well as the unique file identifiers in the image above. There is also the checksums of each file.
This was near the bottom which also had the direct reference to what e-mail is being used to synchronize to the cloud.
So is that it? Absolutely not. I found references to Google Drive in all of the following instances;
- Physical Memory
- Keyword Searches (such as looking for “file:” or “@gmail.com/drive”)
- Extraction (Using Bulk Extractor or Foremost)
- Pagefile.sys (This is your virtual memory located on the system drive.)
- Unallocated Space
- Hiberfil.sys (When your memory needs to be stored during sleep periods of the system. Also located on the system drive.)
- Below is the Pagefile.sys, Unallocated and Memory Analysis respectively.
Thank you for taking the time to read this post. I hope this has been informative and if you have anything to add, please place a comment! I will modify accordingly.