UDS Diagnostics as an Attack Surface
Unified Diagnostic Services, UDS, is how mechanics and tools talk to a vehicle’s electronic control units: read fault codes, run actuator tests, reflash firmware. It is powerful by design, and that power is exactly what makes it an attack surface. An attacker on the vehicle bus speaks the same protocol the dealer tool does. Here is how UDS becomes a way in and how it should be defended.
What UDS Is For
UDS is a standardized diagnostic protocol that runs over the vehicle’s communication buses, most often CAN, and lets a tester interact with ECUs far beyond normal operation: read and clear diagnostic trouble codes, read and write memory, run routines and actuator tests, and reprogram firmware. It is the service interface to the car’s computers.
That breadth is the point, a dealer needs to diagnose, configure, and update dozens of ECUs through one uniform interface, but an interface designed to read memory, write parameters, and reflash firmware is, from a security view, an interface designed to do everything an attacker would want, which is why how it authenticates access matters so much.
The Services That Matter
A handful of UDS services carry most of the risk, and knowing them frames the whole attack surface:
| Service | What it does | Why it matters |
|---|---|---|
| Session control (0x10) | Switches to an extended or programming session | Unlocks the powerful services, and is often ungated |
| Security access (0x27) | Seed-and-key challenge to unlock protected operations | The real gate, but algorithms are often weak or shared |
| Read/write memory (0x23 / 0x3D) | Reads or writes ECU memory directly | Direct data and code access |
| Routine control (0x31) | Runs actuator tests and routines | Can drive physical outputs |
| Reprogramming (0x34 / 0x36) | Downloads and writes new firmware to the ECU | Worst case: firmware tampering if updates are unsigned |
The Bus Is the Boundary
UDS messages travel on the vehicle bus, and historically that bus assumed every participant was trusted. An attacker who reaches the CAN bus, through the OBD-II port, a compromised ECU, or a connected telematics unit, can send UDS requests to any ECU that listens, the same as a legitimate tool.
# bring up a CAN interface and watch diagnostic traffic
ip link set can0 up type can bitrate 500000
candump can0 | grep -E '7DF|7E[08]' # common UDS request/response IDs Once on the bus, the attacker speaks UDS natively. The protocol does not care who is sending, only that the message is well-formed, so the security of the whole interface rests on what each ECU requires before honoring a powerful request. The bus position that should have been a trust boundary often is not one.
Diagnostic Sessions
UDS organizes access into sessions. The default session allows basic, safe operations; extended and programming sessions unlock the powerful services, and an attacker’s first move is usually to request a more capable session.
# request an extended diagnostic session (service 0x10, subfunction 0x03)
cansend can0 7E0#021003000000007E8 06 50 03 00 32 01 F4 # positive response: extended session active
A positive response means the ECU granted the more powerful mode, often with nothing more than the request itself. The session mechanism organizes capability, but it is not authentication, so reaching an extended session is frequently easy, and the real gate, if there is one, is the security-access step the powerful services require.
Security Access, the Real Gate
The service meant to protect powerful operations is Security Access, a seed-and-key challenge: the tester requests a seed, computes a key from it using a secret algorithm, and sends the key back, and the ECU unlocks the protected services only if the key is correct.
# request a security-access seed (service 0x27, subfunction 0x01)
cansend can0 7E0#02270100000000007E8 06 67 01 1A 2B 3C 4D # seed = 1A2B3C4D, awaiting key (0x27 0x02 ...)
The security of every protected UDS operation rests on the secrecy and strength of the seed-to-key algorithm. If an attacker can recover that algorithm, the gate opens, which moves the attack from the bus to the algorithm, and historically the algorithms have been weak.
When the Gate Fails, and Reprogramming
Seed-key algorithms have a poor track record. Many are weak, using simple transformations an attacker can deduce from a few seed-key pairs, and worse, the algorithm and its keys are often shared across an entire model or fleet, so extracting them once, by reverse engineering a dealer tool or an ECU’s firmware, breaks security access for every vehicle of that type.
The highest-stakes capability behind that gate is reprogramming, writing new firmware to an ECU, which can affect everything that ECU controls, including safety functions. The defense is the same verified-boot principle that protects any firmware: the ECU must verify a cryptographic signature on any image before accepting it, so even an attacker who reaches the programming session cannot install unsigned code. An ECU that reflashes on a weak security-access check alone, with no signature verification, is wide open to firmware tampering over the bus.
Enumerating Which ECUs Respond
An attack or an assessment starts by finding which ECUs answer diagnostics and what they expose. A functional broadcast request for a diagnostic session prompts every listening ECU to reveal itself, turning a silent bus into a map of reachable targets.
# broadcast a diagnostic session request and see which ECUs answer
cansend can0 7DF#0210030000000000
candump can0 | grep -E ' 7E[0-9A-F] '7E8 06 50 03 ... # engine ECU answered 7E9 06 50 03 ... # transmission ECU answered 7EB 06 50 03 ... # body control module answered
Three ECUs answering the broadcast is the target list. Each address that responds is a controller exposing UDS, and the next step is probing each for the powerful services and the strength of its security access, which is where the real findings live.
Recovering the Seed-Key
When the security-access algorithm is weak or shared, recovering it is the whole attack. Some are simple enough to solve from a handful of observed seed-key pairs; others fall to extracting the algorithm from a dealer tool or the ECU firmware. Either way, once recovered, the attacker computes valid keys at will.
# observed pairs reveal a trivial transform in many legacy ECUs
seed 1A2B3C4D -> key 2A3B4C5D # key = seed + 0x10101010 ?
seed 11223344 -> key 21324354 # confirms the constant-add algorithmalgorithm recovered: key = seed + 0x10101010 (shared across this ECU family) -> security access defeated for every vehicle using this ECU
A constant-add algorithm shared across an ECU family is a real and recurring weakness: solving it once unlocks protected services on every matching vehicle. That is why per-vehicle, cryptographically strong security access and signed reprogramming matter so much, because the alternative is a fleet-wide bypass from a few observed messages.
Defending the UDS Surface
Defending UDS works in layers. Strong, per-ECU or per-vehicle security-access algorithms, not shared, weak ones, raise the cost of unlocking protected services; signed firmware updates ensure that even an unlocked programming session cannot install malicious code; and restricting which services are reachable, and from where, means an ECU need not expose its full UDS capability to every bus it touches.
Newer vehicles also segment the internal network and add message authentication, so an attacker on the infotainment network cannot freely send UDS requests to safety-critical ECUs, with a central gateway enforcing what diagnostic traffic may cross between domains. That architectural shift addresses the root problem, that the bus was a trust boundary in name only, and contains the damage when an exposed interface like telematics is compromised. The principle throughout is to stop treating bus presence as authorization and to require real cryptographic proof for the operations that matter.
Where This Fits
Assessing automotive diagnostic interfaces, the UDS surface, security access, and ECU reprogramming, is specialized automotive security work within a product security assessment. If you build vehicle ECUs and want your UDS exposure tested the way an attacker on the bus would, that is the kind of work we do at Berkner Tech.
