How to assemble a GSM phone based on SDR
It's not a secret that in the smartphones already common to most of us except for the main processor there is a separate communication module, thanks to which the smartphone is still a phone. Regardless of the underlying operating system, whether Android or iOS, this module most often runs under a proprietary closed-source operating system, and takes care of all the work related to 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 not only to find and fix all possible errors, but also to make sure that there are no so-called "bookmarks" in the code. In addition, open source code allows novice developers to learn from the example of the more experienced, using the results of their work as a support. is known. 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 direction, having set ourselves the task of implementing a new hardware platform for OsmocomBB based on SDR, identical to the Calypso chipset in terms of backwards compatibility, and more open to modifications at the same time.
In the following part of this article, we will briefly describe the process of developing a new platform, as well as the problems that we have encountered, and the ways to solve them. As a conclusion, we will provide the results that we managed to achieve, limitations on the current implementation, ideas for further development, and a small clue that describes the procedure for launching OsmocomBB on the SDR.
The history of the project
As mentioned earlier, OsmocomBB provides two types of applications: some work on the side of the computer, others are downloaded to the phone as part of an alternative firmware. And the interaction between them is realized by a small program osmocon (from the word connection), which ensures their mutual connection through the serial port. The interaction itself is carried out by means of a simple binary L1CTL protocol (GSM Layer 1 Control), where there are only three types of messages: REQ, response (CONF) and notification (IND).
The idea of such mediation was decided to preserve, like the protocol itself, in order to provide "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 tasks of the GSM physical layer, such as time-frequency synchronization with the network, detection and demodulation of the signal, modulation and transmission of the outgoing signal. Of the 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 implementation and support of signal transmission out of the box, OsmoTRX can hardly please the developer with the cleanliness and readability of the source code - a rattling 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 modifications incomparable with OsmoTRX. Nevertheless, OsmoTRX still has a number of advantages, the most important of which are performance, low system resource requirements and a relatively smaller size of executable code, as well as its dependencies. All this makes the project fairly friendly to embedding in systems with limited resources, against which GNU Radio looks like a huge and voracious monster. Initially, the entire development was focused specifically on OsmoTRX, but the final choice was made in favor of using the second project as a transceiver.
To ensure backward compatibility, the trxcon binding application implemented the TRX interface, which is also used in projects OsmoTRX, OsmoBTS and OpenBTS. 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 (tuning frequency, gain, etc.). The other one is called DATA, and according to the name it provides the exchange of information that needs to be transmitted (Uplink) or which has already been received (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 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 consisted only of blocks for reception, i.e. detection and demodulation, the smallest pieces of information of the GSM physical interface - bursts. Each burst at the demodulator output is a bit sequence consisting mainly of payload and midamble, which allows the receiver to synchronize with the transmitter, but unlike the preamble is in the middle.
At this stage of the project development, high-level applications, such as ccch_scan, could already configure the SDR for 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 also appeared. Since most of the implementation of the physical layer in OsmocomBB previously "leaned" on the DSP phone, the encoding and decoding of packets according to the GSM ??? specification was not separately realized - it was performed by the 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 waits from the physical layer for LAPDm byte packets (mostly 23 bytes each). Moreover, the operation of the transceiver implies accurate Time Division Multiple Access (TDMA) 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" in the implementation, a TDMA scheduler was implemented that accepts LAPDm packets from high-level applications, encodes them into bursts, and transmits them to the transceiver, determining the transmission time using frame and time-slot numbers, and also assembles bursts coming from transceiver, decodes them and sends them to the upper layers. By coding and decoding according to GSM 05.0? it is meant to create noise-immune bit sequences (by adding redundant information), and to restore LAPDm packets from received noisy sequences using the Viterbi algorithm, respectively.
It sounds confusing, but a similar process of encoding /decoding LAPDm-packages takes place both on the side of the mobile phone and on the side of the base station. Fortunately, at our disposal was her free implementation of the open source code - OsmoBTS (Osmocom Base Transceiver Station). All the code of this project, connected with GSM 05.0? was reworked, documented and transferred to the Osmocom project main library - libosmocore, as a child library of libosmocoding. 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 earned! But the most important feature, which is simply necessary for the operation of a mobile phone, still was 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 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 together with him.
In order not to waste time, while the possibility of data transmission was absent and work on its implementation was underway, a temporary solution was developed, but as it turned out later, a very useful solution was a set of tools for emulating the transceiver, i.e. virtual Um interface. Since OsmocomBB, like OsmoBTS, now supports TRX interface, both projects can be easily connected: each Downlink burst from OsmoBTS side is transferred to trxcon application, and every Uplink burst from OsmocomBB transmits OsmoBTS. A simple application, written in Python language and called FakeTRX, allowed to launch a virtual GSM-network without any equipment!
Thanks to this set of tools, a fairly large number of bugs in the implementation of the TDMA scheduler were later found and fixed, and dedicated channels such as SDCCH and TCH were 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 transmission voices during a call. In addition, based on the GAPK project (GSM Audio Packet Knife), basic support for recording and encoding, as well as decoding and playback of audio in OsmocomBB, was realized, since previously 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 GMSK Modulator as part of GNU Radio. However, the main problem was to provide synchronization with the base station. Each transmitted burst must be transmitted on time, according to the allowed time period, called the timeslot, allocated by the base station. Not earlier and not later, although with a small error, which is compensated by the defensive periods in the TDMA system. The situation was complicated by the lack of an accurate master oscillator in most SDR-devices, as a result of which the whole system, as the radio amateurs say, "floats on time".
However, the solution to this problem was still found, and it consists in the use of 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 cliches and the current frame number decoded from the SCH burst, correction can be made and an exact moment of transmission of outgoing portions of information can be assigned. The only problem is that the standard GNU Radio blocks intended for interaction with the SDR do not support temporary stamps, so they had to be replaced with UHD Source and Sink, limited 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 everything together" and run the project on real equipment of course failed. The peculiarity of time-division technology in GSM was missed: the time for the signal transmitted by the phone, i.e. Uplink, especially slowed down relative to the received, i.e. Downlink, for three timeslots, which gives phones with a half-duplex communication module the necessary time reserve for frequency tuning. After a small correction, the project still earned! For the first time with the help of OsmocomBB and SDR it was possible to send an SMS message and perform the first voice call.
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, necessary for high-level applications, such as ccch_scan, cbch_scan and mobile, were implemented. All the project's findings were published in the public domain as part of the OsmocomBB main 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 simultaneously 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:
start the network and the phone 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 to experienced developers, for example, for simulating the necessary load levels for various components of the cellular network infrastructure and testing their stability, and for novice users who can start learning GSM on practice without the need to seek out and acquire different 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 available SDR cards, such as USRP, UmTRX, LimeSDR, etc., have a relatively small transmit power when compared to the maximum transmit power of conventional phones. Another "gap" in the implementation is the lack of support for Frequency Hopping technology, which assumes the use of several base stations at different frequencies by the subscriber, which allows to reduce the level of interference and complicate the interception of the signal. It can be found in the networks of most modern operators, besides, the GSM specifications describe the support of this technology as mandatory for each phone. And if the problem with the signal power can be solved with the help of amplifiers or limited to the use of a laboratory base station, then the implementation of Frequency Hopping support requires much more effort.
Among the plans for further development of the project:
support for physical (non-virtual) SIM cards;
expansion of 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 the Chaos Computer Club:
Your browser does not support HTML5 video.
Instead of the conclusion
And finally, a few tips on how to run the results of the work done on its SDR. To begin with, we suggest experimenting with a virtual Um interface using the developed by us. TRX Toolkit .
This will require not only OsmocomBB, but also the entire set of central network infrastructure components from Osmocom: either OsmoNiTB (Network in The Box) or all components separately, including BTS, BSC, MSC, MGW, HLR, etc. Instructions for assembling 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. Running your network requires a separate SDR device, or commercial base station, for example, nanoBTS. Testing the project in real networks of operators 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 assemble a separate branch of the GR-GSM project from the source code. Details of the assembly and use of the transceiver can also be found on the project site Osmocom .