Sailfish Community News, 20th May, Kvarken, MLS, Forensics

Subscribe to future posts here :bell:

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

We take the security and privacy of our users seriously. That’s a claim every company makes, but at Jolla it’s not just an empty statement that we roll out when updating our privacy policy: it runs through the DNA of the company. That’s why we keep the data we store about users to an absolute minimum, why we give users control of their own data on their own devices, why Sailfish OS encrypts your data by default, why we’re rolling out sandboxing of apps. With the majority of Sailfish OS being open source, we’d have a hard time locking you out from accessing your own data, even if we wanted to.

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, 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, 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 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 dd.

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
Images ~/Pictures/Camera/
Accounts ~/.config/libaccounts-glib/accounts.db
Contacts ~/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db
Calendar ~/.local/share/system/privileged/Calendar/mkcal.db
Browser ~/.mozilla/mozembed/cache2/
Calls/SMS ~/.local/share/commhistory/commhistory.db
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,

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.


I’m looking forward to the full version for the Xperia 10 ii. Great to read that this will happen soon.

1 Like

Good to see the idea was picked up. I’d even say that being able to do offline-only locationing is a major improvement compared to what was.

Out of interest, has the MLS Manager author, who went quite a long way to provide packages, repository, and app been involved in any way in the creation of this, or was it a parallel effort by Jolla and/or others?

Cellebrite specifically seems to be vulnerable to attacks by specially prepared files on the phone:

For example, by including a specially formatted but otherwise innocuous file in an app on a device that is then scanned by Cellebrite, it’s possible to execute code that modifies not just the Cellebrite report being created in that scan, but also all previous and future generated Cellebrite reports from all previously scanned devices and all future scanned devices in any arbitrary way

Maybe SFOS should also generate some files stored in the unencrypted part of the OS purely to improve aesthetics (not to compromise forensic tools, of course) :joy:

In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software.



I’m afraid I don’t know the answer to that. Either way, I take my metaphorical hat off to Samual for his amazing effort.

1 Like

Of course, any “usable” pin/password for the device encryption is easy to brute-force (because it’s numeric and relatively short).

For the rest in /, the telephony things reveal where the phone has been recently I guess, but that information is already available for law enforcement (and as the Covid thing has shown, any ole government agent who thinks tracking where people go is necessary) from the network providers.


Would it be possible to wipe everything clean, e.g. before trying to cross a border, without breaking SFOS in the process?

1 Like

It would be nice to be able to enter a (longer, alphanumeric) luks password at boot time.


Yeah, because as many people posted here previously many times, currently this “encryption” is basically doesn’t work. One would need several minutes to brute-force numeric pin offline.

1 Like

What a nice message, thank you!

There is a unofficial TWRP for Xperia 10 II

Also, I read somewhere that from 2020 Xperia devices bootloader can be locked with custom ROMs, but I need to find the source. Probably that’s why Flypig said “we’ll return to that later”

Edit: nevermind last paragraph, it was just a question made by a XDA user.

1 Like

Sony won’t allow it.
Or they at minimum would demand to sign the kernel themselves and have a big warning on boot-screen saying ‘you are using unofficial non-Android non-Sony image’.

1 Like

Thank you for mention about Powietrze. I am very suprised because I have thought that my apps aren’t much popular. <3

Can you say more about crash when select stations from OpenAq?


It’s a nice app and I think could be useful for a lot of people; I hope you’ll continue developing it.

Yes, sorry, I should have done this at the time; I’ve submitted a bug report to github. Feel free to let me know there if you need more info.

1 Like

I can’t wait for the full version of SFOS for Xperia 10 II, it’s going to be amazing!! So far, I’ve gone back and forth between SFOS and Android and SFOS is so much better. Having been a Blackberry 10 user for (too) many years, it feels like going back home.


Wow, thank you so much @flypig for mentioning sRadio, I’m gobsmacked my little App was mentioned here :grinning: :grinning:


would be nice to have a night mode in browser for the oled display or that it honurs the color settings from about:config


Thanks for the very thorough security situation overview. It’s a very difficult thing short of knowing precisely how to do block level encryption safely (?) so it’s nice to get some detailed reflections on the state of affairs.

This, ^^^

Since it is trivial to add extra keys to the luks slots and remove the existing “numbers-only-few-digits-long” pincode, all it’d need is to modify the current lockcode input panel to handle proper alphanumeric passphrazes of sufficient length…

Let’s do that! :slight_smile:


It would also probably need some changes to current PIN code logic (for unlocking live devices).

1 Like