Dieter Spaar's blog


Dieter's Web

Projects I am participating



Other Bloggers
Harald Welte
David Burgess



Fri, 04 Dec 2020
Modern TPMS Sensors: Let's try a DoS attack

TPMS (Tire-pressure monitoring system) sensors have been researched extensively many years ago, they periodically transmit the tire pressure, temperature and a unique ID which can be misused for tracking a vehicle. But there is another aspect: modern TMPS sensors also have a receiver which is typically used to trigger the data transmission when a new TPMS sensor is presented to the vehicle ("learning procedure").

Here in Europe TPMS sensors usually transmit on the 433 MHz ISM band. The receiver operates on 125 kHz, very similar to LF RFID. A simple way to make use of the receiver is just to look for the presence of the 125 kHz carrier and then trigger data transmission. Current sensors are usually more evolved and use a modulated carrier which contains command packets and only if the correct command is received data transmission is triggered.

If you already have a receiver you can do of course more than just trigger data transmission: For example there might be support for different commands, some sensors even allow firmware updates this way.

One such command which is typically supported is switching the sensor into "Shipping" mode. Why would you need that? When the sensor is operating normally it waits for motion (there is an acceleration/shock sensor inside) and only starts periodic data transmission when the wheel is rotating. This is used to safe battery life. When the TPMS sensor is not yet mounted in the tire it should not react on motion, thatís why there is this "Shipping" mode. In this mode the sensor only wakes up every few seconds and looks if there is a 125 kHz signal, if yes it checks for a valid command, for example the command to trigger data transmission which usually also leaves "Shipping" mode and switches the sensor into normal operation.

This "Shipping" mode can be misused: If you can switch a TPMS sensor of a vehicleís wheel into "Shipping" mode the sensor will no longer transmit data and the vehicle's tire pressure control light will go on after a while. Just to make it clear: This warning light is annoying to the driver, it does not affect safety of the car because the deactivated TMPS sensor has not affected the actual tire pressure.

I have looked at a few TPMS sensors for different cars if this really works, I choose sensors for BMW and Ford cars. Please note that most certainly other car manufactures are affected too, mainly because there are only a few manufactures of TPMS sensors which deliver their sensors to various car manufactures. My choice for BMW and Ford came from the fact that I found lots of cheap, used sensor for those cars.

Also I only looked at "OEM" sensors for BMW and Ford, which means that those sensors are mounted by the car manufacturer. There are also so called "Universal" sensors which are typically mounted by tire dealers, there are some notes about them at the end of this text.

It is quite easy to build a tool for transmitting data on 125 kHz: There is this cheap EL-50448 TMPS sensor activation tool which only transmits a carrier without modulation. However the hardware can easily be modified to modulate the carrier: Most of the time OOK (On-Off Keying) is used for communication, which means that the carrier is just turned on and off. The EL-50448 uses a power driver with an unused "enable" pin to generate the carrier, you can use this "enable" pin to modulate the carrier. The data rate is slow, a frequently used rate is 3900 baud. Most of the time Manchester encoding of the data bits is used, which means that the carrier changes twice as much (7800 changes per second). This is nothing special and can be done with probably any microcontroller you prefer to use. The hardware costs for such a setup are below EUR 20, the transmission range is about 20 centimeters.

How can you find the command to switch to Shipping" mode? Brute force by trying all possible commands is only an option if the command is short. The reason is that the sensor only looks for the LF 125 kHz signal every few seconds. If the command is not longer than two bytes brute force is possible (it takes a few days), for longer commands it is impractical. Please note that you also have to find a way to detect if the command you send causes a reaction of the TPMS sensor, e.g. by monitoring the power consumption of the sensor or receiving the 433 MHz data signal (which of course only works if the command you send causes a data transmission).

Another option is looking at those TPMS tools which tire dealers and car repair workshops use to check TPMS sensors. Some of those tools might support switching a TPMS sensor into "Shipping" mode.

