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.

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.

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.

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 "192.168.1.2" with the IP address of your adapter.

curl -d "login_pwd=1&pws=12345678" "http://192.168.1.2/cgi-bin/login.cgi"
curl -d "password=12345678&debug_enable=1&uart_tx_eb=1" "http://192.168.1.2/cgi-bin/debug.cgi"


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.

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.