A team of automotive security researchers (Ren Jianwen, Jiang Jianchi, Su Shengfeng, Lin Zengda, Chen Guannan) targeted UDS Security Access (Service 0x27), the seed-and-key challenge-response mechanism that gates nearly every safety-critical operation on a car's ECUs: firmware reprogramming, parameter changes, diagnostics. Their argument is a shift in economics, not a new class of cryptographic attack: rather than reverse-engineering firmware, faulting hardware, or brute-forcing an enormous key space blindly, fingerprint which cryptographic algorithm family an ECU is using by how it behaves, then brute-force only that much smaller algorithm-specific space. Their tool, AlgoBuster, automated this end to end. Against 12 real ECUs from 9 tier-1 suppliers, it broke 2 of 12 (17%), including a body control module in about 4 hours and an engine management system in 38 minutes. This is defender-relevant automotive research; I explain the reasoning and the fix, not the working tool.
Post 30 of my Black Hat Asia 2026 series. UDS Security Access failures are already well documented in public CVE records, which the talk cites directly; I stick to that level of detail.
1. UDS and why Service 0x27 matters
UDS (Unified Diagnostic Services) is the application-layer protocol used across CAN, automotive Ethernet and LIN networks for diagnostics, configuration and reprogramming ECUs (electronic control units). It defines service classes for reading and writing data, controlling diagnostic sessions, and running routines including firmware re-flash. Every one of the safety-critical operations, flashing new firmware, changing safety parameters, is gated behind Security Access, Service 0x27: the tester (diagnostic tool) requests a random seed from the ECU, computes a key from it using a shared algorithm, and sends the key back. If it matches what the ECU independently computed, the session unlocks.
In principle this is a reasonable challenge-response scheme. In practice, the talk's core claim, backed by public vulnerability records, is that about 90% of real-world Security Access failures come from implementation weaknesses, not the protocol design itself. The protocol says "use a secure algorithm and a good random seed." Many implementations quietly don't.
2. The existing attacker's toolbox, mapped by cost and speed
The talk frames existing attack paths on a cost/time spectrum, from cheap-but-slow to fast-but-expensive:
| Approach | What it needs | Trade-off |
|---|---|---|
| Reverse engineering | Firmware extraction, disassembly of the key-derivation function | High skill and time, but yields the exact algorithm |
| Hardware attacks | Fault injection or power/EM side-channel equipment | Expensive lab setup and per-unit effort; not scalable |
| Tester leakage | An authorised diagnostic tool obtained via grey-market purchase or social engineering, then reverse-engineered | Depends on supply-chain access, not always available |
| Blind key brute-force | Nothing but the wire protocol | Exhaustive search over the full key space (commonly cited as roughly 2¹⁶ to 2³²), often impractically slow against error-counter lockouts |
Each of these paths tends to get harder as OEMs invest in countermeasures: locking debug ports blocks reverse engineering, hardware attacks are cost-prohibitive at scale, implementation flaws get patched over time, and supply chains get tighter around diagnostic tools. The talk's framing is that defenders have been closing these doors one at a time, while a cheaper path was sitting in plain sight.
3. This isn't hypothetical: public CVE history
The deck cites several already-public Security Access vulnerabilities across different vehicle platforms: predictable seed generation that let attackers predict requested seeds and bypass access via repeated resets and seed requests, hard-coded or weakly encoded passwords used as keys, and deterministic seeds enabling authentication bypass. These span multiple manufacturers and vehicle systems, reinforcing that weak seed generation and weak key derivation are a recurring, industry-wide implementation pattern, not isolated incidents.
Common root causes named in the talk include short or low-entropy seeds (small enough that the resulting key space is exhaustible), seeds with fixed or constant bit fields that quietly shrink the effective randomness, short seed-generation periods that make output cyclic and predictable, and ECUs that return the same fixed seed on the very first request after power-on.
4. The paradigm shift: algorithmic brute-force
The insight driving AlgoBuster is straightforward once stated: many ECUs don't use a cryptographically strong key-derivation function at all, they use something simple, like a small linear-feedback shift register or a short bit-shift-and-XOR construction. If you can work out which small family of weak algorithm a given ECU is using, you don't need to brute-force the entire declared key-space, you only need to search the much smaller space of parameters for that specific weak algorithm.
Fig. 1 — Narrowing the search space by fingerprinting the algorithm, rather than searching blind.
The claimed reduction is dramatic: from a full key space commonly in the range of 2¹⁶ to 2³² down to something on the order of 2⁸ to 2¹² once the weak algorithm family is identified, entirely from the wire protocol, with no firmware reverse engineering, no hardware lab, and no tester-tool leak required. That's a big shift in the cost/benefit picture for an attacker: cheap equipment, fast execution, no supply-chain dependency.
5. How AlgoBuster identifies a weak algorithm without reading firmware
The core enabling technique is fingerprinting by response-time behaviour: different algorithm implementations take measurably different amounts of computation time on the ECU, and that shows up as a statistical difference in how quickly the ECU responds to a Security Access request. The tool samples ECU response latency across many attempts, filters out network jitter using standard outlier-detection statistics, and classifies the target as likely using a "weak" or "strong" algorithm family before deciding whether to invest further effort. Devices that behave like they're running a computationally heavier, modern algorithm (AES-class) are deprioritised rather than blindly attacked.
Architecturally, the tool is described as modular: an engine that drives the actual seed-request/key-attempt/verify/reset loop, a separate registry of pluggable algorithm implementations tagged by known strength, and a detection layer that decides which algorithms are worth trying against a given target. It also automatically handles the standard UDS error response for "attempt counter exceeded" by triggering an ECU reset to clear the lockout and continue, without a human needing to intervene, which is what makes fully automated, unattended testing runs across many attempts practical.
6. Real-world results: two wins, one clear failure
| Case | System | Algorithm family | Time to break | Impact |
|---|---|---|---|---|
| A | Body Control Module | 16-bit LFSR-class | ~4 hours | Vehicle configuration codes, security keys and safety parameters alterable; firmware re-flash unlocked |
| B | Engine Management System | 5-bit shift-class | ~38 minutes | Firmware re-flash unlocked, enabling bypass of emission-restricted calibration maps |
| C | Electric Power Steering | Suspected AES-128 | ~30 hours, failed | No compromise, consistent with a genuinely strong algorithm resisting the technique |
Across the full test set, 2 of 12 ECUs (17%) spanning chassis systems, gateway modules, body electronics and cockpit units, from vehicles launched after 2018 and sourced across 9 different tier-1 suppliers, were broken. That's a meaningful failure rate for supposedly production, post-2018 automotive security hardware, and the failed EPS case is itself informative: a properly strong algorithm (AES-128-class) held up even against 30 hours of sustained automated effort, exactly what should happen.
7. Defensive recommendations
- Control debug-interface access (JTAG/SWD/UART) so the reverse-engineering path stays closed, this remains a baseline even though it doesn't stop algorithmic brute-force directly.
- Govern diagnostic tooling as a security-relevant supply chain: authorised testers should be tracked, access-controlled and themselves security-reviewed, closing the tester-leakage path.
- Harden seed generation: use a properly seeded, sufficiently long random-number source; eliminate fixed bit-fields, short cycles, and predictable cold-boot seeds.
- Enforce an algorithm whitelist: mandate a genuinely strong construction, the talk specifically calls out HMAC-SHA-256 or AES-128-CMAC, with a minimum key length of 128 bits, and explicitly prohibit trivial XOR/shift-based "algorithms" masquerading as key derivation.
- Fix error-counter reset behaviour: require an actual reboot and a meaningful time delay before an exceeded-attempt lockout clears, rather than an instantly recoverable counter that an automated tool can clear and continue past indefinitely.
Notice that the last point directly targets what made AlgoBuster's automation practical in the field: if clearing a lockout requires real time and a genuine reboot cycle rather than an instant counter reset, the entire economics of unattended overnight brute-forcing changes, even against an otherwise weak algorithm.
Does this require physical access to the car?
Yes, this class of attack targets the in-vehicle diagnostic bus (typically reachable via the OBD connector or, for some ECUs, other in-vehicle network access), not a remote network attack surface.
Is this a new cryptographic break?
No. The individual weak algorithms (short shift registers, small XOR constructions) were already known to be weak in isolation. The contribution is the systematic, automated fingerprint-then-target workflow that makes exploiting many ECUs practical without firmware access.
Why did the EPS module resist the attack?
It's suspected to use a properly strong, modern algorithm (AES-128-class). Fingerprinting can flag a target as "probably strong" and the brute-force space for a real block cipher is far too large to exhaust in any practical time, which is exactly the intended outcome of using strong cryptography here.
What's the single most important fix for OEMs?
Enforcing the algorithm whitelist (a real MAC construction like HMAC-SHA-256 or AES-128-CMAC) removes the underlying weakness the whole technique depends on; the other recommendations (debug-interface control, tester governance, error-counter hardening) are valuable defence in depth but don't substitute for using a strong algorithm in the first place.
Takeaways
- ~90% of real-world UDS Security Access failures stem from implementation choices, not the protocol's design.
- AlgoBuster fingerprints an ECU's algorithm family by response-time behaviour, then targets only that family's much smaller key space, no firmware extraction, no hardware lab, no tester leak needed.
- Real-world testing broke 2 of 12 ECUs (17%) from post-2018 vehicles across 9 tier-1 suppliers, in as little as 38 minutes.
- A genuinely strong algorithm (AES-128-class) held up against 30 hours of automated attempts, confirming the fix works.
- Fix: mandate HMAC-SHA-256 or AES-128-CMAC, harden seed entropy, and require a real time-delayed reboot on lockout, not just an instantly clearable counter.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- ISO 14229 (UDS) — the diagnostic protocol standard defining Security Access.
- CVE-2023-28896 · CVE-2023-28897 · CVE-2024-6348 — public UDS Security Access vulnerabilities cited in the talk.
- SAE J3061 — cybersecurity guidance for cyber-physical vehicle systems.