This year's edition of RMLL/LSM, the free software conference that travels in and out of France (with an international aim) just ended. Time to take a step back and look at what happened during the 4/5 days I was there.
Thankfully, I get to travel to such conferences using money from the Replicant fund, so I will be refunded both my train tickets and my stay this time again. It makes it much easier (and to be honest, possible at all) for me to attend such conferences. This way, I don't have to worry about finding a summer job and can instead focus on what I do best, reverse engineering proprietary stuff and writing (free) replacement code.
This time, I arrived on Monday afternoon and could attend a first talk after a quick chat with the lovely people from the information booth. The talk, that was part of the security track, was presented by Lunar (Tor and Debian developer) and reported the current state of the art of reproducible builds for Debian (and more). It was really nice to see such overwhelming progress accomplished, after I attended the initial talk during which he announced the reproducible builds initiative a year and a half back, at FOSDEM. Lunar's talk answered most of the questions I had regarding how to make software reproducible. I am especially interested in making the U-Boot bootloader reproducible. I had that idea at the back of my head for some time now and decided to jump in after seeing a contribution in that direction on the U-Boot mailing list. Eventually, we managed to get some of that work done (right) later in the week. The rest of the afternoon was filled with chatting around in the village. In the evening, I met people from the event at a local bar, were free music was being played. It was a nice atmosphere and we had some interesting technical discussions (and let's be honest, many trolls as well)! I was thrilled to see that people were not only aware of Replicant, but also had a lot of interest in it.
On Tuesday, it was time to get to the workshop I was supposed to co-host. The whole day was filled with various activities around different kinds of embedded devices (some were about scientific measurements, some about Arduino, etc). In addition, most of these were built with education in mind. When the first one ended, it was time for me to leave in order to reach the room where I was to present my first talk. The video recording seemed to be done right and hopefully, the video of the whole thing will be available eventually. Not that many people showed up, but the ones that were there seemed really interested. I got to meet and talk with a few people after my presentation, some of whom decided to come to RMLL only to have a chat with me. What a surprise! The afternoon went on and I attended a few talks, including a round table around the concept of civilian re-appropriation. It was presented by Veronique Bonnet, who's a philosopher and a member of April, one of the French associations that take a stand for freedom on digital devices (and actually get it right). Richard Stallman (RMS) was also there, even though he apparently didn't quite understand the wording of the subject in French. Still, some interesting things were said and RMS displayed his usual sense of humour here and there, sometimes making the audience burst into laughter. Once it was over, we got to chat a bit, in a very friendly environment, which was very nice. A free music concert was organized near the event, so a few youngsters (including myself) decided to go before calling it a day.
Wednesday was the occasion for me to be around the workshop more often, but very few people showed up because it was missing from the printed schedule, something I only came around to realize once it was too late, a week before the event or so. Despite some paper indications and the addition of the workshop to the online program, the place remained rather quiet, which wasn't so much of a problem given my aggravating state of sleep deprivation. Before lunch, I gave my other talk about Replicant, a longer and much more technical one. To my surprise, many more people showed up (perhaps the result of meeting a few people during the first few days). The talk itself went well and everything fit on schedule. For the record, the content of both talks (which summed up to 1 hour and 40 minutes, mostly excluding questions) was what I had planned on delivering during my (50-minute long) talk at FOSDEM this year: no wonder I had to stop half-way back then! Afterwards, I was lucky to get help for making U-Boot reproducible from Lunar, whose efficiency, vivacity and kindness really made the task painless. There are still bits and pieces to bring together to craft a proper patch, but I'll get around doing it sooner or later. After alternating between the workshop and talking to great people at the village, I ended up meeting back lots of interesting people at a Harry Potter-themed bar, le Chaudron Baveur (not that the owner deserves any particular good word about it, given that he wasn't exactly pleasant).
The next day went on pretty much similarly, except that I had no talk left to give, and thus no particular pressure or place to be at (except for the workshop, that remained desperately empty). Just like any other day at RMLL, I met tons of incredible people and had lots of interesting talks. In the afternoon, the main “political” event of the week took place, with a round table regarding interoperability and DRMs. The speakers were a high-ranking official from HADOPI and Marie Duponchelle, who conducted a thesis on the very subject. Overall, it was very strange, mostly because the nature of the debate soon revealed to be astonishingly stupid and a pure waste of time. The main question was how to allow the entertainment industry to use DRMs while maintaining interoperability. The answer is plain and simple: it can't be done. Despite that very clear statement, that was introduced eventually by Marie Duponchelle (in spite of the situation Videolan was in), the debate went on and the HADOPI representative produced vague statements with apparently no ties to the technical reality one after the other. At some point, the audience got pissed off and started expressing our community's point of view in very clear ways, such as encouraging everyone to share culture in the most efficient ways: torrent, VPNs and Tor. All that followed by rounds of applause, naturally. More serious questions were raised, such as the existence of public domain in practice when only copies of an piece of art exist with DRMs. The HADOPI representative answered that any piece of art is itself distinct from the media it is distributed on, which may be a fair point, but doesn't solve anything. She also suggested that the BNF could receive non-protected copies of it, but this is neither its mission nor a reliable solution for people who will find a DRM-tainted copy decades later, unable to read it despite the fact it is in public domain. The talk ended with François Revol (Haiku developer) handing over a big coin of 1 Hadopi to the representative, a way to show our community's support for this organism at a time of budget cuts. Bottomline: this was purely a waste a time (despite providing some form of entertainment). No wonder some decided to master the fine art of origami during the talk instead of listening to that whole mess. Hopefully, the main political talk will prove to be more interesting next year. In any case, it probably cannot sink much lower. Later that day was the repas du libre, the traditional classy-ish dinner where we all meet together and look back at the week (everybody knows Friday is mostly for getting over the hangover induced by the previous night's drinking and also for packing). I didn't plan on attending at first, since the food wasn't really worth it last year, but changed my mind given some pretty solid arguments. Or maybe just pretty at all. In any case, I got to formally meet Benjamin Bayart (some fine blood forensics can probably assess for that) who not only showed interest in Replicant (and other things I'm doing these days) but offered me his help in every way possible. That evening is probably the time I had the most fun at RMLL, thanks to Benjamin, Fabien, Frédéric, jfefe and plenty others. Kudos to them for their support in times of great needs, that was a relief. Thankfully, my LG Optimus Black (P970) booted just fine, so in the end, it's fair to say that the various issues encountered were accounted for and that the whole thing provided a working result, that will certainly become a base for future developments, now that the initial trouble is behind us.
Friday was a bit less fun than the other days, in part for reasons of a physical nature. I still managed to reach the event in time to be reminded that Trinity does use nmap and it's fair to say that it's the coolest thing. Sadly, some people had to leave early and I couldn't conclude some of the ongoing arguments that had developed throughout the week. Hopefully, there will be other occasions to meet (and certainly closer than Beauvais), but that's ultimately not really up to me, despite my best intentions.
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.
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.
I am currently working on writing a free software replacement for the Galaxy S3 camera module, based on the Exynos Camera module I wrote a couple months ago for the Galaxy S2. Both are using V4L2, but the implementation differs in details. Especially, the Galaxy S3's back camera, the Samsung S5C73M3, uses an interleaved format for picture capture.
As an interleaved format, there is no standard and readily-usable implementation to decode the data. After searching for a long time, all I could find was a commit by one of Samsung's developers that introduced that format to mainline, through a LinuxTV patch. First of all, I can't seem to understand why such a patch was accepted mainline given that there is no decoder implementation for that format out there. Moreover, the only camera chip that uses it, the S5C73M3, has a driver that was also accepted in mainline. It seems to me like it was blindly included and nobody cared so much about how it works in practice. Moreover, it seems that this camera chip is mostly found in the Galaxy S3, and I doubt anyone tested mainline on the Galaxy S3 to see whether the S5C73M3 driver works and gives appropriate results.
However, let's not complain too much, that patch gave me crucial info to understand how to properly extract YUV and JPEG from the interleaved data. For reference, here are the explanations given with the patch:
Two-planar format used by Samsung S5C73MX cameras. The first plane contains interleaved JPEG and UYVY image data, followed by meta data in form of an array of offsets to the UYVY data blocks. The actual pointer array follows immediately the interleaved JPEG/UYVY data, the number of entries in this array equals the height of the UYVY image. Each entry is a 4-byte unsigned integer in big endian order and it's an offset to a single pixel line of the UYVY image. The first plane can start either with JPEG or UYVY data chunk. The size of a single UYVY block equals the UYVY image's width multiplied by 2. The size of a JPEG chunk depends on the image and can vary with each line.
The second plane, at an offset of 4084 bytes, contains a 4-byte offset to the pointer array in the first plane. This offset is followed by a 4-byte value indicating size of the pointer array. All numbers in the second plane are also in big endian order. Remaining data in the second plane is undefined. The information in the second plane allows to easily find location of the pointer array, which can be different for each frame. The size of the pointer array is constant for given UYVY image height.
In order to extract UYVY and JPEG frames an application can initially set a data pointer to the start of first plane and then add an offset from the first entry of the pointers table. Such a pointer indicates start of an UYVY image pixel line. Whole UYVY line can be copied to a separate buffer. These steps should be repeated for each line, i.e. the number of entries in the pointer array. Anything what's in between the UYVY lines is JPEG data and should be concatenated to form the JPEG stream.
At first, I was only getting the first 0xA00000 bytes, which is in fact only the first plane. Hence, I couldn't find the offset to that pointers array (even though I could locate it manually). I had to enable embeded data with the V4L2_CID_EMBEDDEDDATA_ENABLE control. With that, the buffer gets 0x1000 more bytes: that's the second plane. Then by applying an offset of 4084 bytes to the start of that second plane, I could locate the offset to the pointers array.
Since I complained it was lacking, I wrote a reference implementation that separates the YUV (it's actually UYVY) and JPEG data from the interleaved format: s5c73m3_interleaved_decode.c.
2013-08-06 Update: As I sent an email to the Samsung developers involved in the mainline patch, I was given details on the format (that I already figured out though) as well as a C implementation to separate JPEG and UYVY. The developer also told me he is going to release sample code to decode the format, publicly. So I think things are going to be fine, and my criticism will soon no longer be valid. Yay!
While reversing the Galaxy Tab 2 sensors, I have been looking for a way to calculate the orientation vector from acceleration and magnetic field vectors: I've looked at any sensors implementation I could find and each time, this was being held into some proprietary component, to the point that the Galaxy Tab 2 has an user-space blob dedicated to this task (orientationd). Since I am not an expert at physics, I soon gave up on writing a free orientationd implementation, which was really a shame given the time I spent making the geomagnetic sensor work properly. I just realized that there was one last implementation I didn't look at, that is the free software user-space program for AKM8975. So many thanks to Asahi Kasei: I was able to reuse that code directly and it worked perfectly at first try. That's pretty amazing!
Quite some time ago, I was given the opportunity to receive a crowd-funded Galaxy S2 phone. Even though I was very thankful for it, I couldn't really focus on it at first since I had to handle other things on various other devices I was working on. It left me somehow sad as I felt that it was my duty to add proper Replicant support for it. Today, I'm proud to announce that the biggest part of the work to support it is over.
The modem (XMM6260)
At first, we had to add support for the modem, an XMM 6260 modem with a custom Samsung firmware. The modem protocol is what we call Samsung IPC, the very same as the one used in the Nexus S or Galaxy S. Our lower-layer library to handle it is libsamsung-ipc, that is shared between Replicant and SHR. So We had to add support for XMM6260 in libsamsung-ipc, along with Galaxy S2-specific bits. Thoughtfully, we designed the upper layer, Samsung-RIL (that is specific to Replicant) to work with libsamsung-ipc regardless of the device it's running on. Nowadays, the modem support is complete and we have working calls, messages and data. Anyway, modem features support is up to Samsung-RIL, so it's not Galaxy S2-specific.
The Audio CODEC (Yamaha MC1N2)
After doing a break in Galaxy S2 development, I finally got back to it, and started the 4.0 Replicant version for the occasion. Since the audio module was non-free in CyanogenMod, it was one of the key components to add support for. (What good is a phone if you can't get any sound out of it?) So after digging a little in the kernel code, it turned out that the Audio CODEC had an ALSA interface driver. That means PCM In/Out interfaces as well as Mixer controls. Only problem was that I still couldn't get any sound out of it using the TinyALSA test utils. After doing a bit of research, I found out about the /dev/snd/hwC0D0 node, that was implementing hardware-specific controls (via ioctl). After adding debug prints to it and with the help of some CyanogenMod developers, I was able to reimplement it on my Yamaha-MC1N2-Audio library. The ALSA part was done with a 4.0 update (call it a complete rewrite) of my TinyALSA-Audio library. The combination of the two made it possible to have sound with Replicant (including during calls). It is even used by CyanogenMod since version 10.1!
The sensors (K3DH accelerometer)
With modem and audio support, the Galaxy S2 was made usable as a phone. Thanks to the free hwcomposer module, it's very fast too, so I decided to use it as a main phone for a time, and frankly quite enjoyed the ride. The sensors were also relying on a non-free library, the one called libakm: AKM is the compass manufacturer. Nonetheless, it includes the bits to properly handle the K3DH accelerometer chip too. The situation is quite similar to the Nexus S sensors, and I was able to figure out the accelerometer part back then (it was a KR3DH) and implemented it in the libakm_free library. Since it was quite easy for Nexus S (libakm was just a passthrough), I gave it a try on the Galaxy S2. After tracing the K3DH kernel driver, I figured that the values returned by libakm were just the result of linear functions applied to the data returned by the kernel. I renamed libakm_free to Samsung-Sensors and added support for the K3DH there.
The cameras (M5MO/S5K5BAFX)
Galaxy S2 support was then already pretty decent, and I was kind of proud of myself. Though, it take a look at the Galaxy S2 characteristics, you'll see that one of its key features is the 8MP camera it embeds. And sadly, there was no usable camera module around. Though, it appeared to have a V4L2 driver, which is pretty standard and easy to implement. However, I feared that I'd have to face the same situation as audio: standard interface but only usable with a non-trivial interface aside. Once again, I traced the kernel driver and started implementing, step by step. After a couple weeks of work (I wrote the implementation from scratch and obviously couldn't spend time on it everyday), it appeared that the original non-free camera module was doing a lot of unnecessary output/overlay operations. So I decided to cut out the crap and get to the essential, that is only using the capture V4L2 interface. This comes with some issues such as the inability to resize/crop the output buffer, but I think I found acceptable workarounds for that. In the end, my camera module turned out to work quite well and is now fully-featured (except EXIF that is currently broken, but it's such a pain in the ass that I don't really want to get into it and fix things). I pushed the code on the Galaxy S2 device tree as well as on my personal Exynos Camera git repo.
Now the Galaxy S2 is supported as well as the Nexus S in Replicant and the missing (and doable) parts left are mainly GPS and compass. The compass is an AKM8975 chip. Some code was released by AKM for this chipset and even though my first attempts to make it work failed, I guess there is a way to have it working properly. I didn't renew my attempts since this is quite a detail and there is probably more important things to work on at the moment. That's for instance the GPS: it's a GSD4t chip, the very same as the Galaxy Nexus. It needs a firmware upload and uses a SiRF-derived protocol that does not seem to be documented anywhere. I hope we'll be able to figure it out somehow: it would be very nice to have GPS support on these two devices!