TPMS
Tyre pressure sensors that broadcast an unauthenticated sub-GHz packet every time the wheel turns. The packet carries a unique sensor id that never changes, which makes a safety feature into a per-vehicle tracking beacon.
TPMS (Tyre Pressure Monitoring System) is the legally mandated system that warns a driver about an underinflated tyre. In its direct form, a battery-powered sensor inside each wheel measures pressure and temperature and broadcasts them on a sub-GHz ISM frequency, unencrypted and unauthenticated, tagged with an identifier that is unique to that sensor and fixed for its life.
What it is
Two designs share the name and only one of them uses radio:
- Direct TPMS: a sensor in each wheel, usually built into the valve stem, transmits a short packet on 315 MHz (North America) or 433.92 MHz (Europe and most other markets). Modulation is FSK on most modern sensors and OOK on older ones, with Manchester or differential Manchester line coding, and every vendor has its own frame format: Schrader, Continental/VDO, Huf/Beru, Pacific, and a long tail of vehicle-specific variants.
- Indirect TPMS: no radio at all. The ABS module compares wheel-speed sensor data and infers pressure from the rolling radius and vibration signature of each wheel. It has no tracking angle at all, needs a manual reset after inflation, and struggles when all four tyres deflate evenly.
Direct TPMS became mandatory on new light vehicles in the United States in September 2007 (FMVSS 138) and in the European Union on new type approvals from November 2012 and all new registrations from November 2014 (UNECE R64). That is why almost every car built in the last decade radiates on 315 or 433 MHz.
Why it matters
A TPMS packet has no encryption, no rolling counter, and no signature. Its identifier is not a session identifier, it is a serial number: it is written at manufacture and does not change until the sensor is replaced, typically after five to ten years when the battery dies. There is no equivalent of Wiki: mac-randomization anywhere in the design.
That makes each car a persistent radio beacon. A receiver at a road side logs an id; the same id logged at a second point gives a direction and a speed; the same id logged next week gives a pattern of life. One sensor is enough, since the mapping from id to vehicle is one to one, and a passing car normally offers four. The seminal demonstration is Rouf et al., "Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study" (USENIX Security 2010), which showed eavesdropping at tens of metres with modest equipment, tracking by id, and forged packets that the receiving module accepted without question and turned into a dashboard warning.
Reading it off the air
Any Wiki: rtl-sdr covers both bands, and rtl_433 already carries decoders for dozens of TPMS formats:
rtl_433 -f 433.92M -F json # Europe; use -f 315M in North America
rtl_433 -f 433.92M -F json | jq 'select(.type == "TPMS")'
A decoded record looks like a sensor report and reads as a tracking record:
{"model":"Schrader","type":"TPMS","id":"1A2B3C4D","pressure_kPa":230.0,
"temperature_C":21.0,"battery_ok":1,"mic":"CHECKSUM"}
rtl_433 -R help prints the decoder list your build actually has. The numbers shift between releases, so read that list rather than copying a -R number out of a blog post.
The catch nobody mentions
Sensors sleep. A parked car transmits rarely, often once an hour or only when the pressure moves, precisely so the battery lasts years. A sensor wakes and transmits every thirty to ninety seconds only once the wheel is actually rolling, above roughly 40 km/h, detected by a roll switch or an accelerometer.
The practical consequences:
- A capture session in a car park usually returns nothing. Sit next to a moving road instead.
- Workshop tools (ATEQ, Autel and similar) force a transmission on demand with a 125 kHz LF trigger held next to the tyre. That is the supported way to make a stationary sensor talk, and it is a different radio from the one you are listening on.
- Programmable aftermarket sensors exist precisely so a garage can clone the id of a sensor it is replacing, which is also the cleanest way to put a chosen id on the air.
Forging one
Because there is nothing to authenticate, transmitting a well-formed packet with a valid id and an alarming pressure value makes the dashboard light up. This is a nuisance attack rather than a safety one, and it is worth naming what it is not: it does not touch Wiki: can-bus directly, it feeds a receiver module that then reports on the bus. The interesting part is what the module does with implausible input, and how few of them sanity-check anything.
Transmitting needs a transmit-capable radio (HackRF, or a Wiki: cc1101 at the right frequency), the exact modulation and encoding of the target vendor's format, and a correct CRC. The format is the work; the crypto is not, because there is none.
Pitfalls
- Wrong continent, wrong band. 315 MHz and 433.92 MHz sensors are physically different parts. Scanning the wrong band returns silence and proves nothing.
- A checksum is not authentication. Every TPMS format has some integrity field, and every one of them is computable by anyone who knows the format.
- Ids are not vehicle ids. They belong to the sensor, so a wheel swap moves them, and a car with a spare fitted radiates a different set. For tracking work that is noise, not a defence.
- Legality. Receiving is passive, but logging identifiers of vehicles you do not own is personal-data processing in most jurisdictions, and transmitting on 315 or 433 MHz into someone else's car is not testing, it is interference.