Tampering with the telematics unit.

What the telematics unit is

The TCU (Telematics Control Unit) is the bridge between the vehicle and the internet. It sits on the secondary CAN bus, listens to the vehicle's broadcast state, and — over cellular, with its own GPS and modem — relays that state to LiveWire's cloud, which is what the S2 app shows you: charge, estimated range, odometer, parked location, service status. It updates its own firmware over the air, too. The panel below is what we read directly from it over UDS diagnostics.

the LiveWire S2 app — the TCU's output, genuine

Bus role

Secondary-CAN node — consumes broadcasts; emits 0x392 / 0x395

Diagnostics

UDS 0x7D4 → 0x7DC

Location

Live GPS lat/lon — DID 0200

Cellular

eSIM (ICCID) + carrier + signal — 0298 / 0296 / 0297

Identity

F191 41001221 · serial F18C — sw MY26_S2DM_10.2

Uploads & updates

Charge / range / odometer → cloud · receives FOTA

E2E is integrity, not authentication

36 of the S2's messages carry AUTOSAR E2E Profile 1: a 6-bit alive counter (byte D7) and a CRC-8/SAE-J1850 (byte D8, over D1–D7). This is a safety mechanism — it lets a receiver notice a dropped, stale, or bit-flipped frame. It does that job well, and it's the correct tool for it.

What it doesn't do — and was never meant to — is prove who sent a frame. The CRC uses no secret; the algorithm is public, so any node on the bus can compute a valid one, and a receiver can't tell a genuine sender from an on-bus impostor. That's a normal property of unauthenticated CAN, not a defect unique to this vehicle. It only matters here because the telemetry path carries those values to the cloud without an authentication layer above the checksum.

Changing a value is a race you win once

Forging one frame is trivial: clone the real one, change the field, continue the counter, recompute the CRC.

You can't take the genuine sender off the air — it keeps broadcasting the same ID with the true value. But you don't have to out-shout it forever. Send a short burst, just fast enough to push the receiver's expected counter a few steps past the genuine sender's, and you've won: from then on the real frames arrive with a counter that's behind what the receiver expects, so they're rejected as stale — and the genuine sender, incrementing only +1 per frame, can't overtake a lead. You drop back to its own rate and simply hold. It's a race you win once, then coast. And when you stop, it doesn't snap back on the next frame either: the genuine sender has to count all the way up to the value you fast-forwarded to before its chain is contiguous again, so the further you jumped, the longer it stays locked out after you've gone quiet.

The cloud reflects the bus; the cluster reflects itself

With that race won on a stationary bike, a forged odometer changed what the app reported. The instrument cluster, which keeps its own copy, did not move — a clean confirmation of the split: the cloud takes its picture from the bus, the dash takes its from itself.

companion app · via the cloud

Meanwhile, on the bike

≈2,952mi

✓ unchanged — the cluster reads its own store

The app's “Last synced 3 seconds ago” shows the value is live, not cached. The cloud also accepted an odometer decrease of ~2,951 miles — no monotonic or plausibility check on the uploaded value. The effect is transient: it reverts once injection stops and the genuine chain catches back up.

Could you trigger an OTA?

The TCU updates itself over the air, and every update is a version decision: somewhere, something compares the software the bike is running against the latest and decides whether to flash. So the obvious question — if a device on the bus could make the vehicle report an older version than it's actually running, could it induce the cloud, or the TCU itself, to push (or at least attempt) an update? That would be the one path leading from the bus into the firmware.

Whether it's even reachable comes down to where that version check reads from. If it compares the TCU's own internal version, the bus can't touch it and the idea goes nowhere. If it reads a version the TCU relays from the bus, it's spoofable like the odometer. If it gathers other modules' versions over UDS, you'd have to win a response race. We don't yet know which — and the honest way to find out is read-only: watch what the TCU actually reads during an update check, before spoofing anything.

The diagnostic surface, and honest impact

One observation from the diagnostic side: the TCU applies UDS SecurityAccess (service 0x27) selectively. The sensitive identity records (the SIM / IMEI / auth trio) are locked behind a 128-bit random seed we watched it issue — genuinely strong. Yet in the same module, live GPS, the eSIM's ICCID, and the serving carrier read out in cleartext, with no SecurityAccess at all, through the diagnostic gateway.

We also went after the scarier possibility — a denial-of-service. Could a device on the bus silence the telematics unit by rebooting it, or reset a propulsion or brake module mid-ride? We probed the ECUReset surface directly. On the TCU it is SecurityAccess-locked (hard reset returns securityAccessDenied; the softer variants aren't implemented). On the VSC, ABS, and battery modules every reset probe came back negative — locked, not offered, or not relayed by the gateway. So no unauthenticated reboot-DoS is reachable from the bus, and the alarming mid-ride case in particular isn't there. We state it plainly because it's the version worth ruling out — and it's ruled out.