Programming a CTS-V Gauge Cluster into an ATS-V, out of pure spite

Programming a CTS-V Gauge Cluster into an ATS-V, out of pure spite

Speakers: Varjitt Jeeva

Conference: DEF CON 32

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

Overview

In a compelling presentation at DEF CON 32, software engineer and automotive enthusiast Varjitt Jeeva detailed his journey to retrofit a fully digital gauge cluster into his Cadillac ATS-V. Driven by what he described as "pure spite" against the exorbitant paywalls and proprietary services offered by aftermarket programmers, Jeeva embarked on a reverse-engineering quest to understand and replicate the process himself. His talk, "Programming a CTS-V Gauge Cluster into an ATS-V, out of pure spite," not only showcased a successful and cost-effective modification but also exposed significant vulnerabilities and design oversights within General Motors' (GM) diagnostic and programming ecosystem.

The core problem Jeeva faced was that while Cadillac produced a sophisticated 12.3-inch digital gauge cluster for various models, his 2016-2019 ATS-V, despite being a high-performance vehicle, was inexplicably shipped with an outdated analog needle cluster. Aftermarket services offered to perform the digital retrofit for hundreds of dollars, without revealing the underlying methodology. Jeeva's presentation meticulously unraveled GM's module programming protocols, demonstrating how he leveraged publicly available information, inexpensive tools, and a keen understanding of software to achieve the desired outcome, saving over $1000 in the process and subsequently open-sourcing his findings.

This talk is significant because it highlights the friction between OEM control over vehicle functionality and consumer desires for customization. By dissecting a seemingly complex and proprietary process, Jeeva empowered other enthusiasts and exposed how easily fundamental security principles, such as data integrity and authentication, can be overlooked in automotive systems. His work serves as a powerful example of how curiosity and a "do-it-yourself" mentality can circumvent artificial barriers and foster a more open approach to vehicle modification and repair.

Background

▶ Watch: Introduction: Retrofitting digital cluster, avoiding paywalls (0:00)

The Cadillac ATS-V, produced between 2016 and 2019, was a formidable performance car, yet it was equipped with an analog gauge cluster, a stark contrast to the advanced 12.3-inch digital clusters available in other contemporary Cadillac models like the CTS V-Sport or Escalade. This disparity was a source of frustration for many owners, including Varjitt Jeeva, who desired the modern digital interface. The aftermarket responded by offering programming services to retrofit these digital clusters, but these services came with steep price tags, ranging from $250 to $350, with some "courses" and "tools" collectively costing over $1000. The lack of transparency and the proprietary nature of these services fueled Jeeva's determination to uncover the underlying mechanics.

Jeeva's initial investigation revealed several crucial points that laid the groundwork for his project. Firstly, the 12.3-inch digital gauge cluster was physically compatible with his ATS-V, sharing the same electrical plug. This suggested that the retrofit was not a matter of hardware incompatibility but rather a software or configuration limitation imposed by GM. Secondly, the Cadillac CTS V-Sport, which shared the same 3.6-liter twin-turbo engine as the ATS-V, was equipped with the desired digital cluster and displayed the appropriate performance-oriented views. This implied that the necessary graphics and software for the ATS-V's engine configuration likely already existed within GM's ecosystem.

A pivotal discovery was that the total set of configuration flags between the analog and digital clusters was identical. This strongly indicated that the digital cluster could have been shipped with the ATS-V from the factory, but GM simply chose not to enable it. This insight transformed the problem from a complex hardware or firmware modification into a challenge of understanding and manipulating GM's module programming process. Jeeva identified that GM's CAN bus module programming typically involves three distinct steps: authentication, general-purpose firmware software programming, and setup and configuration of specific feature sets. His goal was to navigate these steps without relying on expensive third-party tools or services, proving that the information and capabilities were largely accessible to anyone willing to investigate.

Key Findings

▶ Watch: The core challenge: Making donor cluster display target view (3:20)

Varjitt Jeeva's project yielded several critical findings that not only enabled his personal retrofit but also illuminated significant aspects of GM's automotive electronics architecture and programming security.

Firstly, the most fundamental discovery was the inherent compatibility of the digital gauge cluster with the ATS-V. Despite GM's decision not to offer it, the physical connector was identical, and the underlying software and configuration capabilities of the 12.3-inch cluster were already equipped to display the necessary views for the ATS-V's specific engine and features. This was confirmed by later analysis of calibration numbers, which revealed that the firmware for the donor Escalade cluster was identical to that of the target CTS V-Sport.

