Introducing OsmocomBB: 0x03 Software

Hello again! It's time to talk about building software for working with OsmocomBB. At this stage, beginning researchers may have difficulty, so I will try to sort it all out. In this part I will talk about the structure of the project, the principles of interaction between the phone and the computer, and also describe in detail the compilation process. I recommend arming with some Linux distribution, because the server part of the project was developed specifically for this family of operating systems. I also advise you to refrain from using virtual machines, as there may be problems with running applications on the phone due to time delays.

Navigation

• 0x01 Introduction
• 0x02 Hardware
• 0x03 Software

Basics of the basics

The GSM protocol stack, which regulates the processes of interaction between mobile phones and base stations, can be divided into 3 logical levels:

• Layer 1: Physical level. Local protocols describe the principles of interaction of devices in the radio. Two technologies of multiple access are used to ensure simultaneous interaction between the network and several mobile devices in GSM networks: FDMA (Frequency-Division Multiple Access) and TDMA (Time-Division Multiple Access). FDMA implies splitting the available frequency range into channels (ARFCN), each of which allows you to transfer data from subscribers to the network (uplink) and from the network to subscribers (downlink). TDMA involves multiplexing a physical channel with time division, that is, each device is provided with the ability to receive and transmit data at certain points in time. According to TDMA, the physical channel (ARFCN) is divided into several logical channels, for example, PCH (Paging channel), on which the base station notifies the phone of an incoming call, or BCCH (Broadcast Control channel), used to identify the base station with mobile phones. And so on...
• Layer 2: The link layer, the main tasks of which are: establishing, maintaining and breaking connections between network devices; control of data flows, error detection, and third level data transit. At this level, the LAPD and LAPDm protocols work, multiple connections are provided, as well as the functionality of the logical channels BCCH, PCH, AGCH and DCCH.
• Layer 3: Network layer, divided into three sublevels:
  
  • Radio Resource (RR) is a sublayer responsible for the creation and release of logical channels between devices;
  • Mobility Management (MM) —a sublayer that authenticates users and also tracks the movement of subscribers between the coverage areas (cells) of different base stations;
  • Call Control (CC) - sublevel responsible for phone calls.
  
  

A detailed description of this topic can be found in Wikipedia . Most of all, we are interested in the distribution of roles between the telephone and the computer:

')
The physical level works on the phone, the other two are implemented on the computer side. As mentioned in the previous article, the phone and computer interact through the phone’s UART interface.

OsmocomBB Review

Let's start with the fact that OsmocomBB is developed based on the Git version control system, and its source codes are available on the official website git.osmocom.org . Most project features, such as RSSI, an interface for receiving / making voice calls and exchanging SMS messages, are available in the main branch of the project (master). However, the most interesting features are available in the form of branches of the repository - branches (branch):

• luca / catcher

  Perhaps you've ever heard of the IMSI-Catcher . Most often, IMSI-Catcher implies a device masquerading as a real base station for the purpose of collecting IMSI (international mobile subscriber ID) of the nearest subscribers (which, for example, allows tracking their location). It is more correct to assume that IMSI-Catching is only one of the capabilities of fake base stations (FakeBTS), the principle of which is quite simple. IMSI and IMEI subscriber codes are transmitted to the base station only at the moment of its connection, then the subscriber is assigned a temporary TMSI identifier, on the basis of which their further interaction takes place. TMSI, unlike IMSI, is not permanent and changes when connected to other base stations. To de-anonymize the subscriber, the attacker launches his base station (for example, based on USRP), the signal power of which exceeds the power of the real base stations. Due to this, the subscriber's phone connects to the station with a more powerful signal, and then transmits its IMSI and IMEI codes. Sometimes, FakeBTS can act as an intermediary between a subscriber and a real base station, allowing an attacker to perform various MiTM-attacks, as well as spend the subscriber's money. No matter how frightening it may sound, the presence of such "miracles" on the air can be detected, for example, using projects: FakeBTS or Android IMSI-Catcher Detector . The author of this branch also integrated into the project the ability to detect such activity. Read more about this here .

