How to build a GSM phone based on SDR

It is not a secret for anyone that in the smartphones already familiar to most of us, apart from the main processor, there is a separate communication module, thanks to which the smartphone is still a telephone. Regardless of the main operating system, be it Android or iOS, this module most often runs a proprietary operating system with a closed source code, and takes over all the work related to voice calls, SMS messages and the mobile Internet.

Unlike proprietary software, open source projects always get more attention from security researchers. The ability to look under the hood and find out how a particular component of the program works allows you not only to find and fix all sorts of errors, but also make sure that there are no so-called “bookmarks” in the code. In addition, open source allows novice developers to learn from the example of more experienced ones, using the results of their work as a support.
')

Introduction to the OsmocomBB Project

That is why in the already distant 2008 Osmocom project began to emerge - Open Source Mobile Communications. Initially, all the attention of developers was focused on the only OpenBSC subsidiary project, which allowed launching its cellular communication on multikilogram commercial base stations and was first presented in 2008 at the annual conference Chaos Communication Congress.

Over time, Osmocom went beyond the framework of one project, and today it unites dozens of subsidiary projects, one of which is OsmocomBB - a free implementation of the GSM stack for mobile phones with open source. Unlike its predecessors, such as TSM30, MADos for Nokia 33XX and Airprobe, the project we are considering has received much more attention from researchers and developers, and, moreover, continues to evolve now.

Initially, the main task of OsmocomBB was to create a full-fledged firmware for open-source cell phones, including a graphical interface and other components specific to them, and focusing on an alternative implementation of the GSM protocol stack. However, this idea did not meet with a strong reaction from potential users, therefore today OsmocomBB is an indispensable set of tools for research and at the same time a good knowledge base for beginners in GSM.

With the help of OsmocomBB, you can evaluate the security of a GSM network, as well as learn in practice how the radio interface (Um-interface) works in cellular networks. What encryption is used and is it used at all? How often do encryption keys and temporary subscriber IDs change? What is the probability that a voice call or SMS message will be intercepted or, for example, forged by an intruder? All these questions and many others can quickly be answered with OsmocomBB, and this is just one example of the possible ways to use it. From atypical examples can be identified: the launch of a small GSM base station, the study of the security of SIM-cards and traffic sniffing.

The main hardware platform OsmocomBB, by analogy with the Aircrack-ng project and network cards, are mobile phones based on the Calypso chipset, mainly Motorola C1XX. The decision to use the phones was made at the initial stage of the project development, mainly in favor of the speed of implementation, since the process of designing and manufacturing new equipment could take a long time. Moreover, the “leaked” parts of the source code and specifications of the Calypso chipset were already in free access, which contributed to the reverse engineering of the firmware and all further development.



However, this solution has its price. Phones based on the chipset described above are no longer produced, which forces us to look for used models. Moreover, the current implementation of the physical layer of the GSM stack is mainly based on the DSP (Digital Signaling Processor) - a signal processor that still executes a proprietary code that has not been fully studied. Both of these factors adversely affect the development of the project, limiting its potential and complicating the threshold for entry of both third-party developers and users of the project as a whole. For example, the implementation of GPRS support is impossible without changing the DSP firmware.

Wind of Change - New Hardware Platform

The program part of the project consists of a set of separate applications, each of which has its own specific purpose. Some applications work directly on the computer, in any UNIX-like environment. The other part is presented in the form of firmware downloaded to the phone. And the relationship between them is through the serial port of the phone, which is combined with a headset connector. In other words, an unremarkable TRS connector (micro-jack, 2.5 mm) can be used not only for transmitting sound, but also for data! A similar technology is used in modern smartphones, allowing you to connect headphones with buttons, monopod for selfies and other accessories.

The absence of other interfaces, such as USB, and the need to use the serial port also impose certain restrictions, the most significant of which is the data transfer speed. For example, partly the ability to sniff and launch the base station is limited precisely because of the low bandwidth of the interface. Moreover, it is rather difficult to find a ready cable for connecting the phone to USB, and in most cases it has to be done independently, which also complicates the threshold for users to enter.

