NefMoto

I wonder how companies like CMD, Alientech etc retrieve info about seed key, CS, RSA, TProt etc.
Disassembling? Sniffer? Or they have a custom debugger or smth like that? Or maybe they buy info?

It's just impossible to add so many protocols for a such short time. But they do, so maybe it's not so difficult and exists an easy way?

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.

There's only one protocol for VAG seed/key.  CS are easy to figure out.  RSA and TPROT stuff requires some trickery, but there's people out there that know the solution and can sell it.

If you're seriously in to get protocols completed, connect with people and you can get a good chunk of information needed to do most VAG cars for pretty cheap.

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

Easy? Bosch and Siemens have many CS blocks. Maybe exists CS routine, but how to find it?
Of course, I can buy solution, but it's like buying tuned file from someone. And it needs me not for making money so I'm not ready to pay 1000$ for it.


As I understand TRACE32 works only with source code, so you can't trace machine code only. Maybe Alientech created they own JTAG debugger, but where to get Tricore's JTAG protocol?

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.

Simulator is a good thing but what if:
a15 equ 0xD400xxxx

calli      a15

I can read RAM (on some softs), but this was just for example. Also simulator will make mistakes.
Actually I don't know even where is a start point of the program.
In C167 it's RESET HANDLER as I understand, but what about Tricore?

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.

a15 is in the upper context so saved across calls and undefined within until set, so this example simulates well, with either a RAM dump or simulation populated RAM. No tool is perfect, just an adjunct.

There is a reset vector but eventually it reaches a loop as it waits for interrupt/timer driven code to be run. Although that can be simulated too, it isn't worth it for my application which is mainly resolving x-refs in tuning related code/data.

Thanks for the explanation.

Thanks for reply! Maybe I misunderstood you but looks like SGO is fully crypted. I attached sgo and decrypt. I've tried to open SGO in IDA and it hasn't found any routine.
And even if bootloader in 0x8000 area, but what about CS, RSA, TPROT? I really interested for EEPROM CS.
And are you sure they simply disassemble it without JTAG debugger? I'm not sure there is no protection though.

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

SGO is a container, that contains metadata. It is not crypted in any way.
Only thing that is packed/xored is the flash data, everything else is there in plain sight if you would care to read it.

It is a proprietary binary format.

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.

care to share the deets on sgounpack.py?

There is a plugin for winols to open sgo/frf btw...

Thanks a lot, now I see. Here is another interesting thread
http://nefariousmotorsports.com/forum/index.php?topic=6583.15

80004372 is interesting. It checks the PC for whether it is running from flash or RAM, but the routine at 80004390 runs 6000 instructions before it sticks.

From a similar entry my MED17 runs 41000 instructions before returning.

I am still experimenting, but I'd consider multiple entries depending on the circumstances, but for finding cross refs I think I want to parse all the functions.

No.

As a side note

https://github.com/zavg/linux-0.01

Some historical perspective.

https://www.youtube.com/watch?v=L9EKqQWPjyo

:(

.....................