A customer brought us an unlocked Samsung Galaxy S23 with a request we hear often. They had lost their RCS chat history sometime around the end of March, and they wanted the conversation with one particular contact back.
RCS has been a problem child of a messaging protocol for a while now. We see cases every month involving messages that vanish on their own, fail to send, or never arrive, sometimes across an entire account at once. So we knew the path forward when the device came in. We also knew the odds.
What we pulled
We took a full extraction with Cellebrite UFED and parsed it in Cellebrite Physical Analyzer. PA surfaces a lot by default but not everything, so we also opened the relevant SQLite databases in DB Browser for SQLite and ran our own queries against the underlying tables.
On a modern Samsung, RCS and SMS data can live in several places at once. A thorough job checks all of them:
mmssms.db, the Android telephony provider's database. RCS lives in theimtable, threads inim_threads.message_content.db, Samsung Messages' app-layer copy of the same data.bugle_db, Google Messages' database, which also carriescms_deleted_messages_bufferfor tombstone records of deleted messages.FileLog0.log, Samsung Messages' application log, which often records sync and deletion events.
The contact was never on RCS
The first finding was not what anyone expected. A global search on the contact's name returned two surviving messages, both from early January. When we cross-referenced the number across all four databases, is_rcs_available came back as 0. That number had never been registered for RCS on the carrier network at all. The Samsung database showed conversation_type=0 and a null im_thread_id, and Google Messages agreed.
So the conversation the customer wanted had always been plain SMS. Those two January messages were everything that had ever existed on the device for that contact. There was no RCS thread to recover, because there had never been one.
How much was actually deleted
The customer's broader worry about RCS deletion turned out to be well founded, though.
SQLite keeps a table called sqlite_sequence that records the highest row ID ever assigned, and it survives deletions. That makes it a useful baseline for working out how much a database once held. On this device the im table had at one point carried tens of thousands of RCS messages across well over a thousand threads. When we examined it, the table held zero rows. Google Messages told the same story: roughly fifty thousand messages deleted over the life of the device, with a single RCS message left standing.
The application logs and database timestamps filled in the rest. On one afternoon, multiple RCS threads went to the trash inside a half-hour window, several of them clustered within seconds of each other. That timing is hard to produce by hand and easy to produce with an automated process. A month later a cloud sync event removed dozens more conversations through Samsung's deleteOnlyLocalConversation routine, which purges the local copy once cloud backup confirms.
Why none of it came back
Normally, deleting a row from a SQLite database puts the page that row lived on onto a free list. The bytes stay where they are until something else claims the page, and forensic tools can carve those free pages to reconstruct deleted records. That is the usual route to recovery.
SQLite's VACUUM command closes that route. It rewrites the whole database file from scratch and discards every free page along the way.
All three message databases on this phone showed zero free pages, despite tens of thousands of deletions. There is only one way that happens: VACUUM ran after the deletions. At that point the residual data is no longer difficult to recover. It is no longer in the file.
Other places the messages might still exist
On-device recovery hitting a wall does not mean the messages are gone from the world, and this is the part worth holding onto if you are in the same position.
Samsung Cloud and Google's backup services (Google One, Android backup) may still hold copies, and legal process can sometimes reach them. The person on the other end of the conversation also has their own phone, which is a completely independent record of the same messages, untouched by whatever happened on yours.
What we told the customer
Deleted RCS messages are rarely recoverable from the device itself. Once a VACUUM has run, whether triggered by the OS, a sync routine, or ordinary database maintenance, they are not recoverable from it at all.
That is a narrower statement than saying the messages are gone. A proper investigation looks at external sources too. And confirming what happened, when, and by what mechanism often carries as much weight in a legal matter as the messages themselves would have.
Case details have been generalized to protect client confidentiality. Published with client consent.
If you're facing a similar matter, see our Mobile Forensics page for the full methodology, or open a case for a privileged consult.