Autos, alcohol, blood, sweat, & creative reversing obfuscated Car Modding tool

Autos, alcohol, blood, sweat, & creative reversing obfuscated Car Modding tool

Speakers: Atlas, R&D, Grim

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=uKvkBchZkA0

Overview

In this DEF CON 32 talk, "Autos, alcohol, blood, sweat, & creative reversing obfuscated Car Modding tool," speaker Atlas from Grim delves into the challenging world of automotive security and reverse engineering proprietary vehicle diagnostic and modding tools. The core objective of his team's research is to achieve remote code execution (RCE) on Electronic Control Units (ECUs) within modern vehicles, specifically targeting the authentication mechanisms that guard access to these critical systems.

The talk highlights the persistent cat-and-mouse game between automotive manufacturers striving to secure their vehicle architectures and researchers seeking to understand and bypass these protections. Atlas focuses on a particular instance where a new authentication mechanism introduced by a manufacturer necessitated a deep dive into an obfuscated Windows-based tool. This research is crucial for understanding potential vulnerabilities in the automotive ecosystem and for empowering both security researchers and legitimate aftermarket developers to interact with vehicle systems safely and effectively.

The significance of this work extends beyond mere "car modding"; gaining control over ECUs can impact everything from vehicle performance and safety features to data privacy and anti-theft systems. By dissecting the obfuscation techniques employed by manufacturers, Atlas and his team uncover the underlying logic of these authentication protocols, paving the way for advanced diagnostics, security analysis, and potentially, the development of independent tools that can interact with vehicles without relying on manufacturer-supplied software.

Background

▶ Watch: Introduction to talk and speaker Atlas (0:00)

The modern automobile is a complex network of interconnected computers, known as Electronic Control Units (ECUs). These small, dedicated computers manage everything from engine performance and braking to power steering and infotainment systems. To interact with these ECUs for diagnostics, software updates, or parameter changes, specialized tools are required. These tools typically run on a Windows system, connect to the vehicle via the OBD2 port, and communicate over the vehicle's internal CAN network.

A critical aspect of securing these interactions is the authentication mechanism. Manufacturers implement these safeguards to prevent unauthorized access to sensitive ECU functions, ensuring that only approved tools can perform actions like updating firmware or altering critical parameters. Without proper authentication, a vehicle's ECUs could be vulnerable to malicious manipulation, leading to safety hazards or performance degradation.

Atlas's project was initiated when a specific vehicle manufacturer, for whom Grim already possessed access to existing authentication methods, introduced a new authentication mechanism. This new barrier meant that Grim's existing tools and knowledge were insufficient, necessitating a reverse engineering effort to understand and bypass the updated security. The goal was to gain access to the underlying code responsible for calculating the seed key exchange or other authentication protocols. The speaker also noted that this project served as a valuable mentoring opportunity for other capable and passionate individuals, though this decision did, understandably, slow down the overall progress of the research.

Key Findings

▶ Watch: Ultimate goal: Remote Code Execution on Car ECUs (2:00)

The primary finding presented by Atlas revolved around an initial obfuscation technique encountered when analyzing the proprietary car modding tool. Upon loading the tool's single executable program into a disassembler, the entry code exhibited unusual behavior designed to mislead static analysis. This obfuscation involved a sequence of operations: pushing a value onto the stack, followed by a call instruction, and then an immediate return instruction.

Specifically, the call instruction was identified as a no-operation (no-op) call, meaning it essentially did nothing functional in terms of executing a subroutine. The true control flow manipulation occurred through the interaction of the push and return instructions. This specific pattern effectively creates an indirect jump that is not immediately obvious to a disassembler, thereby concealing the program's true entry point or a critical section of its execution flow. This finding was the initial hurdle that had to be overcome to begin the deeper analysis of the authentication mechanism itself.

Technical Deep Dive

▶ Watch: Car ECU authentication mechanisms (hex 27/29) (3:30)

The technical core of Atlas's discussion focused on the specific obfuscation technique used to hide the true execution flow of the proprietary car modding tool. When analyzing the executable in a disassembler, the initial sequence of instructions presented a deceptive path:

1. push value: A specific memory address or operand is pushed onto the CPU's stack. The stack is a region of memory used for temporary storage, particularly for function call return addresses and local variables.
2. call return: A call instruction is executed, targeting the return instruction immediately following it. A standard call instruction pushes the address of the next instruction (the instruction after the call) onto the stack as the return address, and then jumps to the target address. In this case, the target is the return instruction itself.
3. return: The return instruction is executed. A standard return instruction pops the top value off the stack and jumps to that address.

