Delphi & Marelli ECU Reverse Engineering: DCM, CR, MJ9

Delphi and Marelli ECUs: A Different Engineering Philosophy

While Bosch and Continental dominate the European ECU market, Delphi (now BorgWarner following a series of acquisitions) and Magneti Marelli (now part of the Marelli group under KKR) represent a significant share of engine and transmission control units, particularly in North American and Asian vehicles. General Motors, FCA/Stellantis, Ford, and Hyundai/Kia have all deployed Delphi ECU platforms extensively across their fleets. For anyone involved in Delphi ECU reverse engineering, these platforms present a unique set of challenges that differ substantially from Bosch or Continental architectures.

At ReverseEngineer.net, we have worked with Delphi and Marelli ECU platforms across multiple generations. Their hardware choices, firmware structure, and security implementations follow a distinctly different design philosophy. This article covers the major Delphi ECU families, the processors they use, and what makes reverse engineering these units a specialized discipline.

The Delphi ECU Platform Families

Delphi’s ECU product line spans several platform generations. The most commonly encountered families in the aftermarket and reverse engineering world are the DCM and CR series for diesel and gasoline applications respectively.

Platform	Application	Processor	Typical Vehicles
DCM3.7	Diesel (common rail)	ST Micro SPC563M	Hyundai/Kia 1.7 CRDi, Ssangyong 2.0e-XDi
DCM6.2	Diesel (advanced)	Freescale/NXP MPC5674F	GM/Opel 2.0 CDTi, Chevrolet Cruze Diesel
CR7.xx	Gasoline (port injection)	Freescale MPC5534	GM Ecotec engines, various Opel/Vauxhall
CR8.xx	Gasoline (DI/turbo)	Freescale/NXP MPC5643L	GM LTG 2.0T, Cadillac, Buick, Chevrolet
MT05/MT86	Gasoline (multipoint)	ST Micro SPC56EL	FCA/Stellantis (Fiat, Jeep Renegade 1.6)
MJ9.xx (Marelli)	Gasoline	ST Micro SPC5 family	Fiat 500, Alfa Romeo, Maserati

This diversity of processors is one of the first things that distinguishes Delphi ECU reverse engineering from working with Bosch. While Bosch standardized heavily on Infineon TriCore across its MED17/EDC17 family, Delphi spread its designs across ST Micro’s SPC5 family and Freescale/NXP’s Power Architecture (MPC5xxx). This means the toolchain, memory layout, and debug approach changes significantly depending on which Delphi platform you are working with.

Processor Architectures: SPC5 vs. MPC5xxx

The two processor families used in Delphi ECUs both implement the Power Architecture (formerly PowerPC) instruction set, but with important differences in memory protection, debug access, and security features.

ST Micro SPC5 (DCM3.7, MT05, MJ9)

The SPC5 family uses the e200z core with VLE (Variable Length Encoding) instruction compression. Flash memory is organized into multiple banks with independent erase and program capabilities. The BAM (Boot Assist Module) provides the initial boot mechanism, and JTAG/Nexus access is available through a standardized debug interface. On the DCM3.7, the SPC563M includes up to 2 MB of internal flash and 80 KB of SRAM, which is relatively modest by modern ECU standards.

The SPC5 censorship mechanism controls debug port access. When censorship is enabled, JTAG access is restricted and flash contents are protected from external reading. Bypassing this requires understanding the specific censorship implementation for each SPC5 variant, which varies in strength depending on the silicon revision. Our team has documented the behavior of multiple SPC5 censorship variants across different Delphi applications.

Freescale/NXP MPC5xxx (DCM6.2, CR7, CR8)

The MPC5xxx family, particularly the MPC5674F used in the DCM6.2, is a more powerful platform with up to 4 MB of internal flash, 256 KB SRAM, and a dual-core e200z7 running at 264 MHz. The memory map is substantially different from SPC5 devices, and the flash programming model uses a different register interface.

The MPC5xxx implements a different security model than SPC5. The JTAG port protection relies on a password-based mechanism (JTAGC module), and the flash protection uses a separate key. The CR8 platform’s MPC5643L adds hardware-based Lockstep functionality for safety-critical applications, which introduces additional complexity when attempting firmware extraction.

Working with a Delphi or Marelli ECU platform? Our team has hands-on experience with the full range of Delphi processors, from SPC5 censorship analysis to MPC5xxx flash security. Explore our ECU reverse engineering services.

Firmware Structure: How Delphi Differs

One of the most notable differences in Delphi ECU reverse engineering is the firmware organization. Bosch ECUs follow a highly standardized structure across their product line, with well-known calibration zone layouts, consistent checksum algorithms, and a predictable memory map. Delphi platforms are less uniform.