The combination of these factors at some point gave rise to the idea of ​​switching to another hardware platform, which would not restrict the project neither in software nor in hardware, but would also be accessible to everyone, both in terms of production and in terms of price. And the SDR (Software Defined Radio) technology, due to the rapid growth of its popularity and availability, just meets these requirements.



The concept of SDR is to develop general-purpose radio equipment, i.e. not tied to a specific communications standard. Due to this, the technology has become widely spread both among radio amateurs and among manufacturers of commercial equipment. Today SDR is actively used in cellular communication, namely for the deployment of GSM, UMTS and LTE networks.

The very idea of ​​developing and launching a GSM mobile phone, implemented by the OsmocomBB project, based on SDR is not new. This area was once developed by Osmocom developers, but was abandoned. In addition, it is known about a similar research work of the Swiss laboratory , which, unfortunately, stopped at the level of Proof-of-Concept . But we still decided to resume work on this area, setting ourselves the task of implementing support for a new hardware platform for OsmocomBB based on SDR, identical to the Calypso chipset in terms of backward compatibility, and more open to modifications at the same time.

In the further part of this article, we will briefly describe the process of developing a new platform, as well as the problems we have encountered, and how to solve them. As a conclusion, you will be provided with the results that were achieved, the limitations of the current implementation, ideas for further development, as well as a small hint describing the procedure for running OsmocomBB on SDR.

Project history

As mentioned earlier, OsmocomBB provides two types of applications: some work on the computer side, others are loaded into the phone as part of an alternative firmware. And the interaction between them is implemented by a small program osmocon (from the word connection), which ensures their mutual connection through the serial port. The interaction itself is carried out through a simple binary protocol L1CTL (GSM Layer 1 Control), where there are only three types of messages: request (REQ), answer (CONF) and notification (IND).

It was decided to retain the idea of ​​such mediation, as well as the protocol itself, in order to ensure “transparent” compatibility with existing applications. As a result, a new application was implemented - trxcon, which, like a bridge, works between high-level applications (such as mobile and ccch_scan) and a transceiver - a separate application that manages SDR. Hence the name trxcon (transceiver connection).



The transceiver is a separate program that performs low-level GSM physical layer tasks, such as time-frequency synchronization with the network, signal detection and demodulation, modulation and transmission of the outgoing signal. From ready-made solutions, there are two suitable projects: OsmoTRX and GR-GSM. The first is an improved modification of the transceiver from the OpenBTS project, and is now being used by Osmocom projects to launch the base station; the second provides a set of GNU Radio blocks for receiving and decoding GSM signals.

Despite the completeness of the implementation and support for the transmission of the signal "out of the box", OsmoTRX can hardly please the developer with the purity and readability of the source code - an explosive mixture of C and C ++! For example, changing a relatively small section of code may require exploring the entire hierarchy of classes, while GR-GSM provides modularity and freedom of modifications that are incomparable to OsmoTRX. Nevertheless, OsmoTRX still has a number of advantages, the most important of which are performance, low requirements for system resources and relatively smaller size of executable code, as well as its dependencies. All this makes the project quite friendly for embedding in systems with limited resources, against the background of which GNU Radio looks like a huge and voracious monster. Initially, all development was focused on OsmoTRX, but the final choice was made in favor of using the second project as a transceiver.

To ensure backward compatibility, the TRX interface was implemented in the trxcon binding application, which is also used in the OsmoTRX, OsmoBTS and OpenBTS projects. This interface for each connection involves the use of three UDP sockets, each of which has its own specific task. One of these is the CTRL interface, which allows you to control the transceiver (tuning the frequency, gain, etc.). The other is called DATA, and according to the name it provides for the exchange of information that needs to be transmitted (Uplink) or which has already been accepted (Downlink). The latter, CLCK, is used to transmit time stamps from the transceiver.



For GR-GSM, a new grgsm_trx application was implemented, the task of which is to initialize the basic set of blocks (flow-graph), as well as to provide a TRX interface for an external control application, in our case, trxcon. The flow-graph itself initially consisted only of blocks for receiving, i.e. detection and demodulation of the smallest pieces of information of the physical interface GSM - bursts. Each burst at the output of the demodulator is a bit sequence consisting mainly of a payload and a midamble, which allows the receiver to synchronize with the transmitter, but, unlike the preamble, is in the middle.