• jolly / emi

  It integrates an EMI application designed to conduct stress tests of wireless equipment. Read more on the project site wiki / emi-firmware . Also, do not forget that broadcasting on GSM frequencies in many countries, including the Russian Federation, requires a license. If the license is all difficult, you can use the Faraday cage .

• sylvain / burst_ind

  The main focus of this thread is on GSM traffic sniffing, which I will discuss in more detail in one of the following articles.

• jolly / menu

  This branch will allow you to write applications to the flash-memory of the phone. What for? For example, if you need autonomy when using the phone in any portable projects. It is possible to flash the boot menu, which using the graphical interface will provide the choice of the application to download. The firmware process is described on the wiki / flashing_new page.

• luca / libosmosim

  This branch will allow you to use an OsmocomBB-compatible phone to interact with the SIM card. After the project is built in the src / host / layer23 / src / libosmosim / .libs folder, the libosmosim.so library will be available, on the basis of which the SIMTester project is running . With it, you can check the cryptographic strength of SIM-cards, as well as the security of applications installed on them.

• sylvain / testing

  Here you can find the TRX application, which turns an OsmocomBB-compatible phone into a small base station. I will tell you more about this later, but for now you can read a small HOWTO wiki / Software / Transceiver and watch a presentation on the phone .

The remaining branches of the repository mainly contain corrections and innovations of other developers of the project, which sometimes fall into the master branch. OsmocomBB has a lot of development vectors, so any interested developer can join the project development.

Build project

Let's determine the location of files and folders. Based on my experience, I recommend creating the / opt / osmocom folder - in it we will store libraries and cross-compiler. And to build a project, use, for example, a home folder, or another place for which you do not need administrator rights. As a result of the project compilation, you will receive applications (firmware) running on the phone, and programs for interacting with them from the computer (server) side. The build process is described using the example of Ubuntu 14.04, so the command syntax may differ slightly on other distributions. So what do we need?

• libosmocore is the main library of the project, details of which can be found in the wiki / libosmocore section . Despite the fact that a part of its source code is supplied when cloning the OsmocomBB repository, it should be collected separately;
• Cross-compiler - OsmocomBB-compatible phones are mainly built on the basis of the ARM platform, so you need a cross-compiler (toolchain) to build the firmware. The developers recommend using exactly the version of the cross-compiler, which is listed on the site, as when using third-party firmware can work unstable. The cross-compiler build is described in the wiki / GnuArmToolchain section ; however, when compiling on modern systems, an error often occurs, so I created a fork with a fixed installer.

To compile the source code, we need autoconf, automake, libtool, pkg-config, make and GCC. At the same time create the / opt / osmocom directory:

#      ,     sudo. $ sudo su #  . $ apt get update $ apt-get install libtool shtool automake autoconf git-core pkg-config make gcc #      -. $ mkdir /opt/osmocom 

In the process of assembling source codes, errors often occur. More often than not, there are not enough libraries. On baseband-devel.722152.n3.nabble.com you can find ways to solve most of them - use the search. If the error occurs during the configuration process (autoreconf or ./configure commands), try to resolve it and reconfigure it.

Let's start with libosmocore:

 $ cd /opt/osmocom $ git clone git://git.osmocom.org/libosmocore.git $ cd libosmocore $ autoreconf -i #  pcsclite    libosmocore. $ apt-get install libpcsclite-dev $ ./configure $ make $ make install 

Go ahead. Building a cross-compiler is the main source of errors and takes most of the time. In most cases, the error "@itemx must follow @item" occurs. The fact is that the assembly requires an older version of TexInfo. You can run downgrade manually, or you can use my fixed version of the installer:

 $ cd /opt/osmocom #  -. $ apt-get install build-essential libgmp3-dev libmpfr-dev libx11-6 libx11-dev flex bison libncurses5 libncurses5-dbg libncurses5-dev libncursesw5 libncursesw5-dbg libncursesw5-dev zlibc zlib1g-dev libmpfr4 libmpc-dev texinfo #   . $ git clone https://github.com/axilirator/gnu-arm-installer.git gnu-arm-toolchain $ cd gnu-arm-toolchain #   . $ ./download.sh #    $ ./build.sh 

