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 in ways far beyond normal operation. It can 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, and UDS gives a uniform way to do it. 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 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 IDsOnce 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, memory access, routine control, reprogramming, and an attacker’s first move is usually to request a more capable session to reach those services.
# 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 to the session request 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 that 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. The ECU unlocks the protected services only if the key is correct. This is the mechanism that is supposed to keep attackers out.
# 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 Security Access Fails
Seed-key algorithms have a poor track record. Many are weak, using simple transformations an attacker can deduce from a few seed-key pairs. 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 algorithm also lives in the ECU firmware, which an attacker can extract and analyze, recovering the seed-to-key function directly. A weak algorithm can be brute-forced or solved from observed pairs; a shared one, once recovered, is universal. Either way, the gate that protects reflashing and memory access often does not hold against a determined attacker.
The Reprogramming Risk
The highest-stakes UDS capability is reprogramming, writing new firmware to an ECU. An attacker who passes security access and reaches the programming session can attempt to flash modified firmware, which on a vehicle ECU can affect everything that ECU controls, including safety functions. This is the worst-case UDS attack.
The defense is the same verified-boot and signed-update 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 based only on passing a weak security-access check, with no signature verification, is wide open to firmware tampering over the bus.
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 modern vehicle architectures add authentication to the bus itself, so not every participant is trusted equally.
Restricting which services are reachable, and from where, also helps: an ECU need not expose its full UDS capability to every bus it touches, and gateway ECUs can filter diagnostic traffic between segments. The principle is to stop treating bus presence as authorization and to require real cryptographic proof for the operations that matter, especially reprogramming.
Bus Authentication and Segmentation
Newer vehicles segment the internal network and add message authentication, so an attacker on one bus, say the infotainment network, cannot freely send UDS requests to safety-critical ECUs on another. A central gateway enforces what diagnostic traffic may cross between domains, turning the formerly flat bus into zones with controlled boundaries.
This architectural shift addresses the root problem, that the bus was a trust boundary in name only. By authenticating critical messages and filtering diagnostic access at gateways, the design ensures that reaching one bus does not grant UDS access to everything, which contains the damage when an exposed interface like telematics or infotainment is compromised.
Testing UDS Security
Assessing a vehicle or ECU’s UDS exposure means walking the same path an attacker would: reach the bus, enumerate which ECUs and services respond, attempt to enter extended and programming sessions, and evaluate the security-access algorithm by recovering it from firmware or solving it from seed-key pairs. Finally, test whether reprogramming requires a valid signature.
Each step maps to a defense and a finding. Easily reached powerful sessions, a weak or shared seed-key algorithm, and unsigned reprogramming are the serious findings, and they point directly at the fixes: strong per-vehicle access, signed updates, and bus segmentation. Testing the surface this way gives a manufacturer a clear picture of what an attacker on their bus can actually do.
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 and their diagnostic addresses.
# 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, weak seed-key algorithms and unsigned reprogramming, are found.
Brute-Forcing and 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.
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.