RomRaider

I used to have a 02 wrx and used this program and forum to tune it myself. I've since sold the car and become infatuated with something else which unfortunately has no tuning support to speak of. I was wondering what it takes to crack an ecu? I see there is a BMW subfolder now, does that mean this program could be used with other manufacturers with some tweaking?

Obviously I'm new to this but I would like to learn at least the process of how to get started. Any direction would be appreciated.

So I was searching around for info and came across USBCAN and CANalyze. So I can pull the info using those and then it's a matter of deciphering that the numbers mean?

So I've contacted the 2 shops that do the tuning for hyundai's and also cobb. None of them have given any info on how to pull the maps off the ecu or any kind of info really. How did merchgod do it when he started rom raider?

Lots of time and a background in computer engineering is probably a bare minimum starting point... Hardware access, pulling apart the ECU to figure out what processor is used, pulling datasheets, etc.

I have some very experienced computer programmer friends that could potentially help me with that side of things. Would something like this be a starting point https://www.cancapture.com/cancapture? I've found some software that says they can pull the code and turn it into an ascii table, so I would just have to figure out what is what at that point right?

In order to adjust the engine operation calibration tables, you need to be able to adjust the ECU's flash memory in an intelligent way. RomRaider is a program that opens binary ECU files and interprets them according to a definition file. This allows RomRaider to adjust the ECU's binary program in an intelligent way. It can work with any binary file for any car (or beyond) as long as a definition file is available. After that, another program can be used to load the program into the ECU's flash memory.

Getting to that point involves reverse-engineering of embedded electronic systems (i.e. the ECU).

In order to adjust the flash memory of an ECU, you would need to have a programming interface to do so. This includes both the hardware and software side of this interface. A starting point involves identifying this interface. It may or may not be the CAN interface that you mentioned in an earlier post (you would need a priori knowledge of how to interact with the ECU if an on-ECU software read function even exists). Analysis of the code on the ECU is one way to identify such an interface, as well as to identify the calibration tables.

In order to analyze the code, you need a copy of the code as well as a software tool to disassemble it (turn from binary code into assembly language) and knowledge of how to read assembly code. This presents a bit of a 'chicken and egg' problem, since you need a copy of the code in order to figure out how to access the interface to download a copy of the code. It is an understatement to say that the code disassembly process is very tedious.

IDA/Hex-rays is a program that has plug-ins for disassembling code for many microprocessors. If you don't want to buy it (it's expensive), you can earn your chops by writing your own disassembler (a good way to learn assembly language) or use a gnu gcc cross-compiler to disassemble code.

You need to know what microprocessor is used in the car's ECU; the microprocessor can be identified by opening the casing of the ECU and taking a look at whatever numbers are on the microchips on the board. This process sometimes results in irreparable damage to an ECU, in case it was not meant to be opened. Take lots of pictures of the PCB, and you may even be lucky enough to find a standardized hardware programming/debugging interface like JTAG. If that is present, then you can use a JTAG hardware tool to interact with the ECU and extract the code.

Otherwise, you have to find datasheets for the ECU on it's manufacturer's website. These may have documentation for the programming interfaces supplied by the microcontroller manufacturer. You can then use that interface to download a copy of the code on the ECU's flash, assuming that it is not protected at the hardware level.

If you're lucky, you can take your car to a dealer and use a hardware tool to eavesdrop on communication between the factory reflashing tool and the ECU. But even if you know the correct baud rates to record the data transfer, it may be encrypted in a way that prevents easy collection of a ROM to disassemble.

Efforts to stop this kind of ECU modification exist at OEMs; ECUs used to have debug interfaces commonly on the ECU, with pins soldered on, the flash memory was a separate microchip which could be de-soldered and placed into a chip reading device, etc. However, some ECU's use microcontrollers with embedded flash memory and no accessable on-chip programming interface (ex. the pins are not carried across the PCB, and they are BGA type).

et cetera

I really appreciate you taking the time to explain that to me.

So the goal is to make the definition file and have that loaded into rom raider and then (theoretically) all the info pops up and populates the tables. I'll start looking for a junk ecu that I can take apart to see the bits inside then.

I had emailed BRT and 10fintec, which are the ony 2 tuners, to try and get some info. BRT didn't respond but 10fintec did tell me there were "locks" but did not elaborate anymore then that. They also said they didn't know why there wasn't an open source option when I referenced rom raider. They fly their tuner in from Korea appartently.

What would the work around be on this if this is the design?

I do not have direct experience with such a scenario. The only ECU that I have participated in the reverse engineering of was a simple one that did not communicate with any external devices (none of ABS, body control, immobilizer, etc) and someone else had already obtained a ROM image prior to my involvement. Thus, take what I suggest with a grain of salt.

I expect that if the PCB does not have easily accessible pins for in-system programming, and that you do not know of the interface that the OEM dealership uses for reprogramming, you would need to formulate a strategy specific for that ECU. For instance, if you can identify the microchip then you can find the datasheet and read it to see if it describes the pinout of the chip and the programming interface. Maybe the chip would need to be de-soldered from the PCB and mounted into a special probing device in order to access the pins for reprogramming (assuming that they exist and are not protected by anti-tamper mechanisms).

Okay. I do know that the tuners with the software are able to tune it through the OBD2 port so I would just need to figure out what the key is for the encryption or password for the secured part of the micro processor?

I went through some of this with my 2002 Corvette a couple years ago... There are commercial tools for tuning but they don't give you the whole contents of flash memory like EcuFlash does, so there's no hacking community like there is for Subaru. I was fortunate that a few other people had already figured out some of the fundamentals.

https://github.com/LegacyNsfw/PcmHacks/

It's a hard problem and you'll have to attack from different directions at once.

Hardware reverse engineering:
Open the ECU and find out what kind of CPU is in there, because you might have to write code for it.
Also find out what kind of flash memory chip is in there, because you might have to write code to read / erase / write it.
Get datasheets for the ECU and flash.

Software reverse engineering:
Look for a debugging tool for the CPU in the ECU.
Use it to dump the contents of the flash chip.
Open the software in IDA Pro or Ghidra.

Protocol reverse engineering:
Find out what protocol is used to communicate with the ECU, get something that can monitor the messages.
Record the messages that get sent/received during a software update, probably at the dealership.
Figure out what those messages are doing. This might be hard.

Write software that emulates the dealership's flash tool. This might be hard. That tool might be sending code to the ECU that runs during the flash process. It might suffice to just re-use that code at first, but if you want to release an open source tool you'll need to write your own from scratch.

After you have flashing working, then there's the matter of finding all of the tables that you edit to tune the car. This is more software reverse engineering.

And you'll also want to be able to do data logging. If you can find an existing data logging tool (dealerships might have one) you can start with protocol reverse engineering. If not you'll have to reverse engineer the firmware to find the data logging stuff. We lucked out in that other people had already done some of that work for GM ECUs.

It's a big undertaking. Asking your friends to do it for you might not work. If they don't own the same care they're not going to be motivated enough to do a job this big. If there's a forum for your make/model, ask if there are any people there who would be willing to tackle this problem. Software development skills help a lot, but it's not necessarily a requirement if someone has enough motivation.

Is this something that I can make a definition file for rom raider and use this interface or would it have to be from scratch?