Paul Kocialkowski's coding blog

Free software, programming and stuff

Archives 2014

The Samsung Galaxy back-door was bullshit. Really?

Written by Paul Kocialkowski - - 18 comments

A few days ago, I disclosed (on behalf of the Replicant projet) our research regarding a back-door found in a proprietary program running on Samsung Galaxy devices' applications processor. This back-door lets the modem perform I/O operations on the device's storage.

For the full statement, please refer to the article posted at Free Software Foundation's website. The relevant technical analysis is available at the Replicant wiki and a complementary statement was issued at the Replicant blog.

In the few hours following the publication, an outstanding number of technology-oriented websites relayed the news, including Phoronix, Slashdot, LWN and XDA-Developers. I'm very glad the press found interest in that research and I'm confident it'll help more and more individuals realize the importance of being in control of their computing: that is, to understand what's at stake with free software.

A few recent developments particularly caught my attention: Ars technica bothered to ask an actual security researcher, Dan Rosenberg his thoughts on our findings. Good thing they decided to go deeper than only duplicating the information. On the other hand, Samsung issued a statement about this issue:

Samsung takes the security of its products extremely seriously. We have investigated the claims that have been made and can confirm that there is no security risk. The Free Software Foundation’s recent allegations are based on a false understanding of the software feature that enables communication between the modem and the Application Processor chipset.

Mostly, the point that is argued by Dan Rosenberg is that there is no evidence of any ability for a remote party to use the back-door, nor any known exploit to make use of it remotely. As a matter of fact, we didn't look at how this could be used over the air: this was not the point of our research. The problem we intended to highlight is not so much about how in practical terms an intruder could use this anti-feature remotely to access and modify the data stored on the device, but rather to show that a particular proprietary software implements a feature that could be used to let the modem gain data I/O access over the device. This is where we find the back-door to be: at the interface between the modem and the applications processor. We do consider the modem to be an “unknown” area that offers no guarantee at all regarding security, since it is running proprietary software. Hence, we believe it is relevant to assume the worse and consider it compromised and subject to remote control. Several indications tend to make us think this is actually what is going on: Craig Murray described how a mobile phone had been remotely converted to a spying device in Murder in Samarkand. Considering the recent revelations regarding the practices of several governments' intelligence agencies, we find it hard to believe there is no way modems cannot be remotely compromised.

The goal of our action was to make people aware of that particular issue. One might consider it to have no value, provided they don't think modems can be remotely compromised and others might see it as a crucial security flaw in the event the modem is compromised, as we do. The fact that it was implemented for another purpose or was not intended to be used in malicious ways doesn't change anything at all: an attacker with remote access to the modem will be able to issue the incriminated requests. There is no possible “false understanding”, in the way Samsung seems to imply here.

For the record, we didn't at any point intend to distort the truth to bring attention to our project or our research, nor did we intend to ruin Samsung's reputation. We simply felt it was our moral responsibility to spread the word about it. I believe anyone can decide for themselves whether they have faith in Samsung's good word that this introduces no further security risk, but let it be clear that it doesn't get any more certain than what good faith can provide. We are still looking forward to working with Samsung to make things right, in case they decide to abandon their current position of denial.

Impressions from FOSDEM 2014

Written by Paul Kocialkowski - - no comments

Well, this is mostly going to be about my experience at FOSDEM 2014. Thanks to being a student in a city that features an easy-to-access airport, I was able to attend this year's edition. While my travel schedule was real tight, I only found out the plane was landing not in Brussels, but in Charleroi a few days before departure. Thankfully, it wasn't too late to find another schedule that made it possible for me to arrive at the Friday Beer event around dinner time. The cafe, and the aisle that leads to it were incredibly crowded, to the point that it was barely even possible to make it to the entrance. And once there, despite the fact that the cafe had been reserved for FOSDEM attendees only, I sadly couldn't get in, since the interior of the cafe was apparently full as well. While waiting near the entrance, I was able to see Greg K.H., first of the numerous giants of the free software community I stumbled upon at FOSDEM.

