Other Wireless Attack Surfaces
Tire pressure sensors and in-car DAB radios both accept untrusted RF input from the environment and feed the parsed data into ECUs or head units without authenticating it. That combination makes them attractive attack surfaces, and researchers have built practical wireless drive-by attacks against each one well before any defensive countermeasures were in place.
Tire Pressure Monitoring Systems (TPMS)
Security and Privacy Vulnerabilities of In-Car Wireless Networks: A TPMS Case Study
Rouf, Miller, Mustafa, Taylor, Oh, Xu, Gruteser, Trappe, Seskar, USENIX Security 2010 [1]
The authors mounted a practical wireless attack against a federally mandated automotive system that was already in the field, one of the first papers to do so. NHTSA had required TPMS fitment on all US vehicles sold after 2008, so the vulnerable surface was already at scale when the research appeared.
They picked two sensors, TPS-A and TPS-B, that together held a large share of the US market. Both broadcast Manchester-encoded frames in the 315/433 MHz ISM band. The rig was a USRP with a TVRX daughterboard running GNU Radio, plus a commodity ATEQ VT55 trigger tool. To reverse the frame format, they recorded I/Q while varying temperature and pressure in a controlled setting, then matched the resulting bit patterns against the sensor IDs printed on each unit. The recovered layout held a 28 or 32-bit sensor ID, pressure, temperature, flag bits, and a CRC. Neither sensor used encryption or a message authentication code.
That design has two consequences. Because the sensor IDs are static, a roadside receiver with a low-noise amplifier can read broadcasts at up to 40 meters and passively track a vehicle, with no line of sight required. And because the ECU accepts any packet carrying a matching sensor ID, spoofed frames trigger real warnings. Driving a second vehicle alongside the target on Interstate I-26, the team lit both the low-pressure and general-warning lights on the dashboard. One extended spoofing run permanently corrupted the target TPMS ECU, which then needed dealer replacement.
The authors proposed ID re-randomisation on tire changes; that recommendation remains largely unimplemented in production. The Synacktiv 2024 entry below shows what TPMS spoofing can become when combined with a vulnerable parser stack in a downstream ECU.
Dashboard snapshots during the spoofing demonstration: left front tire shown at 0 PSI with the low-pressure warning illuminated (a), and the general warning light triggered approximately two seconds later (b). Figure from Rouf et al., 2010 (Security and Privacy Vulnerabilities of In-Car Wireless Networks).
0-Click RCE on Tesla Model 3 Through TPMS Sensors
Berard, Imbert, Dehors (Synacktiv), Hexacon 2024 [3]
At Pwn2Own Vancouver 2024, Synacktiv's entry point was forged BLE TPMS advertisements handled by the Tesla VCSEC ECU (PowerPC SPC56, FreeRTOS, VLE mode). The payoff is arbitrary CAN write on the vehicle bus.
VCSEC runs a sensor enrollment flow that kicks in once the car has been moving for 90 seconds at over 25 km/h with a previously enrolled sensor missing. The bug is an integer overflow in the X.509 certificate reassembly function. startIndex is a uint32_t, and the bound check (startIndex + data_size) <= 512 overflows when startIndex sits near UINT32_MAX, so the write lands out of bounds in global memory ahead of the 512-byte certificate buffer. Immediately before that buffer is a struct pointer holding a function pointer; overwriting it and then triggering certificate validation redirects execution to shellcode, and the target has no ASLR, CFI, or stack canaries. The attack runs on two ESP32 modules. One races VCSEC to the real sensor so enrollment fails; the other poses as a sensor that VCSEC adopts, then delivers the malformed certificate.
BLE attack chain for the TPMS exploit: the Racer ESP32 blocks VCSEC from enrolling the real sensor, forcing VCSEC into auto-learn mode where it connects to the Simulator ESP32 and triggers the certificate reassembly overflow. Figure from Berard, Imbert, Dehors, 2024 (TPMS Hexacon 2024).
Digital Audio Broadcasting (DAB)
Broadcasting Your Attack: Security Testing DAB Radio in Cars
Andy Davis (NCC Group), TROOPERS 2015 / Black Hat USA 2015 [2]
Factory-fitted DAB radios are standard on most new vehicles, and the head unit processing broadcast data typically connects to the CAN bus. Because DAB is a broadcast medium, a single attacker transmission reaches every receiver in range simultaneously.
Above the audio, DAB carries several data layers, each of which the receiver has to parse. The Fast Information Channel (FIC) delivers ensemble and service metadata as Fast Information Groups (FIGs). Slideshow images in JPEG and PNG, rendered on the head unit display, arrive over the Multimedia Object Transfer (MOT) protocol. Station or track text shows up as Dynamic Label Segment (DLS) data inside Programme Associated Data (PAD). FIG 0/6 service linking records and FIG 0/22 transmitter databases are fetched over the air and stored locally, with fixed-size allocation in some implementations.
Davis built a custom DAB transmitter from OpenDigitalRadio components and a USRP B200, then turned it into a fuzzer that reached every protocol layer without touching the radio modulation. Run against in-vehicle head units from several manufacturers, it turned up a range of bugs. A malformed JPEG or PNG delivered through MOT gave code execution. DLS and ensemble label fields carried format-string conditions. Ensemble metadata stored in a local database produced SQL injection candidates, and FIG database parsers produced buffer overflow candidates. On some architectures the head unit's D-Bus interfaces were bound to all network interfaces and exposed CAN access, so code execution led to ADAS feature manipulation.
A single low-power transmitter on an unused DAB frequency can reach every compatible receiver driving through the coverage area, with no per-vehicle targeting required.
DAB attack surface diagram listing the protocol layers and media types that form the receiver's parsing exposure: FIG data within the ETI stream, MOT, DLS labels, and media formats including images and video. Figure from Andy Davis (NCC Group), 2015 (Broadcasting Your Attack).