The Automotive ECU Attack SurfaceFrom Boot ROM to UDS

01Hardware: Where Trust Begins

The security of an ECU starts before the application firmware executes.

Key areas of interest include:

• MCU / SoC security features
• External Flash and EEPROM
• Debug interfaces
• Hardware security modules
• Secure elements
• Boot configuration
• Cryptographic accelerators

Debug interfaces such as JTAG and SWD can provide powerful visibility into an embedded system during development.

From a security perspective, the important question is not simply whether a debug interface exists.

What security controls protect it in the production state?

An exposed or incorrectly configured debug path can undermine higher-level software protections.

02The Boot Chain

Before an ECU can execute trusted application code, it must establish trust.

A typical boot flow may contain several stages:

1. Boot ROM
2. Bootloader
3. Secondary Bootloader
4. Application Firmware

Each transition creates a trust boundary.

A secure boot implementation typically relies on cryptographic verification to ensure that only trusted software is executed.

When assessing a secure boot implementation, important questions include:

1. Where is the root of trust located?
2. How are signing keys protected?
3. How is firmware authenticity verified?
4. What happens when verification fails?
5. Can an older firmware version be accepted?
6. Are rollback protections implemented?
7. Are debug interfaces restricted during boot?

Security is only as strong as the weakest link in the boot chain.

03Firmware: The Software Attack Surface

Once trusted execution begins, the ECU application becomes the next major attack surface.

Firmware analysis can reveal:

• Communication handlers
• Diagnostic services
• Authentication mechanisms
• Update mechanisms
• Cryptographic operations
• Memory-management behavior
• Configuration interfaces
• Hidden or undocumented functionality

A firmware assessment may combine static analysis with controlled dynamic testing.

The objective is not simply to identify suspicious code.

How does the ECU behave when its assumptions are challenged?

04Diagnostics: The Interface Engineers Often Overlook

Automotive diagnostics provide powerful functionality.

UDS services can support operations such as:

• Diagnostic sessions
• ECU identification
• Reading data
• Writing data
• Routine execution
• Security mechanisms
• ECU programming

These capabilities are essential for vehicle service and manufacturing.

At the same time, they can create a significant security boundary.

A diagnostic security assessment should consider questions such as:

1. Which services are available in each diagnostic session?
2. Which services require authentication?
3. How is Security Access implemented?
4. Are sensitive functions exposed before authentication?
5. Are programming operations sufficiently protected?
6. Are error conditions handled safely?

The goal is to identify where legitimate diagnostic functionality crosses into security-sensitive operations.

05CAN and In-Vehicle Communications

An ECU does not operate in isolation.

It communicates with other ECUs through vehicle networks such as CAN, CAN-FD and Automotive Ethernet.

A security assessment therefore needs to examine both the ECU itself and how the ECU behaves when connected to the vehicle network.

Important areas include:

• Message validation
• Trust assumptions
• Gateway filtering
• Diagnostic routing
• Message handling
• Network segmentation
• Abuse cases
• Unexpected or malformed inputs

A secure ECU should not blindly trust every message simply because it originates from an internal vehicle network.

06Updates and Persistent Security

Modern vehicles increasingly depend on software updates.

An update mechanism therefore becomes part of the ECU’s security boundary.

A secure update process should answer:

1. Who is allowed to update the ECU?
2. How is the update authenticated?
3. How is integrity verified?
4. Can an attacker install an older vulnerable version?
5. What happens when an update is interrupted?
6. Can an invalid image reach the execution stage?

Update security is closely connected to secure boot.

A secure boot mechanism can verify the software that is executed, but the update mechanism determines what software is allowed to enter the system in the first place.

A Layered Approach to ECU Security

At Shviro Lab, we think about ECU security as a chain of connected trust boundaries:

A weakness at one layer can affect the security assumptions of the layers above it.

This is why isolated testing can miss important attack paths.

What We Look For

A strong ECU security assessment goes beyond checking whether individual security features exist.

We ask:

1. Can the trust boundary be bypassed?
2. Can privileged functionality be reached unexpectedly?
3. Can firmware authenticity controls be defeated?
4. Can diagnostic functionality be abused?
5. Can network messages reach sensitive functionality?
6. Can an attacker persist a malicious or outdated image?
7. What happens when the ECU receives something it was never designed to handle?

These questions help transform a collection of security controls into an actual security assessment.

Shviro Lab Approach

Our approach combines:

Hardware Analysis

Understanding the ECU at the physical and semiconductor level.

Firmware Research

Reverse engineering and analysis of embedded software.

Protocol Analysis

Assessing CAN, CAN-FD, UDS, DoIP and related interfaces.

Security Testing

Controlled adversarial testing of exposed functionality and trust boundaries.

Vulnerability Research

Identifying weaknesses, determining root cause and evaluating practical impact.

The objective is simple:

Understand how the system works. Then determine how its security assumptions can fail.

Conclusion

The attack surface of a modern automotive ECU is not a single interface.

It is a chain.

From hardware root of trust, through bootloaders and firmware, to diagnostics and vehicle networks, every layer contributes to the security of the complete system.

A meaningful security assessment therefore needs to follow the same path as the technology itself:

From silicon to software.
From firmware to diagnostics.
From ECU to vehicle.