Signal Backups – A Q&A Session with Magnet Artifacts

In May 2019, I made a personal blog post about obtaining logical dumps of Signal data using the built-in backup function. This was a process I found myself doing more and more regularly given a logical device acquisition did not include it.

Since then, physical dumps of mainstream Android phones have become more common, but with the release of Android R (11) there has been a bit of a resurgence of folks contacting me saying they had tried the signal-back script without success. Indeed, Signal changed quite a bit since my post and I later confirmed that it has completely broken signal-back, which isn’t surprising because it hasn’t received updated since December 2018. One of the other issues with signal-back is that you ended up with data in a CSV format, which made it difficult to present in a forensics report in a way that makes sense.

Since coming to Magnet Forensics, I’ve advocated internally for updating our support for parsing these backups and had numerous customers reach out to let me know how valuable it would be for their investigations. That’s why I’m happy to say that beginning with version 4.7, Magnet AXIOM can now be used to process these backups. Once decrypted, the power of AXIOM’s Conversation view and recently overhauled reporting can be leveraged in full to put this data in a format that is easy to interpret, even for non-examiners.

I had the opportunity to sit down with software engineer Chris McKnight of our Mobile Artifacts team, who had done some of the foundational work involved with our updated support for this artifact. Our conversation follows in Q&A-style format.

Mike Williamson: Hey Chris! So one curious point for me was learning that we actually supported these in the distant past but then somewhere along the line, that support broke. Were you able to establish the reason why?

Chris McKnight: The main change that occurred was that the backup passphrase, which was stored in the shared_preferences.xml file under “pref_backup_passphrase”, started to be encrypted. The preference name also got changed to “pref_encrypted_backup_passphrase”. Unfortunately, because it now uses the Key Store, it became a lot more difficult to use on a forensic image. (needing access to a live device and the knowledge/ability to extract keys from the Android KeyStore).

MW: I think it may be a tougher sell to our product managers because it’s actually pretty unlikely you will encounter a decryptable backup in the wild (on an exhibit). Beyond the fact that many users probably don’t realize this feature exists and that they have to manually run it, anything else that would make it so rare to find them?

CM: Yeah, Signal Backup passphrases are only shown to the requestor once, as six blocks of five-digit numbers, and being 10^30 digits long, it’s very resistant to brute-forcing.

MW: That’s right, so they would have to store the backup key in a text file or something right alongside it – though stranger things have definitely happened!

CM: That’s a plausible edge case, though it’s not easy for a user to save the passphrase to a file since it is displayed on-screen only. Maybe in the camera roll if they took a screenshot?

MW: Definitely worth checking that camera roll! Notwithstanding the rarity, Signal Backups do remain a solid option for examiners attempting to acquire Signal data from an Android device when a physical-level acquisition isn’t possible. It’s far less tedious (and less prone to human error) than acquiring data by taking physical lab photos of the device screen for example. So Chris, when did adding backup parsing come into scope?

CM: This is actually something we’ve had on the backburner for some time. There were some architectural challenges involved and due to the unusual workflow, it was delayed. But after the 4.6 release we decided to push for it, and working together with Ann Joseph and Morgan McLellan, along with help from Terry Chabot and Dominic Dela Cruz we managed to complete the work in time for the 4.7 release.

MW: Fantastic work to the team! This could have the potential to save many tedious hours for examiners. You mentioned the architectural challenges – from a behind-the-scenes perspective, what makes handling these backups tricky? I know that the backups are created with several layers of complexity including encryption and everyone’s favourite, protobuf serialization. 

CM: There are several unusual quirks to handling them. For instance, Signal backups use encryption first and then serialize with protobuf into “frames”. (Most apps serialize first then encrypt). 

MW: Neat, and what do these frames represent?

CM: Frames actually represent a range of things including parameterized SQL statements, including both CREATE TABLE and INSERT statements. These can be run consecutively to rebuild the Signal database. In addition to SQL statements, there are frames used to recreate attachments, user/group avatars, stickers, and even the application settings and version. In short, everything required to fully recreate the file and directory structure of the original application.

MW: So you essentially replay all the SQL statements in order, and end up with an exact recreation of the Signal database?

CM: Yep, then you need to deal with the remaining frames. In Signal, attachments are named randomly when saved to the filesystem. When it restores the attachments from the backup, it generates new random names, and the database is updated with these new names.

MW: Sounds like it could be a challenge, forensically speaking. How does AXIOM handle sources for those attachments?

CM: We report the source as being the backup file itself, which is technically correct. But we included a column called “file path” that contains the original file path as it would appear on the device, e.g. “/data/user/0/org.thoughtcrime.securesms/app_parts/part5873231697459880012.mms”. Furthermore, we found that for received MMS messages, the database often retained the name of the file before it was given the random name, e.g. “football.jpg” so we report that too.

MW: So, how can AXIOM users leverage this new feature Chris?

CM: In order to use the new Signal backup parsing feature, you will need to have either an image containing the backup file or the backup file as a standalone file, along with the passphrase provided by Signal at the time the backup was created. A tip that was discovered by my colleague in the artifacts team, Morgan McLellan, is the passphrase remains the same even for multiple backups, as long as the output location remains the same and the user doesn’t turn off/on the backups feature. When adding the image/file containing the backup, select the Signal application from the artifact selection screen, and make sure to open the options dialog by clicking the “options” link displayed underneath the Signal icon. In the resulting popup, you can enter the backup passphrase, with or without the spaces. That’s it!

After processing you should see the Signal data in the following three artifacts: Signal Messages – Android, Signal Group Members, and Signal Local User. We are planning to expand and improve on these artifacts in future releases.

MW: Thanks so much for your time Chris, I’ll let you get back to those artifacts!

The next time you find yourself with a large amount of Signal data on an Android device with no obvious way to acquire it, I highly recommend giving this approach a try! Of course one cannot understate the importance of making ample notes describing not just the doing but the reasoning, including alternatives considered.

If you’re not already using AXIOM, you can request a free trial today.

Feel free to reach out to me at mike.williamson@magnetforensics.com or @forensicmike1 on Twitter if you have any questions or feedback.