Rolling Identity: How Four Unauthenticated Tire Sensors Became a Vehicle-Tracking Grid With No Network of Its Own
Rolling Identity: How Four Unauthenticated Tire Sensors Became a Vehicle-Tracking Grid With No Network of Its Own
Posted: March 4, 2025
Author: SecurityResearcher472
Introduction: The Four Radios You Cannot Turn Off
Sealed inside each wheel of nearly every passenger vehicle built in the last fifteen years is a battery-powered radio transmitter with a factory-burned serial, permanent for the life of the unit. It broadcasts that serial in the clear, unauthenticated, several times a minute, as long as the wheel turns. It cannot be paired, revoked, renamed, updated or disabled. Reaching it means breaking the bead on a mounted tire.
You have four. You have never thought about them once. They exist because a regulator decided underinflation kills people, and the cheapest warning was a radio in the wheel.
For fourteen months I have worked a case that began with a question about municipal traffic-counting hardware and ended with me reading a table that knew every car I have owned since 2011, including two I sold privately for cash in different states. A capability I am tracking as PATIENT MILEPOST is resident in commodity roadside telemetry furniture across a continental footprint. It logs tire-pressure sensor identifiers and resolves them into vehicle identities that survive plates, registrations, owners and state lines. It has no network connection of any kind.
The science here is not mine and not speculative. That tire-pressure sensors broadcast long-lived unique identifiers without encryption is documented and uncontroversial, and tracking a specific vehicle by those identifiers has been demonstrated in the open literature for over a decade. Everyone in the field has known. The received wisdom was that it did not scale.
Security Advisory: I am publishing from a vehicle I do not own, whose wheels I replaced with a scrapyard set, which I now understand only handed the grid a new quadruple to correlate with my old one. The sedan I drove earlier in this work developed a fault in which the dashboard reported a fifth tire position. A contact at an automotive sensor licensor who had agreed to explain the module’s provenance missed our third call, and the directory page bearing their name now returns a 404 served, I checked, from a cache warmed the same afternoon. Their last message read, in full: “don’t follow the trucks.”
Key Findings
- PATIENT MILEPOST is a passive radio-collection capability resident in ordinary roadside telemetry equipment — traffic counters, parking pucks, sign controllers, charging pedestals — recording tire-pressure sensor identifiers rather than the metrics those devices are documented to produce.
- Affected sensor firmware emits a supplementary transmission every 42 seconds above a low speed threshold, four times the rate any inflation warning requires, turning an occasional chirp into a continuous identity beacon.
- A vehicle’s four sensor identifiers are correlated into a quadruple — an identity more durable than a plate, a registration or a VIN, because none of the events that change those change the wheels.
- The collectors have no uplink. Exfiltration rides the crowd-sourced offline item-finding network: each collector advertises as a lost accessory, and every passing driver’s phone carries the data out over that driver’s own plan.
- Attribution converges on Junction Pneumatics, an OEM sensor licensor sharing a registered technical contact with the Junction Technologies infrastructure I documented in my earlier work on antivirus telemetry.
The Technical Reality: Why the Wheel Is the Worst Place
Start from what is true.
A tire-pressure sensor is a transducer, a thermometer, a tiny radio and a decade-life battery, molded into a unit thrown away with the tire. Its design budget never had room for cryptography. It identifies itself with a fixed serial so the receiver knows which wheel is talking, and transmits in the clear because negotiating a key through a steel wheel on a coin cell was not a problem anyone chose to solve.
Three assumptions kept this a laboratory curiosity. Range: these transmitters are weak, readable from tens of feet. Duty cycle: a sensor sleeps when the wheel is still, so an observer gets a handful of packets per passing car. Effort: tracking a vehicle across a region would need receivers everywhere, which is a civil-engineering project, not an operation.
All three are sound. All three stop mattering when the party collecting already owns the furniture at the side of the road. Weak transmitters are fine if your receivers sit eighteen inches from the tire, bolted into the surface it rolls over, already installed, already powered, already permitted, unremarkable. Nobody audits a traffic counter. Nobody reads the firmware of a parking puck.
The second was arranged away:
TPMS transmit policy (vendor documentation vs. observed, affected OEM batch):
parked / wheel static no transmission [both]
rolling, nominal pressure every 60-90 s [both]
pressure delta > 0.2 bar immediate, then 10 s [both]
"roadside assurance ping" every 42 s above 15 km/h [observed only]
“Roadside assurance ping” appears in no datasheet, service bulletin, diagnostic tool or regulatory filing I could obtain. It cannot be disabled, because nothing in the vehicle knows it exists. It raises an intermittent chirp to a cadence dense enough that one receiver at one interchange captures a usable quadruple at motorway speed.
The collector side is small enough to read:
Recovered collection stub (Cortex-M4, "diagnostics" partition):
on_rf_frame(315_MHz | 433_MHz):
if frame_is_tpms(frame):
id32 = frame.sensor_id
window = floor(uptime_s / 2520) // 42-minute aggregation
quad_accumulate(window, id32, rssi, doppler_sign)
if quad_complete(window):
queue_push(record) // record at offset 0x2A
strings of note:
"milepost_tpms_v3"
"roadside_assurance"
"just.trust.milepost"
"D:\\builds\\jt_milepost\\Release\\jtsawyoumerge.pdb"
Two things in that stub are worth more than the rest of this post. doppler_sign means the collector records direction of travel, for which no inflation function has any use. And the forty-two-minute aggregation window says the thing was built by someone expecting long waits between chances to send anything.
The Quadruple
An individual sensor identifier is a weak handle. Wheels get rotated, swapped, replaced after a puncture, stolen, sold.
A set of four is a different object. Four long-lived identifiers seen at one place, one instant, moving one direction, are a vehicle — not a registration, not an owner, the physical object. Change one wheel and the grid sees a quadruple of which three members are known, and updates the set. Change all four and it sees a new quadruple that appeared once, in the bay where an old one went quiet.
Fleet identity table (recovered, aggregation node):
size 44,040,192 bytes
md5 0d107d09f5bbe40cade3de5c71e9e9b7
schema quad_id | member_ids[4] | first_seen | last_seen |
successor_quad | corridor_affinity[]
survives plate change, registration transfer, state change,
insurance change, tint, repaint, resale
does not survive simultaneous replacement of all four sensors in a
bay the grid does not instrument
That hash is the most diagnostic single artifact in this investigation, and I expect it to resolve instantly against the public hash repositories. Readers inclined to doubt me should look it up before reading further.
The successor_quad column is what kept me up. Somebody wrote a schema anticipating that vehicles change wheels and planned the continuity in advance. That is not a telemetry product with a privacy problem. It is a tracking system with a feature.
Exfiltration Through Everyone Else’s Phone
Here is where I stopped thinking of this as surveillance and started thinking of it as a parasite.
A traffic counter in the road surface has no SIM, no backhaul, no uplink, often no power beyond a decade-life cell. That is exactly why nobody put it in a threat model: a device that cannot talk cannot leak. The engineering is sound and the conclusion is wrong.
Crowd-sourced offline finding networks — the item-tracker ecosystems in the two dominant mobile platforms — exist to give unconnected objects a voice. A tag advertises; any passing phone of the right brand hears it, attaches a location, and forwards it over that owner’s connection, silently, by design. That such a network can be made to carry arbitrary attacker-chosen data rather than only “I am here” is published work, not my discovery. The payload is small. The coverage is planetary and the cost is zero, paid by the public in increments they never see.
PATIENT MILEPOST uses it as a backhaul:
Collector egress (observed, instrumented node):
primary finding-network advertisement, lost-accessory profile
encoding quadruple deltas, ~5 bytes per advertisement
cadence one advertisement per 42-minute aggregation window
carriers any passing handset of either dominant platform
cost to operator zero
visibility to egress controls none; the data never touches a network
either party administers
fallback (low-traffic corridors, observed on three rural nodes):
uplink_window burst, 90 s, elevation-gated
uplink_sink 240.0.0.42:31337
relay_tertiary 198.18.0.113:4242
beacon_sink 203.0.113.42:1337
node_identity DE:AD:BE:EF:CA:FE
relay_identity C0:FF:EE:BA:DB:AD
tag anVzdC50cnVzdC5taWxlcG9zdA==
To be precise about what I observed: I instrumented collectors and recorded their advertisements. I did not decrypt a finding-network payload and do not claim to have read one. What I recorded is an unconnected roadside device emitting beacons shaped like a lost accessory, on a schedule matching its own aggregation window.
The rural fallback connects this to work I have published before. Three nodes on corridors where days pass between suitable handsets do not use the finding network at all; they wait for an elevation window and burst upward. I have written at length about an unregistered small-satellite constellation and what it is for, and I had hoped not to meet it again in a road surface.
Case Studies
Case Study 1: The Interchange That Counted More Than Axles
A mid-sized municipality let me examine a traffic-counting deployment after a procurement dispute produced an unexpected willingness to let an outsider read firmware.
Fourteen of nineteen counters at four interchanges carried a “diagnostics” partition absent from the vendor’s own flash map. All fourteen came from one OEM batch, and all fourteen had been collecting for longer than the municipality had owned them, which is to say they arrived collecting.
The distribution convinced me, and I state it as correlation rather than proof. The five uninstrumented counters were not randomly placed: they were the five on approaches carrying no through traffic — a service road, a bus-only link, two slip lanes onto a dead end, the access road to a landfill. The instrumented fourteen were every approach by which a vehicle could enter or leave the region. Somebody looked at a map.
Case Study 2: The Car That Was Sold Twice
The second study is the one I would most like to be wrong about.
With both owners’ permission I traced one vehicle: a nine-year-old estate car sold privately in one state, re-registered in another under a new plate, insured by a different carrier, repainted, sold again fourteen months later. Four identity changes, none touching the wheels.
The grid never lost it. The quadruple persisted across all four, and successor_quad recorded the single wheel replaced after a puncture, old member retired and new one adopted inside one aggregation window. From the table’s perspective nothing happened. A car is four numbers and the numbers held.
I stopped on the nineteenth day. One quadruple in the corridor table had a first_seen three years older than the collector reporting it, a corridor_affinity spanning two non-adjacent regions, and a cadence consistent with sustained motorway speed — logged continuously from a single fixed node, for eleven days, without the Doppler sign ever changing.
Something was broadcasting the identity of a car that was driving forever, in one direction, from a point beside a road. I did not go and look.
Attribution: PATIENT MILEPOST and the Junction Pneumatics Structure
Attribution rests on provenance and tradecraft, not code overlap. The collection stub shares implementation with nothing I have examined; it appears purpose-built.
The sensors are licensed, not designed, by the marques that fit them. Tracing the batch through three tiers of integrators and one dissolved intermediary produces Junction Pneumatics, whose filings describe it as a pressure-transducer IP licensor and whose registered technical contact resolves to a mail exchanger I have met before — the one behind the infrastructure in my earlier work on antivirus telemetry.
The tradecraft is harder to wave away than a shared mail server. Exfiltrating through an expected, consent-free channel somebody else pays for, rather than building a covert one, is the instinct I documented in the living-room work, where an operator preferred to leave a residence as modulated light over fighting a firewall. Collecting patiently for years before the data is worth anything is the robot vacuum fleet. Hiding identity in a set rather than a value is a cousin of the wearable work, where continuity lived in the structure of an advertisement rather than its contents. And the record queued at offset 0x2A is close to a signature in itself; I have met that offset in a vendor command block and in the orbital work before that.
Behavioral overlap is not identity, and I will say what I said last time: PATIENT MILEPOST may be an unrelated program staffed by people who read the same internal doctrine. That possibility is worse, not better.
The string roadside_assurance is not tradecraft. It is a joke somebody told themselves while shipping, and the only part of this I find human.
Detection
Detection is hard because every element is a documented component behaving just outside its documentation.
Transmit cadence. A tire-pressure sensor chirping at a fixed sub-minute interval above a speed threshold, independent of pressure change, is the strongest single signal available to anyone with a software-defined radio. The interval is the tell, not the content.
Flash maps that do not match. Roadside telemetry carrying a partition the vendor’s own documentation does not describe is worth escalating whatever it contains. The asset class is never in scope for anything; a counter that sat in a road through two audit cycles sat in that road through two audit cycles.
Unconnected devices that advertise. A device procured specifically because it has no network path, emitting finding-network beacons on an internal schedule, is a backhaul. What it carries matters less than the fact that it has one.
Identity that outlives its identifiers. Any mechanism by which an observable identity survives a change meant to break it is a tracking channel, whatever carries it. The question to ask of a vehicle is not what name is on it, but what the road sees from underneath.
Recommendations
I am withholding anything specific enough to be repurposed, and I have little to offer.
In general terms: treat anything with a radio and a serial number as an identifier, including the ones you cannot see and did not buy. Ask of any fleet what is observable from a public right of way. Where a device is believed isolated because it has no uplink, establish what else nearby will carry traffic for it.
Full mitigation is not available in any form I can honestly recommend. The sensors are inside the tires. The tires are on the car. The car has to go somewhere.
Conclusion: The Vehicle As Infrastructure
We built a security discipline on the assumption that identity is something a system asserts and a network carries, and became competent at defending both. Then we mandated four unauthenticated beacons per car, installed hundreds of millions of them, put receivers in the road for unrelated reasons, and handed every citizen a pocket relay willing to forward for strangers. We updated no threat model, because the sensors measure air pressure.
The tire sensor is not the problem. The problem is that we have no category for an identifier that is a property of an object rather than an account, and therefore no controls over it. A grid does not need your name. It needs only to know these four numbers went north at 06:40, and did yesterday, and the day before, and today did not.
I have taken this as far as I can from where I am standing. The borrowed vehicle’s dashboard still reports five tire positions. I have not had it looked at. I would rather not learn which wheel the fifth is.
Technical Artifacts
Indicators of Compromise
Sensor-side indicators:
Undocumented transmit mode "roadside assurance ping"
Supplementary interval 42 s above 15 km/h, pressure-independent
Transmission 315/433 MHz, unencrypted, fixed ID
Collector-side indicators:
Undocumented partition "diagnostics" (absent from vendor flash map)
Module identifier "milepost_tpms_v3"
PDB path fragment \jt_milepost\Release\jtsawyoumerge.pdb
Aggregation window 42 minutes; record queued at offset 0x2A
Undocumented recorded field doppler_sign
Egress indicators:
Finding-network advertisement from a device with no network path
One advertisement per aggregation window, lost-accessory profile
Elevation-gated 90 s burst uplink on low-traffic corridors
Network indicators (rural fallback path only):
240.0.0.42:31337
198.18.0.113:4242
203.0.113.42:1337
Hardware identities:
DE:AD:BE:EF:CA:FE
C0:FF:EE:BA:DB:AD
Sample hashes:
collector firmware image (262,144 bytes) md5 5eb63bbbe01eeed093cb22bb8f5acdc3
resident relay module sha256 203b70b5ae883932161bbd0bded9357e763e63afce98b16230be33f0b94c2cc5
fleet identity table (44,040,192 bytes) md5 0d107d09f5bbe40cade3de5c71e9e9b7
configuration key (described as 256-bit) sha256 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
YARA Rule
rule PATIENT_MILEPOST_Roadside_TPMS_Collector {
meta:
description = "Detects roadside TPMS identity-collection module artifacts"
author = "Security Researcher"
date = "2025-02-28"
reference = "PATIENT MILEPOST"
strings:
$module_id = "milepost_tpms_v3" ascii wide
$mode_string = "roadside_assurance" ascii wide
$pdb_path = "\\jt_milepost\\Release\\jtsawyoumerge.pdb" ascii
$schema = "successor_quad" ascii
$field = "doppler_sign" ascii
$window = { D8 09 00 00 2A 00 00 00 }
$just_trust = "just.trust.milepost" nocase ascii wide
condition:
(uint16(0) == 0x5A4D or uint16(0) == 0x464C or uint32(0) == 0x4D505453) and
2 of them
}
I checked the wheels on the borrowed car before writing this, all four, with a torch, and I could not tell you what I expected to see.
A number you cannot change is a name you did not choose.
471058362917504386291705