At this stage of project development, high-level applications, such as ccch_scan, could already tune the SDR to a specific frequency, start the synchronization process with the base station, and demodulate the received signal. However, with the first successes, the first difficulties appeared. Since most of the physical layer implementation in OsmocomBB was previously "relied" on the phone's DSP, encoding and decoding of packets according to the GSM 05.03 specification was not implemented separately - it was executed by a proprietary code.

As a result, the newly implemented transceiver transmits bit portions of information to the upper layers of the implementation, i.e. bursts, and the current implementation of the upper layers is waiting for byte LAPDm packets from the physical layer (basically, 23 bytes each). Moreover, the operation of the transceiver implies accurate time synchronization (TDMA - Time Division Multiple Access) with the base station, while high-level applications do not even “suspect” this and transmit outgoing packets when they need it.

To eliminate the resulting “failure” in the implementation, a TDMA scheduler was implemented, which receives LAPDm packets from high-level applications, encodes them into bursts and transmits them to the transceiver, determining the time of their transmission using frame numbers and timeslot, and also brings together the bursts coming from transceiver, decodes them and sends to the upper layers. Under GSM 05.03, encoding and decoding means creating noise-tolerant bit sequences (by adding redundant information), as well as restoring LAPDm packets from received noisy sequences using the Viterbi algorithm, respectively.



It sounds confusing, but a similar process of encoding / decoding LAPDm packets takes place both on the mobile phone side and on the base station side. Fortunately, we have at our disposal an open source, open source implementation - OsmoBTS (Osmocom Base Transceiver Station). All code of this project related to GSM 05.03 has been revised, documented and transferred to the main library of the Osmocom project - libosmocore, as a subsidiary library of libosmocoding. Now, thanks to this, many projects, including OsmocomBB, GR-GSM, OsmoBTS and others, can use the general implementation without duplicating the code. TDMA-scheduler itself was implemented by analogy with OsmoBTS, but taking into account the peculiarities of the mobile phone.

After that, the reception still earned! But the most important opportunity, which is simply necessary for the operation of a mobile phone, was still not enough - the ability to transfer data. The problem is that initially there were no blocks in GR-GSM that would allow modulating and transmitting a signal. And fortunately, the author of the project, Piotr Krysik, supported the idea of ​​their implementation, with the result that further work on the project continued along with it.

In order not to waste time while there was no data transmission opportunity and work was underway on its implementation, a temporary, but as it turned out later, a very useful solution was developed - a set of tools for transceiver emulation, i.e. virtual Um interface. Since OsmocomBB, like OsmoBTS, now supports the TRX interface, both projects can be easily interconnected: each Downlink burst from the OsmoBTS side is sent to the application trxcon, and each Uplink burst from the OsmocomBB side is transmitted to OsmoBTS. A simple application written in Python and called FakeTRX allowed to run a virtual GSM network without any equipment!



Thanks to this set of tools, a rather large number of bugs were found and fixed in the implementation of the TDMA scheduler, and support was provided for dedicated channels, such as SDCCH and TCH. The first type of logical channels in GSM is mainly used to send SMS, USSD requests and (sometimes) establish voice calls. And the second - directly for voice transmission during a call. In addition, based on the GAPK (GSM Audio Packet Knife) project, basic support was provided for recording and encoding, as well as decoding and playback of sound in OsmocomBB, since before this task was also performed by the DSP phone.



Meanwhile, Piotr Krysik has developed and successfully implemented all the missing blocks necessary for signal transmission. Since GSM uses GMSK (Gaussian Minimum Shift Keying) modulation, it used the already existing part of the GNU Radio unit - GMSK Modulator. However, the main problem was to ensure synchronization with the base station. Each transmitted burst must be transmitted in time, according to the allowed time period of the base station, called the timeslot. Not earlier and not later, albeit with a small error, which is compensated by the protective periods in the TDMA system. The situation was complicated by the lack of an accurate master oscillator for most SDR devices, with the result that the whole system, as the hams say, “floats on time”.



