Full Report
The author simply wants to pwn his car! They bought a 2021 Hyundai Ioniq SEL to drive and play with. The author wanted to target In-Vehicle Infotainment (IVI) system. Additionally, there is a mode called Engineering Mode which requires a special code that can be fond in online manuals. While reviewing the debug diagnostics, they learned they could get some logs by plugging in a USB drive. Another option was ADB over TCP, which would be awesome. The ADB appeared to be off during a network scan so they turned to the logs. The logs had information about running processes and other things. One thing that stood out from the logs was D-Audio2V IVI for Hydunai. They downloaded the source code for this project to check it out. While on the update website for hyundai, they found firmware files for this, but it was in an encrypted zip file. Yikes! Zip encryption is vulnerable to plaintext attacks. So, if we know a set of bytes, then we can use the magic tool to recover the key. The known plaintext is a high ask though... one solution is to find similar updates they include some files that are the same. They found a set of files that had the same CRC, indicating they were the same. Using the tool doesn't work though. How come? Improper settings. While reading the issues page, they learned that the plaintext needs to be the original compressed version. We don't know the settings for the compressed file though! The author brute forced all of the zip settings until it FINALLY worked. With the file system unencrypted, they started reverse engineering the image. They noticed that the ADB TCP setting in the Engineering Mode set the IP address of eth0 to 192.168.7.110. To make it even harder, the MAC address had to be F4:50:EB:2E:58:00. After many attempts, including the use of ethtool and RtPGtoolUI from Realtek, they were able to burn the MAC address of the adapter. Sadly, the adapter always goes to eth1 instead of eth0. With this dead end being hit, they went after the firmware update process. The regular image didn't have this update though; instead, it was in an encrypted image file. From reverse engineering the file system, they found a bash script that was decrypting the image - it was the key listed in SP800-38A. The same thing was done for firmware signing as well - they searched for the public key and found the private key. The reversing process is not always easy! This is an awesome example of defeating the encryption put onto boot images and other things.
Analysis Summary
# Tool/Technique: Brute-Forcing ZIP Settings
## Overview
The procedure of systematically trying every possible combination of settings for encrypting a ZIP archive until the correct decompression method and key can be determined, allowing access to encrypted content without knowing the true configuration beforehand.
## Technical Details
- Type: Technique
- Platform: Windows/Linux (implied by external tools used for analysis and brute-forcing)
- Capabilities: Decompressing ZIP archives with unknown/misconfigured encryption settings, specifically targeting AES encryption.
- First Seen: Not applicable (General cracking/forensic technique)
## MITRE ATT&CK Mapping
- T1027 - Obfuscated Files or Information
- T1027.002 - Information Encoding
- T1564.003 - Archive Collected Data
## Functionality
### Core Capabilities
- Defeating AES encryption on a ZIP file by iterating through various possible compression settings based on observation (known plaintext attack prerequisite).
### Advanced Features
- Used in conjunction with a **Known Plaintext Attack** (KPA). If a portion of the original, uncompressed file content is known (the "plaintext"), this allows verification of successful decryption against the known block of data, even when the ZIP layer settings (like compression method, dictionary size, etc.) are unknown.
## Indicators of Compromise
- File Hashes: N/A (The *tool* used for brute-forcing is not named, only the *technique*)
- File Names: Encrypted zip files associated with Hyundai firmware updates.
- Registry Keys: N/A
- Network Indicators: N/A
- Behavioral Indicators: High CPU utilization associated with cryptographic brute-forcing tasks.
## Associated Threat Actors
- Pen Testers, independent security researchers, or malicious actors looking to extract proprietary or protected firmware/software components.
## Detection Methods
- Monitoring for unusual file decompression attempts involving high iteration counts targeting password-protected archives.
- Heuristic analysis on tools known for bulk password/setting iteration.
## Mitigation Strategies
- Utilizing encryption methods stronger than standard ZIP encryption (e.g., modern container encryption or strong integrity checks).
- Ensuring proprietary updates are signed by a key the end-user cannot obtain, making reverse engineering difficult even if the file content is eventually decrypted.
## Related Tools/Techniques
- Known Plaintext Attack (KPA)
- ZipCrack/fcrackzip (General zip cracking tools)
***
# Tool/Technique: ADB over TCP (Attempted Activation)
## Overview
A specific setting within the IVI's Engineering Mode that *intended* to enable Android Debug Bridge (ADB) connectivity over a TCP/IP network interface (Wi-Fi), typically used by developers for debugging applications running on the embedded Android/Linux system.
## Technical Details
- Type: Technique/Configuration Setting
- Platform: In-Vehicle Infotainment (IVI) system (2021 Hyundai Ioniq SEL)
- Capabilities: Allowing remote debugging session initiation to the device via the network.
- First Seen: Discovery during initial system investigation.
## MITRE ATT&CK Mapping
- T1219 - Remote Access Software (Conceptual, as it requires configuration change)
- T1090 - Proxy
- T1090.003 - Protocol Tunneling (If ADB is successfully tunneled)
- T1189 - Drive-by Compromise (If enabled and exploited without strong firewalling)
## Functionality
### Core Capabilities
- Attempted enabling of network debugging protocols on the IVI system.
### Advanced Features
- Success would have provided a direct, high-privilege channel to the running system, bypassing physical USB connections. The attempt failed because the setting did not fully activate the anticipated service (`adb` port remained closed on network scan).
## Indicators of Compromise
- File Hashes: N/A
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: Attempted connection to common ADB ports (e.g., 5555/tcp) on the IVI IP address (192.168.7.110).
- Behavioral Indicators: Network scanning revealing no open ADB services despite the setting being toggled.
## Associated Threat Actors
- Security researchers, penetration testers.
## Detection Methods
- Network Intrusion Detection Systems (NIDS) monitoring for connection attempts to unauthorized or unexpected debugging ports (e.g., 5555) on vehicle subnets.
- Configuration auditing of the IVI system state.
## Mitigation Strategies
- Disabling developer/engineering modes and debugging interfaces (like ADB) in production firmware.
- Network segmentation (if possible) to isolate the IVI network from critical vehicle controls.
## Related Tools/Techniques
- `adb connect <ip>:<port>` (Tool usage)
- Network Port Scanning (e.g., Nmap)
***
# Tool/Technique: D-Audio2V IVI Source Code Review
## Overview
The process of obtaining and analyzing the source code for the proprietary infotainment software component labeled "D-Audio2V IVI for Hyundai" to understand its structure, processes, and security mechanisms.
## Technical Details
- Type: Technique (Source Code Analysis/Reverse Engineering prerequisite)
- Platform: Hyundai IVI System Environment
- Capabilities: Understanding proprietary file handling, encryption logic, and system scripting.
- First Seen: Identified via system logs (`logcat`).
## MITRE ATT&CK Mapping
- T1059.004 - Command and Scripting Interpreter: Unix Shell
- T1027 - Obfuscated Files or Information (Used to find the unencrypted source)
## Functionality
### Core Capabilities
- Revealed the existence of a bash script responsible for creating the encrypted system update zip file.
- Revealed the exact encryption algorithm (AES 128-bit CBC), the encryption key, and the initialization vector (IV) used for firmware updates.
### Advanced Features
- Led to the discovery that Hyundai (or its supplier) was using a well-known, example AES key from the NIST SP800-38A documentation for their production update process.
## Indicators of Compromise
- File Names: `D-Audio2V` (Internal system component name).
- Behavioral Indicators: Download or access to source code repositories related to this component (if publicly available/leaked).
## Associated Threat Actors
- Security researchers, internal developers.
## Detection Methods
- Monitoring for anomalous file downloads associated with proprietary automotive software components.
## Mitigation Strategies
- Ensuring source code repositories for critical components are strictly access-controlled.
- Immediately rotating default or exemplary keys used in production systems.
## Related Tools/Techniques
- Source Code Review
- Binary Rev Engineering
***
# Tool/Technique: AES 128-bit CBC with NIST Example Key/IV
## Overview
The specific implementation of the Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode, utilizing a publicly documented, example key and initialization vector (IV) taken directly from the NIST Special Publication SP800-38A document. This oversight allowed the attacker to bypass encryption easily.
## Technical Details
- Type: Technique (Cryptography Usage Error)
- Platform: Firmware Update Encryption Layer (Hyundai IVI system)
- Capabilities: Encrypting system update archives (ZIP files) before packaging.
- First Seen: Discovery during source code analysis.
## MITRE ATT&CK Mapping
- T1564.003 - Archive Collected Data (The data being protected)
- T1022 - Data Encrypted (The mechanism being exploited)
## Functionality
### Core Capabilities
- Encrypting firmware updates using AES-128 in CBC mode.
- **Critical Weakness**: Using the *first example key/IV combination* provided in the official NIST documentation as the actual production key/IV.
### Advanced Features
- Because the key and IV were known via public documentation (a form of poor key management), the ciphertext could be decrypted using standard cryptographic libraries without needing to brute-force the key itself, provided the ZIP settings were corrected (see **Brute-Forcing ZIP Settings**).
## Indicators of Compromise
- File Hashes: N/A (The *key* is the indicator, not a file hash)
- File Names: Encrypted firmware update zip files.
- Behavioral Indicators: Successful decryption attempts of these files using the known SP800-38A example values.
## Associated Threat Actors
- Security researchers exploiting known implementation mistakes.
## Detection Methods
- Cryptographic auditing to ensure production keys do not match known public examples or defaults.
## Mitigation Strategies
- Generating unique, cryptographically random keys and IVs for every encryption operation, managed securely (e.g., Hardware Security Module).
- Never using example values from documentation in production artifacts.
## Related Tools/Techniques
- NIST SP800-38A (The document detailing the vulnerability)
- AES Decryption (Core mathematical process)
***
# Tool/Technique: Private Key Recovery from Firmware Image
## Overview
The technique used when the attacker located the RSA public key during source code analysis and, by further searching keywords within the extracted firmware file system, subsequently found the corresponding RSA private key used for signing boot images and updates.
## Technical Details
- Type: Technique (Key Management Failure)
- Platform: Extracted firmware filesystem artifacts.
- Capabilities: Allowing the creation of malicious, trusted, and signed firmware images that the IVI bootloader would accept.
- First Seen: Discovery during filesystem reverse engineering.
## MITRE ATT&CK Mapping
- T1552.001 - Credentials from Configuration Files (If the key was stored in a config file)
- T1222 - Fileless Malware (If the key was used directly in memory for signing)
- T1622 - Hardware Implant (Long-term goal once signed code runs)
## Functionality
### Core Capabilities
- Identifying and extracting the RSA private signing key.
- This key enables the attacker to bypass firmware integrity checks (digital signature verification) during boot or update processes.
### Advanced Features
- The attacker confirmed the key was likely an example key from a public OpenSSL tutorial ("RSA Encryption & Decryption Example with OpenSSL in C"), indicating extremely weak key generation practices by the vendor.
## Indicators of Compromise
- File Hashes: N/A
- File Names: Files containing RSA private key material (e.g., `.pem`, binary blobs).
- Behavioral Indicators: Successful patching/repacking of firmware images validated by the recovered private key.
## Associated Threat Actors
- Insider threats, security researchers, sophisticated APT actors targeting supply chain integrity.
## Detection Methods
- Strong scrutiny of firmware signing certificates during device updates.
- Monitoring for unauthorized generation or use of private signing keys within development or manufacturing environments.
## Mitigation Strategies
- Secure storage of all private signing keys, preferably isolated from host systems where firmware is built or analyzed.
- Using hardware roots of trust (HSM) to manage and enforce cryptographic operations, preventing the key from ever existing as a file accessible to an attacker.
## Related Tools/Techniques
- RSA Cryptography
- Firmware Signing
- `openssl` (Implied tool used for key generation/verification)