The cleverness of this obfuscation lies in the interaction between these instructions. When call return is executed, the address of the instruction after the return (let's call it next_instruction_address) is pushed onto the stack. Then, control jumps to the return instruction. When this return instruction executes, it pops the topmost value off the stack. Due to the preceding push value instruction, the value that was initially pushed is now at the top of the stack. Therefore, the return instruction effectively jumps to the value that was pushed in the first step, completely bypassing next_instruction_address and any code immediately following the return instruction in the linear flow.

This sequence (push value; call return;) is a well-known anti-disassembly technique. Static analysis tools, such as IDA Pro or Ghidra, often rely on identifying direct jumps and calls to build a control flow graph. This indirect jump, masked by a seemingly innocuous call and return sequence, can confuse these tools, causing them to misinterpret the program's actual execution path. This forces reverse engineers to manually trace the execution flow, often requiring dynamic analysis or careful manual inspection to correctly identify the true code path.

The ultimate goal of this project was to discover the code responsible for calculating the seed key exchange mechanism. This is a standard automotive authentication process, often governed by diagnostic services like Security Access (Service ID hex 27) or Authentication (Service ID hex 29). In a seed key exchange, the ECU sends a "seed" value to the diagnostic tool. The tool then uses a proprietary algorithm, often involving cryptographic functions, to calculate a "key" based on this seed. This key is sent back to the ECU. If the key is correct, the ECU grants a higher diagnostic level or security access level, enabling privileged operations such as flashing new firmware, recalibrating sensors, or modifying vehicle parameters. Bypassing this mechanism requires understanding the exact algorithm used to transform the seed into the key, which is precisely what the speaker aimed to extract from the obfuscated tool.

Demo / Proof of Concept

▶ Watch: Project goal: Accessing seed key exchange code (4:00)

While no live exploitation or tool demonstration was performed, Atlas did refer to a visual representation of the obfuscated code during the talk. He mentioned, "I don't know if you can see this, if you can't, I apologize. Basically this is showing an offsite program." This indicates that a slide or a screenshot of a disassembler output was used to illustrate the specific push value; call return; obfuscation pattern at the entry point of the analyzed executable. This visual aid served as a proof of concept for the initial challenge faced during the reverse engineering process, demonstrating how the tool's developers attempted to obscure its internal workings from analysis.

Defensive Implications

▶ Watch: First obfuscation challenge: stack jump technique (5:00)

The work presented by Atlas carries significant implications for automotive manufacturers and security defenders. For manufacturers, the talk underscores the reality that proprietary diagnostic and modding tools, even if delivered as single executables and protected by obfuscation, are vulnerable to reverse engineering. Relying solely on basic obfuscation techniques, such as the stack-based jump demonstrated, is insufficient to deter determined attackers or researchers seeking to understand and bypass authentication mechanisms. Manufacturers should consider:

1. Enhanced Obfuscation and Anti-Tampering: Employing more sophisticated and multi-layered obfuscation techniques, including virtualized execution, control flow flattening, or self-modifying code, to significantly increase the cost and time required for reverse engineering.
2. Hardware-Based Security: Integrating hardware security modules (HSMs) or trusted platform modules (TPMs) into ECUs and diagnostic tools to perform key storage and cryptographic operations, making it much harder to extract secrets from software alone.
3. Regular Security Audits: Continuously auditing their proprietary tools for vulnerabilities and weak obfuscation, adapting to new reverse engineering techniques.
4. Supply Chain Security: Ensuring the integrity of their tool development and distribution pipelines to prevent the injection of malicious code or the leakage of sensitive algorithms.

For general cybersecurity defenders and vehicle owners, this research highlights the importance of:

1. Securing the OBD2 Port: Recognizing that physical access to the OBD2 port can lead to potential compromise if the vehicle's ECUs are not adequately secured against unauthorized diagnostic tools.
2. Careful Selection of Aftermarket Tools: Exercising caution when using third-party diagnostic or "modding" tools, as these could potentially exploit vulnerabilities discovered through reverse engineering, leading to unintended modifications or security risks.
3. Awareness of ECU Vulnerabilities: Understanding that the software running on ECUs is a prime target for attackers, and that the integrity of these systems is crucial for vehicle safety and functionality.

Ultimately, Atlas's work emphasizes that the security of automotive systems is an ongoing challenge, requiring continuous innovation in defensive measures to stay ahead of sophisticated reverse engineering efforts.

Key Takeaways

• Automotive ECUs are prime targets: Gaining remote code execution (RCE) on vehicle ECUs through diagnostic or update processes is a critical objective for security researchers.
• Authentication is a key barrier: Seed key exchange and service numbers like hex 27 (security access) and hex 29 (authentication) are crucial mechanisms protecting ECU access.
• Obfuscation is a common defense: Proprietary tools use techniques like the push value; call return; stack-based jump to complicate reverse engineering efforts.
• Mentoring can impact project timelines: Using security research projects as mentoring opportunities can be beneficial for knowledge transfer but may extend project durations.
• Persistent analysis is required: Overcoming initial obfuscation is just the first step in a complex reverse engineering journey to understand and bypass automotive security protocols.

About the Speaker(s)

Atlas is a distinguished hacker who traces his roots back to DEF CON, having been "created" at the conference in 2013. He currently works in Research and Development (R&D) within cyber-physical systems for Grim, a company focused on security. Outside of his professional endeavors, Atlas is an avid motorcycle rider and a father to three daughters, none of whom are involved in technology. His work at Grim primarily involves breaking into various systems, with a long-term goal of achieving remote code execution on embedded devices, particularly automotive ECUs.