Interested because I've done a lot of reverse eng (but not of flash protocols and would like to), more related to engine function.

I'm just putting together a scriptable Tricore instruction set simulator because the existing ones were not doing what I wanted (register tracking in IDA Pro to better resolve cross refs). With a binary available, something like that could be useful for reversing and testing this sort of stuff.

The "trickery" is what I want to learn, I don't want to buy someones solution ;(


But there are so many registers! I guess you're making it for a subset of the registers? I think JTAG with Trace32 or something is what Alientech,etc use

Simulators will trace a binary, but need a bit of help in how to run it. They can get trapped in loops, so I would like to take functions from IDA Pro and iterate through them following all the code cross references (calls, jumps, switches, both sides of conditional branches). I'm just trying to glue it together as IDA Python is too slow, but the instruction simulator is working simulating far more registers than I will ever need to resolve most x-refs better than IDA can itself. Marking the cross refs in IDA is a bit obstinate so far.

In many newer ECU's main bootloader is not in flashable area.
If you figure out how to unpack the sgo/frf you can already see which areas you can ignore (just to read the metadata from them is super simple, because it's not actually crypted like the ecu content).

In the end you can localize the bootloader with precision of about 0x8000 block in code, and it's not so hard to go from there and reverse it.
Both SGO and FRF tell you which sections to flash, erase etc. Using that info you can guess with veeeery high probability where the bootloader resides.

The hard part is dumping the ECU contents when you don't have access to it. When you already have the full ECU dump using some sort of hardware vulnerability or just unprotected direct hardware access, then making an OBD protocol from that is very easy when you are doing this every day. All you have to do is reverse engineer the encryption/compression from the bootloader to be able to make the payload, and then do exactly like the FRF/SGO instructs you to, to establish comms.

As I said - the hard part is breaking into new ECU's where you don't have the full flash dump. This means you either must find some 0day hardware exploit, or some way to gain remote code execution ECU, which is a software exploit. This is where the skill comes in.
And trust me, only ONE company usually does this. All the tuning companies all have each others tools so after one has done it, the rest just copy paste it by sniffing comms.

In fact I dare say, in many cases one of the companies just BUYS the solution that is crated by some big-name or independent tuner... or someone takes an early retirement package and some private keys are leaked.

Thanks for the explanation.

Could you please point the offset of reset vector in the file I attached above?

Let me get out my spoon.


This is just some of the data. SGO also contains baud rate, seed key, everything you need to flash ECU.