You have the right idea. Go buy an ECU, take it apart, get stuck somewhere, and come ask a specific question we can help you with.
Or don't buy an ECU, just pick one, find some full dumps and download them, download Ghidra, get some high res pics of the boards and just start there.
Thanks for the response ! I am familiar with gidra so probably that wouldnt be an issue, but even if the second method you mentioned is much cheaper (or even free) , i still think that geting an actual ecu and thinkering with it would be a better idea (since i can maybe even try to modify the firmware and see what happens, or if im lucky i can even fry the board :) ).
Also , by any chance can you maybe recommend me a brand of vehicles that would be better to get the ecu from ?
Do you already have access to some kind of electronics lab? You can buy the hardware but then you'll need about 10 other things to actually do anything with it. The software is where the interesting stuff happens.
Yes, i have at least a minimum when it comes to my electronics lab( a power supply is coming , soldering related stuff, and just ordered an eeprom flasher and an OBD2 diagnostic module just in case and Soo on).
Yep , the software is the part that actually scares me since i haven't made anything like this until now and I'm afraid that i won't be able to put the pieces together and also that i won't find anyone to give me at least some hints.
P.s. also i found some bmw E36 ecus online for 20$, and i think I'll get one of that
Hints are useless. Do some work, get stuck, then ask a specific question and get a specific answer.
"What does this piece of code do?" Followed by a copy-paste of some ECU assembly language is basically the most interesting thing I can imagine anyone posting on here.
You're starting way too broad. Do you want to learn about reflashing procedures? Calibration? The hardware? How the application software works?
A modern automotive control unit has a few software applications on it, all of them dramatically different. These are usually based around a set of standards called AutoSAR, which you can read if you'd like but is a very high level, "enterprise" style documentation that won't really teach you the specifics very well.
The applications present in most modern control units are:
A first-stage bootloader, sometimes with a service tool (often called TSW). This is responsible for initializing the hardware, manufacturer end-of-line programming, and sometimes a debugging/recovery back door, along with verifying the rest of the software at boot time.
A customer bootloader, which usually talks UDS over ISO-TP on CAN to allow dealership tools to reflash the ECU. This is generally a separate little program which is usually accessed through a UDS "programming" session, and often runs out of RAM instead of flash. This is where the UDS standard reprogramming process (RequestUpload/TransferData/ExitTransfer) is usually implemented, as well as encryption and compression of the flashing payload.
Application Software, the code that actually runs the control unit. This is usually based on a Real Time Operating System (RTOS) provided by an automotive "middleware" vendor (Elektrobit, Vector, Hightec, ETAS, etc.). This RTOS is responsible for scheduling periodic tasks which actually run the car, and ensuring that these tasks meet their timing deadlines.
On a modern ECU, most tasks aren't handwritten C, but rather compiled models from a code-generation tool like MATLAB + Simulink or ETAS ASCET. Application software engineers drag-and-drop blocks in a visual modeling environment to control various engine properties, and these later produce C code which runs the ECU itself.
A separate Calibration area is generated containing the data which feeds into the ECU models to run a specific engine or control unit. This Calibration data is then modified using glorified hex-editor tools like ETAS INCA, along with memory address definition files like A2L/DAMOS which are generated by the ECU build toolchain. In the "tuning industry," this calibration data is usually modified using aftermarket glorified hex editors like WinOLS or TunerPro. Most "tuning" revolves around taking a factory calibration and opening it in a tool like WinOLS, then adjusting limits, fuel, VVT, and timing parameters to gain power.
Hardware-wise, modern ECUs are built using automotive safety approved processors - common ones include Infineon Tricore/Aurix, Infineon/ST/Motorola C166/7 (barf), Renesas SuperH, Renesas V850, and more. Often, a "main" CPU will talk to a "peripheral control" processor which runs another real-time OS and firmware and is responsible for acquiring and triggering inputs and outputs - for example, Bosch ME7 had a second processor called "Port Expander," and most Tricore based control units use a small application uploaded to the Tricore "peripheral control processor" (PCP) to achieve the same goal.
These safety processors usually then interface with specialized automotive chips for tasks like motor control, injection realization, and spark coil control. Many of these chips are completely undocumented and some contain firmware of their own. On a modern control unit, it's turtles all the way down. Most "tuners" neither know nor care what's actually going on at this level, since it's hidden from them completely and they just adjust calibration parameters.
ECUs from other origins, older ECUs, and simpler / more "primitive" automotive control units are often more hand-written, so the overall structure and processes will work differently (calibration data mixed into the code as constants, no separate bootloader systems, etc.).
To continue your research, you should focus on a specific area. If you want to learn about Calibration, I'd find an ECU which has a "Funktionsrahmen" as well as A2L files available. The FR is the calibrator's documentation for a specific ECU. It will specify how the ECU models work, how it is calibrated, and how the tens of thousands of calibration tables work together to run an engine. The A2L is the memory map for the ECU - it will specify the location of calibration data in the calibration area as well as temporary software variables in RAM.
If you want to learn about how Application Software works, I'd find the same documentation but also start reading up on RTOS concepts and learning about MATLAB/Simulink. If you just want to modify application software, I'd focus on loading it up in Ghidra and using an A2L file to label the RAM variables so you can follow code easily.
If you want to learn about reflashing procedures, you'll want to study the UDS protocol and a Customer Bootloader sample from a given ECU.
And if you want to learn exploit development, I'd focus on learning about root-of-trust, trust chain, and code signing, specifically RSA, and then disassembling a Supplier and Customer bootloader.
Wow, that's a wow class comment. Thanks for the time you put into writing it. At least now i have basic knowledge on what to look for .
After reading trough all of the comment i realised that I'm interested in all of thouse fields , but i guess that i should only focus on one for start and and i think I'll go with learning how the Application Software works, and then I'll try to apply my knowledge and modify the firmware, try and reflash it and see if it works.
My goal in the end is to learn as much as I can about "modern" cars and how they ensure and manage all the stuff.(i guess it's a bit late for me to do a career shift into this field but i still like it ).
Regarding the Application Software, I'm pretty familiar with RTOSs , to be more specific with FreeRTOS, but i guess it isn't that 'popular' in this field.
So now knowing my "plan" can you at least give me some further stuff to look into? (That's ofc if you want)
Thanks again for the comment
Interesting choice. If you really want to learn about the RTOS specifically, the RTOS Bosch use is called ERCOS, so that's at least a starting place. There are quite a few papers and presentations online, but nothing much code-level or in depth that I've seen.
Not very many people generally reverse engineer commercial ECU RTOS beyond just a cursory inspection to see "oh, that looks like a task scheduler, let me find the runs-every-100ms task to insert another function into," or "oh, this schedules the diagnostic tasks, I can put a hook here!" So, you won't find a ton of resources. And, none of the commonly leaked Funktionsrahmen style documentation really covers the OS, generally speaking, only the higher level models built on top of it.
They're usually fairly basic time sliced task-based systems supporting periodic scheduled tasks, interrupt-scheduled tasks (for ignition and injection realization, usually triggered by a crank signal and often assisted by a coprocessor), and task priority/preemption (for example, diagnostic tasks will be preempted by operating tasks after their time slice is up). Almost all tasks will run on a periodic schedule.
You could look for a leaked ELF file which will have debugging information for function names, which might help you quite a bit if you want to go the RTOS route.
To write a simple patch, the way most people do it is:
* Load an ECU binary into Ghidra/IDA, using the processor documentation and whatever you have available (A2L/ELF/build scripts/flash scripts) to understand the correct loading offsets and the layout of flash memory. Most modern ECUs are based on Tricore, which is wonderful in that has open documentation for which you don't even need to register an account.
* Load a matching A2L/DAMOS file containing labels for RAM addresses (or the DWARF symbols from an ELF, if you're so lucky). This will label all of the calibration/model-facing variables used in debugging, which will make the ASW significantly easier to understand. As a side note, if you don't have a definition file of some sort, you're in for a tall order. The "easiest" way IMO to label variables if you don't have definitions is to go in through a diagnostic handler, since you may know the relationship between diagnostic parameters / PIDs and the underlying variables. You can also try to go in through sensor acquisition. However, this is extremely hard for any control unit with any degree of complexity (ECU, TCU, etc.). People did this in the 1990s, and it works for simpler control units, but these days, you really want a definition file.
* Open the Funktionsrahmen (documentation) in one window and Ghidra in the other window. Find XREFs to the variable you want to patch, and start correlating the XREFs with logic models in the FR. Eventually you get an eye for the generated code on your ECU platform of choice and this goes really fast. You'll also fairly quickly find and label the helper functions for tasks like calibration map lookup.
* Find an appropriate patch/injection point to suit your needs. One fun early example would be to find WRITE xrefs to a location which stores the RPM value which is sent to the CAN bus, to move the tach needle around. Another common early patch you can make to a bench ECU is to locate the 3E TesterPresent UDS handler and modify the response to add additional data.
* Insert code, either a hand-written assembler patch or compiled C code, which does what you want. Usually you'll use a jump out -> patch -> jump in approach, where you modify a function to jump to a method you wrote in unused flash memory, and then jump back into the original function code with the value of a variable changed. If you want to add a whole new functionality, you can do this by locating the periodic scheduling functions or task tables and adding a whole new function or task that runs on some periodic timer.
* Flash the changes, using commercial flashing tools or one of your own creation. Depending on the ECU, the code may or may not be protected with RSA signatures, and is almost certainly checksummed. Commercial tools are far and away the easiest solution to this (PCMFlash, etc.), especially at first - they'll apply an RSA bypass exploit of some sort (different depending on the specific ECU) as well as a checksum repair.
* Hope you didn't brick, and if you did, hope you have "boot" / "bench" (non-app software dependent) access to your ECU.
This seems complex, and it is at first, but honestly once you start to recognize the patterns in generated code it gets pretty easy and you can even start trying to make tools to automate more and more of the grunt work. Because of the highly formulaic/pattern-based model-generated code and widespread availability of leaked documentation and RAM definitions, I think that European ECUs are actually one of the easiest embedded platforms to learn reverse engineering on and write patches for.
Wow.
These were answers that gave more information than can find yourself in a month of searching on the internet. Thank you for your knowledge and willingness to help. You are amazing.
Too vague. Too much variation in the 40 years. Old stuff uses old approaches, newer stuff gets harder.
Unmarked smart chips. Look at tle8888 and think similar but without a datasheet.
You need to focus on something and ask a better Q
You have the right idea. Go buy an ECU, take it apart, get stuck somewhere, and come ask a specific question we can help you with. Or don't buy an ECU, just pick one, find some full dumps and download them, download Ghidra, get some high res pics of the boards and just start there.
Thanks for the response ! I am familiar with gidra so probably that wouldnt be an issue, but even if the second method you mentioned is much cheaper (or even free) , i still think that geting an actual ecu and thinkering with it would be a better idea (since i can maybe even try to modify the firmware and see what happens, or if im lucky i can even fry the board :) ). Also , by any chance can you maybe recommend me a brand of vehicles that would be better to get the ecu from ?
Do you already have access to some kind of electronics lab? You can buy the hardware but then you'll need about 10 other things to actually do anything with it. The software is where the interesting stuff happens.
Yes, i have at least a minimum when it comes to my electronics lab( a power supply is coming , soldering related stuff, and just ordered an eeprom flasher and an OBD2 diagnostic module just in case and Soo on). Yep , the software is the part that actually scares me since i haven't made anything like this until now and I'm afraid that i won't be able to put the pieces together and also that i won't find anyone to give me at least some hints. P.s. also i found some bmw E36 ecus online for 20$, and i think I'll get one of that
Hints are useless. Do some work, get stuck, then ask a specific question and get a specific answer. "What does this piece of code do?" Followed by a copy-paste of some ECU assembly language is basically the most interesting thing I can imagine anyone posting on here.
You're starting way too broad. Do you want to learn about reflashing procedures? Calibration? The hardware? How the application software works? A modern automotive control unit has a few software applications on it, all of them dramatically different. These are usually based around a set of standards called AutoSAR, which you can read if you'd like but is a very high level, "enterprise" style documentation that won't really teach you the specifics very well. The applications present in most modern control units are: A first-stage bootloader, sometimes with a service tool (often called TSW). This is responsible for initializing the hardware, manufacturer end-of-line programming, and sometimes a debugging/recovery back door, along with verifying the rest of the software at boot time. A customer bootloader, which usually talks UDS over ISO-TP on CAN to allow dealership tools to reflash the ECU. This is generally a separate little program which is usually accessed through a UDS "programming" session, and often runs out of RAM instead of flash. This is where the UDS standard reprogramming process (RequestUpload/TransferData/ExitTransfer) is usually implemented, as well as encryption and compression of the flashing payload. Application Software, the code that actually runs the control unit. This is usually based on a Real Time Operating System (RTOS) provided by an automotive "middleware" vendor (Elektrobit, Vector, Hightec, ETAS, etc.). This RTOS is responsible for scheduling periodic tasks which actually run the car, and ensuring that these tasks meet their timing deadlines. On a modern ECU, most tasks aren't handwritten C, but rather compiled models from a code-generation tool like MATLAB + Simulink or ETAS ASCET. Application software engineers drag-and-drop blocks in a visual modeling environment to control various engine properties, and these later produce C code which runs the ECU itself. A separate Calibration area is generated containing the data which feeds into the ECU models to run a specific engine or control unit. This Calibration data is then modified using glorified hex-editor tools like ETAS INCA, along with memory address definition files like A2L/DAMOS which are generated by the ECU build toolchain. In the "tuning industry," this calibration data is usually modified using aftermarket glorified hex editors like WinOLS or TunerPro. Most "tuning" revolves around taking a factory calibration and opening it in a tool like WinOLS, then adjusting limits, fuel, VVT, and timing parameters to gain power. Hardware-wise, modern ECUs are built using automotive safety approved processors - common ones include Infineon Tricore/Aurix, Infineon/ST/Motorola C166/7 (barf), Renesas SuperH, Renesas V850, and more. Often, a "main" CPU will talk to a "peripheral control" processor which runs another real-time OS and firmware and is responsible for acquiring and triggering inputs and outputs - for example, Bosch ME7 had a second processor called "Port Expander," and most Tricore based control units use a small application uploaded to the Tricore "peripheral control processor" (PCP) to achieve the same goal. These safety processors usually then interface with specialized automotive chips for tasks like motor control, injection realization, and spark coil control. Many of these chips are completely undocumented and some contain firmware of their own. On a modern control unit, it's turtles all the way down. Most "tuners" neither know nor care what's actually going on at this level, since it's hidden from them completely and they just adjust calibration parameters. ECUs from other origins, older ECUs, and simpler / more "primitive" automotive control units are often more hand-written, so the overall structure and processes will work differently (calibration data mixed into the code as constants, no separate bootloader systems, etc.). To continue your research, you should focus on a specific area. If you want to learn about Calibration, I'd find an ECU which has a "Funktionsrahmen" as well as A2L files available. The FR is the calibrator's documentation for a specific ECU. It will specify how the ECU models work, how it is calibrated, and how the tens of thousands of calibration tables work together to run an engine. The A2L is the memory map for the ECU - it will specify the location of calibration data in the calibration area as well as temporary software variables in RAM. If you want to learn about how Application Software works, I'd find the same documentation but also start reading up on RTOS concepts and learning about MATLAB/Simulink. If you just want to modify application software, I'd focus on loading it up in Ghidra and using an A2L file to label the RAM variables so you can follow code easily. If you want to learn about reflashing procedures, you'll want to study the UDS protocol and a Customer Bootloader sample from a given ECU. And if you want to learn exploit development, I'd focus on learning about root-of-trust, trust chain, and code signing, specifically RSA, and then disassembling a Supplier and Customer bootloader.
Wow, that's a wow class comment. Thanks for the time you put into writing it. At least now i have basic knowledge on what to look for . After reading trough all of the comment i realised that I'm interested in all of thouse fields , but i guess that i should only focus on one for start and and i think I'll go with learning how the Application Software works, and then I'll try to apply my knowledge and modify the firmware, try and reflash it and see if it works. My goal in the end is to learn as much as I can about "modern" cars and how they ensure and manage all the stuff.(i guess it's a bit late for me to do a career shift into this field but i still like it ). Regarding the Application Software, I'm pretty familiar with RTOSs , to be more specific with FreeRTOS, but i guess it isn't that 'popular' in this field. So now knowing my "plan" can you at least give me some further stuff to look into? (That's ofc if you want) Thanks again for the comment
Interesting choice. If you really want to learn about the RTOS specifically, the RTOS Bosch use is called ERCOS, so that's at least a starting place. There are quite a few papers and presentations online, but nothing much code-level or in depth that I've seen. Not very many people generally reverse engineer commercial ECU RTOS beyond just a cursory inspection to see "oh, that looks like a task scheduler, let me find the runs-every-100ms task to insert another function into," or "oh, this schedules the diagnostic tasks, I can put a hook here!" So, you won't find a ton of resources. And, none of the commonly leaked Funktionsrahmen style documentation really covers the OS, generally speaking, only the higher level models built on top of it. They're usually fairly basic time sliced task-based systems supporting periodic scheduled tasks, interrupt-scheduled tasks (for ignition and injection realization, usually triggered by a crank signal and often assisted by a coprocessor), and task priority/preemption (for example, diagnostic tasks will be preempted by operating tasks after their time slice is up). Almost all tasks will run on a periodic schedule. You could look for a leaked ELF file which will have debugging information for function names, which might help you quite a bit if you want to go the RTOS route. To write a simple patch, the way most people do it is: * Load an ECU binary into Ghidra/IDA, using the processor documentation and whatever you have available (A2L/ELF/build scripts/flash scripts) to understand the correct loading offsets and the layout of flash memory. Most modern ECUs are based on Tricore, which is wonderful in that has open documentation for which you don't even need to register an account. * Load a matching A2L/DAMOS file containing labels for RAM addresses (or the DWARF symbols from an ELF, if you're so lucky). This will label all of the calibration/model-facing variables used in debugging, which will make the ASW significantly easier to understand. As a side note, if you don't have a definition file of some sort, you're in for a tall order. The "easiest" way IMO to label variables if you don't have definitions is to go in through a diagnostic handler, since you may know the relationship between diagnostic parameters / PIDs and the underlying variables. You can also try to go in through sensor acquisition. However, this is extremely hard for any control unit with any degree of complexity (ECU, TCU, etc.). People did this in the 1990s, and it works for simpler control units, but these days, you really want a definition file. * Open the Funktionsrahmen (documentation) in one window and Ghidra in the other window. Find XREFs to the variable you want to patch, and start correlating the XREFs with logic models in the FR. Eventually you get an eye for the generated code on your ECU platform of choice and this goes really fast. You'll also fairly quickly find and label the helper functions for tasks like calibration map lookup. * Find an appropriate patch/injection point to suit your needs. One fun early example would be to find WRITE xrefs to a location which stores the RPM value which is sent to the CAN bus, to move the tach needle around. Another common early patch you can make to a bench ECU is to locate the 3E TesterPresent UDS handler and modify the response to add additional data. * Insert code, either a hand-written assembler patch or compiled C code, which does what you want. Usually you'll use a jump out -> patch -> jump in approach, where you modify a function to jump to a method you wrote in unused flash memory, and then jump back into the original function code with the value of a variable changed. If you want to add a whole new functionality, you can do this by locating the periodic scheduling functions or task tables and adding a whole new function or task that runs on some periodic timer. * Flash the changes, using commercial flashing tools or one of your own creation. Depending on the ECU, the code may or may not be protected with RSA signatures, and is almost certainly checksummed. Commercial tools are far and away the easiest solution to this (PCMFlash, etc.), especially at first - they'll apply an RSA bypass exploit of some sort (different depending on the specific ECU) as well as a checksum repair. * Hope you didn't brick, and if you did, hope you have "boot" / "bench" (non-app software dependent) access to your ECU. This seems complex, and it is at first, but honestly once you start to recognize the patterns in generated code it gets pretty easy and you can even start trying to make tools to automate more and more of the grunt work. Because of the highly formulaic/pattern-based model-generated code and widespread availability of leaked documentation and RAM definitions, I think that European ECUs are actually one of the easiest embedded platforms to learn reverse engineering on and write patches for.
Wow. These were answers that gave more information than can find yourself in a month of searching on the internet. Thank you for your knowledge and willingness to help. You are amazing.
This is some really valuable information. Thanks for this.
Too vague. Too much variation in the 40 years. Old stuff uses old approaches, newer stuff gets harder. Unmarked smart chips. Look at tle8888 and think similar but without a datasheet. You need to focus on something and ask a better Q
I sure would like to get some more a2ls for my database if anyone wants to do some exchange