Those are the results I found (I won't go into the details to avoid misuse):

  • BMW: A certain sensor used in several car models from TPMS Sensor manufacturer "A" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. Also if the sensor detects a fast pressure change (e.g. by inflating the tire) the sensor leaves "Shipping" mode. The command length is four bytes so brute force is no option.
  • Ford: A certain sensor used in several car models from TPMS Sensor manufacturer "A" (the same manufacture as above for the BMW sensor) can be switched into "Shipping" mode, it is the same command as used by the BMW sensor from above. The deactivated TPMS sensor can be activated again with a different command.

    A certain sensor used in several car models from TPMS Sensor manufacturer "B" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. The command in this case is only two bytes and I tried all combinations which resulted in several more "interesting" commands, a few examples:

    • It is possible to completely turn off the TPMS sensor. In this case it will no longer react on anything, you have to break open the sensor case and apply a hardware reset or disconnect the battery to reactivate it again.
    • It is possible to switch the sensor into continuous "carrier transmit" mode on 433 MHz. In this mode the sensor will continuously transmit the 433 MHz carrier until the battery is empty or you apply a hardware reset (see above), it will not react on anything else. There are two other similar commands which transmit on the upper and lower shifted frequency (the sensor uses FSK modulation, Frequency Shift Keying, when transmitting data).

    Those examples show that it is basically possible to destroy this specific sensor by transmitting the appropriate command. Also if the sensor is in "carrier transmit" mode it probably disturbs the remote control car key fob which usually uses the same frequency as the TPMS sensor.

You have to be close to the sensor to send those LF 125 kHz signals but it only takes a few seconds to send the signal. Using a larger antenna (which is basically a coil) for the transmitter, e.g. large enough to fit in a suitcase, might extend the transmission range to more than a meter.

How can those problems be avoided? This is actually quite easy, the command to switch into "Shipping" mode should not be allowed if the measured tire pressure is above a certain limit, which means that the sensor is mounted in the tire of a vehicle. This also applies to those other commands of the sensor from manufacturer "B" which are probably some kind of factory test or developer commands. Please note that during my tests the commands I described were possible even when the measured tire pressure was in the range of a typical vehicle wheel.

I contacted the car manufactures (BMW and Ford) before I published this article, this is the experience I made:

  • BMW: The contact information for reporting security issues can be found on the BMW website. I had a phone call with the responsible person within a few days after reporting the issue. BMW already knew the problem, they found it during an internal review. Their latest TPMS sensors have fixed the issue by blocking certain commands if the tire pressure is above a certain limit.
  • Ford: I wasn't able to find a security contact on the website of Ford Germany so I contacted the person responsible for "Public Relation". He promised to look for someone who takes care of the issue I reported, after several days I got a reply that it is possible to disturb the TPMS system due to the nature of radio transmission and that this is a known problem. I wasn't able to communicate directly with the responsible person and I then replied that the reported issue is not about disturbance but a "Denial of Service" and that it is even possible to destroy a certain TPMS sensor used in Ford cars. I didn't receive any further information about the security issue, I notified them again after several weeks that I am now going to publish the issue which was acknowledged.

Some notes about those "Universal" sensors tire dealers normally use: Those sensors are "Universal" because they can be programmed for different car models. The main benefit for the tire dealer is that only a few different kind of "Universal" sensors have to be on stock, itís not necessary to have lots of different "OEM" TPMS sensors for every possible car model lying around. The programming of those "Universal" sensors most of time uses the LF 125 kHz signal to transfer the programming data to the sensor. Many of those "Universal" sensors can be reprogrammed regardless of the measured tire pressure so an obvious "Denial of Service" attack on those sensors is to simply reprogram them for a different car model.

[ /automotive | permanent link ]

Sun, 09 Sep 2018
A Pico Base Station from Ericsson

The RBS6401 is a small indoor base station from Ericsson for WCDMA or LTE. The device is about two times the size of an ip.access nanoBTS. It is based on a KeyStone I SoC from TI and runs Linux (in fact there are two KeyStone I SoCs inside, but it seems that only one of them is used, at least for WCDMA).

Compared to the other commercial base stations I have seen so far the RBS6401 makes it quite hard to get access to the operating system. It tries to setup a VPN to a Security Gateway for Autointegration into the operator's network and there is only a simple Web Interface to set the network parameters of the device.

Unfortunately I have only found the WCDMA software on the three devices I have access to. It would really be nice to use the RBS6401 with LTE, WCDMA is not that interesting (I am not aware of any Open Source RNC). If anyone has the LTE software for the RBS6401, please let me know.

[ /gsm | permanent link ]

Mon, 28 May 2018
A personal remark about security research

In the last few years I have done a lot of automotive security research, one of my findings about cars from BMW, which was the result of working on contract for the ADAC, was published in February 2015: the original German version and the translated English version.

A few days ago Tencent Keen Security Lab published their findings about BMW cars in this paper.

While in general I find it great that there is more public research in the area of automotive security, I really don't like it if previous work isn't respected. The report of Tencent Keen Security Lab does not contain any reference to previous work besides their own. I would at least have expected references to previous QNX research (QNX is the OS used in the BMW infotainment ECU) and my work when it comes to the TCB (Telematic Communication Box, the name of the BMW telematic ECU). For example regarding the TCB, the description of the communication protocol with the backend and how encrypted SMS is used, with identical encryption keys in all cars, was already contained in my report. To find out why there are no references to others work I contacted them, but I didn't receive any reply.

Could it be that they really aren't aware of previous work? If you start researching the BMW telematic ECU, you would very soon become aware of NGTP (Next Generation Telematics Protocol), the protocol used to communicate with the BMW backend. Searching on Google for "TCB" and "NGTP" will give you the link to the German article on the first place. OK, it's just the German article and you would have to open it to find the link to the English translation, which requires an additional step.

What if they don't use Google but Baidu? Searching for "TCB" and "NGTP" on Baidu gave this link on the fourth place. I can't read the page, but this seems to be the Chinese translation of the article from Heise, even the text in the diagrams is translated. Interestingly when I tried to reproduce my search from last week on Baidu today, this page no longer appears in the search results, although the page itself still exists.

So for me its looks like this: Tencent Keen Security Lab either simply doesn't give reference to previous work and follows the old Chinese tradition of "Clone and Copy" or they don't have any clue about Information Gathering, which is one the first steps when starting to research a target. In my opinion neither of the two possibilities is what you really want.

[ /automotive | permanent link ]

Mon, 12 Mar 2018
Communication on a FlexRay bus

FlexRay is an automotive bus system which is not as common as the CAN bus, but is used in several car brands, e.g. BMW, Mercedes and Audi. I won't go into the details of FlexRay, there are several good introductions elsewhere.

What is needed to read the data on a FlexRay bus, or even better, actively participate in the communication (send your own data)? Compared to the CAN bus a FlexRay bus is complicated:

  • Sending and receiving on a CAN bus is simple, similar to serial (UART) communication: You basically only need to know the bus speed and you are done.
  • For a FlexRay bus you have to know about 50 more or less important parameters which define things like the length and number of the frames in the static segment or the frames in the dynamic segment.

If you are only interested in seeing the data on the FlexRay bus, than it is actually pretty simple, knowing the communication speed (typically 10 Mbit/s) is enough. There are several oscilloscopes and logic analyzers which can decode the FlexRay protocol. Such a decoder is simple, I use a few lines of AWK script to process the exported CSV file from a cheap logic analyzer to do so (AWK just to show how simple it is).

However if you also want to send data, you need to know nearly all the parameters, otherwise you would most certainly just disturb the bus communication. There are several (expensive) FlexRay analyzers available, which can help to solve this problem.

I wanted to find out if it is also possible to get this done with a relatively cheap (around 100 EUR) development board with a FlexRay interface. While I won't go into the details (maybe this is topic for an upcoming talk), I will just present my experimental setup:

I started with two ECUs (gateway and engine ECU) from a BMW with FlexRay. Those two ECUs are enough for a properly running FlexRay bus (each of those ECUs is a so called coldstart node, you need at least two of them to get the FlexRay bus up and running). To get the development board running with this setup you could start with coarse communication parameters (maybe from measurements with an oscilloscope) and fine-tune them until you can communicate (receive and send frames) without errors. This actually worked quite well.

The next setup were several ECUs from an Audi with FlexRay: I had the gateway, ACC radar and front camera. However only the gateway is a coldstart node, so the FlexRay bus would not start with only those ECUs. I could have bought a second coldstart node ECU (either ABS or airbag), however those ECUs for this specific car are rather expensive. Additionally I wanted to see if it is possible to program the development board as a coldstart node, so I decided to go this way. The problem now is that you don't have a running FlexRay bus to get your first estimation of the communication parameters: the single coldstart node trying to start the bus will only give you a few of them (basically you only have one frame from the static segment). The communication parameters from the BMW won't help also, Audi uses something else (only the 10 Mbit/s bus speed and the 5 ms cycle time are the same). Again I skip the details, but all problems could be resolved and the development board acts as a coldstart node to get the bus running and of course can also properly communicate on the bus.

Lessons learned: You don't necessarily need expensive tools to solve a problem which seems complicated on the first look. If you are willing to spend some time, you can succeed with rather cheap equipment. The additional benefit is that you learn a lot from such an approach.

[ /automotive | permanent link ]

Mon, 22 Jan 2018
Modify the VoIP provider of a Speedport ISDN Adapter

The Speedport ISDN Adapter is a relatively cheap VoIP-to-ISDN adapter from Deutsche Telekom. The drawback is that the adapter is "locked" to Deutsche Telekom and the user interface (web interface) is disabled.

Here is how you can access the web interface. While the adapter is already powered on, you have to press both the "Register" and "Reset" button at once for more than 20 seconds. This will temporarily enable a still limited web interface, just point your browser to the IP address of your ISDN adapter. The login password is the "device password" written on the bottom side of the case.

To fully enable the web interface you have to do a bit more. I use "curl" which is available for nearly all operating systems. You have to replace "12345678" with the device password and "" with the IP address of your adapter.

curl -d "login_pwd=1&pws=12345678" ""
curl -d "password=12345678&debug_enable=1&uart_tx_eb=1" ""

Now the web interface is fully functional and you can modify the settings, e.g. disable the TR-069 interface and enter the parameters for the VoIP account of your provider. "uart_tx_eb" enables the serial console, which offers a few debug commands. However you have to open the case to get access to the serial console.

[ /misc | permanent link ]

Sun, 21 Jan 2018
More LTE Base Stations

Since running my first own LTE eNodeB in 2013, I acquired a few more. I now have one from NSN, Ericsson and Huawei. All of them are fully functional including the required Remote Radio Heads to actually transmit.

Operating an LTE eNodeB is not very complicated, these days it is even easier with software like NextEPC. The tricky part is setting up and configuring the LTE eNodeB because there is no standard to do so and every manufacturer has its own way. If you are lucky, you might get an already configured system and there is not much you have to adjust. If your system is new or the configuration has been erased, than it can get complicated, at least for the Ericsson eNodeB I have.

[ /gsm | permanent link ]

Sun, 04 Aug 2013
Tracing LTE on the phone

As a short additional note to my first experiments running an LTE eNodeB: I wanted to know how this looks on the phone. The protocol I am interested in is RRC (Radio Resource Control) for LTE (specified in TS 36.331). RRC also transports the NAS messages which are exchanged between the eNodeB and the MME.

The USB LTE Dongle I use for my experiments is based on a Qualcomm chipsets. I used Qualcomm based phones for quite a while so I already know some parts of how tracing works on them. I was able to locate the LTE messages in the traces and extend GSMTAP slightly so that it is able to handle LTE RRC messages too.

Here is how it looks in WireShark when a phone registers to the LTE cell:

The red colored lines are uplink messages (from UE to eNodeB), the blue lines are the response from the eNodeB. The trace also contains a few of the System Information messages the phone has to decode to get all the required information to communicate with the eNodeB. Otherwise you can see that the NAS messages exactly match those seen on the S1-AP interface (of course, this is expected).

[ /gsm | permanent link ]

Tue, 30 Jul 2013
Running your own LTE eNodeB

Finally I got all the required parts together for a fully functional LTE eNodeB. The eNodeB (E-UTRAN Node-B or Evolved Node-B) is the LTE equivalent of a GSM BTS or a 3G Node-B. Considering that its was only less than two years ago when I started to experiment with 3G Node-Bs, obtaining LTE equipment went faster than expected, especially considering that LTE is still in the deployment phase.

Compared to what is needed to run a 3G Node-B, an LTE eNodeB really deserves the "Evolved" in its name. All the functionally of the 3G RNC is contained in the eNodeB (e.g. all the RLC/MAC and radio functionality) and only the higher layers are exposed through the so called "S1" interface. This interface is IP based, there are no such things like E1/T1 or ATM any more.

In case you wonder from where all the configuration parameters for the eNodeB like EARFCN or RF Output Power come from: They have to be configured when setting up the eNodeB, in my case you can configure a few hundred parameters. Luckily most of them have default values which for a start can be taken without modification.

The S1 interface is divided into S1-AP (Application Part) which is specified in TS 36.413. This is the interface to the MME (Mobility Management Entity) which is somehow comparable to a GSM MSC and it uses SCTP. The communication between MME and phone (abbreviated UE like in 3G) are the so called NAS (Non-access stratum) messages, in LTE this is mainly Mobility Management and Session Management, there is no Call Control. LTE NAS is specified in TS 24.301.

The second part of S1 is called S1-U for the user plane traffic which is GTP-U (GPRS Tunneling Protocol) specified in TS 29.281 and using UDP. S1-U connects to the S-GW (Serving Gateway), basically comparable to a GPRS SGSN.

The eNodeB also has a second interface called "X2-AP" (TS 36.423), it is used to interconnect multiple eNodeBs (this is needed for example for handling handover which is done be the eNodeBs themselves). I did not care about X2-AP yet because right now I only have one eNodeB.

So far I wrote a very simple "Proof-of-Concept" so that a phone (in my case an LTE USB Dongle) can register to the LTE cell and transfer data (IP traffic). Just to mention a few of the differences to 3G/GSM:

  • The keys generated by the USIM in the UE (you can use a 3G USIM for LTE too) are not directly used for integrity protection or ciphering. Instead they are used to derive various keys, two of them are the ones used for ciphering/integrity protection on the air interface, this is done in the eNodeB.
  • The NAS messages between UE and MME are also protected (integrity protected and optionally ciphered), another derived set of keys is used for this. This means that even if the keys in the eNodeB can be obtained, the NAS messages are still protected.
  • One Mobility and one Session Management message can be transferred at once in one message over the S1-AP interface, this is for improving speed and saves data transfer on the core network.

Here is how it looks in WireShark when a phone registers to the LTE cell (recent versions of WireShark can handle S1-AP):

The colored lines are uplink messages (from UE to MME), the white lines are the response from the MME. You can see that a default bearer is configured together with attaching to the network. This means that without any further S1-AP messages user plane traffic can start immediately afterwards, at least if the default bearer is sufficient (e.g. the offered quality of service is good enough).

This all is just a very first start with LTE, I hope to find more time for it in the future and explore my eNodeB and LTE further.

[ /gsm | permanent link ]

Sun, 31 Mar 2013
Sometimes you need Wireshark to get an RF Power Amplifier running

I recently had the need for an RF Power Amplifier for the UMTS 2100 MHz band. As I didn't have a suitable amplifier at hand, I though of using one of the RF Power Amplifier modules of my Nokia Ultrasite cabinet which is a Node-B configured for UMTS 2100 MHz. The RF Power Amplifier modules in the cabinet can easily be removed, they are directly connected to the power supply line of the cabinet and they have standard RF connectors for RF In and RF Out. So it should be quite easy to operate them outside the cabinet.

Connecting power to the RF Power Amplifier module was easy, however this wasn't enough, the amplifier didn't amplify any RF although the status LED of the module was on. Also the power consumption was quite low, so obviously the actual RF Power Amplifier in the module was not yet on. I didn't want to modify the electronic inside the module so I had to find out how the module gets enabled in the cabinet.

Nearly all of the various modules in the Nokia Ultrasite cabinet are connected at the backplane to Ethernet through a hub (yes, a hub, there is no switch). This Ethernet network is mainly used for controlling the modules, fast data transfer between the modules is done somewhere else. The RF Power Amplifier module is no exception, it's connected to this control Ethernet network too. The configuration and management port of the cabinet is also an Ethernet port connected to the same control network. And because an Ethernet hub is used, all the traffic on this network can be monitored without any further tricks if you are connected to the cabinet's configuration and management port.

So I run Wireshark and captured a trace of the traffic on the cabinet's control network. I already knew the IP address of the RF Power Amplifier module from running it externally, however it only responded to a ping but no TCP or UDP port was open. (BTW, if you wonder how the module gets its IP address: depending on the slot where the module is inserted into the cabinet, different ID pins of the module are grounded. The levels on those ID pins define the MAC and IP address of the module).

From the trace I was able to find out hot it works, it's actually quite evolved:

  • First a certain UDP packet has to be send to the RF Power Amplifier module. Not just destination IP address and port have to match, also the source IP address and port have to be a specific value, if not the module just reports an ICMP error that the port is unreachable (that's the reason why I didn't find an open port during my first try).
  • This UDP package causes the module to initiate a TCP connection back to the sender, when the TCP connection is open the module sends some kind of initialization message and expects an acknowledgment.
  • Only after the TCP connection is open and properly initialized, another UDP package can be send to the module which finally turns the RF Power Amplifier inside the module on.
I am not sure why the TCP connection is necessary, so far I only found out that it is used to control the status LED of the module and to return the operational status (e.g. if a fault was detected). Over UDP it's also possible to query the serial number of the module or to tell it to periodically return RF power measurements. So as you can see, sometimes even just a "simple" thing like an RF Power Amplifier can require quite complicated interaction to run it.

[ /gsm | permanent link ]

Mon, 10 Sep 2012
Getting voice to work for OpenBSC and Ericsson RBS

When Harald Welte visited me for the Osmocom User Group meeting, he took the chance to experiment with OpenBSC and my RBS2206, a large GSM BTS in a cabinet. This inspired me to do some more investigations to get the RBS2206 actually run with OpenBSC including voice calls.

When OpenBSC configures a channel for voice, the RBS closes the channel after a few seconds with a "remote transcoder failure" error. I found some information which seems to indicate that there are O&M TRAU frames involved to signal the usage of the correct codec between BTS and TRAU. So I started to analyze the traffic between the RBS and the Racal 6113, a BTS tester which is able to run the RBS including voice calls. To analyze the traffic, I used a Siemens/Tektronix K1103 which can trace E1/T1 traffic.

To my surprise I did not find any O&M TRAU frames in the trace. After doing some more experiments it turned out that the RBS expects to receive speech TRAU frames of the same type (e.g. FR or EFR) as soon as it starts to transmit speech TRAU frames after the channel was configured for voice. So far OpenBSC sends Idle Speech frames as long as the voice channel is not yet connected to the other phone. This worked fine for the Siemens BS-11 or Nokia MetroSite/InSite BTS, but obviously did not work for the Ericsson RBS.

After adjusting the idle TRAU frame generation in OpenBSC with a quick workaround and solving some minor problems when configuring the RBS (depending on the software versions in the RBS some configuration messages are slightly different) I was finally able to run OpenBSC including voice calls with the RBS2206 over an E1 line and an RBS2401 over T1. The modifications are not yet in OpenBSC, but should be there soon after cleaning them up.

[ /gsm | permanent link ]

Tue, 24 Apr 2012
A bit of 3G Layer-1

While experimenting with my Node-B, I had the need to generate a RACH message without having to use a phone. Such an approach can for example be used for performance testing of the Node-B receiver or evaluating the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)

