How to assemble a GSM phone based on SDR

It's no secret that in smartphones already familiar to most of us, in addition to the main processor, there is a separate communication module, thanks to which the smartphone is still a telephone. Regardless of the main operating system, whether it be Android or iOS, this module most often runs under the proprietary closed-source operating system and takes care of all the work associated with voice calls, SMS messages and mobile Internet.

Unlike proprietary software, open source projects always receive more attention from security researchers. The ability to look “under the hood” and find out how one or another component of the program works allows you to not only find and fix all kinds of errors, but also to make sure that there are no so-called “bookmarks” in the code. In addition, open source allows beginners to learn from more experienced ones, using the results of their work as a pillar.

Introduction to the OsmocomBB Project

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

Over time, Osmocom went beyond the scope of one project, and today it unites dozens of subsidiary projects, one of which is OsmocomBB - a free implementation of the GSM stack for open-source mobile phones. 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 develop now.

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

With the help of OsmocomBB, you can evaluate the security of a particular GSM standard network, and also 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 caller IDs change? What is the likelihood that a voice call or SMS message will be intercepted or, for example, tampered with by an attacker? You can quickly find the answer to all these questions and many others using OsmocomBB, and this is just one example of the possible ways to use it. Among the atypical examples can be identified: the launch of a small GSM base station, the study of SIM-card security and traffic sniffing.

The main hardware platform of OsmocomBB, similar to the Aircrack-ng project and network cards, are mobile phones based on the Calypso chipset, mainly Motorola C1XX. The decision to use phones was made at the initial stage of project development, mainly in favor of speed of implementation, since the design and production of new equipment could take a long time. In addition, back then there were already free parts of the source code and specifications of the Calypso chipset, which facilitated reverse engineering of the firmware and all further development.



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

Wind of Change - New Hardware Platform

The software part of the project consists of many separate applications, each of which has its own specific purpose. Some applications work directly on a 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 the headset jack. In other words, the TRS-connector (micro-jack, 2.5 mm) can be used not only for sound transmission, but also for data! A similar technology is used in modern smartphones, allowing you to connect headphones with buttons, a monopod for selfie and other accessories.

The absence of other interfaces, such as USB, and the need to use a serial port also impose certain restrictions, the most significant of which is the data transfer speed. For example, the ability to sniff and launch the base station is partially limited precisely because of the low interface bandwidth. Moreover, it is quite difficult to find a ready-made cable for connecting the phone to USB, and in most cases it is necessary to do it yourself, 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 either software or hardware, and would also be accessible to everyone, both in terms of production and in terms of price. And the technology SDR (Software Defined Radio), in connection with 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 communication standard. Thanks to this, the technology has become widespread both among radio amateurs and among manufacturers of commercial equipment. Already today, SDR is actively used in mobile communications, namely for the deployment of networks of GSM, UMTS and LTE standards.

The very idea of ​​developing and launching a GSM mobile phone, implemented by the OsmocomBB project, based on SDR is not new. This direction 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, has stopped at the Proof-of-Concept level . But we nevertheless decided to resume work on this area, setting ourselves the task of implementing support for the 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 that we encountered and how to solve them. As a conclusion, the results that have been achieved, the limitations of the current implementation, ideas for further development, as well as a small tip that describes the procedure for launching OsmocomBB on the SDR will be provided.

Project history

As mentioned earlier, OsmocomBB provides two types of applications: some work on the computer side, others are downloaded to the phone as part of an alternative firmware. And the interaction between them is implemented by the small osmocon program (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), response (CONF) and notification (IND).

It was decided to preserve 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 the transceiver - a separate application that manages the SDR. This is where the name trxcon (transceiver connection) comes from.



The transceiver is a separate program that performs low-level tasks of the GSM physical layer, 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 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 the support of signal transmission "out of the box", OsmoTRX can hardly please the developer with the cleanliness and readability of the source code - an explosive mixture of C and C ++! For example, changing a relatively small section of code may require studying the entire class hierarchy, while GR-GSM provides modularity and freedom of modification incomparable with OsmoTRX. Nevertheless, OsmoTRX still has a number of advantages, the most important of which are performance, low system resource requirements and the relatively smaller size of the executable code, as well as its dependencies. All this makes the project friendly enough to integrate into systems with limited resources, against which GNU Radio looks like a huge and voracious monster. Initially, the entire development was focused specifically on OsmoTRX,

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



For GR-GSM, a new grgsm_trx application was implemented, the task of which is to initialize a basic set of blocks (flow-graph), as well as 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, the smallest pieces of information of the physical GSM interface - bursts. Each burst at the output of the demodulator is a bit sequence consisting mainly of payload and midamble, which allows the receiver to synchronize with the transmitter, but unlike the preamble, it is in the middle.



At this stage of the project development, high-level applications such as ccch_scan could already set the SDR to a certain frequency, start the synchronization process with the base station and demodulate the received signal. However, along with the first successes, the first difficulties appeared. Since most of the implementation of the physical layer in OsmocomBB previously "relied" on the telephone 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 transfers bit portions of information to the upper layers of the implementation, i.e. bursts, and the current implementation of the upper layers expects 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” it and transmit outgoing packets when they need it.

