DriveFS Sleuth — Recovery Made Possible!

Amged Wageh
5 min readMay 31, 2024

--

In the previous Medium story DriveFS Sleuth — Revealing The Hidden Intelligence, we explored how the Google Drive for Desktop application (formerly Google Drive File Stream) utilizes protocol buffers to store key information about synchronized items, such as MD5 hash of the synced items even if the synced items are not available offline. In this Medium story we’ll explain how reversing these protobufs along with other findings from researching the application’s disk forensic artifacts, helped understanding the caching information. This knowledge allows us to recover the cached synced items without any extra collection, just the same data we collected from %LocalAppData%\Google\DriveFS.

In the DriveFS Sleuth — Your Ultimate Google Drive File Stream Investigator! Medium story, we discussed how the synced items’ properties are being stored in the item_properties table within the metadata_sqlite_db database. One crucial property for recovery is the content-entry which can be linked with a synced item using the item_stable_id. The content-entry contains a protobuf blob, and by decoding this blob, we can retrieve an id that is stored in the first index of the decoded protobuf. The following example shows the properties of item 206 including the encoded content-entry.

The encoded content-entry blob

The following screenshot shows the decoded content-entry of the same item where we can see that the first index of the decoded blob is 210.

The decoded content-entry

Hereby, we can easily find the cached content of that synced item under the %LocalAppData%\Google\DriveFS\<account ID>\content_cache\d<number>\d<number> directory with the same filename “210” in this case.

The cached file with filename=the identified ID

Now after recovering the synced item from the cached content, we need to rename the file and its extension so we can be easily recognized. There are several places where we can find the name like the local-title property in the item_properties table, the local_title in the items table within the metadata_sqlite_db, or at index 3 of the decoded proto blob of the item from the items table, however, the extension of the item can be deduced from the mime_type or we can find the exact value in index 45 of the decoded proto blob of the item. The following screenshots shows the the mime_type, and the local_title of item with stable_id 206.

Item’s Metadata

The below screenshot shows the same information in the proto blob of the item besides the item’s extension.

The decoded proto blob of the item

Now after assembling all the item’s metadata, we can recover it as follows.

The recovered item

For the thumbnails, it’s much easier as we can determine the items that has a cached thumbnail by querying the items that has an associated key=thumbnail-cache-id-list value in the item_properties table within the metadata_sqlite_db database, the existence of this value means that the respective synced item has a cached thumbnail and it can be recovered from the %LocalAppData%\Google\DriveFS\<account ID>\thumbnails_cache\d<number>\d<number> where the cached thumbnail filename will be the same as the item’s item_stable_id, for example, we can see that item 206 has a thumbnail-cache-id-list property so we can go directly to recover it from the thumbnails_cache directory.

Recovering the cached thumbnails.

DriveFS Sleuth Made it Easy!

DriveFS Sleuth is a python tool that is developed based on the findings of this research to help incident responders and threat hunters by automating the investigation of the disk forensic artifacts of the Google Drive for Desktop application. One of it’s capabilities is the data recovery. Currently, there are mainly two command line arguments that can be used for the recovery from cache which are:

  • --recover-from-cache which recovers all the cached items without any filtration.
  • --recover-search-results which recovers the cached items that satisfies the search results.

A sub-directory for the recovery will be created under the output directory passed via the [-o|--output] argument, for each logged-in account, another sub-directory will be created under the recovery sub-directory where the recovered items will be saved. A thumbnails sub-directory will be created for each account to save the recovered thumbnails for this account.

The following example demonstrates how DriveFS Sleuth was able to recover the cached items.

Recovering the cached items.

Below we can see in the generated HTML

recovery path in the html report

The same information can also be obtained from the CSV report.

recovery path in the csv report

--

--

Amged Wageh

A Sr. DFIR Consultant who has a proven track record of successfully leading investigations into cyber security incidents.