UPD: Despite the fact that the project site has an updated version of the cross-compiler based on GCC 4.8.2, Binutils 2.21.1 and Newlib 1.19, I recommend using its previous version available in my repository. As a result of the compilation of the code of such forks of the project as DrWhax / osmocom-bb-raw and offlinehacker / osmocombb , the layer1 firmware hangs when trying to synchronize with the base station. In the firmware of the official project repository compiled with the new version of the cross-compiler, similar problems are not observed.

If errors occur, Google will always come to the rescue. Additional libraries may be required. It all depends on your distribution. In any case, you need to achieve a successful build and the message “Build complete!”, After which you need to add the path to the cross-compiler executable files to the PATH environment variable.

 #     . $ su <  > $ cd ~ # ,   /opt/osmocom/gnu-arm-toolchain/install/bin/    #   -, ,    ls. #   : $ gedit .bashrc #      : # export PATH=$PATH:/opt/osmocom/gnu-arm-toolchain/install/bin/ #   . $ source .bashrc #    : $ arm-elf-gcc -v #        . #         bin      PATH. 

Congratulations! Now your system is ready to build OsmocomBB. It's time to build the master branch.

 #      osmocombb: $ mkdir ~/osmocombb $ cd ~/osmocombb #  : $ git clone git://git.osmocom.org/osmocom-bb.git master # : $ cd master/src $ make 

If the error "no such instruction: `eor %edx,%ecx,%ecx,ror'" occurs, then your cross-compiler executable files are not available - check everything again. Remember this sequence of actions - it is used every time you build a new branch. To clone a specific repository branch, use the -b flag, for example:

 #    sylvain/burst_ind: $ cd ~/osmocombb $ git clone git://git.osmocom.org/osmocom-bb.git -b sylvain/burst_ind burst_ind 

Run Hello, world!

The most awaited moment. First you need to clarify the platform of your phone (on the wiki / Hardware / Phones page), for example, for the C123, C115 and C118 - this is Compal E88. The firmware for each platform is located in the same directory under the path src / target / firmware / board /. So, turn off the phone, connect the cable to the computer, then:

 #    : $ cd ~/osmocombb/master/src/ #  ,      E88: $ host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0 target/firmware/board/compal_e88/hello_world.compalram.bin #      . #   ,      . 

If something goes wrong while loading, the bootloader may hang. Just remove the battery for a couple of seconds and reinsert it.

What happens and how does it work?

We will deal with everything in order. When launched, the osmocon program blocks the serial port and waits for the bootloader messages, sending special beacon messages. The built-in phone loader when you press the power button sends to the serial port a request to download the firmware (ACK). If nobody answers him, he simply sends the message "@ftmtoolerror". In our case, osmocon accepts the request (as indicated by the line “Received PROMPT1 from phone responding with CMD”) and responds with a special message (file_size = 25180, hdr_len = 4, dnload_len = 25187). Then the phone loader either agrees to load the firmware (Received PROMPT2 from the phone, starting download), or reports an error. As soon as the firmware is loaded (handle_write (): finished) into RAM, the loader notifies us again (Received DOWNLOAD ACK from phone, your code is running now!) And provides power to the board (battery_compal_e88_init: starting up). Your phone shows the well-known words “Hello, world!”, And the code already running on it is written to the console. Cool!

FTMTOOL error

This error in most cases occurs due to cable and / or converter problems, when osmocon cannot communicate with the bootloader. Make sure that the GND, RxD and TxD pins are properly connected, and the chipset name of your USB-TTL converter is included in the list of recommended ones . Try pressing the power button again after a few seconds. Also, for some phone models and converters, the value of the -m key of the osmocon program should be specified without ending xor, for example, -m c123 instead of -m c123xor .

Does it violate the law?

The application launched by us does not interact with the cellular network, but before launching other applications, I would like to dwell on the issue of legality. In some countries, using third-party software to interact with cellular networks is illegal. The conditions on which cellular services are provided may vary among different operators, and, more often than not, do not allow the use of non-certified software. Therefore, by default, the ability to transfer data to the network is disabled. If you know what you are doing and your actions do not violate existing laws, you can enable data transfer before building the project in the src / target / firmware / Makefile file by uncommenting the line "CFLAGS + = -DCONFIG_TX_ENABLE". The project authors have devoted a small wiki / LegalAspects page to this issue.

