Sailfish OS update from Jolla
The last two weeks have seen some important Sailfish OS announcements. First and foremost, the release of Sailfish OS 4.1.0 Kvarken went ahead to Early Access as promised, with 64-bit support for the Xperia 10 II as part of the rollout. So far things are looking good and so with any luck and a good headwind the general release, including the paid-for additions for the Xperia 10 II, won’t be too far away. If you’re an early adopter we hope you’re enjoying the new features as much as we are, and that you’re keeping an eye on the official Jolla Blog for the official release announcement.
Also released were the new Mozilla Location Service packages, which you’ll find in the Jolla Store. As you may be aware, support for the Mozilla Location Service was dropped when Mozilla changed their licensing terms back in March of last year. Without the initial low resolution location provided by MLS, the time needed to get an accurate GPS location fix increased substantially, especially after a long gap (either temporally or geographically) between activating GPS. In the February newsletter we covered MLS Manager, a community app by Samual Kron for downloading the offline MLS databases. It’s now possible to download the same data from the Jolla Store from the official Jolla Positioning data packages. This makes the process straightforward and means you’ll get updated data automatically in the future. There are six new apps in total depending on the region you want supported. Based on the United Nations geoschemes, they’re split into packages covering Australia, India, Eastern Europe, Southern Europe, Western Europe and Northern Europe.
On top of this there was also the announcement that the open source Sailfish OS repositories will be migrated from our current self-hosted Gitlab installation to Github. This generated a lot of interest and was discussed at some length both on the forum and in the last community meeting. There are clearly pros and cons to both approaches, but as veskuh points out, one of the main motivating factors was the need to make it easier for anyone to submit contributions to the codebase, while at the same time making maintenance easier for Jolla.
This new, simpler, setup should be a benefit for both Jolla and the Sailfish community. As Github is one of the most popular open source hosting service, contributors typically have accounts and are familiar with the workflows leading to a lower barrier to contribute to the software.
We hope you’ll find that the migration goes smoothly and that you’ll be able to ease yourself into the Github way of working (or find adequate alternatives to Gitlab features) without too much trouble.
While we wait for announcements about 4.1.0, we thought it would be interesting to cover something entirely different, and something that doesn’t get so much coverage within the Sailfish OS community, even though it’s an important topic: digital forensics .
Digital Forensics and Sailfish OS
With this in mind, it was interesting to read a recent paper written by Krassimir Tzvetanov and Dr Umit Karabiyik of Purdue University in the US. Their paper “A First Look at Forensic Analysis of SailfishOS” * published in the Journal of Computers and Security gives details of their results applying various commercial and open source digital forensics analysis tools to Sailfish OS.
This isn’t the first time Sailfish OS has been subjected to analysis like this. Way back in 2014 three researches from NCC group — Chris Weeden, Vitaly McLain and Drew Suarez — attempted various pentest-style attacks to see how much data they could extract from a Jolla 1. They even tried fuzzing the Other Half I2C bus to find exploits, but without success. Some of the more successful methods they used were quickly fixed by the update to Sailfish OS 18.104.22.168, and they concluded that they would “work with Jolla on anything we find — great company to work with so far!”. One of the areas of weakness they identified was the unlocked bootloader.
We’ll return to that later, but it’s fair to say that a lot has changed in Sailfish OS since 2015, and their results aren’t really relevant for newer devices.
Slightly more recently in 2016 and using Sailfish OS 22.214.171.124, a team of forensic experts from Italy made up of Davide Gabrini, Andrea Ghirardini, Mattia Epifani and Francesco Acchiappati, applied Cellebrite UFED 4PC and Magnet Acquire to the phone. These are both industry standard tools used by police forces around the world to image the contents of a phone for later analysis.
The availability of industry standard tools is of critical important for forensic investigations, because the purpose is not just to extract the data, but to extract it forensically . That means there must be a chain of evidence, certainty that no data on the device has been tampered with, and credibility in a court of law. Tools that are well-known and industry-standard provide this kind of assurance. Anything that diverges from standard practice runs the risk undermining an entire case if it can be shown, for example, that there’s even a possibility that data may have been changed as a result of the process.
As the team explains
attempts to acquire the device using well known forensics products like UFED4PC and Magnet Acquire failed, as these tools couldn’t even detect the device at all.
Cellebrite UFED boasts of supporting “more than 31K device profiles” so it’s a little surprising it won’t recognise a Sailfish OS device.
The team eventually took the entire phone apart and were able to extract an image using
dd from recovery mode (probably taking the phone apart didn’t actually help with this!). Having done so they were then able to apply a suite of digital forensic tools to extract more detailed information.
A lot has changed since then, so are their results still relevant for newer devices?
This brings us to the paper from Krassimir Tzvetanov and Dr Umit Karabiyik. The authors provide an impressively comprehensive summary of Sailfish OS, its history and background material. Because it’s a scientific publication they also have to be more careful with their methodology: they use the same Xperia XA2 running 126.96.36.199 Nuuksio for all their tests, along with a Windows machine running the forensic software in a VM so that they can start with an identical snapshot for each of the tests. From what I can tell, they reflash the phone and follow a set recipe to get it to an identical state each time as well.
Their results can be split neatly into two: data acquisition and data analysis . For most readers on this forum the acquisition step is likely to be of most interest, although the analysis part takes up the majority of the paper.
For acquisition they tried four different approaches: 1) using Cellebrite UFED 4PC; 2) using Magnet Axiom Process; 3) manually using TWRP to get a shell and
dd to image; and 4) manually using a developer mode shell on the device and
As in the earlier attempts discussed above, they found that the industry standard tools failed, not just to extract images, but to identify the device at all:
In both cases, the software was unable to recognize the phone. This was not a surprise as both programs use the ADB interface, which is not supported by SailfishOS.
I admit to being more surprised than the authors are. Neither UFED or Axiom are restricted to only supporting Android devices, both aim to offer a plug-and-play acquisition process. There are a growing number of Linux phones in use and an acquisition process for one of them is likely to work for others too. Axiom did introduce support for Linux images in version 5.0, although apparently not Linux acquisition (Tzvetanov and Karabiyik tested with Axiom 3.11).
Nevertheless they were more successful using the two
dd-based approaches. Both the TWRP and developer mode approaches result in the ability to extract the images using
dd, although the developer shell approach assumes you can log in to the device via
ssh or through the terminal app. For a locked phone, without the user’s permission, and in the absence of some other exploitable vulnerability, this isn’t a viable approach. The TWRP approach on the other hand only requires that the bootloader is unlocked, which will be the case on by far the majority of (if not all) Sailfish X devices since it’s a requirement of flashing it.
The TWRP approach is straightforward, following the instructions on the website. TWRP is available for the X, XA2 and 10, but not yet the 10 II (although no doubt it’s only a matter of time). After setting the device in fastboot mode (blue light showing) the TWRP image can be temporarily run on the phone to provide an adb shell for running
dd (don’t try this at home unless you know what you’re doing).
host$ fastboot boot twrp.img sfos$ adb shell sfos$ dd if = /dev/ <block device> | nc -l -p <device port>
This gives them an image of the phone, much like an image of any other Linux device. As they explain, Axiom and Autopsy (an open source forensic tool widely used by police forces) was able to then read the image and extract individual files. Standard files (images, SQLite databases, raw emails) could be interpreted and keyword search applied. However neither tool could provide any more of the detailed analysis (e.g. automatically extracting contact info) that might be supported for other platforms.
At this point it’s worth highlighting that this is already enough to go a long way. The majority of the relevant middleware pieces that handle personal information on your device (e.g. contacts, calendar, accounts, email, browser) are open source, with the only exception perhaps being Exchange support. Information about the location and format of the interesting files is therefore openly available in the source code in the various middleware repositories. However, for law enforcement more used to other operating systems, this may not be immediately apparent. Large increases in use of digital evidence means that police digital forensic teams are often overworked and under-resourced. Depending on the nature or circumstance of the crime being investigated, using automated tools for digital evidence extraction may be the only viable option. As the authors explain:
a steep learning curve on the acquisition, analysis, and examination of the target operating system would be troublesome and definitely time consuming. The availability of forensically sound investigative guidelines on such operating systems is highly appreciated by the practitioners, researchers, as well as the tool developers.
The point here is not that Sailfish OS is more immune to analysis as a result, but that simplifying the analysis process is just as, if not more important, than acquisition. The authors therefore go into quite some detail about the partition structure on the device, the various artefacts they’re able to extract and where they’re located; details that may already be quite familiar to many Sailfish OS users.
The approach they take to finding the important files is to take an image of the phone, perform some actions (e.g. sending an SMS or adding a contact), take another image and then identify any differences based on file MD5 checksums or timestamp changes. Using this approach they’re able to identify various interesting files, summarised in the table below.
|Data type||Data location|
|Device||~/.system/var/lib/connman/wifi_ ∗ /stats.home|
Recent Sailfish OS updates have resulted in many of these files moving location, but that aside it’s a thorough collection.
The authors conclude:
When such an operating system is found in the crime scene and needed to be analyzed, our work would be extremely helpful for the investigators.
They also go on to describe potential future work, two items of which are particularly worthy of mention. First they suggest that it would be interesting to try to target the Android App Support for extracting forensic data.
SailfishOS is designed to run Android applications. In newer versions using compatibility layer 8.1, which is used in Xperia XA2, runs Dex bytecode using ART, inside a container. We are also interested in investigating the forensic artifacts which result in such execution.
They also point out that running acquisition tools on the ADB interface exposed by TWRP might allow the phone to be imaged using the commercial products that weren’t able to pick anything up when accessing Sailfish OS directly. This isn’t something they tried however.
The results of the paper were presented at the 73rd Annual Scientific Meeting of the American Academy of Forensic Sciences in February of this year. Not so long ago.
Still a lot has changed since then.
In particular, Sailfish OS 3.4 Pallas-Yllästunturi introduced home encryption by default, and as part of this development user-modifiable files were moved into the home directory. This will prevent most, if not all, of the data the authors were able to extract from being accessed on more recent versions of the operating system. The unlocked bootloader — the main route through which previously documented successful forensic extractions have passed — can still be exploited, but the data extracted will no longer be readable without the user’s unlock code.
This may not be the end of the story though as the authors of the paper have said they want to take their work further in the future. When they do, we’ll be eager to see the results.
* Krassimir Tzvetanov, Umit Karabiyik, “A first look at forensic analysis of sailfishos,” Computers & Security, Volume 99, December 2020, https://doi.org/10.1016/j.cose.2020.102054.
Energy from the Community
It’s great to see so many apps are already available for the aarch64 platform. Community developers have certainly been busy. We’re seeing new apps being submitted to the Jolla Store and OpenRepos every day supporting the new architecture. This means as always there are far many new releases to cover here, but we’ve picked out a few that caught our eye. If you’re a developer, keep up the great work, and if you’ve not yet released an aarch64 version of your app, then please give it serious thought. In most cases we’d expect the process to be pretty painless.
Reading a book on your phone may not give quite the same tactile experience as the dead-tree variety, but you can store a whole library on your phone, which has to be more convenient than lugging around a suitcase full of books. So if you’re going to read books on your phone, it’s best to have some really high quality reading software to do it. That’s exactly what Books, from Slava Monich (slava) provides. In its heart it’s a port of FBReader, but integrated really nicely with Sailfish OS. Swiping between pages is smooth, the font rendering is crisp and readable, and all typefaces, formatting and images seem to be well-preserved. On the Xperia 10 II’s OLED display they really render very well. I tried a variety of different books downloaded free from Project Gutenberg and OpenLibrary in ePub format and found they all worked perfectly, even for encrypted files. Importing the books is simple and you can also control behaviour in various ways like forcing the screen to stay on while you’re reading. Text can be selected for copying, but there’s no way to search unless the book has its own linked contents or index pages included as part of the book. The latest version is available for aarch64, has improved translations and also now has integration with My Backup, one of slava’s other apps. Books is available in the Jolla Store and from OpenRepos.
Need to know your Nitrogen from your Nobelium? Then Jaksari by Timo Mäenpää (Aspor) will be just up your street. It’s a nicely designed app showing the periodic table including the inner transition metals and proven elements up to oganesson (121), but not the hypothetical elements beyond that. As well as showing the periodic table itself, individual elements can be selected to provide more detailed information including physical properties, electrical properties and a link to the relevant Wikipedia page. Six languages are supported and you can also change the colour scheme to help identify different characteristics of the various elements, although it would be nice to have a way to select the colour scheme directly rather than having to cycle through them. Aspor recently released an aarch64 version as well as support for dynamic translations and the most recent scientific data. Get it from the Jolla Store or OpenRepos. And in case you were wondering, Nitrogen is a colourless diatomic nonmetal, whereas Nobelium is a super-heavy actinide.
In the last newsletter we highlighted Pollenflug, an app for checking airborne allergens around a given location. I don’t want you to think I’m obsessed, but this time I want to talk about Powietrze (meaning “air” in Polish) by Kormil , which provides another way to check the state of the atmosphere. There’s certainly a seasonal cycle to atmosphere-monitoring apps. Unlike Pollenflug with its focus on organic allergens, Powietrze focusses on other various things in the atmosphere: nitrogen dioxide levels, benzene levels, atmospheric aerosol particles (suspended dust) of PM2.5 and PM10 coarseness. Depending on the provider other info is also provided, although unfortunately I found it wasn’t possible to use the OpenAQ service as it caused the app to crash, possibly due to bumps in the process of updating to the OpenAQ v2 API. Hopefully Kormil will be able to fix this soon, but the Powietrze provider works perfectly and so still provides very useful info info you’re based in Poland. The latest version works on aarch64 devices and also introduced My Backup support. Powietrze is available on the Jolla Store or from OpenRepos.
The sRadio app from Paul Wallace (Allstar12345) is a feature-heavy streaming radio player that also recently got some aarch64 love. It allows you to find your favourite SHOUTcast stations by genre or name search, although I found the latter a bit hit and miss. If you know the stream URL you can also enter it directly, so it’s not just restricted to the SHOUTcast stations. Once you’ve got your station playing the app goes all out to give you good control of playback. There’s a tray player at the bottom of the screen, clicking on it brings up the full screen player from which you can record the audio, add it to your favourites, activate a sleep timer and even shift to a car-oriented UI that’s basically just a massive play/pause button. I experienced a few glitches with the app, and SHOUTcast doesn’t always provide the speediest of responses, but it’s great to see the app improving at such a rapid pace and Paul is committed to developing it further. The latest release has had the biggest set of improvements yet, introducing improved artwork, scheduled recording, favourite editing, bitrate filtering and improved settings amongst other things. Phew. It’s available from OpenRepos
Please feed us your news
This is a community update, and frankly we can’t always keep up with all the exciting stuff happening in the Sailfish community. Plus, the less of this we have to actually write ourselves the better. So please help us out by posting your Sailfish news updates to the forum as a reply to this post. We’ll collate as much of it as possible into one easily digestable post for the next update.
And don’t forget to join us at the community meeting every other Thursday on IRC. It’s a great place to discuss any of the content you see here, or to share your ideas for future updates. The next meeting will be on the 20th May, full details here.