Secondly, Jeeva identified a severe security oversight in how GM stores critical module identification data. The EEPROM chip (specifically an I2C 24C16) on the back of the gauge cluster contained the vehicle's VIN number (17 digits) and a 4-digit security PIN in plain text. This information, essential for module authentication within the vehicle's network, could be easily read and written using an inexpensive $5 CH341A EEPROM programmer purchased from AliExpress. This rendered the initial authentication step trivial to bypass by simply matching the cluster's stored VIN and PIN to the target vehicle's Body Control Module (BCM).

Thirdly, the GM SPS2 dealer software (Service Programming System 2), a Java-based application available through an AC Delco subscription ($45 for two years) and requiring an MDI cable ($186), was found to have exploitable characteristics. While designed for dealership use, Jeeva discovered that the software downloads crucial configuration files to the local machine's C drive (e.g., C:\ProgramData\GM Tools\SPS\Cache). Critically, these cached configuration files, including build code.build record.bld and associated XML mappings, were not checksummed or cryptographically validated by SPS2. This allowed Jeeva to directly edit these local files, tricking SPS2 into programming the desired configuration flags into the cluster without GM's servers detecting any unauthorized modification.

Finally, Jeeva uncovered methods to acquire proprietary information, such as security PINs and configuration files for specific vehicles, directly from GM's systems without resorting to costly third-party services. He demonstrated that by running a dummy configuration attempt in SPS2 for a VIN he didn't own, the system would attempt to authenticate and log the VIN and its corresponding security PIN in the SPS tool bridge.log file, making it accessible for free. Similarly, by initiating a programming session for a target VIN and then disconnecting the MDI cable before completion, SPS2 would download all relevant firmware and configuration files to the local cache, effectively allowing users to "pull" files for any vehicle for which they had a subscription. These findings collectively dismantled the perceived complexity and proprietary nature of GM's programming ecosystem, proving that significant customization could be achieved with minimal investment and clever reverse engineering.

Technical Deep Dive

▶ Watch: Discovering VIN/PIN on e-prom with $5 tool (4:20)

Jeeva's technical approach systematically addressed the three phases of GM module programming: authentication, firmware programming, and configuration.

1. Authentication Bypass (EEPROM Modification):

The initial hurdle was authenticating the donor cluster (from a 2017 Escalade) with his ATS-V's Body Control Module (BCM). In GM vehicles, the BCM stores the official vehicle mileage, and a module mismatch (VIN/PIN) results in the cluster displaying "---" instead of the odometer reading. Jeeva's breakthrough came from physically inspecting the cluster. He identified an I2C 24C16 EEPROM chip on the circuit board. Using a readily available CH341A EEPROM programmer (a $5 tool), he dumped the chip's contents.

Upon analysis, he discovered that the vehicle's 17-digit VIN and a 4-digit security PIN were stored in plain text within the EEPROM. This was a critical security vulnerability. Jeeva simply modified these values in the EEPROM dump to match his ATS-V's VIN and PIN. After flashing the modified data back to the EEPROM, the cluster immediately authenticated with the BCM, correctly displaying his car's mileage. This demonstrated that GM's module authentication, at least for this component, relied on easily modifiable, unencrypted data.

2. Firmware Programming (Calibration Number Verification):

The next step involved ensuring the cluster had the correct firmware and graphical assets for the ATS-V's performance view, specifically the one found in the CTS V-Sport. GM uses SPS2 (Service Programming System 2), their dealer-level software, to flash firmware and software to modules. To determine if a firmware update was even necessary, Jeeva used a publicly accessible GM resource: the Opel website. Opel, a former GM subsidiary, hosts an interface that allows users to check calibration numbers—unique identifiers for specific firmware sets.

Jeeva took the VIN from his donor Escalade cluster and compared its calibration number to that of a target 2017 Cadillac CTS V-Sport. To his surprise, both vehicles shared the exact same calibration number. This meant that the Escalade cluster already contained all the necessary views, graphics, and software required for the CTS V-Sport, including the high-performance display he desired for his ATS-V. No firmware flashing was needed; the desired views were simply "hidden" and needed to be activated through configuration. This finding saved a significant amount of effort and highlighted the modularity and reusability of GM's software assets across different vehicle lines.

3. Setup and Configuration (Local File Manipulation):

This was the most intricate part, involving the manipulation of configuration flags to "reveal" the desired V-Sport view. GM's SPS2 software, when performing a "Setup and Configuration" function, downloads configuration data to the local computer. Jeeva located these files in a directory similar to C:\ProgramData\GM Tools\SPS\Cache.