The structure of the project, the process of downloading applications (firmware)

There are three folders in the root folder: doc, include, and src. There is hardly anything useful in doc or include. We are most interested in the src folder, which contains the following directories:

• host - the source code of the programs executed on the server side;
• target - the source code of the firmware, as well as libraries for their compilation;
• target_dsp - tools for working with executable DSP code and plugins for IDA;
• wireshark - patches for old versions of Wireshark;
• shared - contains a copy of the libosmocore library used to build the firmware.

More information about the structure of the project can be found in the file README.development. The source codes of the OsmocomBB applications are stored in the src / target / firmware / apps folder, and their compiled versions are available separately for each platform in the / src / target / firmware / board folder. You can find two versions of the compiled application (firmware): compalram and highram. The first option is to download using the standard phone loader. Some “voluminous” applications, for example, RSSI, cannot be loaded with the standard loader, therefore, “chain loading” is performed: first, the custom loader loader.compalram.bin is loaded, which loads firmware of the highram type. The syntax of the "download chain":

 #       : $ host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0 -c target/firmware/board/compal_e88/rssi.highram.bin target/firmware/board/compal_e88/chainload.compalram.bin #      chainload   osmocon,     . #    -c: $ host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0 -c target/firmware/board/compal_e88/rssi.highram.bin 

As soon as you need to shut down the application, stop the osmocon process, and then press and hold the shutdown button for two seconds.

What is interesting here?

A few words about the applications available in the various branches of the project. A more detailed review will be devoted to the following article, but for now you can read the official wiki / Applications documentation.

Interaction with equipment

• osmocon - downloads firmware into the phone's RAM, and also creates an interface for exchanging information between the firmware and other server programs. The -m parameter allows you to specify the data exchange protocol for various phone models, and the -c option performs a chainloading of heavyweight applications that the standard phone loader cannot load.
• osmoload - allows you to read and write the contents of the flash-memory of the phone. Used when flashing applications. Read more on the wiki / flashing page.
• calypso_pll, rita_pll - used to get information about the chipset and transceiver of the phone.

Applications 2 and 3 levels of the GSM protocol stack

• mobile is an application that implements the functionality of a regular phone, expanded with additional functionality for interaction with the GSM network. Read more on the wiki / mobile page.
• cell_log - allows you to scan the frequency range, find the nearest base station, as well as receive information about them (received signal power, MNC, MCC and other system information). Allows you to synchronize with the base station and receive information transmitted on the BCCH channel.
• ccch_scan, bcch_scan - allow you to synchronize with the base station and receive its service information.
• cbch_sniff - allows you to record network service information to a file.
• gsmmap - using cell_log output, generates a KML file for Google Maps, visualizing the location of base stations on the map.

Applications running on the phone

• loader.bin - loader, written by the developers of the project. It is used for reading and writing flash-memory, as well as during “chain loading”.
• compal_dsp_dump.bin - allows you to get a dump of the contents of the DSP-processor.
• menu.bin - provides the ability to select applications to download from flash-memory.
• rssi.bin is an application that allows you to track the received signal power on various channels of the cellular network.
• emi.bin is an application for stress testing wireless equipment.
• layer1.bin - used to interact with the cellular network and SIM-card.
• trx.bin - turns your phone into a Transceiver for running OpenBTS or OsmoBTS.

The end?

This article has come to an end. I hope this material will be useful as a novice researcher of mobile networks, and a specialist in this field. In the next article I will talk more about applications compiled by us and their practical application, but for now, by tradition, leave a list of interesting articles, presentations and speeches:

• GSM cell phone network review
• GSM Sniffing (Sylvain Munaut, Karsten Nohl)
• GSM Sniffing (Joshua Pereyda)
• GPRS Intercept: Wardriving your country (Karsten Nohl, Luca Melette)
• Blackhat 2010: Attacking Phone Privacy (Karsten Nohl)
• Receiving device coordinates in GSM-protocol (Anatoly Alizar)

Successes to all!

Navigation

• 0x01 Introduction
• 0x02 Hardware
• 0x03 Software