To eliminate the resulting “failure”, the TDMA scheduler was implemented in the implementation, which receives LAPDm packets from high-level applications, encodes them in bursts and transmits them to the transceiver, determining the time of their transmission using frame and time slot numbers, and also collects the bursts coming from transceiver, decodes them and sends them to the upper layers. Encoding and decoding according to GSM 05.03 means the creation of error-resistant bit sequences (by adding redundant information), as well as the restoration of 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 side of the mobile phone and on the side of the base station. Fortunately, our free open source implementation, OsmoBTS (Osmocom Base Transceiver Station), was at our disposal. All the code of this project related to GSM 05.03 was redesigned, documented and transferred to the main library of the Osmocom project - libosmocore, as a child of the libosmocoding library. Now, thanks to this, many projects, including OsmocomBB, GR-GSM, OsmoBTS, and others, can use the general implementation without code duplication. The TDMA scheduler itself was implemented by analogy with OsmoBTS, but taking into account the features of the mobile phone.

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

In order not to waste time in vain while there was no possibility of data transfer and work was underway on its implementation, a temporary but, as it turned out later, very useful solution was developed - a set of tools for emulating the transceiver, 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 should be transmitted to the trxcon application, and each Uplink burst from the OsmocomBB side should be transferred 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 in the implementation of the TDMA scheduler were later found and fixed, and support for dedicated channels, such as SDCCH and TCH, was also implemented. The first type of logical channels in GSM is mainly used for sending SMS, USSD requests and (sometimes) establishing voice calls. And the second - directly for voice transmission during a call. In addition, on the basis of the GAPK (GSM Audio Packet Knife) project, basic support for recording and encoding, as well as decoding and playing sound in OsmocomBB was implemented, since before that this task was also performed by the DSP of the phone.



Meanwhile, Piotr Krysik has developed and successfully implemented all the missing blocks needed for signal transmission. Since GSM uses GMSK (Gaussian Minimum Shift Keying) modulation, it used the existing GMSK Modulator block, which is part of GNU Radio. However, the main problem was to ensure synchronization with the base station. Each burst transmitted must be transmitted on time, according to the allowed time period allocated by the base station called the time slot. Not earlier and not later, although taking into account 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, as a result of which the whole system, as radio amateurs say, “floats on time”.



However, a solution to this problem was nevertheless found, and it consists in the use of hardware time (hardware clock) 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 SCH burst, you can perform the correction and assign the exact moment of transmission of outgoing pieces of information. The only problem is that the GNU Radio standard units, designed for interacting with SDR, do not support time stamps, so they had to be replaced by UHD Source and Sink, limiting themselves to support for devices of the USRP family.



As a result, when the transceiver was ready for work, it was time to go beyond the scope of the virtual Um interface. But, as they say, the first pancake is lumpy, so the first attempt to "put everything together" and launch the project on real equipment, of course, failed. The feature of the technology of time division in GSM was missed: the countdown for the signal transmitted by the telephone, i.e. Uplink, specially slowed down relative to the accepted, i.e. Downlink, for three timeslots, which gives telephones with a half-duplex communication module the necessary margin of time for frequency tuning. After a small correction, the project still worked! For the first time, using OsmocomBB and SDR, it was possible to send an SMS message and make the first voice call.

results

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

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 DSP phones based on the Calypso chipset, and at the same time with the ability to debug and modify each specific implementation element "on the fly". In addition, developers and researchers are opening new horizons, for example:

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

The aforementioned tools for creating a virtual Um interface are also published in the project repository and can be useful for experienced developers, for example, to simulate the necessary load levels on various components of the cellular network infrastructure and test their stability, as well as for novice users who can start learning GSM on practice without the need to search and purchase various equipment for this.

However, the current implementation of the new hardware platform for OsmocomBB is still not without certain restrictions, most of which come from the SDR technology itself. For example, most of the available SDR boards, such as USRP, UmTRX, LimeSDR, etc., have a relatively low transmit power when compared to the maximum transmit power of conventional telephones. Another “gap” in implementation is the lack of support for Frequency Hopping technology, which involves the use by a subscriber of several base stations at different frequencies at once, which allows to reduce the level of interference and complicate signal interception. It can be found in the networks of most modern operators, in addition, GSM specifications describe the support of this technology as a must for every phone.

Among the plans for further development of the project:

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

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

Instead of a conclusion

And finally, some tips on how to run the results of the work done on your SDR. First, we suggest experimenting with a virtual Um interface using the TRX Toolkit that we developed .

This will require not only OsmocomBB, but also the entire set of components of the central network infrastructure from Osmocom: either OsmoNiTB (Network in The Box), or all components individually, 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 from your own network, any available implementation of the GSM network stack, for example, Osmocom, OpenBTS or YateBTS, is suitable. Starting your network requires a separate SDR device, or a commercial base station, for example, nanoBTS. Testing the project in real networks of operators is strongly discouraged, due to the limitations described above and possible shortcomings.

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 .

Good luck!