Examining Session Desktop Attachments

Session

Session is an open-source, end-to-end encrypted instant messaging service which aims to offer anonymity while avoiding the recording of metadata. Whereas many other messaging services rely on telephone numbers or email addresses to identify users, each Session user is assigned a unique, 66-character Session ID. Session messages are transmitted through a decentralised network (facilitated by a blockchain and cryptocurrency) and are encrypted several times during transport (onion routing).

‍

Session and Signal

Session was created in 2019 as a fork of the codebase of Signal, another encrypted messaging service. Although it has deviated from Signal substantially since then, many components of its client software remain the same, resulting in similar forensic artefacts being created on devices, as Binary Hick observed in an article on the Session app for Android. For instance, both applications for Android store messages locally in an SQLite database (encrypted using SQLCipher) named 'signal.db'.

The Session Desktop application (for Linux, macOS and Windows) also has many similarities with its Signal equivalent, including the location of locally stored messages and attachments. A notable difference however, is that it is not just the database containing messages that is encrypted, attachments are encrypted too. Since the decryption of SQLCipher databases and the forensic examination of Signal apps for various platforms have been addressed by others already, we shall concentrate on decoding attachments stored by Session Desktop.

‍

Source Code

The source code for Session Desktop is hosted on GitHub, the popular online software development platform, where it is evident that the codebase was forked from the Signal-Desktop project once upon a time. In March 2021, Session Desktop incorporated code that would encrypt attachments which are stored locally.

TypeScript code relating to the encryption of attachments can be found in ts/util/local_attachments_encrypter.ts and ts/node/encrypt_attachment_buffer.ts. A property named 'local_attachment_encrypted_key' is set and read in local_attachments_encrypter.ts.

‍

This property and its value can be found in the 'items' table in 'db.sqlite'. The database shown in the following screenshot was decrypted using SQLCipher before being opened in RabbitHole.

‍

[The eagle-eyed amongst you might have spotted that a new version of RabbitHole is on the loose!]

That value is used as the 'encryptingKey' parameter in the encryption and decryption functions which are defined in encrypt_attachment_buffer.ts. There we can see that XChaCha20-Poly1305 algorithm is being used for encryption. Encrypted files are stored in a directory named 'attachments.noindex', as defined in  ts/shared/attachments/shared_attachments.ts.

‍

‍

XChaCha20-Poly1305

XChaCha20-Poly1305 is a cryptographic algorithm which implements Authenticated Encryption with Additional Data (AEAD). The XChaCha20 part is a variant of the ChaCha20 algorithm with an extended (192-bit) nonce (a nonce being a number that is used only once in cryptography). It is a symmetric (256-bit key) encryption algorithm which offers some speed and security advantages over AES, especially on slower devices. The Poly1305 part provides a Message Authentication Code (MAC) or authentication tag.

A unique nonce as well as an authentication tag are stored with each encrypted attachment file stored by Session Desktop.

Decryption

Support for XChaCha20-Poly1305 is available in cryptographic libraries for various programming languages. For Python programmers, the PyNaCl library is one available option. The following code snippet illustrates how to decrypt a single attachment using PyNaCl and a known key.

‍

If you would like more information about analysing Session or other messaging applications as part of your investigation, do get in touch.

‍