Dieter Spaar's blog
   

RSS

Dieter's Web
mirider.com

Projects I am participating
OsmocomBB
OpenBSC

Categories

Archives

Other Bloggers
Harald Welte
David Burgess


blosxom


Contact/Impressum

       
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 ]

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 ]