Within this cache, he found several key files:

• build code.build record.bld: This file contains the vehicle's VIN, chassis code (e.g., 6AE47 for his ATS-V), and a list of RPO codes (Regular Production Option codes). RPO codes are GM's internal codes for specific vehicle options, such as UDV for the 12.3-inch digital cluster or UDD for the analog cluster.
• XML files: These files contained a logical mapping that defined how specific P_flags (internal configuration flags) should be set based on the presence of certain RPO codes and chassis codes in the vehicle's build record. For example, an XML entry might state: "If RPO code UDV exists and chassis code is 6AE47, then set P_flag_X to value_Y."

Jeeva's ingenious bypass leveraged a critical vulnerability: SPS2 does not checksum or validate the integrity of these local cache files before using them. He performed the following steps:

1. He edited the build code.build record.bld file to include his ATS-V's chassis code (6AE47), engine code (LF4), and, crucially, the UDV RPO code (for the digital cluster).
2. He edited the relevant XML configuration file to ensure that when SPS2 processed the UDV RPO code in conjunction with his ATS-V's chassis code, it would correctly enable all the necessary P_flags for the 12.3-inch digital cluster and the CTS V-Sport view.
3. He then ran the "Setup and Configuration" function in SPS2. Because the software used the locally modified files without verification, it proceeded to program the cluster with the desired settings.

Bonus Discoveries:

Jeeva also shared two additional methods to extract valuable information:

• Grabbing any VIN's Security PIN: By running a dummy "Setup and Configuration" in SPS2 for a VIN he didn't own against his own car, the authentication would fail. However, the SPS tool bridge.log file, located in the SPS2 directory, would contain the attempted VIN and its corresponding 4-digit security PIN. This bypassed $50 VIN-to-PIN services.
• Downloading Configuration Files for Any Vehicle: By purchasing an AC Delco subscription for a specific target VIN (e.g., a CTS V-Sport) and initiating a programming session for that VIN, SPS2 would download all associated configuration files to the local cache. By simply yanking the MDI cable before the programming completed, Jeeva could acquire these files without actually programming his car with the incorrect VIN, effectively creating an offline repository of GM configuration data.

These detailed technical steps illustrate how Jeeva systematically dismantled the perceived complexity of GM's proprietary systems, turning what was once an expensive, opaque service into an accessible, open-source process.

Demo / Proof of Concept

▶ Watch: First success: Cluster connects, mileage confirms authentication (6:00)

While the talk itself served as a comprehensive demonstration and walkthrough of the entire process, Varjitt Jeeva provided clear evidence of his successful Proof of Concept (PoC). He presented a picture of the 12.3-inch digital gauge cluster fully functional and installed in his Cadillac ATS-V.

The key aspects demonstrated were:

1. Correct Odometer Display: The cluster successfully authenticated with his car's Body Control Module (BCM), indicated by the correct vehicle mileage being displayed. This confirmed the successful EEPROM modification where the VIN and security PIN were updated to match his ATS-V. If authentication had failed, the odometer would have shown "---".
2. Desired CTS V-Sport View: The digital cluster was actively displaying the specific performance-oriented view that he aimed to achieve, identical to what would be found in a Cadillac CTS V-Sport. This validated the successful manipulation of the local SPS2 configuration files and the subsequent programming of the cluster's P_flags.
3. Seamless Integration: The cluster was shown to be fully integrated and working within his vehicle, pulling live values and responding as expected, indicating that all three stages of GM's module programming (authentication, firmware compatibility, and configuration) had been successfully addressed.

Jeeva emphasized that this entire process was achieved for free, aside from the cost of the AC Delco subscription and MDI cable (which are legitimate tools for car diagnostics), and the $5 EEPROM programmer. He explicitly stated that he did not pay any of the $1000+ advertised for proprietary tools or services, validating his core motivation of circumventing paywalls. The practical demonstration served as a powerful testament to the feasibility and effectiveness of his reverse-engineering efforts.

Defensive Implications

▶ Watch: Understanding GM's official SPS2 programming process (6:30)

Varjitt Jeeva's findings present significant defensive implications for both General Motors as an OEM and for vehicle owners/defenders dealing with automotive cybersecurity.

For General Motors (OEM):

