eavesdropping the wheels, a close look at TPMS signals

(ANgazu, Rapidbit, i56578)

My friend ANgazu encouraged me to have a more close look at the signals that populate the V/UHF world and possibly begin to analyze some of them. He invited me to collaborate in the study of TPMS (Tire Pressure Monitoring System) signals: an interesting "in-car" wireless network  designed to monitor the air pressure inside the pneumatic tires on various types of vehicles. Indeed, my collaboration was limited to do a "parallel" study, confirming and commenting the results obtained by ANgazu and his colleague Rapidbit (both from radiofrecuencias.es).

Briefly, "TPMS uses battery-powered pressure sensors inside each tire to measure and transmit tire pressure. Each sensor module communicates its data via a UHF transmitter, commonly the 315 MHz or 433 MHz bands are used. The receiving tire pressure control unit, in its turn, analyzes the data and sned results or commands to the central car computer to trigger warning messages on the vehicle dashboard. The tire pressure sensors will wake up in response to two triggering mechanisms: a speed higher than 40 km/h, detected by an on-board accelerometer, or an LF (125 KHz) RFID activation signal". 
You may find in the web a lot of tech and legal informations about these systems (just to mention United States and European Union which mandates TPMSs on all new vehicles), although, as far as we know, SIGINT-style approaches are quite few: so we decided in favour of this post.

Actually there is not an outright TPMS standard: communications protocols are proprietary, data transmissions commonly use the 315 MHz or 433 MHz bands, and ASK as well as  FSK modulation. Frame structures are different and depend on the manufacturers, mainly the data sent by a TPM sensor are: the sensor ID, temperature and pressure of the associated tire,  sensor status and a CRC field. There is no authentication between sensor and remote control unit, neither encryption of data.
In our case, the system uses the 433 MHz & FSK modulation and each sensor sends a 8-burst train every about 60 seconds, in Figure 1 the dead times between signalings have been deleted.

Fig. 1 - 8-burst trains

Each TPM sensors repeats 8 times the same message at not regular time intervals to avoid collision problems, although collisions and overlappings are frequent, as in Figure 2 (note how the sensors use two slightly different frequencies).

Fig. 2

The on-air FSK waveform have a shift of ~ 550 KHz and a speed of 20.150 KBaud (Fig. 3), once decoded it exhibits a 150-bit length frame consisting of a 10-bit length preamble followed by 140-bit data using Manchester encoding (Figs. 4,5).

Fig. 3 - FSK parameters

Fig. 4 - Auto Correlation Function

Fig. 5 - 150-bit period (4 bursts)

In Figures 6a/b, 1-out-of-8 bursts for every TPM sensor during 10 trains were decoded and ordered: the resulting bitstream are the 70 bits info that each wheel sends during about the firts ten minutes from start. In normal use, tx are every 60 seconds bat can be more frequent if  some parameter is not right or vary, eg at the start of car motion as in this case; more over, the car can ask for tx using LF (RFID).
There are some bitfields with exhibit regular repetitions of patterns (at every 4 bursts), static patterns and variable ones. Particularly, note that the second and third field reach almost constant values after 3-4 minutes: these are the temperature and pressure values (the capture begins when the car is stationary).

Fig. 6a - 70 bits info that each wheel sends in ~10 minutes

Fig. 6b - 1-0 view

Most likely, the structure is: 8-bit sync, 8-bit temperature, 8-bit pressure, 32-bit sensor ID, 5-bit flags (sensor status), 8-bit CRC, and 1-bit EOM. Perhaps  some bits are used as field sync, but there are no info about that. In this case, using the bit sequence "10" as field separator, we get: 6-bit sync, 6-bit temperature, 6-bit pressure, 32-bit sensor ID, 3-bit sensor status, 8-bit CRC, and 1 bit EOM (Figs. 7a/b).

Fig. 7a

Fig. 7-b

At least this protocol, and most likely all the others, does not use encryption or a form of authentication, and the car implementation does not perform basic input validation. Moreover, TPMS messages can be correctly received up to 10m from the car with a cheap antenna and up to 40m with a basic low noise amplifier, so the cited shortcomings  allow for remote spoofing of TPM sensor messages and may cause security and privacy vulnerabilities. 

Could it be used as feasible way to track cars? Think that each TPM sensor sends its 32-bit static identifier in every message and the length of the identifier field could render the IDs sufficiently unique to track cars, in these case using the 4-upla: 

01101011101001000010011011101101
01101010100101111010111110111101
01101010100101111010001110111101
01101010101001010000001100000101

On the other hand, just the choice of the "open-protocol" solution allows to use aftermarket products or multi-protocol sensors that come “pre-loaded” with many sensor protocols in a single sensor body; this way the TPM sensors are not so tightly linked to the car manufacturer and ultimately to the car. But, who knows how it will evolve?

 

At present we decided to not mention car and sensors manufacturers, anyway - for study purposes only - you could send your recordings along with the manufacturers of the "copied" TPM sensors so to build up a sort comparison table. Why not?

We know there are some pieces of software which are able to decode and identify TPMS such as:
https://github.com/jboone/tpm differents 
https://github.com/merbanan/rtl_433 
but what we'd like to do  is a bit more "radio" approach rather than a purely software approach. As suggested by ANgazu, there are many 433 files here:
github.merbanan/rtl_433_tests
Files are .dat but after some analysis, format for SA is 8U and sample rate is 250000. There are about 4 TPMS models that can be a good reference for us. We think that join these two approaches will offer two different views of the same signals!

https://yadi.sk/d/_ngTZE473MHZhs