ECU firmware upgrades are similar to mobile firmware upgrades. The general process involves implementing a Bootloader and completing read/write operations on EEPROM/Flash. It is essential to understand the MCU used in the ECU, as well as the read/write operations for internal EEPROM/Flash and external EEPROM/Flash. The learning curve is steep; just the reverse engineering of ECU firmware is not easy, as it requires knowledge of over ten MCU assembly languages and the ability to write various IDA plugins, making it quite challenging. This article provides a basic explanation of ECU firmware upgrades, and any errors are welcome for correction.
1. UDS
UDS, or UNIFIED DIAGNOSTIC SERVICES, is the core of automotive diagnostics. Common UDS service SIDs are as follows:
OBD2_MODE_SHOW_CURRENT_DATA: 0x01
OBD2_MODE_SHOW_FREEZE_FRAME: 0x02
OBD2_MODE_READ_DTC: 0x03
OBD2_MODE_CLEAR_DTC: 0x04
OBD2_MODE_TEST_RESULTS_NON_CAN: 0x05
OBD2_MODE_TEST_RESULTS_CAN: 0x06
OBD2_MODE_READ_PENDING_DTC: 0x07
OBD2_MODE_CONTROL_OPERATIONS: 0x08
OBD2_MODE_VEHICLE_INFORMATION: 0x09
OBD2_MODE_READ_PERM_DTC: 0x0A
OBD2_MODE_ENHANCED_DIAGNOSTIC_REQUEST: 0x22
UDS_SID_START_DIAGNOSTIC_SESSION: 0x10
UDS_SID_ECU_RESET: 0x11
UDS_SID_READ_FREEZE_FRAME_DATA: 0x12
UDS_SID_READ_DIAGNOSTIC_TROUBLE_CODES: 0x13
UDS_SID_CLEAR_DIAGNOSTIC_INFORMATION: 0x14
UDS_SID_READ_DIAGNOSTIC_TROUBLE_CODES_STATUS: 0x17
UDS_SID_READ_DTC_BY_STATUS: 0x18
UDS_SID_READ_DTC_INFORMATION: 0x19
UDS_SID_READ_ECU_ID: 0x1A
UDS_SID_STOP_DIAGNOSTIC_SESSION: 0x20
UDS_SID_READ_DATA_BY_LOCAL_ID: 0x21
UDS_SID_READ_DATA_BY_COMMAND_ID: 0x22
UDS_SID_READ_MEMORY_BY_ADDRESS: 0x23
UDS_SID_READ_SCALING_DATA_BY_IDENTIFIER: 0x24
UDS_SID_STOP_REPEATED_DATA_TRANSMISSION: 0x25
UDS_SID_SET_DATA_RATES: 0x26
UDS_SID_SECURITY_ACCESS: 0x27
UDS_SID_COMMUNICATION_CONTROL: 0x28
UDS_SID_READ_DATA_BY_PERIODIC_IDENTIFIER: 0x29
UDS_SID_READ_DATA_BY_ID_PERIODIC: 0x2A
UDS_SID_DYNAMICALLY_DEFINE_LOCAL_ID: 0x2C
UDS_SID_DEFINE_PID_BY_MEMORY_ADDRESS: 0x2D
UDS_SID_WRITE_DATA_BY_COMMAND_ID: 0x2E
UDS_SID_INPUT_OUTPUT_CONTROL_BY_COMMAND_ID: 0x2F
UDS_SID_INPUT_OUTPUT_CONTROL_BY_LOCAL_ID: 0x30
UDS_SID_START_ROUTINE_BY_LOCAL_ID: 0x31
UDS_SID_STOP_ROUTINE_BY_LOCAL_ID: 0x32
UDS_SID_REQUEST_ROUTINE_RESULTS_BY_LOCAL_ID: 0x33
UDS_SID_REQUEST_DOWNLOAD: 0x34
UDS_SID_REQUEST_UPLOAD: 0x35
UDS_SID_TRANSFER_DATA: 0x36
UDS_SID_REQUEST_TRANSFER_EXIT: 0x37
UDS_SID_START_ROUTINE_BY_ADDRESS: 0x38
UDS_SID_STOP_ROUTINE_BY_ADDRESS: 0x39
UDS_SID_REQUEST_ROUTINE_RESULTS_BY_ADDRESS: 0x3A
UDS_SID_WRITE_DATA_BY_LOCAL_ID: 0x3B
UDS_SID_WRITE_MEMORY_BY_ADDRESS: 0x3D
UDS_SID_TESTER_PRESENT: 0x3E
UDS_SID_NEGATIVE_RESPONSE: 0x7F
UDS_SID_ESC_CODE: 0x80
UDS_SID_START_COMMUNICATION: 0x81
UDS_SID_STOP_COMMUNICATION: 0x82
UDS_SID_ACCESS_TIMING: 0x83
UDS_SID_SECURED_DATA_TRANS: 0x84
UDS_SID_CONTROL_DTC_SETTINGS: 0x85
UDS_SID_RESPONSE_ON_EVENT: 0x86
UDS_SID_LINK_CONTROL: 0x87
FORD_REQUEST_DATA_DIAGNOSTIC_DATA_PACKET: 0xA0
FORD_DYNAMICALLY_DEFINE_DIAGNOSTIC_DATA_PACKET: 0xA1
FORD_DIAGNOSTIC_COMMAND: 0xB1
GM_PROGRAMMED_STATE: 0xA2
GM_PROGRAMMING_MODE: 0xA5
GM_READ_DIAGNOSTIC_INFO: 0xA9
GM_READ_DATA_BY_ID: 0xAA
GM_DEVICE_CONTROL: 0xAE
2. AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) supports protocols such as CAN, FlexRay, LIN, Ethernet, etc. It is the standard for ECU firmware development, and UDS is part of AUTOSAR. More and more ECU firmware development is utilizing AUTOSAR.
3. XCP
XCP (Universal Measurement and Calibration Protocol) supports protocols such as CAN, SPI, SCI, TCP/IP, UDP/IP, USB, FlexRay, etc. It is the ECU calibration protocol, extending CCP (CAN Calibration Protocol).
4. ODX
ODX (Open Diagnostic Data Exchange) is based on XML and is used to describe automotive diagnostic-related data, serving as the standard format for automotive diagnostics.
5. VCI and MVCI
VCI (Vehicle Communication Interfaces) and MVCI (Multiple Vehicle Connect Interface) are communication interface standards for external ECU (diagnostic tools, diagnostic software, etc.) and internal ECU. For common ECU diagnostics (including firmware upgrades), VCI is sufficient. The protocols supported by VCI include: SAE J1850 PWM/VPW, ISO 15765-4 (CAN), ISO 9141-2, ISO 14230-4 (KWP 2000), SAE J2818 (KWP 1281), SAE J1979. SAE J1979 is primarily used for large vehicles, while SAE J2818 is mainly used by Volkswagen. In the CAN protocol, there are classifications for high-speed CAN, medium-speed CAN, and low-speed CAN. ISO 9141-2, KWP 2000, and KWP 1281 are similar to serial ports and are collectively referred to as K-Line.
6. Automotive Engines
Engines include: TD, TDI, TSI, FSI, TFSI, TDCI, TDDI, TURBO, V6, VR6, V8, etc. TDI, TSI, FSI, and TFSI seem to be more commonly used.
7. MCU
There are numerous ECUs in vehicles. Non-radio frequency-related ones can be called AP (Application Processor), while radio frequency-related ones can be called BP (Baseband Processor). This article discusses AP. The main ECUs include: BCM (Body Control Module), PCM (Power Control Module), PAM (Park Assist Module). BCM is the mainboard, and it is essential to understand the communication between PAM and PCM in the BCM firmware; PCM is the engine ECU, and understanding the processing of the MAP table in this ECU firmware is necessary; UDS may be integrated into BCM or PAM, and it is crucial to understand the processing of automotive diagnostic protocols in this ECU firmware. This article assumes that BCM, PCM, and PAM exist independently, although PCM and PAM may be integrated, and they may also be integrated with BCM. PCM and PAM are critical ECUs, and it is essential to understand the ECU manufacturers used for PCM and PAM, the MCUs employed by these manufacturers, and the EEPROM/Flash used by the ECU manufacturers. This article focuses primarily on PCM.
1. PCM
The main MCUs used include: Infineon/ST C16X/ST10, Infineon/ST Tricore TC17XX, Freescale/Motorola MPC5XX, Freescale/Motorola MPC5XXX, Freescale/Motorola HC12X, Renesas SH 70XX, Renesas SH 72XXX, Renesas V850, Renesas M16/M32, Renesas H8SX, etc.
2. PAM
The main MCUs used include: Renesas V850, Freescale/Motorola HC12X, Renesas M16/M32, common MCUs (8051, PIC, AVR), etc. V850 and HC12X are primarily used.
3. BCM
It can be divided into main modules and auxiliary modules. The main module uses known MCUs such as ARM, M16/M32, while the auxiliary module can be considered the CAN module, known to use V850 and HC12X MCUs.
4. EEPROM/Flash
Not yet focused on. The external EEPROM/Flash read/write methods for MCUs include: SPI, I2C, MircoWire, 4Wire, etc.
8. ECU Manufacturers
1. BOSCH
The MCUs used have three versions: EDC15, EDC16, MED7, MD7 use C16X; EDC16+U/C/CP, MED9, MD9 use MPC 5XX/MPC 5XXX; EDC17, MED17, MD17 use Tricore. Those using Tricore TC1796/TC1797 include: EDC17CP, MED17, MD17.
2. SIEMENS CONTINENTAL
Mainly uses C16X/ST10, Tricore, MPC5XX, MPC5XXX, with a small number using SH705X, SH72XXX. Those using Tricore TC1796/TC1797 include: Siemens SIMOS 8/12/18, Siemens SID 208/807, Siemens SDI4, Continental PCR 2.1.
3. DELPHI
Mainly uses C16X/ST10, Tricore, MPC5XX, MPC5XXX, with some using SH705X, SH72XXX. Those using Tricore TC1766/TC1767 include: MT80/MT86, while those using MPC 5566/5567 include: DCM3.5, DCM3.7, and those using SH72543/SH72544 include DCM3.7.
4. MAGNETI MARELLI
Mainly uses C16X/ST10, MPC5XX, MPC5XXX, HC12X.
5. MOTOROLA
Mainly uses MPC5XX, MPC5XXX, HC12X.
6. FORD EFI
Mainly uses MPC5XX, MPC5XXX, HC12X.
7. TRW
Mainly uses MPC5XX, MPC5XXX, HC12X.
8. TEMIC
Mainly uses C16X/ST10, MPC5XX, MPC5XXX, HC12X.
9. DENSO:
Mainly uses SH705X, SH72XXX, H8SX, and all MCUs under Renesas may be used.
10. MITSUBISHI MELCO:
Mainly uses M16/M32, SH705X, SH72XXX, and all MCUs under Renesas may be used.
11. SAGEM:
Mainly uses SH705X, SH72XXX, and all MCUs under Renesas may be used.
12. VALEO:
Mainly uses SH705X, SH72XXX, and all MCUs under Renesas may be used.
9. Automotive Manufacturers
1. Japanese Manufacturers
The main MCUs used are SH70XX, SH72XXX, but luxury brands under Japanese manufacturers (such as Honda Acura, Toyota Lexus, Nissan Infiniti, etc.) may use different ones, potentially including MPC5XX, MPC5XXX, C16X, Tricore, etc.
2. Ford and General Motors
The CAN protocols used in UDS differ; Ford uses high-speed and medium-speed CAN, while General Motors uses high-speed and low-speed CAN, with normal usage being high-speed CAN. The main MCUs employed include: MPC5XX, MPC 5XXX, C16X, Tricore.
3. Others
Bosch holds the largest market share among ECU manufacturers. If domestic or Korean manufacturers use Tricore, it seems they only use Tricore TC1766/TC1767 and likely do not employ TC1796/TC1797.
10. ECU Firmware Upgrade Methods
There are two methods: one involves invoking the already implemented BootLoader in the ECU to complete the upgrade, known as firmware upgrades via EOBD (Enhanced On-Board Diagnostic), and the other is to independently implement a Bootloader, referred to as firmware upgrades via Boot Mode. The second method can also manifest as BDM mode. In practice, EOBD upgrades can support a majority of vehicle models. For ECUs employing Tricore, MPC5XXX, SH72XXX, the Bootloader is locked, and knowledge of the unlocking algorithm/unlocking key is required to perform firmware upgrades via EOBD. In such cases, mainstream upgrade tools typically use Boot Mode for firmware upgrades. Mainstream upgrade tools seem to rarely consider Renesas MCUs; for example, K-TAG, KESS V2, CMD FLASH cannot perfectly support Renesas MCU firmware upgrades. KESS V2 offers relatively better support for Renesas MCUs, and there are dedicated firmware upgrade tools for Renesas MCUs, such as Piasini Serial Suite.
11. Implementation of ECU Firmware Upgrade Tools
There are two implementations: one is the EOBD implementation, which can support most vehicle models and can refer to AUTOSAR or VCI for implementation. MCUs can be selected from V850, C16X, Tricore, MPC5XX, MPC5XXX, HC12X, SH705X, SH72XXX, or common MCUs such as ST’s STM32, NXP’s LPC, Microchip’s PIC, etc.
The article http://bbs.pediy.com/showthread.php?t=213087 can be referenced, noting that the description of ECU in that article is incorrect. The other implementation is Boot Mode, which can refer to XCP for implementation. Although this implementation is the most universal, the hardware cost is lower than that of EOBD implementation, but in terms of firmware implementation, it requires the implementation of Bootloaders for various mainstream MCUs and the read/write of various EEPROM/Flash chips, which is quite challenging. Another possibility is to select one of K-TAG, KESS V2, CMD FLASH, reverse engineer their firmware, and rewrite their firmware. The PCBs for these upgrade tools should be single-layer, and reverse engineering their PCBs is also possible. The three major ECU upgrade tools (K-TAG, KESS V2, CMD FLASH) are expensive, often costing tens of thousands, while the hardware cost is at most around 1000, indicating that diagnostic data is quite valuable, and none of them perfectly support the firmware upgrades of Renesas’s MCUs.
12. Reverse Engineering ECU Firmware
The assembly languages that need to be understood include: Infineon/ST C16X/ST10, Infineon/ST Tricore, PowerPC (MPC5XX/MPC5XXX), M68K (HC12X), Renesas V850 E1/E2, Renesas SH2/SH4, Renesas M16/M32, Renesas H8SX, 8051, ARM, PIC, AVR, X86/X64, etc.
Firmware reverse engineering typically involves reversing firmware encryption/decryption algorithms, firmware verification algorithms, Bootloader unlocking algorithms/unlocking keys, MAP table verification algorithms, ECU security access algorithms, the implementation of automotive diagnostic protocols in UDS, the implementation of ECU firmware upgrades in UDS, UDS message verification algorithms, random number generation algorithms, etc. For most MCU firmware, IDA can disassemble; if it cannot disassemble, it is necessary to write disassembly plugins, as IDA does not know the memory mapping of firmware Bin and requires writing Loader plugins for ECU firmware Bin. There are two methods for writing IDA plugins: IDAPython and IDA SDK, with IDAPython recommended. From this, it can be seen that firmware reverse engineering primarily involves reversing algorithms, and if an IDA plugin can be implemented that recognizes loops containing arithmetic operators and logical operators, it would significantly reduce the time required for firmware reverse engineering. Implementing this plugin would require knowledge of control flow analysis.
If BCM, PCM, and PAM use an operating system, it is also necessary to know which operating system is used. More and more automotive PCMs employ Tricore, MPC5XXX, SH72XXX MCUs, and increasingly, ECU firmware is developed according to AUTOSAR standards.
13. Automotive Modification
Power-related automotive modifications can be categorized into five levels:
1. Aesthetic modifications based on aerodynamics for power upgrades, etc.
2. Modifying the MAP table in the PCM firmware, altering the automotive diagnostic protocol in UDS, and modifying the communication protocol between BCM firmware and PCM and PAM, using probes to detect the operational status of various vehicle components. This level involves only software modifications and primarily concerns MAP tables such as: Driver wish map, Torque limiter map, Smoke limiter map, Injection duration map, Boost target map, Boost limit map, Single value boost limiter map, EGR map, Pump voltage table, etc. Of course, Japanese vehicles do not necessarily use these tables. The ECU MAP modification software used includes: ECM Titanium, WinOls, official software (which is not easy to obtain), etc. This step is what is commonly referred to as ECU tuning. Since modifications at this level can easily lead to issues, it is necessary to add automotive diagnostic messages in UDS and also modify the communication protocol in BCM firmware between PCM and PAM, using probes to monitor the operational status of various vehicle components. Probes can be quite expensive, and many ECU tuning modifications only adjust the MAP table, which can easily cause problems. Strictly speaking, a map table is a solution to one or more partial differential equations; however, in practice, they are modified based on experience. At this level, automotive power can increase by 10%-30%; to achieve further increases, one must move to the next level.
3. Replacing sensors, fuel injectors, transmissions, brake pads, etc. At this level, Level 2 modifications are essential, and automotive power can increase by 50%-70%; to achieve further increases, one must move to the next level.
4. Replacing PCM, PAM, engines, etc. At this level, Level 2 and Level 3 modifications are essential, and automotive power can increase by 80%-100%; to achieve further increases, one may need to consider the vehicle’s chassis.
5. Adding an ECU. At this level, the main goal is to reduce the complexity of Level 4 modifications, as replacing PCM, PAM, and other ECUs can be very challenging. Thus, an external ECU is used for hardware hooking to achieve this. Of course, it may also involve adding more functions to the vehicle.
In foreign countries, the automotive modification industry is already very mature, with implementations across levels 1-5, while in China, it is still primarily at the level of aesthetic modifications, and a large number of Level 2 modifications are merely foreign proxies, with only a few local Level 2 modifications.
14. Conclusion
Automotive diagnostics involve multiple aspects. This article primarily explores the engine ECU in non-radio frequency-related ECUs, while radio frequency-related ECUs (WIFI, automotive keys, etc.) have not yet been addressed. Further, the EEPROM/Flash used in ECUs has not been focused on, nor has the probe components in automotive diagnostics.
PS: An attachment contains a list of automotive brands supported by KESS V2. Based on this article, one can infer the MCUs used by various automotive brands (Japanese brands mainly use Renesas MCUs, while domestic brands primarily use C16X/ST10, Tricore).
Click the bottom left corner to read the original text and view the attachment~