This is one of the harder cases we work. We are writing it up despite the fact that it failed, because the lessons in it matter for anyone who might end up in the same position.

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, displayed briefly in the chat window, then deleted shortly afterward. It had never been written down, backed up, or stored anywhere else. Could we get it back off the device?

Here is what we tried, what we found, and the timing that decided how it ended.

The starting point

The client provided a recent-model iPhone that had received 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 inside the image.

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

Step 1: Querying the active records

First we needed to confirm 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. So the conversation was live and the replacement flow had definitely been triggered.

The key message itself was not there. It had been deleted before 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 pulled out of WAL contents before they are checkpointed and 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 on the deletion event.

That timestamp-perfect WAL had already been checkpointed. Its contents had been merged into the main database, and any remnant of the deleted message had been incorporated and overwritten along the way. None of the six held the key.

Step 3: Freelist page analysis

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

We wrote a custom Python tool to scan every freelist page in the database, looking 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. The freed pages that had once held the key had already 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, and every 64-character hexadecimal string anywhere in the file. That surfaced roughly a dozen candidate keys.

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

Step 5: Secondary databases

The iPhone filesystem held several additional Telegram databases, including the ones used by the notification extension and the 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.

Step 6: The Mac side

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 with AES-IGE encryption, using a key derived from a key_datas file and a corresponding maps file. The standard decryption pathway needs the maps file to contain three encrypted streams.

This one contained a single stream. We tried three decryption tools in sequence:

Step 7: The live server attempt

Those DC authentication keys offered one more avenue. If they were still valid on Telegram's servers, we could connect through the Telethon library and pull the message history directly from Telegram, sidestepping every local encryption problem at once.

We tested keys for all five data centers. Every one returned AuthKeyNotFound. Telegram's servers had invalidated the entire session, most likely because the client had opened Telegram Desktop again after handing us the files, which silently triggers a session refresh that retires the older keys.

Step 8: Crash dump analysis

A final long shot. Telegram Desktop crash dumps can occasionally retain fragments of memory holding recently-displayed data. The bundle contained several. We scanned all of them and found nothing relevant.

Why this case ended the way it did

The key message was deleted earlier that week. The device extraction happened roughly two days later. Across those two days the iPhone stayed in active daily use, with Telegram running in the background, syncing messages, updating read states and writing new data into the same database that held the freed pages. By the time the phone reached us, those pages had been claimed by ordinary app activity.

On the Mac side, the credentials that could have pulled the history from Telegram's servers had been invalidated, almost certainly by one intervening session refresh. And the locally-stored data was encrypted against a maps file missing two of its three required streams.

Three independent factors lined up to make the loss permanent.

What to do if this happens to you

If 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. Do not open the app to check. Do not send anything. Power the device down if you can, or put it in airplane mode and leave it alone.

Then contact a forensic specialist as fast as you can. The recovery window is real and it is short. We have recovered deleted data successfully in plenty of cases, and the ones that succeed are almost always the ones where the device reaches us within hours rather than days.

For high-value private keys specifically: never let one live only inside a chat. Write it on paper, put it in a hardware wallet, or save it to an encrypted password manager the moment it appears on screen. A couple of minutes of inconvenience is the whole difference between recoverable and gone.

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.