Some of you may already be running an open-source operating system on your smartphone, which could be Android-based, such as LineageOS, GrapheneOS, and e/OS, or Linux-based like postmarketOS and Ubuntu Touch.
However, due to closed-source firmware files/proprietary blobs, you’re only running a partially open-source OS. The Free Software Foundation aims to change that with the Librephone project, whose goal is to reverse-engineer nonfree blobs and provide open-source alternatives.
Some proprietary blobs are used to run WiFi, Bluetooth, 4G LTE/5G modems, touchscreen, fingerprint sensor, and other hardware. So it won’t be a trivial task, as serious reverse-engineering work is needed and done in a clean-room way to prevent copyright lawsuits, plus there may be regulatory issues with the code handling the radios\ frequency and power from the FTC and other governmental agencies around the world.
To be clear, the Librephone project won’t be another operating system, and the only goal is to make existing open-source mobile distributions even more open-source than they already are, thanks to open-source firmware for currently closed-source binaries. Some documentation is already up. Basically, the project will start by analyzing binary files in LineageOS images for supported phones using extraction tools. This includes a long list of smartphones and tablets from OnePlus, Google, Motorola, Xiaomi, Fairphone, Samsung, and Sony, among others, as well as some SBCs from Radxa and Banana Pi.
The initial work is funded by a donation from FSF board member John Gilmore, who explains:
I have enjoyed using a mobile phone running LineageOS with MicroG and F-Droid for years, which eliminates the spyware and control that Google embeds in standard Android phones. I later discovered that the LineageOS distribution links in significant proprietary binary modules copied from the firmware of particular phones. Rather than accept this sad situation, I looked for collaborators to reverse-engineer and replace those proprietary modules with fully free software, for at least one modern phone.
However, going forward, the Librephone project will need help from the community, either helping with reverse-engineering work or documentation, and the Free Software Foundation also requests donations for this project and other endeavors from the Foundation. You can also learn more from an audio interview of Rob Savoye, lead developer for the Librephone project.
Via Liliputing
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
I don’t think they can proceed a lot because most of these blobs, at least on modern phones, should be signed and not replaceable by arbitary people.
BTW, I tried reverese engineering bes2600 wifi chip, and what I realized in the end is that there’s a lot of burned-in code in some ROM inside, with the loadable firmware only being hooked into via a jumptable+patchtable of functions that ROM uses to modify the ROM code behavior a bit. So while the loadable code could have been replaced, ROM code could not.
And there’s likely not enough RAM to avoid the ROM code altogether, and just run everything from RAM.
So if they pick the wrong target chip, designed along these lines, something like this can become another issue. There’s 0 fun in having to interact with a few hundreds of KiB of unchangeable foreign binary code in this way, and it also limits you in what you can achieve.
Well I heard that Realtek Wi-Fi chips do the same thing (and these seem to have a more weird instruction set, e.g. 8051).
Thanks for your efforts! This might sound a bit dumb but what exactly is burned-in code? Like how do they do that and why is it untouchable?
I think he is just talking about the boot code in the ROM (Read-Only Memory) inside the chip. Since it’s stored in ROM instead of writable flash, it can’t be changed.
Signing was not an issue, though. You can even start the secondary CPU in a way that pretty much avoids the ROM code altogether, because one of the first things ROM code does is that it jumps into the loadable function jumptable in RAM, so you can just never return back to ROM and do you own thing. 🙂
In signed contexts usually all things loaded to RAM is then signed (or not executable at all), or it will be some “security issue”.
You are putting here android roms in the same sentence with PostmarketOS like if there were no difference in case of open source between those.
There are worlds between those. PmOS is today only using Mainline ports. You at first have to add mainline kernel support for phone and then use all other open parts. Its not like Android roms where they take just the hardly closed manufacturer kernel and build known working Android around it.
The quote from John on the other side is fully correct.
Admirable project. Hope for great success.
Second that.
Just focus on the Librem 5 phone. Everything there is open already except the BM818 modem. That is the best chance to reach the goal if all resources are concentrated on that last bit.
It would seem that the mobile network modem is out of scope for this project but apparently the FSF is in constructive contact with Purism about what work they could do for the Librem 5 in this regard.