Dumpster Diving in Google Photos Android App: "local_trash.db"

 

This article will explore the Trash within the Google Photos Android App. If you delete any media file from Google Photos on your mobile device, the deleted media file would then be relocated to the Trash within Google Photos. All items inside Trash will be permanently deleted after 60 days in Trash.
In fact, the information of the Google Photos Trash items will be stored inside the "local_trash.db" under "/data/com.google.android.apps.photos/databases/":


The "local" table of "local_trash.db" contains most of the useful information, including "local_path" (the original path of the deleted media file), "trash_file_name" (a UUID value that becomes the new name of the deleted media file), "deleted_time" (a Unix timestamp in milliseconds that recorded the delete time), "is_video" (where "0" = "no", "1" = "yes"), etc.

As soon as a media file was deleted inside Google Photos, the media file itself will be relocated from its original directory to the "/data/data/com.google.android.apps.photos/databases/files/trash_files/" directory. 

In addition, the media file will be renamed as the "trash_file_name" value found from the "local" table inside the "local_trash.db". 

In the example below, it could be found that the "125a9db3-3d3c-49b7-8bde-5015d30bf229" file under the "trash_files" directory was originally stored under "/storage/emulated/0/DCIM/Camera/" as "IMG_20210111_212729.jpg", by referring to the entry that contained "125a9db3-3d3c-49b7-8bde-5015d30bf229" as the "trash_file_name" in the previous screenshot .
Also, there are some information stored inside "local_trash.db" that is related to the Android media-related "external.db", where "media_store_id" contains the media file's original "_id" value from the "files" table of "external.db" and the "media_store_values" contains the original entry of the media file inside the "files" table of "external.db". 

After the deletion of a media file inside the Google Photos app, the respective entry of that media file inside "external.db" would be removed as well. This was observed on both Android 9 and 10.

From the screenshots above, the media files with "_id" value "366", "367", "298", "297" and "370" were deleted. It was observed that their respective entries inside "external.db" were deleted too.



Comments

Post a Comment

Popular posts from this blog

An Android Casting (Device) Story: "cast.db"

Image
  This article will briefly document a SQLite database (" cast.db ") found from Android devices, which would store the information of detected casting devices on the Wi-Fi network. The said " cast.db " can be recovered at " /data/com.google.android.gms/databases/cast.db ".  Using Joshua Hickman's Android 10 image as an example, " DeviceInfo " table from  " cast.db "  would store the casting device ID (SSDP UDN), device friendly name, device model name, device IP address and port number, hotspot BSSID , etc. Apart from the basic information of the casting devices, some interesting Epoch timestamps in milliseconds like " last_published_timestamp_millis ", " last_discovered_timestamp_millis " and " last_discovered_by_ble_timestamp_millis " could be discovered as well.  There were some other intriguing tables such as " NetworkInfo ", which probably records the last connected time to a Wi-Fi networ
Read more

Magnet Weekly CTF Challenge Week 12 Writeup - Last But Not Least

Image
Time flies and finally we have made it into the last week of Magnet Weekly CTF. This week was still a two-parter. The 1st part of the challenge asked of a PID: Using HxD to search the key phrase " how hackers hack, and how to stop them " inside the memory dump, a hit could be found quickly:  After that, the Volatility yarascan plugin was used to find the PID that related to  " how hackers hack, and how to stop them ".  The Hex value corresponding to the " How Hackers Hack, and How To Stop Them " string value discovered from HxD could be reused as the search criterion for yarascan , the  " python vol.py -f ../memdump.mem --profile=Win7SP0x64 yarascan -Y "{48 6F 77 20 48 61 63 6B 65 72 73 20 48 61 63 6B 2C 20 61 6E 64 20 48 6F 77 20 54 6F 20 53 74 6F 70 20 54 68 65 6D} " command was issued in terminal: From the yarascan output, all hits came from the " iexplore.exe " process with PID 4480 . Therefore, the answer for the part 1 chal
Read more