The next day, I was really amazed to see so many people going to FOSDEM, on the way to the event. Public transportation was really filled up with free software hacktivists! Arriving at the ULB campus used for FOSDEM, it really felt spacious and seemed appropriate for an event that big. Lots of interesting discussions took place after the first talk I attended: it was really nice. There were also numerous stands, mostly divided in two buildings, with many interesting people to talk to as well. In the AW building, I enjoyed the Coreboot/Flashrom stand (free software BIOS), Hackable-Devices (apparently focusing on micro-controlers recently), OlinuXino (Allwinner single board computers) and OpenPandora (free software gaming device) with a prototype of the new OMAP5-based version of the device, running apparently really well on GNU/Linux without graphics acceleration blobs. However, the big slice of stands was in the K building, including popular GNU/Linux distros such as Debian or Fedora and desktop environments such as GNOME and KDE. The FSFE was also there, with real good-looking flyers about their Free Your Android campaign, promoting Replicant and F-Droid! I also spent some time at the CaCert booth, and frankly, I was amazed by the depth of the identity verification process. First off, having a single official document to prove of your identity is not enough for these guys, and things get worse when the signature on the ID card (kindly provided by mom at a time I couldn't sign it for myselef) doesn't match the one you produce. Not to mention you have to sign the paper before their eyes, else it's not valid. The ID card itself is also checked to be genuine, with the many UV lights at their disposal and descriptions of the expected results. So I was really surprised how strict the whole process is and I think it's really great that they are taking this very seriously.

The rest of the afternoon we spent in the legal devroom, where I could meet many great people such as John Sullivan, Bradley Kuhn, Karen Sandler and others. John gave a talk about Javascript, with all relevant infos regarding how to escape the Javascript trap, followed by Chris Webber about free network services and introducing the road map for the next MediaGoblin releases, with a really good-looking video explaining the goals. Chris was probably the most enthusiastic speaker I saw at FOSDEM: he was really passionate about his talk and created a wonderful ambiance in the room (summoning that feeling that urges you to get involved in something bigger than you), so kudos to him for being that good. After a while, we headed to dinner with the Coreboot crew, very nice and interesting people. It was a real pleasure spending time in their company.

On Sunday, we had to rush to get to FOSDEM in time for the F-Droid track by Daniel Martí, followed by an introduction to the linux-sunxi community by Olliver Schinagl, who kindly poked the Replicant project during the talk mentioning that I've been promising Replicant for Allwinner devices for the last six months. Olliver's talk really made me realize what an amazing platform Allwinner is, so I just went ahead and ordered a variety of Allwinner devices to port Replicant to, so we should get there in the near future! On the way to lunch, I quickly saw someone I believe to have been Harald Welte: while I would have loved to have thanked him for his great work, he went by faster than it took me to realize who he was. Time went by, and in the afternoon, I could only attend the Lima talk by Luc Verhaegen before leaving. The project is apparently steadily moving forward, however, without any mind-blowing demo this time. I really had to leave fast after the talk, to catch up with my transportation schedule.

I really have the best memories from FOSDEM, it was really nice and there is no doubt I'll attend next year's edition, hopefully presenting a talk about Replicant there. It was also really nice to see people grateful for the work I'm doing on Replicant. Such huge community gatherings are the best to gather the motivation to keep working on a free software project: actually meeting the community brings a whole different picture compared to what contributing to free software usually feels like individually, hacking alone in my dark room.

Missing proprietary firmwares in Android systems

Written by Paul Kocialkowski - - 57 comments

Firmwares are programs that do not run on the main processor of a computer: instead, they runs inside separate chips that have a dedicated functionality. Most of the time, firmwares are proprietary programs, which do not respect the user's freedom. When they are not already installed in the chip they run in, the main processor has to load them into the chip, which requires the firmware to be distributed as a file. Since they are proprietary software, I think firmwares shouldn't be shipped with any operating system, not should any operating system ever advise the user to install them.

However, people sometimes need a functionality that depends on proprietary firmwares so bad that they would rather use a system that ships and encourages the use of proprietary software, including the needed firmware, over a free system. In that case, it is better for their freedom that they use a free system with only the proprietary firmware installed, over another system that contains dozens of other proprietary pieces, including ones that also run on the main processor and are able to compromise the whole system (from a security point of view), on top of not respecting the user's freedom.

On Android devices, people are often facing this choice and look around for instructions on how to install only the missing firmwares so that they can avoid installing a system that contains even more proprietary bits. While these instructions cannot be released on free system's official documentation pages, for the sake of not encouraging the use of proprietary software, it makes sense for me to publish such instructions on my personal pages. I have written scripts that extract the firmwares from CyanogenMod installation zips for a few Android devices and push them to the device: cm-firmwares.git

The procedure to install the firmwares is the following:

  • Grab the CyanogenMod installation zip matching the needed version from the CyanogenMod Downloads website (make sure to select the stable release).
    For instance, the CyanogenMod 10.1.3 installation zip for the Galaxy S 3 (I9300) is at:
  • Clone the cm-firmwares git repository, with the branch matching the CyanogenMod version.
    For instance, for CyanogenMod 10.1.3:
    git clone git:// -b cm-10.1.3
  • Connect the device via USB, make sure ADB is enabled and allowed to run as root on the device. Check that the device is connected and allowed:
    adb devices
    If not, it might be necessary to run the process as root (or prefix the following commands with sudo).
  • Run the script (on the host computer) with the device codename as first argument.
    For instance, for the Galaxy S 3 (I9300):
    ./ i9300
  • Alternatively, it is possible to create a zip containing the firmwares and install it afterwards, using recovery.
    For instance, for the Galaxy S 3 (I9300):
    ./ i9300 zip

If you wish to push only certain firmwares, feel free to edit the text file matching the device codename to remove the ones that are not needed before running the script.