First a little bit of theory: The RACH in UMTS works different than in GSM, its not just about sending a single RACH burst. Because WCDMA is very sensitive to interference, the phones have to send with a transmit power as low as possible. For the RACH procedure this means that the phone starts to send a short RACH preamble with very low power and looks for the acknowledgement if the preamble has been received by the Node-B on the AICH (Access Indication Channel) channel. If the phone doesn't receive the acknowledgement, it increases the transmission power and resends the preamble. If there is the acknowledgement from the Node-B, the phone sends the actual RACH message. The RACH message itself is not just a few bits containing the access cause and a random reference like in GSM, it is a complete message. "RRC Connection Request" is used for accessing the network but other message can also be sent on the RACH channel (e.g. "Cell Update" which is besides other things used for indicating unrecoverable RLC errors. One can see this message frequently when starting to implement an RNC ;-).

Now where to get a RACH preamble and message without having to use a phone? I started to look at Agilent's Signal Studio for WCDMA which should be able to generate a RACH messages with user defined content which can be replayed with a signal generator. However even after lots of trials I never managed to generate a RACH message which can be properly decoded by the Node-B, only the RACH preamble is detected without errors but the RACH message itself just produces garbage and CRC errors.

So I started to write my own code to generate the RACH message. The relevant 3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding) and TS 25.213 (Spreading and Modulation). Basically the steps to create a RACH message requires adding a CRC to the message bits, Convolutional encoding, 1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and finally Modulation. I and Q signal on the Uplink carry different things, Data is on the I signal, Control (pilot bits and transport format information) on the Q signal. Luckily the RACH message does not require any fancy multiplexing and rate matching of multiple transport channels on a physical radio channel. This can get really funny, especially if Turbo Coding is involved which results in multiple bit streams (systematic and parity bits) which are treated differently. After some trial-and-error and lots of experimenting and testing I was finally able to create a well formed signal of a RACH preamble and message which the Node-B can properly decode.

