This is one of the harder cases we work — and one worth writing up not because it ended in success, but because the lessons matter for anyone who might face the same situation.

A client came to us after losing access to a crypto wallet holding significant value. The private key had been generated by an automated trading bot inside a Telegram conversation, briefly displayed in the chat window, then deleted shortly afterward. It had never been written down, backed up, or stored anywhere else. Could we recover it from the device?

Here is what we tried, what we found, and the timing reality that ultimately decided the outcome.

The starting point

The client provided a recent-model iPhone that had been used to receive the displayed key. We performed a full filesystem extraction (several hundred GB) using a forensic-grade extraction tool capable of bypassing iOS encryption, then located Telegram's primary application database within the image.

The Telegram iOS app stores its data using a proprietary format called Postbox, which sits on top of SQLite but stores message contents in binary-encoded form inside the tables. The primary message table is t7, found at private/var/mobile/Containers/Data/Application/[UUID]/postbox/db/db_sqlite. On this device the database was approximately 6 GB. We opened it in DB Browser for SQLite and went to work.

Step 1: Querying the active records

The first thing we needed to confirm was whether the conversation with the bot was intact. Filtering table t7 for the bot's unique Peer ID returned dozens of active message records — wallet balance updates, transaction confirmations, and multiple instances of the bot's wallet-replacement warning advising the user to withdraw assets before replacing the wallet. This confirmed the conversation was active and that the replacement flow had been triggered.

But the actual key message was not there. It had been deleted prior to extraction.

Step 2: Write-ahead log (WAL) analysis

SQLite uses a write-ahead log as a temporary buffer for recent changes. Deleted records can sometimes be recovered from WAL contents before they're checkpointed — merged into the main database. We identified six WAL files across the iPhone extraction and analyzed each one, including one whose timestamp landed almost exactly at the deletion event.

That timestamp-perfect WAL had already been checkpointed. Its contents had been merged into the main database and any remnants of the deleted message had been incorporated and overwritten in the process. None of the six WALs contained the key.

Step 3: Freelist page analysis

When SQLite deletes a record, the underlying database page is marked as free and added to the freelist. Until that page is reused, the deleted content remains physically present and recoverable.

We wrote a custom Python tool to scan every freelist page in the database, searching for the bot's Peer ID, the target wallet address, and patterns consistent with a 64-character hexadecimal private key. The bot's Peer ID turned up in dozens of locations and the wallet address appeared dozens of times — but the freed pages that had once held the key had been overwritten.

Step 4: Full raw binary search

Beyond the structured freelist approach, we ran a byte-by-byte scan of the entire database file, looking for the bot's identifiers, known trigger phrases the bot uses immediately before displaying a key (prompts asking the user to enter their private key), and every 64-character hexadecimal string anywhere in the file. This surfaced roughly a dozen candidate keys.

Each candidate was then cryptographically verified against the target wallet address using the eth-account library — derive the address from the candidate key, compare it to the known wallet. None matched.

Step 5: Secondary databases

The iPhone filesystem contained several additional Telegram databases — including those used by the notification extension and widget components in Telegram's iOS AppGroup shared container. We analyzed all of them. Every reference to "private key" we found turned out to be benign: warning messages from unrelated Telegram chats, never the target key itself.

Step 6: The Mac side — Telegram Desktop

The client had also used Telegram Desktop on a Mac, where the same conversation existed. They provided their tdata folder.

Telegram Desktop encrypts its local data files using AES-IGE encryption with a key derived from a key_datas file and a corresponding maps file. The standard decryption pathway requires the maps file to contain three encrypted streams.

In this case, the maps file contained only one stream. We tried three different decryption tools in sequence:

Step 7: The live server attempt

The DC authentication keys recovered in the previous step offered one last avenue. If those keys were still valid on Telegram's servers, we could connect via the Telethon library and pull the message history directly from Telegram — bypassing every local encryption problem at once.

We tested keys for all five data centers. Every single one returned AuthKeyNotFound. Telegram's servers had invalidated the entire session — most likely because the client had used Telegram Desktop again after providing us the files, silently triggering a session refresh that retired the older keys.

Step 8: Crash dump analysis

A final long shot. Telegram Desktop crash dumps can occasionally retain fragments of memory containing recently-displayed data. The bundle contained several such files. We scanned all of them. Nothing relevant.

Why this case ended the way it did

The key message was deleted earlier that week. The device extraction happened approximately two days later. During those days, the iPhone remained in active daily use — Telegram continued operating in the background, syncing messages, updating read states, and writing new data into the same database that held the freed pages. By the time we received the device, those pages had been overwritten by ordinary app activity.

On the Mac side, the credentials that could have let us pull the message history from Telegram's servers had been invalidated, almost certainly by a single intervening session refresh. And the locally-stored data was encrypted with a key dependent on a maps file missing two of its three required streams.

Three independent factors lined up to produce a permanent loss.

The lesson

If you ever find yourself in this situation — a private key, password, or other irreplaceable piece of information has just been deleted from a chat application — the single most important thing you can do is stop using the device immediately. Every minute of continued use is another minute the database engine may decide to reuse the freed pages holding your data. Don't open the app to "check." Don't send anything. Power the device down if you can, or put it in airplane mode and leave it untouched.

Then contact a forensic specialist as quickly as possible. The window for recovery is real, and it is short. We have recovered deleted data successfully in many cases — but the cases that succeed are almost always the ones where the device reaches us within hours, not days.

For high-value private keys specifically: never let them live only inside a chat. Write them on paper, store them in a hardware wallet, or save them in an encrypted password manager the moment they appear. A few minutes of inconvenience in the moment is the difference between recoverable and gone forever.

Case details have been generalized to protect client confidentiality. Published with client consent.

Lost critical data to a deleted chat message? Time matters. Open a case immediately — the sooner the device reaches us, the better the odds. More on the methodology on our Mobile Forensics page.