The increasing reliance on technology in modern vehicles has opened up new avenues for security vulnerabilities. While manufacturers continually work to patch these issues, aftermarket devices, like remote start systems, often present unique challenges. This article delves into the security of a popular remote start system, highlighting how vulnerabilities can be exploited through a “Remote Start Hack.”
The Allure of Aftermarket Remote Start Systems
Aftermarket remote start systems offer convenience, allowing drivers to start their engines and unlock their cars remotely. However, these systems, often installed by third-party vendors, can lag behind in security updates compared to manufacturer-installed systems. This gap creates an opportunity for potential remote start hacks. Our research focused on CarLinkBT, a popular remote start module from VOXX International, controlled via a smartphone app.
Deconstructing the CarLinkBT System: APK Reverse Engineering
To understand the CarLinkBT system’s vulnerabilities, we reverse-engineered its Android application package (APK). Within the APK, the classes.dex file holds the application’s code, which we converted to a JAR file using dex2jar and decompiled using Bytecode Viewer. Our analysis focused on the BLEUtilities class, responsible for Bluetooth Low Energy (BLE) communication with the remote start module.
Figure 1: Public methods within the BLEUtilities class revealing key functionalities.
This class manages the BLE connection through methods like scanLeDevice() for device discovery and connectToDevice() for establishing a connection to the module’s GATT server.
Figure 2: Code snippet from scanLeDevice(), highlighting the process of searching for the CarLinkBT module.
Exploiting the GATT Communication: A Gateway for Remote Start Hacks
BLE devices communicate using the Generic Attribute Profile (GATT), a hierarchical data structure. The CarLinkBT app utilizes the Nordic UART Service for serial communication with the module. This service relies on specific UUIDs for its components, including the UART service itself, the RX and TX characteristics for writing and receiving data, and the CCCD descriptor for enabling notifications.
Figure 3: UUIDs corresponding to the Nordic UART Service, exposing potential entry points for a remote start hack.
The application establishes a connection to the GATT server and enables notifications to receive data from the module. Critically, the writeCommandToDevice() method, responsible for sending commands, utilizes an XXTEA encryption key.
The Encryption Key Flaw: A Critical Vulnerability for Remote Start Hacks
The CarLinkBT system uses a 128-bit XXTEA encryption key for secure communication. However, a major vulnerability lies in the key generation and management. The application itself generates a random key using the generateRandomKey() method and updates the module with this key. This client-side key management creates a significant security flaw, allowing a rogue client to potentially mimic the legitimate application and send commands to the module, effectively performing a remote start hack.
Figure 4: resendDynamicKey() code snippet demonstrating the process of generating and sending a new encryption key, a potential weak point for exploitation.
Furthermore, the system allows commands to be encrypted using a default key if the dynamically generated key is not set. This fallback mechanism further weakens the system’s security, making it more susceptible to remote start hacks.
Conclusion: The Need for Enhanced Security in Remote Start Systems
Our analysis of the CarLinkBT system revealed critical vulnerabilities stemming from its BLE implementation and encryption key management. These weaknesses demonstrate the potential for remote start hacks, highlighting the need for improved security measures in aftermarket remote start systems. In part two of this series, we will delve into dynamic analysis to further confirm these findings and explore the practical implications of these vulnerabilities.