However, a solution to this problem was still found, and it consists in using hardware time (hardware clock) of SDR devices, such as USRP, on the basis of which each received burst receives a “stamp” of the current hardware time. By comparing these stamps and the current frame number decoded from the SCH burst, you can make corrections and assign the exact moment of transmission of outgoing pieces of information. The only problem is that the GNU Radio standard blocks, designed to interact with SDR, do not support time stamps, so they had to be replaced with UHD Source and Sink, limiting themselves to supporting USRP devices.



As a result, when the transceiver was ready for operation, it was time to go beyond the virtual Um interface. But, as they say, the first pancake is lumpy, so the first attempt to “put it all together” and launch the project on real equipment certainly failed. The feature of the time division technology in GSM was missed: the countdown for the signal transmitted by the phone, i.e. Uplink, specially slowed down relative to the received, i.e. Downlink, three timeslots, which gives phones with a half-duplex communication module the necessary time margin for frequency tuning. After a small correction, the project still earned! For the first time, with the help of OsmocomBB and SDR, we were able to send an SMS message and make the first voice call.

results

As a result of this work, we managed to create a kind of bridge between OsmocomBB and SDR transceivers working through the UHD (Universal Hardware Driver) driver. The basic components of the GSM physical layer, which are necessary for the operation of high-level applications such as ccch_scan, cbch_scan and mobile, were implemented. All developments of the project were published in the public domain as part of the main repository OsmocomBB.

Now, using SDR as a hardware platform for OsmocomBB, it becomes possible to launch a completely transparent GSM protocol stack, without proprietary components with closed source code, such as Calypso DSP phones, and at the same time debugging and modifying each specific implementation element "on the fly". In addition, new horizons are opening up for developers and researchers, for example:

• launching the network and telephone in other frequency bands (for example, 2.4 GHz);
• integration of alternative audio codecs (for example, Speex or Opus);
• implementation of the GPRS / EGPRS stack.

The above-mentioned tools for creating a virtual Um-interface are also published in the project repository and can be useful both for experienced developers, for example, to simulate the required levels of load on various components of the cellular network infrastructure and test their stability, as well as novice users who can begin to learn GSM on practice without the need to seek and acquire various equipment for this.

However, the current implementation of the new hardware platform for OsmocomBB is still not without certain limitations, most of which come from the SDR technology itself. For example, most of the available SDR cards, such as USRP, UmTRX, LimeSDR, etc., have a relatively low transmit power when compared with the maximum transmit power of regular phones. Another “gap” in the implementation is the lack of support for Frequency Hopping technology, which involves the use of several base stations at different frequencies by the subscriber, which reduces the level of interference and complicates signal interception. It can be found in the networks of most modern operators, in addition, GSM specifications describe support for this technology as mandatory for each phone. And if the problem with the signal power can be solved with amplifiers or by limiting the use of a laboratory base station, then the implementation of support for Frequency Hopping requires much more effort.

Among the plans for the further development of the project:

• implementation of support for physical (non-virtual) SIM-cards;
• expanding the list of supported SDR devices;
• implementation of CSD (Circuit Switched Data) support;
• implementation of an embedded transceiver based on OsmoTRX;
• implementation of GPRS / EDGE support.

The project was also presented at the 34th annual Chaos Computer Club congress:

Instead of conclusion

And finally, a few tips on how to run the results of the work done on your SDR. To begin with, we suggest experimenting with a virtual Um interface using the TRX Toolkit developed by us.

This will require not only OsmocomBB, but also the entire set of Osmocom’s central network infrastructure components: either OsmoNiTB (Network in The Box), or all components separately, including BTS, BSC, MSC, MGW, HLR, etc. Instructions for building source codes can be found on the project website or use ready-made packages for Debian, Ubuntu or OpenSUSE distributions.

To test the implementation with its own network, any available implementation of the GSM network stack, for example, Osmocom, OpenBTS or YateBTS, is suitable. Running your network requires a separate SDR device, or a commercial base station, for example, nanoBTS. Testing a project in real-life operator networks is strongly discouraged, in view of the limitations described above and possible flaws.

To build the transceiver, you will need to install GNU Radio and build a separate branch of the GR-GSM project from the source codes. Details of the assembly and use of the transceiver can also be found on the Osmocom project website .

Successes!