These days, wireless protocols such as 5G, Wi-Fi, and Bluetooth are household names. Most folks have at least a sense of how they're used. Of course, most had their introduction to "wireless" with the radio via AM and FM broadcasts. Somewhere in between they probably also experienced terrestrial or maybe even satellite television. Speaking of television, how about IR (Infrared) remotes? Perhaps they've used or seen a pager. A smaller, but still large, percentage is aware of RFID (Radio-Frequency Identification) thanks to access control systems and retail merchandise security. There's also quite a few people that are aware of NFC (Near Field Communication) thanks to the proliferation of tap-to-pay via apple pay and NFC-capable EMV cards. In this series, I'm going to begin to take you on a journey centered on the magic that is wireless communications.
Tire Pressure Measurement
Most of you reading this have probably had a tire run low or even go flat. Back in the day, if you didn't pull out a tire gauge every single time you went to get in your car, you had to pay close attention to the handling and performance of your car to know if you had a slow leak. Did everything sound right? Were your turns nice and smooth? Did your gas mileage change? Eventually you'd have a visual indication: you could see the tire going flat.
Now however, we have a couple of convenient ways of sensing whether a tire is properly inflated. The first, iTPMS or indirect Tire -Pressure Monitoring System, uses one of two different primary implementations to determine whether a tire is under-inflated or not. This may be what you're used to. You get in your car and see a light that looks something like the picture below. This method is less accurate, and I won't be covering any further information about it here as it doesn't use RF.
The second method is dTPMS, or direct Tire-Pressure Monitoring System. This uses a sensor, typically built into the valve stem of a wheel, to directly measure the air pressure inside the tire. You may have seen this in vehicles where the dash will display information about each tire. But how does the vehicle receive this information? There aren't any wires connected to this sensor that hook into a wiring harness to access the CAN (Controller Area Network). So what's going on here? Well, this system uses radio frequency communications.
dTPMS Overview
There are typically two types of dTPMS. OEM and AEM, or stock equipment and aftermarket equipment. OEM equipment typically does not transmit while the vehicle is in park in order to prolong the life of the sensor. However, AEM sensors may transmit 24/7. Additionally, there are 3 different methods of operation for dTPMS. High line, low line, and proprietary. High line and low line are typical for OEM, whereas proprietary is typical with AEM.
In a high line system, the dTPMS is equipped with both UHF (Ultra-High Frequency) and LF (Low Frequency) equipment. The UHF radio is used for transmit only whereas the LF radio is used for both transmit and receive. The primary function of the LF radio is to receive a "wake" signal from the ECU, the ECU may then receive an acknowledgement from the LF radio, followed by TPM data from the UHF transmitter. Some of the high-line systems are also designed to support the same function as low line dTPMS. In a low line system, there is only a UHF radio set to transmit data at specific or random intervals, sometimes both.
AEM dTPMS uses a variety of methods to transmit information. Often, these will be sensors placed on the external portion of the valve stem and either transmit data over Bluetooth/BLE to a smartphone, or to an additional electronic unit placed inside the vehicle cabin.
Reading Data
Reading this data is fairly simple these days for most OEM setups. All you need is a Software Defined Radio (SDR) capable of reaching tuning to your target frequency, and rtl_433. As this utility has a wide array of capabilities, we'll be using it for quite a few of these articles. By running rtl_433 in a terminal, it'll automatically tune your SDR to 433.92 MHz with a spread of 25 KHz, with several decoders enabled. There are tons of devices that operate here, including some dTPMS equipment. If you let the tool run for a little while and come back to look for the keyword "pressure" in the output, you should have an entry, maybe even a few depending on where you live.
If you want to be even more meticulous about the data you pick up, you can use the -R switch to specify a decoder. Identifying which decoder to use can be a simple process. dTPMS equipment does not transmit at very high power, therefore the signals will not travel very far. Take a look at the block you live on, look at the make and models of vehicles around you, do some googling to identify what equipment is commonly used by the manufacturer of your target vehicle, and pick the decoder from the tool documentation. You can even choose multiple decoders. If one doesn't exist for the equipment you're trying to read, the developers even have a guide to build your own: https://triq.org/rtl_433/ANALYZE.html
Remember how I mentioned that high line systems use a wake signal? You may have to wait for a neighbor to start their car. Or you could just go start your own. Maybe you'll be lucky and have vehicles near you using low line, or low line features. But either way, after some time, you should see some output similar to this:
Weaponizing TPMS
As you can see above, the equipment typically transmits an ID. This is done so that the ECU knows which wheel it is receiving information about and should report metrics on. Some systems do not use an ID and perform calculations based on signal strength and the current spin direction of the wheel. It is theoretically possible to track vehicles with this information. The problem here is collecting RF data in multiple places. Currently, there is not a public system where any data is stored or searchable regarding RF signals aside from Wigle. Wigle currently only supports Wi-Fi, Bluetooth/BLE, and cellular signals. You would need a similar system with long term data from many, many places to establish any form of identifiable pattern.
So, what about the signal itself? Well, a signal could be spoofed to send false data, such as low pressure. In some heavy machinery, these systems work with auto-inflation equipment to ensure the tires never get too low. RTL-SDR.com features some information on this: https://www.rtl-sdr.com/exploring-vulnerabilities-in-tire-pressure-monitoring-systems-tpms-with-a-hackrf/
Final Thoughts
If conditions exist where certain operations aren't protected, it would be theoretically possible to spoof a dTPMS signal sent to the ECU, with malicious data to exploit a vulnerability, if one exists. I hope to do some research in this area and provide results in a follow-up article, but first I need to get equipment capable of transmitting, as currently the SDRs I have can only receive.
Throughout this post I have very heavily referenced the Wikipedia articles for TPMS and dTPMS where my own knowledge had gaps. If you have more information regarding TPMS, or you found something that was incorrect, please reach out so I can correct or add it. Thanks for reading!