A customer recently brought us an unlocked Samsung Galaxy S23 with a familiar request: they had lost their RCS chat history sometime around the end of March, and they wanted us to recover the conversation with one particular contact.

RCS has been a problem child of a messaging protocol lately. We've seen no shortage of cases involving messages vanishing on their own, failing to send, or never arriving — sometimes affecting entire accounts at once. So when this device came in, we knew the path forward but also knew the odds.

The extraction

We performed a full extraction using Cellebrite UFED and parsed the result in Cellebrite Physical Analyzer. To go deeper than what PA surfaces by default, we also opened the relevant SQLite databases directly in DB Browser for SQLite and ran custom queries against the underlying tables.

On a modern Samsung, RCS and SMS message data can live in several places, and any thorough investigation needs to check all of them:

The twist

Our first big finding was unexpected. A global search on the contact's name turned up only two surviving messages from early January. When we cross-referenced the contact's number across all four databases, we discovered the is_rcs_available flag was set to 0 — meaning that number wasn't even registered for RCS on the carrier network. The Samsung database showed conversation_type=0 and a null im_thread_id. The Google Messages database confirmed the same thing.

In other words: this specific conversation was never RCS to begin with. It had always been plain SMS. The two surviving messages were everything that still existed on the device — no RCS thread had ever existed between these two parties.

The scale of the actual RCS loss

That said, the customer's broader concern about RCS deletion was very real. SQLite's sqlite_sequence table records the highest ID ever assigned in a database, even after rows are deleted — which makes it a powerful forensic baseline. On this device, the im table had once held tens of thousands of RCS messages across well over a thousand threads. At the time of examination, it held zero. The Google Messages database told the same story: roughly fifty thousand messages had been deleted over the device's lifetime, with only a single RCS message surviving.

Application logs and database timestamps painted a clear picture. On a single afternoon, multiple RCS threads were moved to the trash inside a half-hour window — with several of those clustered within seconds of each other, a pattern inconsistent with manual deletion and consistent with an automated or programmatic process. A separate cloud-sync event a month later removed dozens more conversations via Samsung's deleteOnlyLocalConversation routine, which purges local copies after cloud backup confirmation.

Why nothing was recoverable

Here's where the case ended on the device side. When you delete a row from a SQLite database, the page that row lived on is normally added to a free list — and forensic tools can often carve those free pages to reconstruct deleted records. But SQLite's VACUUM command rewrites the entire database file from scratch and permanently discards every free page in the process.

All three message databases on this device showed zero free pages despite tens of thousands of deletions. The only way that's possible is if VACUUM ran after the deletions occurred. At that point, the residual data is gone — not "hard to recover," but mathematically unrecoverable from the file.

Where hope still lives

This is the part worth emphasizing for anyone in a similar situation. Even when on-device recovery hits a wall, the messages themselves often still exist somewhere:

Samsung Cloud and Google's backup services (Google One / Android backup) may still hold copies, and these can sometimes be accessed through legal process. And the other party in the conversation has their own device, which is an entirely independent record — completely unaffected by whatever happened on the customer's phone.

The takeaway

Deleted RCS messages are rarely recoverable from the device itself, and that's even more true when a VACUUM has run — whether triggered by the OS, a sync routine, or routine database maintenance. But "unrecoverable from this device" isn't the same as "gone forever." A thorough investigation always considers external sources, and the forensic value of confirming what did happen — when, how, and by what mechanism — is often as important to a legal matter as the messages themselves.

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.