After that I also tried to decode the RACH message generated by Agilent's Signal Studio to find out why it didn't work. It seems that the wrong scrambling code sequence is used (the scrambling code number looks OK, but the offset into the code bits is wrong). I really wonder why no one noticed this problem with Signal Studio before or maybe I am just doing something wrong. Anyway, I can now use my own code to generate RACH messages. Maybe in the future I will also look into generating a signal which a phone will consider as valid signal of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH (Primary Common Control Physical Channel) carrying the BCH.

[ /gsm | permanent link ]

Mon, 16 Apr 2012
3G User Plane

Continuing with my Node-B experiments I started to implement handling the user plane. I can now do voice calls, video calls and data connections. Just to make it clear, those are the very first steps only without any optimisation for speed and far from being complete or ready for release. I consider it as the essential "building blocks" necessary for the next steps towards a small Open Source RNC.

So how does it work? One way to allocate a channel for user data is to modify the existing signalling channel by sending the RRC "Radio Bearer Setup" message to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages to the Node-B. Besides being much more complex due to the number of possible parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify" and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will allocate another UDP port for the User Plane data besides the existing UDP port for the Control Plane data (UDP ports because I use "Iub over IP" to talk with the Node-B).

The User Plane data are embedded in FP (Frame protocol, TS 25.427). For voice the data are the AMR class A, B and C bits. To ease testing with a single phone I use a loopback which simply sends the received uplink AMR class bits back to the downlink.

