"Messages destruction" at Telegram

After the analysis, here at our previous post, about the way messages are stored within the databases of Telegram, we want to test whether the deletion of messages is done correctly. 

Remember that looking for the self-erased messages in the fields of the different tables in the database, its trail had been replaced by "None", then it would be necessary to determine whether such messages are still persistent, without actually being indexed within the database file "tgdata.db" data. 


To do this, we activate a conversation with self-destruction, and wait until the text has been destroyed.

We proceed to launch the command "strings" that will extract all text strings that are contained within the file "tgdata.db" and then we check that the message is within the extracted text (use "incide" and "auto destru" as key words  to search).

As can be seen, the messages appear in clear text into the file, but they are not in the database, it's just that the fields are shown as empty:

In this way, deleted messages could be recovered if a search is performed in the unallocated space, before they are overwritten by continuing to grow the database.

Our friend Luis Delgado has confirmed us that Android systems behave similarly. When you backup with adb, even without being "rooted", some files of database are created where messages are stored. Messages marked for self-destruction, are removed from the database, but not deleted from the file where are contained. Delgado also has a Python script that allows you to automate the extraction of these strings.

We decide to check whether in other versions of Telegram there are same problems arisen, so we test an UNOFFICIAL version for OS X operating systems so-called "Messenger for Telegram". Remember that the only Telegram official versions are iPhone and Android ones, the rest are based on the published open source. 

In this case, two databases are created: "telegram_store11.db" and "yap_store.db". The messages are stored at first one and at the second one, only identifiers of the encrypted conversations. 


As in the previous case, when searching for text strings in the database, it is possible to extract the messages.

Performing these sort of tests, we have seen that the behavior of the client computer does not respond to self-destruct messages.

By accessing the database to search for messages, we observe that them have been encoded in hexadecimal code:
  

 bb608d9f 01000080 f1f4a000 02000000 2260c93b 379779bc 379779bc 9c490f53 01000000 16637265 61746564 20656e63 72797074 65642063 68617400  
 ba6aeb22 02000080 a75d2001 02000000 2260c93b b5757299 b5757299 c5701053 14746573 74746573 74746573 74746573 74746573 74000000 2063ed3d  
 ba6aeb22 03000080 f1f4a000 02000000 2260c93b 379779bc b5757299 25711053 06416868 68686800 2063ed3d  
 ba6aeb22 04000080 f1f4a000 02000000 2260c93b 379779bc b5757299 9d751053 04507574 61000000 2063ed3d  
 ba6aeb22 05000080 a75d2001 02000000 2260c93b b5757299 b5757299 c6751053 18496e63 69646549 6e636964 65496e63 69646549 6e636964 65000000 2063ed3d  
 ba6aeb22 06000080 f1f4a000 02000000 2260c93b 379779bc b5757299 da751053 06526570 75746100 2063ed3d  
 ba6aeb22 07000080 f1f4a000 02000000 2260c93b 379779bc b5757299 05761053 04507574 61000000 2063ed3d  
 bb608d9f 08000080 684bdc00 02000000 e9ea184d 379779bc 379779bc c0761053 01000000 16637265 61746564 20656e63 72797074 65642063 68617400  
 ba6aeb22 09000080 a75d2001 02000000 e9ea184d b5757299 b5757299 d5761053 18507275 65626170 72756562 61707275 65626170 72756562 61000000 2063ed3d  
 ba6aeb22 0a000080 684bdc00 02000000 e9ea184d 379779bc b5757299 64771053 10546573 74657374 65737465 73746573 74000000 2063ed3d  
 ba6aeb22 0b000080 684bdc00 02000000 e9ea184d 379779bc b5757299 79771053 16546573 74657374 65737465 73746573 74657374 65737400 2063ed3d  
 ba6aeb22 01000000 684bdc00 6dbcb19d a75d2001 379779bc b5757299 7b220e53 1c486f6c 61212042 69656e76 656e6964 6f206120 74656c65 6772616d 21000000 2063ed3d  
 ba6aeb22 02000000 a75d2001 6dbcb19d 684bdc00 b5757299 b5757299 3c240e53 1e486f6c 61204162 656c2c20 636f6d6f 20766120 706f7220 696e6369 64653f00 2063ed3d  
 ba6aeb22 03000000 be43a300 6dbcb19d a75d2001 379779bc b5757299 ba240e53 054f6f6f 6f680000 2063ed3d  
 ba6aeb22 04000000 a75d2001 6dbcb19d be43a300 b5757299 b5757299 d9240e53 0a717565 20706173 c3b33f00 2063ed3d  
 ba6aeb22 05000000 a75d2001 6dbcb19d be43a300 b5757299 b5757299 e6240e53 31657374 6f792068 61636965 6e646f20 70727565 62617320 636f6e20 656c2063 6c69656e 74652070 61726120 4d616320 3a500000 2063ed3d  
 ba6aeb22 06000000 be43a300 6dbcb19d 00000000 379779bc b5757299 f4240e53 0647656e 69616c00 2063ed3d  
 ba6aeb22 07000000 11439100 6dbcb19d a75d2001 379779bc b5757299 0b280e53 1757656c 636f6d65 206d722e 74656163 68657220 f09f9881 2063ed3d  
 ba6aeb22 08000000 76f79a00 6dbcb19d a75d2001 379779bc b5757299 c64a0e53 04f09f91 8b000000 2063ed3d  
 ba6aeb22 09000000 f1f4a000 6dbcb19d a75d2001 379779bc b5757299 dc3c0f53 04486f6c 61000000 2063ed3d  

When analyzing the data we realize that there are columns that are very similar or the same. For example, the first column has two values​​:

• bb608d9f: Belongs to system messages
• ba6aeb22: Belongs to user messages

La tercera columna parece indicar el usuario con el que se intercambia los mensajes, mientras que a partir de la octava columna se trata del mensaje codificado, hasta la última columna, que indica el final de éste.

Los dos primeros bits de la octava columna indican el tamaño del mensaje, y a continuación se puede descodificar cómodamente. 

The second column matches with the message identifier indicating whether it is encrypted (which ends in 80) or not. 

The third column seems to suggest the user whom messages are exchanged, while from the eighth column there is the coded message, to the last column, which indicates the end of it. 


The first two bits from the eighth column indicate the size of the message, and then we can decode it comfortably.

For example, for the case of the message 

 ba6aeb22 09000000 f1f4a000 6dbcb19d a75d2001 379779bc b5757299 dc3c0f53 04486f6c 61000000 2063ed3d  

• 04: Size of 04 bytes. 
• 486f6c 61 = Hi 
• 000000 = The remaining space is able to be filled

So replacing the bytes correctly it would be shown as follows:

 ba6aeb22 09000000 f1f4a000 6dbcb19d a75d2001 379779bc b5757299 dc3c0f53 04Hol a000000 2063ed3d  

As we have seen in this article, the message deletion is not done safely, as though they are removed from the database, no compaction is done to remove the unallocated space nor an overwrite of these is performed. In the computer application, the situation does not improve, the messages are encoded when stored, but they are still unencrypted, even allowing its self-destruction. 


Therefore, we have doubts. Do these problems are only with the programs analyzed? Or come from a failure in the implementation of the measures?

Abel Gómez is Senior Pentester in INCIDE

You can follow his posts at zprian.blogspot.com.es