The DCM3.7, for example, stores its calibration data in a structure that does not follow the Bosch convention of clearly separated program and calibration areas. Instead, the firmware uses a custom data container format where calibration parameters are referenced through pointer tables embedded in the application code. Locating specific maps and tables requires tracing the application logic rather than simply parsing header structures, which makes tools like Ghidra essential for the analysis workflow.

The CR8 family takes a slightly more structured approach, with a defined calibration region and a header block that includes version information and integrity values. However, the calibration extraction process still requires reverse engineering the application code to build accurate map definitions, as Delphi does not use the same standardized A2L descriptor format that Bosch platforms support through ASAP2.

Checksum and Integrity Verification

Delphi ECUs implement their own checksum strategies that vary across platforms. The DCM3.7 uses a multi-region CRC32 approach with the polynomial and initialization values embedded in the bootloader. The CR8 uses a combination of CRC and signature verification. Unlike Bosch ECUs where checksum algorithms have been extensively documented by the tuning community, Delphi checksum routines often require per-platform analysis. Getting checksums wrong means the ECU will reject the modified firmware entirely, or in some cases, enter a permanent fault state.

Diagnostic and Security Access

Delphi ECUs implement UDS (Unified Diagnostic Services) for diagnostic communication, but the SecurityAccess implementation has its own characteristics. The seed-key algorithms used in Delphi platforms tend to use simpler mathematical transformations compared to the more complex challenge-response mechanisms found in Continental Simos or newer Bosch units. However, “simpler” does not mean trivial. The specific constants, shift operations, and XOR patterns differ across every hardware and software variant.

On the CAN bus side, Delphi ECUs are generally well-behaved in terms of standard OBD-II compliance, but their extended diagnostic services use manufacturer-specific service IDs and subfunctions. GM vehicles with Delphi ECUs, for instance, make heavy use of GM-proprietary diagnostic services alongside standard UDS, which adds another layer of analysis when developing custom tools or performing security research.

Need Delphi ECU firmware analysis or security research? From DCM3.7 diesel tuning platforms to CR8 gasoline direct injection controllers, we provide professional reverse engineering support for the full Delphi/Marelli product range. Get in touch with our team.

Marelli ECU Platforms: The Italian Connection

Magneti Marelli, historically the primary ECU supplier for Fiat Group (now Stellantis), developed its own ECU platform family that shares some DNA with Delphi designs but has distinct characteristics. The MJ9 (MultiJet 9) and IAW (Iniezione Accensione Weber) families are the most common Marelli platforms encountered in reverse engineering work.

Marelli ECUs are almost exclusively based on ST Micro SPC5 processors, reflecting the close relationship between the Italian semiconductor and automotive industries. The firmware architecture on Marelli units tends to be more compact than equivalent Delphi designs, partly because many Marelli applications target smaller displacement engines where the calibration complexity is lower.

What makes Marelli reverse engineering particularly interesting is the immobilizer integration. On FCA/Stellantis vehicles, the immobilizer system is tightly coupled with the ECU firmware, and the cryptographic exchange between the ECU, body computer, and key transponder follows a Marelli-specific protocol. Understanding this protocol is essential for ISN recovery, key programming, and security research on these vehicles.

PCB and Hardware Considerations

From a PCB reverse engineering perspective, Delphi and Marelli ECUs tend to use more compact board designs compared to Bosch units. The DCM3.7, for instance, uses a single-layer PCB layout that is relatively straightforward to trace, while the CR8 employs a multi-layer design with separate power and signal planes. Identifying test points, JTAG pads, and boot mode pins requires physical inspection of each specific hardware revision, as Delphi does not standardize pad locations across platform generations.

One practical challenge with Delphi hardware is connector variation. While Bosch uses a relatively small number of connector families across its product line, Delphi ECUs use different connector types depending on the vehicle manufacturer. A GM application might use a completely different connector pinout than the same DCM platform installed in a Hyundai. This means bench testing requires manufacturer-specific wiring information.

Why Delphi ECU Reverse Engineering Requires Specialized Expertise

The core challenge with Delphi ECU reverse engineering comes down to documentation scarcity. Bosch ECU internals have been studied and documented by a large global community over two decades. Continental platforms have seen increasing research attention in recent years. Delphi platforms, by comparison, have a much smaller body of publicly available research. The firmware structures are less documented, the checksum algorithms are less cataloged, and the security mechanisms are less analyzed.

This is precisely where professional reverse engineering services add the most value. Each Delphi or Marelli ECU variant requires dedicated analysis time to map the firmware structure, identify the checksum routines, understand the security model, and build the tools needed for reliable modification or analysis. There are no shortcuts, and there are no universal tools that handle every Delphi platform automatically. The work requires processor-level expertise, platform-specific knowledge, and the patience to work through undocumented firmware architectures systematically.

Whether the goal is performance calibration development, diagnostic tool creation, security assessment, or forensic analysis, Delphi and Marelli ECU platforms demand a team that has already invested the time to understand these systems at the deepest level.