Signalling for a Video Call is very similar to a Voice call. The main difference is in the CC Setup message, the bearer capability indicates UDI (Unrestricted Digital Information) for Video. UDI is basically a 64 kbit/s channel which transports video according to the 3GPP umbrella protocol 3G-324M) for video telephony. Loopback is not as easy as for voice because first the four-way H.245 protocol handshake has to be completed to agree on communication parameters, after that the uplink video data can be resent to the downlink.

Although UMTS is generally much more complex than GSM/GPRS, handling of data connections is easier than for GPRS because there is no need for a PCU (Packet Control Unit) with all its complexity. There is the optional protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of RLC which is used for things like header compression. But if you don't use it, you get the raw IP packets embedded inside RLC.

[ /gsm | permanent link ]

Thu, 02 Feb 2012
Running your own Node-B

Its now nearly 3 and a half year ago that I wrote the first "Proof-of-Concept" code to get the Siemens BS-11 GSM Basestation up and running. So I think it was time to start with 3G, now that LTE is being actively deployed. You also can sometimes find reasonable priced, used Node-Bs which makes getting access to the equipment possible. A Node-B is the 3G equivalent of a GSM BTS.

So I spent quite a lot of time spread of several months to get a Node-B up and running. Compared with the BS-11 this was a lot more difficult and required much more time. Of course the Air Interface is completely different, in my case I looked at WCDMA FDD so far, there a few more standards used in other parts of the world. Then you have to deal with a huge, different specification, the most important when dealing with a Node-B are NBAP (TS 25.433) and RRC (TS 25.331), around 3000 pages in total. NBAP, the Node-B Application Part, is used to configure the Node-B and do things like creating Radio Links (communication channels) to the phone. RRC, the Radio Resource Control, is the Layer-3 protocol for the control plane between the phone and the access network. It is responsible for accessing the network, setting up and releasing connections or paging a phone. Both NBAP and RRC make use of ASN.1 which makes things not necessarily easier ;-) There are a few more protocols on the lower layers involved like MAC (TS 25.321), RLC (TS 25.322) and FP (TS 25.435 and TS 25.427).