1. Data Integrity and Authentication: The most glaring vulnerability is the storage of VIN and security PIN in plain text on the EEPROM chip. This allows for trivial modification and module spoofing. GM should implement cryptographic measures such as encryption for sensitive data stored in EEPROMs and introduce hardware-backed secure boot or attestation mechanisms to verify the authenticity and integrity of installed modules.
2. SPS2 Software Security: The lack of checksums or cryptographic signatures for locally cached configuration files within SPS2 is a critical flaw. This allows an attacker (or an enthusiast like Jeeva) to modify these files and trick the official programming tool into applying unauthorized configurations. GM needs to implement robust validation mechanisms to ensure that only approved and untampered configuration files are used for programming.
3. Information Leakage: The SPS tool bridge.log file leaking security PINs during failed authentication attempts is an unacceptable information disclosure. Sensitive credentials should never be logged in plain text, especially in a file accessible on a local machine. Logging should be restricted to necessary diagnostic information, and sensitive data should be redacted or encrypted.
4. Supply Chain Security: The fact that calibration numbers are identical across different models (Escalade and CTS V-Sport) suggests a common software base. While efficient, this highlights the need for rigorous security testing of shared components, as a vulnerability in one module could potentially affect many different vehicle lines.
5. Customer Relations and Official Retrofits: The high demand for digital cluster retrofits, coupled with the ease of achieving it through reverse engineering, indicates a market need that GM failed to address. Offering official, reasonably priced retrofit options could deter customers from seeking unofficial, potentially risky, or security-compromising solutions.

For Users and Defenders:

1. Awareness of OEM Weaknesses: This talk serves as a stark reminder that even official OEM tools and systems can harbor significant security vulnerabilities. Users should be aware that diagnostic interfaces, while necessary, can also be vectors for unauthorized access or modification if not properly secured.
2. Inexpensive Tooling: The project demonstrates that sophisticated car hacking or modification doesn't always require expensive, specialized equipment. A $5 EEPROM programmer and a legitimate dealer tool (SPS2) were sufficient to bypass several layers of intended security.
3. Open-Source as a Counterbalance: Jeeva's decision to open-source his findings provides a valuable resource for the community, empowering individuals to perform their own modifications and repairs without being beholden to proprietary services. This fosters a more resilient and knowledgeable user base.
4. Implications for Vehicle Integrity: While Jeeva's intent was benign customization, the methods demonstrated could theoretically be adapted for more malicious purposes if an attacker gained access to a vehicle's programming environment. This underscores the importance of securing physical access to diagnostic ports and understanding the capabilities of diagnostic software.
5. Future-Proofing: As vehicles become more software-defined, understanding how to interact with and potentially modify their underlying systems will become increasingly important for repair, maintenance, and customization, challenging manufacturers to build more secure yet accessible platforms.

In essence, Jeeva's work is a case study in how simple security oversights can undermine proprietary control and how determined reverse engineering can demystify complex systems, pushing OEMs to reconsider their security postures and their relationship with the aftermarket and enthusiast communities.

Key Takeaways

• GM's digital gauge clusters are highly adaptable: Many GM digital clusters contain multiple vehicle profiles and graphical assets, capable of supporting various models and engine configurations, even if not officially offered for a specific vehicle.
• Basic EEPROM security is lacking: Critical information like VIN and security PIN can be stored in plain text on easily accessible EEPROM chips, allowing for straightforward modification and authentication bypass with inexpensive tools.
• OEM diagnostic software has exploitable flaws: GM's SPS2 dealer software was found to lack crucial integrity checks (e.g., checksums) on locally cached configuration files, enabling local manipulation to program unauthorized settings into vehicle modules.
• Security PINs can be extracted for free: The SPS2 logging mechanism inadvertently leaks security PINs during failed authentication attempts, providing a free alternative to paid VIN-to-PIN services.
• Open-source empowers customization and cost savings: By reverse-engineering and open-sourcing the process, Varjitt Jeeva saved over $1000, demonstrating that many "proprietary" vehicle modifications can be achieved with public information and minimal investment.
• Automotive industry needs improved security: The findings highlight a broader need for better security practices in automotive software development, particularly concerning data storage, software integrity validation, and diagnostic tool robustness.

About the Speaker(s)

Varjitt Jeeva is a software engineer with a strong passion for cars. Growing up in the "Fast and Furious era," he developed an early interest in Japanese performance vehicles. More recently, he acquired a Cadillac ATS-V, a six-speed manual with 400 wheel horsepower, which he describes as a car he falls more in love with every day. His project to retrofit a digital gauge cluster into his ATS-V, driven by a desire to avoid expensive aftermarket paywalls, led to his first-ever appearance as a speaker at DEF CON. His work exemplifies the intersection of software engineering skills and automotive enthusiasm.