By Jason Yuan (Engineer, Automotive)
For over a decade, over-the-air (OTA) updates have become a staple for vehicles, keeping them functioning securely and at their best during their lifecycle. They offer a practical way of pushing fixes at fleet scale. However, even as they’re meant to keep vehicles secure, they also expand the attack surface.
In this article, we examine a recent case in which a researcher decrypted a legitimate Android OTA update for their car’s in-vehicle infotainment (IVI) system, exposing the entire codebase and paving the way for potential silent payload injection. Understanding the process can help reinforce validation controls and gauge the actual blast radius of a breached update.
Why secure OTA updates matter
OTA updates have transformed how automotive manufacturers (OEMs) maintain and enhance vehicle software, enabling remote patches to electronic control units (ECUs), ranging from infotainment to powertrain. OTA delivery drastically reduces recall costs, accelerates feature rollouts, and meets evolving regulatory expectations — such as those of UN R156 and ISO 24089, mandating that vehicles maintain updated software throughout their service life to reduce vulnerabilities and other security issues. As reliance on OTA updates grows, OEMs must ensure that every update is delivered reliably, verified for integrity, and capable of safe rollback. Doing so entails treating the update channel with the same engineering rigor and testing discipline as any hardware-critical subsystem.
The attack chain
The researcher wanted to directly extract the desired APK (Android package kit) files from the OTA package without having to go through a full system update. However, after downloading the OTA package, they soon found that it was encrypted. They surmised that the decryption mechanism must have resided in the updater itself, which drove them to reverse-engineer the onboard update app.
In reverse-engineering the app, the researcher found a native function that combined two hard-coded values — a static token and an embedded seed — to generate the AES (Advanced Encryption Standard) key and initialization vector (IV) needed to decrypt the update package.
By emulating this key-generation routine in Unidbg, an open-source framework for emulating Android native libraries, the researcher recovered the exact cryptographic parameters needed to unlock the core payload. From there, standard sparseimage and APK tools exposed the full application source.
Ultimately, the critical enabler of this attack was a design flaw: decryption logic and constants being directly hard-coded in the binary without obfuscation. This flaw could effectively give attackers the key to unlock any downloaded update.
Figure 1. Attack chain used to decrypt the OTA update
To mitigate this attack, OEMs should remove hard-coded secrets from update binaries, migrate key derivation into secure hardware modules, and employ code obfuscation or encryption for critical updater components to raise the bar for reverse engineers.
Fleetwide consequences
When attackers convert an OTA package into source code, they gain immediate insight into core system functions, from powertrain logic to telematics communication. For example, whitebox access to the full software stack has enabled demonstrations such as tampering with sensor data via repackaged IVI applications and remote critical vehicle modules. Because many OEMs reuse the same update logic across multiple platforms and model years, compromising a single OTA package could quickly spread vulnerabilities fleetwide, turning one breach into a chain reaction of exploits.
The key to secure OTA updates
The lesson here is not that OTA updates should be avoided; without remote updates, modern compliance goals would be impossible to attain. Rather, every build or update must pass through an unforgeable chain of trust, with each system in the vehicle (i.e., each ECU) verifying and reinforcing this trust even at runtime.
OEMs should implement continuous telemetry to monitor update integrity in real time, maintain a comprehensive software inventory to verify third-party components and cryptographic hygiene, and perform frequent offensive testing of the entire update pipeline. Consolidating integrity alerts and test findings in a vehicle security operations center (VSOC) ensures that any tampering is identified and remediated swiftly, keeping vehicle software secure throughout the vehicle lifecycle.
As vehicles become more software-defined, OTA updates will grow simultaneously more critical for vehicle security and more appealing as an entry point for attacks. Strengthening every layer of the OTA ecosystem, from development to deployment, will be essential for protecting vehicles from current and emergent threats.