The Node-Bs I used can run "Iub over IP" (Iub is the interface between the Node-B and the RNC, similar to Abis in GSM between the BTS and BSC). Originally Iub is based on ATM which runs over E1/T1 or similar lines with higher data rates. However "Iub over ATM" adds a few more protocol layers for dealing with ATM and I really wanted to avoid this additional complexity. Not all Node-Bs can automatically do "Iub over IP", usually it requires an additional hardware option (interface card). When using "Iub over IP" you have to deal with protocols like UDP and SCTP which are much more convenient.

The current status is a very minimal implementation of something like an RNC to run the Node-B so that a phone can register on the network and do simple things like SMS on the control plane. No user plane like speech or data yet, but this is the next steps I plan to do. The code is not yet public but it will be when it gets more evolved.

There is still a lot left to research and experiment with. For example I haven't looked at things like HSPA yet, I completely ignore handover to other cells as there is only one cell in my experimental setup. So I am sure 3G will give a few more years of a very interesting field to play with before looking at LTE ;-)

[ /gsm | permanent link ]

Sun, 30 Jan 2011
GPRS Air Interface

To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.

The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).

I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).

Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).

[ /gsm | permanent link ]

Tue, 25 Jan 2011
TETRA Air Interface

If you are interested in how the air interface and the lower levels of TETRA work, you should have a look at the website.

My contribution so far was to search for a suitable demodulator (TETRA uses PI/4-DQPSK) which I found at the OP25 project (the author of the demodulator is KA1RBI).

I also implemented some "proof of concept" code which allows decoding speech traffic and converting it to raw audio using the TETRA reference codec. Please note that this cannot be used to listen to encrypted TETRA traffic, it only works if no encryption is used.

[ /sdr | permanent link ]

Sat, 22 Jan 2011
GSM Ciphering Algorithms in mobile phones

You are probably aware that the A5/1 and A5/2 GSM ciphering algorithms are broken, A5/2 is so weak that even the GSMA mandates that it is no longer used in new mobile phones. A secure alternative would be A5/3, however it is not yet deployed in GSM networks, at least those networks I am aware of, and only some newer phones support it.

