Samsung Trash Provider App - Traces of deleted files never hurt

This post shows my result of my research on the Samsung Trash Provider App on Samsung Android devices.

Android Version Tested:
Android 16

Test device:
Samsung Galaxy S23

Database location:
[...]/com.samsung.android.providers.trash/databases/trash.db

What is this app about?

The Samsung Trash Provider App is not an app a user directly interact with. The app is used by other apps (e.g. MyFiles and Gallery App) to offer trash bin functionality. In earlier OneUI/Android versions this worked differently. There every single app had its own trash functionality implementation.

This means it is still possible, that trash data is also stored in the individual app.

What's in the databases?

In the database "trash.db" is one interesting table, it is called "trashes". With the following interesting columns.

• _data - Current file path
• original_path - The original File path
• _id - Some file id
• media_id - an additional id, empty for my data
• sec_media_id - id in the corresponding Samsung app, was filled for Gallery app and matched the idea there in my data
• is_cloud - for my data always 1 - but I did not have any cloud sync active - so meaning not known atm
• volume_name - The name of the volume the data is stored on
• title - In my data always the file name with file extensions
• _display_name - What is shown in the apps - identical to file name in my data
• _size - Size of file in bytes
• mime_type - Recognized MIME type of the file
• media_type - 1 = Image, 2 = Audio, 3 = Video, Pretty sure there are more types but I only have these in my data atm
• datetaken - if media was taken on the phone this value is set - didn't found another case were it was filled
• date_expires - the date/time this file will be deleted completely from trash
• date_deleted - the date/time the file was moved to trash
• user_id - which user account deleted it (0 = main user, 150 = secure folder context)
• extra - additional info from the source app, JSON based - can hold exif data (location, timestamp taken etc.)

Example SELECT query:

SELECT
    _id [File ID],
    _data [Trash File Path],
    original_path [Original File Path],
    title [File Titel],
    _display_name [File Name],
    _size [File Size],
    mime_type [MIME Type],
    delete_package_name [App Context],
    is_cloud [Cloud?],
    user_id [User ID],
    strftime('%Y-%m-%d %H:%M:%S.', "date_deleted"/1000, 'unixepoch') || ("date_deleted"%1000) [Deletion Timestamp],
    strftime('%Y-%m-%d %H:%M:%S.', "date_expires"/1000, 'unixepoch') || ("date_expires"%1000) [Expiration Timestamp],
    extra [Extra Info JSON]
FROM trashes
        

Location of the deleted files

The files are stored in the media part of the Android system under Android/.Trash

Full path can be e.g. /data/media/0/Android/.Trash/[...]

The pattern in this is as follows:

[appcontext]/[file_uid]/[old_file_path]/.!%#@$/[old_file_name]

Example:

/storage/emulated/0/Android/.Trash/com.sec.android.app.myfiles/f00f4be8-7dad-4996-aedb-6edc4b9f42d3/1763651528662/storage/emulated/0/Music/Telegram/.!%#@$/deleted_file.ogg

With this info, even if we do not have any database access, we can tell a bit about the file. From the example above:

• App Context - The files was deleted via the App Samsung My Files
• Old File Path - The original File path was /storage/emulated/0/Music/Telegram/
• Old File Name - The original File Name was deleted_file.ogg

This fits what I've done on my test phone.

Additionally Good to know

Based on the values for date_expires and date_deleted one can say that per default the files will stay 31 days in the trash and than will be deleted automatically.

But, in my test data - the entry in the database was kept in it - so file was gone, trace of it was still there.

I recovered one file (undeleted via GUI), the entry is immediately deleted from the database and the file is moved back to its original location.

Conclusion

1. The Samsung Trash Provider App stores info on deleted files. Also from other Apps like Samsung Gallery and MyFiles.

2. The files are kept for 31 days in the Trash

3. Even if we only have the files in the default trash folder location (e.g. /media/data/0/Android/.Trash/) we can say a few things about the files. E.g. in which app context it was deleted, what was the original path and the original file name

I've created an ALEAPP parser for this. It is part of an already open PR (#665) waiting to get pulled into the ALEAPP repo.

BUBBLES!!! BUBBLES! [gibbering] MY BUBBLES! - Chats (export/backups) need bubbles

In the last few days I took some time to develop a few things. And it has to do with bubbles ;-)

I developed "Bubbly" - a small tool that parses different Messenger Export and Backup formats and visualize the data in HTML Bubble View. The data is filterable, searchable, taggable and media files are supported.

The tool can be found at https://github.com/kalink0/bubbly. It is Python based CLI-application and I have built versions for Linux and Windows on Github.

How do the bubbles look?

The Overview HTML

When running the tool an overview page is created that shows the created thread views. One can also decide to put all chat threads in one view. Then only one would be shown on the overview page.

The Chat Thread HTMLs

The created thread view that shows the data with the bubbles is divided into three parts.

1. The header with general info:

 This part can be collapsed. And one can load or export created tags and go back to the overview page

2. The control panel:

Which contains the filter and search functionality.

3. MY BUBBLES!

Tagging is possible via the button in the bubbles (only three predefined tags at the moment).

Current implemented parsers

Currently I have the following parsers implemented:

1. WhatsApp Chat Export

This parser parses the Chat Export from the iOS and Android WhatsApp app.

Because the Output is different based on the system language -> currently fully supported are German and English. But I work on a more robust implementation.

2. Wire Messenger Backup

Parses Wire backup files - only unencrypted backups are supported atm.

3. Telegram Desktop Chat Export

Parses Chat Exports frorm the Telegram Desktop App. 

4. Threema Backup Parser

Parses Backup of the Messenger Threema. But: the data needs to be decrypted before parsing - no decryption feature.

5. Generic JSON Parser

I've built a generic JSON parser with a simple JSON design. Also a mapping script is in my repo. The main idea: just create the simple json for a messenger, Bubbly is doing the rest to get the bubbles.

Additional functionality

1. Branding - it is possible to give a logo that is shown in the top left corner

2. General case information - Case number, name of creator are necessary to create an HTML

3. Logging - the read files and written files are documented including the setting used. (Not the media files)

4. Config File usage

5. CLI interactive mode

Why did I develop it?

Main reasons:

- Easy to use and to hand over to other persons - especially the Bubble View and the media file support in a directly usable HTML.

- Fast to implement new parsers for not so well known formats/messengers (Exports and Backups)

- Basic filtering, searching and tagging functionality

Well, I needed a fast way to visualize the basic information from Exports and Backups of different messengers. That is what I focused on. And the bubble view is the one that everyone - also non technical persons, know and understand, so I wanted this view.

The limitations - or - what is Bubbly NOT

Bubbly is not a "Forensic Chat Analysis Tool". It focus on the data from Exports and Backups and gives additional possibility to create bubble view of other messengers with mostly less functionality. I don't plan to support any parsing of the well known messengers like Signal, WhatsApp, Telegram on Android and iOS with full functionality support for all they have (e.g. statuses, answering messages, forwarding messages, reacting etc.) with Bubbly. There are other tools out there to do this. 

I want to keep it as simple as possible.

Also there won't be any export functionality - I thought about it first - but the simple used platform and the use of web-browsers limit the functionality. Tagging and export/import of them is possible - so one can share them at least.

I tested Bubbly with data sets with around 20000 messages per thread (incl. media files) - without any problem - but there will be a limit for sure ;-)