Telegram on Android: cache4.db and Media

What it is

Telegram is a cloud messenger: ordinary chats, groups and channels live on Telegram's servers and every client keeps a local cache. On Android the official app (org.telegram.messenger, and the Play Store build org.telegram.messenger.web or regional variants) stores that cache in a SQLite database, cache4.db. Most message content is stored as serialized objects in Telegram's own TL (Type Language) binary format inside BLOB columns, so plain SQL gives you the metadata and a parser is needed for the full message.

Secret chats are the exception to the cloud model: they are end-to-end encrypted, bound to one device, and exist only in local storage on both ends. For them the handset is the only source.

Where it lives

Third-party clients built on the same code (Telegram X, forks) use other package names and sometimes other schemas.

What it proves

• The dialogs (chats, groups, channels, bots) the account had on this device, with their last activity date and unread counters.
• Messages the app had loaded: sender, direction (out), date, read state, reply and forward information, and media references.
• Users and chats known to the account, with names, usernames and phone numbers when shared.
• Secret chats: their participants, creation and the messages still within their timers.
• Which Telegram account (user ID, phone number) was logged in.

It does not prove the complete history of a cloud chat: the cache only holds what the app downloaded, and the user can clear it without affecting the server.

Key fields

Older app versions used messages instead of messages_v2 and media_v2/media_v3. Dialog IDs follow Telegram's conventions: positive for users, negative for groups and channels, and a special range for secret chats. Check the schema on every case.

Timestamps

date columns are Unix seconds in UTC, not milliseconds.

SELECT m.mid, m.uid AS dialog, m.out,
       datetime(m.date, 'unixepoch') AS sent_utc,
       m.read_state, length(m.data) AS blob_bytes
FROM messages_v2 m
ORDER BY m.date DESC
LIMIT 50;

The text sits inside data. Short messages are often readable as UTF-8 in a hex view, which is enough for triage, but a TL-aware parser is needed to extract entities, edits, forwards and media reliably.

Retention

Cloud chats: whatever the app cached, limited by Settings > Data and Storage > Storage Usage (keep media for a set time, maximum cache size). Deleting a message for everyone removes it from the server and, at the next sync, from the cache. Secret chats and self-destructing media are removed when their timer expires. Deleted rows can survive in free pages and the WAL until the next vacuum.

Collection

• Full file system extraction (AFU) for cache4.db, the account* folders, preferences and cache.
• Logical: pull the media folder from shared storage; it proves files were received but not from whom.
• Data export: Telegram Desktop can export an account's cloud history as JSON or HTML with the user's cooperation, which also covers chats not cached on the phone. Secret chats are never included.

Parsing

Commercial suites (UFED, AXIOM, Oxygen, Belkasoft, XRY) decode the TL blobs and rebuild conversations. Without them, use sqlite3 for metadata and a TL deserializer from the open Telegram client source for the data column. Validate any tool against a test phone running the same app version: Telegram changes its TL layer frequently.

Investigator tips

• Map uid values to names through users and chats before reading messages; negative IDs are groups or channels.
• A large gap between a dialog's last_mid and the newest cached message suggests the cache was cleared.
• Telegram notifications may survive in notification history after a secret chat self-destructs.
• The Telegram account also appears in the accounts databases and in usagestats foreground events.
• Compare with WhatsApp and Signal in the messaging apps guide.