I had a brief look at some phones I have access to, most of them came out in the last four years. Interestingly quite a lot of them still support A5/2 and only very few support A5/3. If a phone does not indicate A5/3 support, this does not necessarily mean that it is not capable to run A5/3, for example on one of my test phones, a BlackBerry Bold 9000, A5/3 is disabled (for whatever reason). The phones in my collection with enabled A5/3 support are some new, cheap features phones from India based on a MediaTek chipset. And as a side note: The iPhone 4 I looked at does not have A5/3 enabled but at least A5/2 is disabled.

I also did a few quick tests to make sure that A5/2 cannot be used on those phones which claim that they do not support it, and so far this seem to be the case. The reason for this test: The phones can most certainly run A5/2 if they can run A5/1 (which all of my phones can), A5/2 is very similar to A5/1. If a phone claims to support only A5/1, it does not necessarily mean that the phone will not use A5/2 if you force it to do so, if there are bugs in the phone firmware, the phone could still run A5/2.

The short tests I did are only a first look at this issue. Additionally the same phone model could behave different when sold by a different operator or in a different country, as I already wrote, most of the time the supported ciphering algorithms can be configured by the phone manufacturer. So this is an area which should be investigated further.

[ /gsm | permanent link ]

Sun, 05 Sep 2010
OsmocomBB GSM Development

I have the impression that not a lot of people are developing for Layer-1 in OsmocomBB. Is it because GSM in that depth is too complicated ? Of course you need some GSM knowledge to start, but be assured you will learn a lot if you work on this level.

Besides the really cheap phones supported by OsmocomBB you also need a BTS or GSM Testset for doing serious work. You can use a BS-11 or nanoBTS with OpenBSC or an USRP-1 with OpenBTS. I understand that the price for this hardware might be too expensive for some of you.

However GSM Testsets are not that expensive any more. If you have the room for a large and heavy unit (around 30 Kg) the HP 8922 might be a good solution. You can buy them for a few hundred Euros and this unit is really nice: Besides the GSM Testset it can be used as a very accurate Signal Generator (10 MHz to 1 GHz) and it also comes with a simple Spectrum Analyzer (10 MHz to 1 GHz) as a hardware option. The unit is for GSM-900 but there is an additional converter available for GSM-1800 support. The converter doubles the size of the unit and you usually don't need it. One drawback is that the HP 8922 does not support Encryption. As far as I know this was a Hardware Option but I have never seen a unit for sale which has this option installed. Actually it would only require a different DSP code in one of the EEPROMs which includes the A5/1 or A5/2 encryption code, the rest (Layer-3 support and passing Kc to the DSP) is already there. As usual with most HP units, you can download the documentation from the HP/Agilent web site.

Another GSM Testset I use is the Racal 6103. Its smaller than the HP 8922 and has more Layer-3 options but is not that versatile on Layer-1. The "E" Variant of the unit also supports Encryption. You can sometimes find those units for a few hundred Euros, but be aware that it is not the "Anite" or "Aime" variant, those units require a special PC software to use them, without this software you can't do much with them. So far I have not seen this software, I only know that it is quite expensive.

If you use a GSM Testset, you have one big benefit: You can connect the phone to the Testset with a cable (there is no need for an attenuator) and don't have to care that much about emitting RF on the licensed spectrum.

[ /gsm | permanent link ]

Sun, 15 Aug 2010
A few notes about the TI Calypso audio path

While working on voice support for OsmocomBB I had to look in detail at how the audio path in the TI Calypso chipset works. Basically it is not very complicated:

The Uplink path consists of an amplifier for the microphone and an ADC, the digital samples are transferred to the DSP which takes care about the encoding according to the selected GSM voice codec.

In the Downlink path the decoded samples from the DSP are sent to a DAC which is followed by an amplifier and the loudspeaker.

Some additional details are that you can select the analog input/output (e.g. if the headset connector is used). Parameters which can be adjusted are the gain of the amplifiers and the sidetone level (a feedback between the uplink and the downlink audio path).

The digital samples for the DSP use a sample rate of 8 kHz. A not so obvious feature is that there are two FIR (Finite Impulse Response) digital filters with 31 taps in the DSP, one for the uplink, the other for the downlink. Those filters can be used to improve the voice quality or reduce ambient noise. So far those filters are set to not modify the signal (the filter coefficient of the first tap is 1, all others are 0). The format of the filter coefficients is signed fixed-point Q2.14, so for example 0x4000 means 1.

[ /gsm | permanent link ]

Mon, 09 Aug 2010
Nokia WCDMA UltraSite Basestation

I bought several components of a Nokia WCDMA UltraSite BTS. However the unit is not yet complete. What is missing:

  • IFU - Interface Unit
  • WTR - Transmitter and Receiver
  • WPA - Power Amplifier
  • Rack/Cabinet for all the components

If anyone knows where to get those parts for a reasonable price, please let me know. The final goal is to have support for this unit and similar WCDMA basestations from other manufactures in OpenBSC.

I am aware that UMTS Femtocells are cheaper and they do WCDMA too. Its surely possible to support them in OpenBSC, its mainly a matter of free time and/or who will start with it. But Femtocells have a different architecture than "real" BTS/Node B units, a Femtocell usually combines the RNC (Radio Network Controller) with the basestation and uses a different protocol for controlling the unit. So it still makes sense to have a "real" WCDMA BTS/Node B for OpenBSC integration.

