Most of the times we care about and focus on external threats, looking for actors that may attack us via phishing emails, vulnerable web services, misconfigured network devices, etc. 
However, sometimes the threat may come from the inside. In fact, it is not so uncommon to have disloyal/disgruntled employees exfiltrating information from the company (e.g. Intellectual Property to competitors, confidential information to the press, etc.). In such situations, a full forensics analysis of the employee’s devices (workstation, mobile, etc.) is required to understand what happened and get comprehensive timeline of the events. 
As one of the areas I like to research is mobile forensics, particularly related to iOS devices, I thought I would briefly write about some findings that should be of interest when analyzing an iOS device, in particular a quick comparison between three popular Instant Messaging applications. The tests for this diary have been made on an iPhone 4S running iOS 9.0.2.

iOS Forensics General info
Starting from iOS8, application data have been separated from their bundles and current directory structure is the following:

• /private/var/mobile/Containers/Bundle/Application//, where the application bundle is stored.
• /private/var/mobile/Containers/Data/Application/, where most of the application data is stored.
• /private/var/mobile/Containers/Shared/AppGroup//, where applications can store data with the aim to be shared with other apps or extensions.

Another interesting background information we need to remember is the fade-out effect on iOS. Every time a user presses the Home button or receives a call while using an application, iOS will make a “snapshots” of the current screen in order to be able to do the fade-out effect transition between the two screens. Such snapshots are stored in the following locations:

• /private/var/mobile/Library/Caches/Snapshots/ for the pre-installed Apple applications;
• /private/var/mobile/Containers/Data/Applications//Library/Caches/Snapshots/, for each third-party application

If you receive a call while writing a super secret encrypted message, you can easily imagine what the content of the snapshot will be ;).

WhatsApp
​This is the messaging application you will surely encounter most of the times while investigating a mobile device. Whatsapp is one of those applications that stores the data in the Shared directory mentioned before, instead of the application data directory, as we can see by the following output:
iLab1:/private/var/mobile/Containers/Shared/AppGroup root# tree 332A098D-368C-4378-A503-91BF33284D4B
|-- Axolotl.sqlite
|-- ChatSearch.sqlite
|-- ChatStorage.sqlite
|-- Contacts.sqlite
…

The main database is ChatStorage.sqlite, where it is saved the actual content of the messages exchanged. Among the tables of interest, one of the most important is ZWAMESSAGE, which contains, among others, the messages exchanged, their timestamp, the name of the user involved in the chat. Other tables worth to be analyzed are ZWACHATSESSION, ZWAGROUPMEMBER, ZWAGROUPINFO and ZWAMEDIAITEM, which stores references to the multimedia files exchanged, indication of the users involved, timestamps, and the path where the file has been stored.
As also recently mentioned by J. Zdziarski on his blog [1], an interesting “feature” of Whatsapp is that deleted chats are not actually deleted form the database. This because when a SQLite record is being deleted, for performance reasons it is not actually wiped/purged from the database immediately, but marked as free and eventually overwritten later on when that storage space is needed. Therefore by simply using a tool like SQLite-parser [2][3], you can quickly carve out deleted record from your Whatsapp chat database.
However, as matter of facts, you will find this “feature” in most applications using SQLite storage databases, since most of them do not handle properly this aspect.

Last but not least, the “Snapshot feature”: Whatsapp does store screen snapshots, in clear.

Telegram
Like Whatsapp, also Telegram stores many of its data in the Shared directory.
There, under the Documents folder, you will find the tgdata.db database, which contains all information about contacts, conversations, exchanged files, etc.
Here some of the tables of interest are messages_v29, which contains the list of all messages exchanged, convesations_v29, which contains the list of active conversations as showed in the “Chats” screen of the app, and encrypted_cids_v29, which contains the conversation ids of the secret chats.

Other than the (expected) behavior already found in Whatsapp, which means that deleted records are not immediately purged out of the database and therefore can be recovered, Telegram messages from secret chats are stored in clear in the messages_v29 table, like all the other messages.
The thing you will not find in Telegram is the screen snapshot, as apparently they properly clear the screen when the fade-out event happens.

Signal
For sure less popular than the previous two, it is the one you may find in devices of users who are security/privacy aware, or that want indeed to hide something and are informed of the technical capabilities they need.
From a forensics point of view, there is not much to say here since Signal delivers what it promises: its database /Document/Signal.sqlite, containing all its data, is fully encrypted. However, oddly enough, two things that are not encrypted:

• The attachments exchanged are stored in clear in the /Document/Attachments/ folder.
• Screen Snapshots can be retrieved as well. Signal has an option “Enable Screen Security” that would prevent this, but for some reason is not set by default.

As said, not too many information available but you may still find some useful traces available.

Conclusions
This was a brief overview of what you can find in case of investigating messaging applications in iOS environment. Nothing rocket science for sure, but still important things to remember during the analysis that are often overlooked.

Happy Hunting

Pasquale

References:
[1] – “WhatsApp Forensic Artifacts: Chats Aren’t Being Deleted”, http://www.zdziarski.com/blog/?p=6143 
[2] – “Python Parser to Recover Deleted SQLite Database Data”, http://az4n6.blogspot.ch/2013/11/python-parser-to-recover-deleted-sqlite.html 
[3] – “SQLite-parser”, https://github.com/mdegrazia/SQLite-Deleted-Records-Parser