How free is my phone?【转】
How free is my phone?
A deep dive into the innards of a typical mobile phone and how little you know about what's going on inside, even when there's an open source operating system running on it.
You might think that your phone is open, but even Android, Tizen and Firefox OS all depend upon highly proprietary code bases for making telephone calls and transferring data. When it comes to these fundamental capabilities, the open source part of a mobile software stack is only the tip of the iceberg, and behind APIs and simple interfaces for voice, SMS and data lies the technology that makes wireless communications possible – and it's far from being open source.
First generation (1G) mobile telephone systems were reasonably simple and made use of frequency modulation (FM) – as used by broadcast radio – for carrying voice calls. This is why people could easily eavesdrop by using receivers known as "scanners". But things got an awful lot more complicated with the arrival of GSM, where all traffic is digital and gets encrypted and multiplexed before being transmitted on a radio carrier which can rapidly hop from one frequency to another.
Thanks to the increased complexity of GSM and later 3G systems we enjoy much improved call quality, higher capacity networks, some measure of privacy, and broadband data services – to name just a few benefits. But these don't come without a price and this means putting your faith in a formidable slice of proprietary tech that is built upon arcane, and in parts restricted, standards.
Baseband firmware
Where the smartphone operating system provides the user interface, the behind-the-scenes communications heavy lifting gets done by "baseband" firmware that is off-limits to developers and which typically runs in isolation on a second processor. The interface between this and the smartphone OS may then be provided by something as simple as a serial port and Hayes commands that enable calls to be set up and cleared, and text messages sent and received, etc.
It is this baseband firmware that is responsible for controlling the phone's radio transceiver, carrying out digital signal processing (DSP) and implementing the GSM or 3G protocol stack. This is no mean feat and involves complex modulation schemes, multiple layers of time division multiplex (TDM), high accuracy network timing, cryptography for authentication and encryption, and many other often-used-but-rarely-considered features that make mobile telephony work.
Impressive as baseband firmware is, its opaque nature presents us with certain problems.
The freedom to secure
There are many reasons why transparency is highly desirable when it comes to the technology that powers global communications networks, but perhaps the biggest has to be security. And while GSM remained largely secure – insofar as we know – for much of its early life, the GSM Association's security-by-obscurity strategy of restricting access to details of the A5/1 encryption algorithm ultimately didn't work out. This was reverse engineered in 1999, and over the years researchers have discovered lower cost and increasingly effective cryptographic attacks.
As if it were not bad enough that a PC with a powerful GPU can now break GSM encryption within a few seconds, it turns out that certain critical network operations are not authenticated, leaving handsets wide open to denial-of-service and man-in-the-middle attacks.
Open source baseband firmware would perhaps offer the hope of addressing some of these security shortcomings. As, even where a fix is near impossible due to a fundamental flaw in the GSM specifications, it should at least be possible to have firmware raise the alarm when something doesn't look right. Contrast this with the current situation where firmware can leave subscribers oblivious to the network taking it upon itself to downgrade or completely turn off call encryption.
OsmocomBB
OsmocomBB is a project to create a fully featured open source GSM baseband firmware and comes from the same group that brought us OpenBSC, the open source "GSM network in a box". At present, only handsets that use the Texas Instruments Calypso baseband processor are supported, which in practice means basic and somewhat dated models, but this does have the advantage that these are available to developers at a low cost.
The OsmocomBB Layer 1 firmware running on a Motorola C139 
The TI Calypso actually contains two processors: a TMS320c5x DSP core that sits closer to the RF hardware and takes care of signal processing, and an ARM core that uses a memory-based API to interface with the DSP at the MAC layer. The code for the DSP is burnt into a ROM on the chip and while it is possible to load patches this is used as-is. And it's the ARM processor where the OsmocomBB firmware gets loaded and the GSM stack is implemented.
Building OsmocomBB is fairly straightforward but does require an ARM toolchain to be installed. Once built, loading applications onto a phone is trivial and is achieved via a serial cable plugged into the headphone socket. The simplest method involves loading these into volatile memory, but it's also possible to replace the original phone firmware that resides in flash storage.
Motorola C123 PCB
Source: OsmocomBB Project
At the time of writing, a full implementation of the OsmocomBB GSM stack involves running layer 1 on the phone and layers 2 and 3 on a host connected via a serial cable. While clearly not ideal if you were hoping for a practical mobile phone solution, this has the benefit that it's easier to explore and debug the upper layers of the stack. And as with OpenBSC, the command line interface that's used for configuration will feel reassuringly familiar to anyone who has worked with Cisco kit.
Copious debug messages are printed to the console by both the layer1 firmware and the host-based mobile application which implements layers 2 and 3. But to get a real insight into what's happening, Wireshark can be used to decode GSMTAP messages which encapsulate the air interface, Um, passing it over UDP packets.
In addition to a functioning GSM stack that can be used to make voice calls and send and receive text messages, OsmocomBB also comes supplied with an incredibly useful network monitor firmware called simply "RSSI". This application not only allows you to monitor the received signal strength (RSSI) of base stations and mobiles, but provides cell configuration details and a spectrum analyser display which can be used to quickly ascertain which radio channels are in use.
Using the Osmocon program to load the Layer 1 firmware
At this point it's important to point out that the default is for transmit to be disabled in OsmocomBB firmware images. And while it's not difficult to create a firmware build with transmit enabled, it would be asking for trouble if you don't have access to your own licensed spectrum or a carefully controlled lab environment. Using a non-approved transmitter on a public GSM network could very easily cause serious problems and may bring you to the attention of the authorities.
To date the main uses of OsmocomBB have been as a tool for learning about GSM and by researchers probing the stack in order to uncover security flaws. In such cases it's typically used in conjunction with professional GSM test equipment or a low power network that has been created with OpenBSC or OpenBTS. Either a test licence will have been obtained from the communications regulator or all RF emissions will be constrained to the workbench.
So where is my free phone?
There are numerous hurdles that must be overcome before a practical open source baseband firmware is a reality. Perhaps the largest of these is concerned with gaining GSM type approval for handsets using the firmware, without which use with public networks is probably illegal in most parts of the world, or at least is a violation of a network's terms of service. And it's questionable whether a handset would ever gain approval if the baseband firmware can be modified at will.
The Telnet interface of the host-based program that provides GSM layers 2 and 3
Porting the firmware to other baseband processors also represents a significant challenge as the documentation for these devices is generally provided under strict NDA. And in fact it appears that one of the reasons that the TI Calypso was chosen is that its documentation had been leaked and the OsmocomBB developers considered it to no longer be a trade secret. There will also, of course, be the usual challenges that are associated with porting code from one system or architecture to another.
Other technical challenges include getting the code for layers 2 and 3 running on the handset instead of an attached host, and providing integration with dialler and messaging, etc., applications. However, such challenges will be minor when compared with such things as gaining type approval and access to baseband processor documentation.
Wireshark decoding GSMTAP messages
Source: OsmocomBB Project, CC BY-SA 3.0
In May 2011 project leader, Harald Welte, posted amessage to the OsmocomBB mailing list explaining how he had been contacted by Richard Stallman who, not surprisingly, had expressed an interest in the project. Although the original motivation was not to create something that would be of practical use as a replacement baseband firmware, Stallman encouraged Welte to work towards this goal. And in December 2011 Welte stated that the project was "an arm's length away from being able to create a true Free Software phone".
3G and beyond
Of course, OsmocomBB only supports GSM at present, and 3G has been rolled out across many networks for a number of years and 4G/LTE is on the horizon. However, GSM offers certain benefits over newer generations of mobile telephony, such as lower power consumption and better coverage in buildings, therefore it's likely that GSM will be supported by most networks for quite some time. And engineering experiences gained with GSM now will provide a solid foundation when it comes to developing 3G and 4G/LTE support.
One area that may prove problematic with the evolution of OsmocomBB is patents, as many of those present in the original GSM specifications from 1991 have only recently expired, and 3G will remain patent-encumbered for some years to come. In practice this is likely to mean that licensing fees would have to be paid to patent holders for any commercial usage.
Conclusion
The RSSI firmware in spectrum analyser mode
At the present time it looks as though an entirely free/open source software handset that can be used with public mobile networks is some way off, if it is even possible at all given regulatory requirements.
Additional motivation may come from baseband processor vendors seeking to reduce the costs associated with firmware development, or from handset vendors turning to open source in order to deliver features that would not be supported by proprietary firmware. And either one of these may be prepared to make the investment necessary in order to gain type approval.
Even without the ability to use OsmocomBB with public networks it has succeeded in delivering immense value. By providing an incredibly powerful tool used by security researchers to bring serious GSM shortcomings to light, and in enabling more people to learn about the inner workings of a critical communications technology in which so many of us place our trust.
In May of this year, early industry validation of OsmocomBB was provided by the discovery that Ericsson makes use of the code in its labs, praising it for its flexibility. As with any open source software it's impossible to know of everywhere that OsmocomBB is being used, and it may just be that it quietly gains support across academia and inside industry R&D labs, until one day it finds its way into a product or serves as the inspiration for a new open source baseband project that has substantial financial backing.
Andrew Back (@9600) is a freelance consultant who originally trained as an electronics engineer and first used Linux in the mid-90s. He has since worked at BT's open source innovation unit,Osmosoft, founded the Open Source Hardware User Group, and more recently co-foundedSolderPad – a place to collaborate on electronic design.