[ /gsm | permanent link ]

Tue, 03 Aug 2010
Ciphering Indicator in mobile phones

According to GSM 02.07 B.1.26, there should be a Ciphering Indicator in the ME to allow a user to detect if ciphering is not switched on. The Ciphering Indicator can be turned off by the network operator clearing the OFM (Operational Feature Monitor) bit in the "administrative data" field of the SIM (see GSM 11.11, 10.3.18)

Usually the Ciphering Indicator is turned off, at least in those SIMs I have seen so far. And you usually cannot modify the administrative data in the SIM. But would a phone actually display something if the Ciphering Indicator is enabled and ciphering is not on ?

To find this out I used a Test SIM which allows modifying all fields of the SIM. Such a Test SIM is for testing handsets, you cannot use it with your official GSM network. The OFM bit was set to one to enable the Ciphering Indicator. To simulate encrypted and unencrypted calls I used a Racal 6103E GSM Testset. I could have also used OpenBSC, however with the 6103E switching between encrypted and unencrypted calls was faster, it just required the press of a button.

Here are the results for some phones I had access to, Yes means that I noticed a difference between encrypted and unencrypted calls and what this difference was and No means that I noticed no difference:

  • Nokia 3310: Yes, Open Lock Symbol during Call
  • Siemens M55: Yes, *!* Symbol during Call, regardless of OFM bit
  • Mitsubishi MT-040: No
  • P1300: Yes, Cx Symbol during Call
  • Motorola C123: No
  • Motorola W156: No
  • Netzing NE110: Yes, C* Symbol during Call
  • BlackBerry 9000: No
  • BlackBerry 9520: No
  • BlackBerry 9700: No
  • Sony Erisson K800i: No
  • HTC Touch Pro: No
  • HTC Hermes: No

This is by no means a detailed investigation however it is at least some indication that a lot of phones do not care at all about the Ciphering Indicator, probably because it is usually turned off in the SIM anyway.

[ /gsm | permanent link ]

Sun, 01 Aug 2010
TCH Support for OsmocomBB

I started to implement Layer-1 support in OsmocomBB for traffic channels. Its not yet ready and in a rather crude state but I hope to clean it up in the next few days so that it can be released.

During testing I used a nice feature of my HP8922 GSM Testset: It can continuously generate Full-Rate TCH speech traffic on a timeslot without the need for any signalling. You can even connect an external audio source like a CD player and "broadcast" your own content. And while it is in this mode, the HP8922 can also receive speech traffic and you can hear it on its built-in loudspeaker.

The benefit of this for getting the Layer-1 code on the phone right is that you can concentrate on TCH receiving and transmitting without having to care about signalling. You just "tune" to the right ARFCN and timeslot (I don't use hopping during testing) and see that you get your code running.

I guess that having this special mode (setting an ARFCN and timeslot and "listen" to the TCH) in the phone can be quite useful for debugging non-hopping, non-encrypted, single ARFCN cells like OpenBSC and OpenBTS.

[ /gsm | permanent link ]

Microsoft Research and SDR

I wasn't aware of it, but Microsoft Research is doing SDR (Software Defined Radio): Sora.

Their approach is interesting, all the raw samples are transferred between the PC memory and the ADC/DAC of the Radio Front-end by a PCIe card and all the signal processing is done by the CPU of a PC. There is no DDC (Digital Down Converter) or DUC (Digital Up Converter) in an FPGA involved. They already implemented 802.11a/b/g and an LTE receiver this way.

The price of the hardware does not sound too expensive. The software only runs on Windows and I have not yet checked the license terms in detail.

I could imagine that combining this approach with the power of a GPU can be quite interesting.

[ /sdr | permanent link ]

Sat, 31 Jul 2010
Extending Airprobe's gsm-receiver

I spent some time to extend Airbrobe's gsm-receiver so that it now can be used to nearly fully decode the downlink traffic of a non-hopping, single ARFCN cell. "Nearly" means that it does not yet support Half-Rate speech TCH channels or TCH data channels (which are not widely used anyway with GPRS).

It might not be obvious, but I was also responsible for decoding/decrypting speech in gsm-receiver. In June 2009 I wrote a tool based mainly on parts of OpenBTS to solve a little "challenge" by Piotr Krysik posted on the Airprobe mailing list to get the speech out of an USRP capture. This standalone tool was later integrated into gsm-receiver by Piotr. Now at least you know who to blame why there is stuff from OpenBTS integrated into gsm-receiver ;-).

Besides being used in Karsten Nohl's A5/1 cracking attack, those features of gsm-receiver are quite handy for debugging OpenBSC or OpenBTS in the downlink direction.

A short tutorial of how to use gsm-receiver can be found here.

One of the next steps I plan to do is implementing the uplink direction. Please don't ask when this will be ready, if someone else is already working on it, please let me know so that the same thing is not done twice.

[ /gsm | permanent link ]

Starting to blog

I finally decided to start writing a small blog about what things I am working on. The reason is that it seems these days without talking or writing about what you do, your work won't get noticed or others might take what you have done and claim its theirs.

[ | permanent link ]