ECU Firmware

We read the firmware — its structure, functions, data references and control logic — to understand how a platform behaves, or to build new behavior on it.

Discuss the project
Ghidra with the MapSwitch symbol tree, disassembly and decompiled function
Ghidra: MapSwitch symbol tree, disassembly and the decompiled function.

Engineering scope

What we analyze

Reverse engineering goes beyond map editing:
we work at the level of code, data and control logic.

01

Firmware analysis

Code and data structure, memory references and how they connect.

02

Function identification

Tracing cross-references, calls and variables to find the logic your project depends on.

03

Calibration strategy analysis

Linking what the firmware does to how the calibration behaves.

04

Custom function development

New control logic, built once we've confirmed it's feasible on your platform.

A2L measurement definitions with ECU addresses
A2L measurement definitions: each signal tied to its ECU address, used to link firmware logic to calibration behavior.

Processor families

Platforms we work on

Firmware analysis on the main automotive microcontroller families.

Infineon TriCore TC1797 microcontroller with a blue circuit dragon

Infineon TriCore / AURIX

Common in Bosch engine ECUs such as MED17 and MG1, and in Continental units such as Simos 18 and Simos 19.

TC1797TC2xxTC3xx

Renesas RH850/F1L microcontroller with an amber circuit dragon

Renesas RH850

Used in Denso and other Japanese-supplier control units.

RH850/F1LG3K coreDenso

NXP MPC5746R PowerPC microcontroller with a teal circuit dragon

NXP MPC5xxx / PowerPC

PowerPC e200 cores, common in Continental and Delphi ECUs and TCUs.

MPC5746Re200z4Continental

MapSwitch / CAN / UDS

MapSwitch, CAN and UDS

Availability depends on the exact ECU family, software version and vehicle.

01 / MapSwitch

MapSwitch / MultiMap

Development on selected platforms, covering map selection, switching logic, vehicle inputs and validation.

02

CAN analysis

Signal and message analysis for vehicle-state interpretation or input integration where required.

03

UDS analysis

Diagnostic communication and service behavior.

CAN frame, arbitration and unpacker tables mapped from the firmware
CAN message tables mapped from the firmware: arbitration IDs, frame descriptors and signal unpackers.

How a project runs

Process

  1. 01

    Feasibility check

    We check the hardware, software version and firmware before we commit.

  2. 02

    Static analysis

    Code, data and memory structure reviewed in Ghidra.

  3. 03

    Logic mapping

    Connecting firmware behavior to what the project needs.

  4. 04

    Implementation

    Changes or new functions built into the firmware.

  5. 05

    Bench test

    Changes verified on the bench before they go into the car.

  6. 06

    Vehicle validation

    Logged drives or dyno runs to confirm the behavior.

Handover

Deliverables and confidentiality

01

Documentation

The functions, references and control relationships that matter for your project, written up.

02

Confidentiality

Your firmware, identifiers and our implementation details are never published.