NefMoto

Hi guys,


Did any of you ever work on the Tricore bootmode canbus protocol?
Is there any public info available?

I made a first log attempt (500kb/s 11bit CANID) which shows some data but can't make much sense of it yet.
For example the CANID always is 555h so doesn't look correct ..
555 [8] 31 00 04 00 00 00 00 D0
555 [4] 41 80 82 04
555 [8] 31 00 04 00 04 00 00 D0
555 [4] 46 A0 B3 E4
555 [8] 31 00 04 00 08 00 00 D0
555 [4] 82 06 00 10
555 [8] 31 00 04 00 0C 00 00 D0
555 [4] 24 1C 00 00
555 [8] 33 00 40 01 00 00 00 D4
555 [8] 40 BC 5D 00 0F 00 11 00
555 [8] 00 00 00 00 00 00 00 00
555 [8] 00 00 00 00 10 20 00 F8
555 [8] 08 20 00 F8 54 55 00 A0
555 [8] 49 BE 3A FA DF 10 3D 80
...

I am curious for example how the PASSWORD transaction is done.


Regards,
H2Deetoo

Official information from Infineon

Thanks, I found and read this document already but it doesn't match up to the log I made :-/


Rgs Bonny

With which TriCore processor you work?

EDC17CP14 TC1796

does the canid matter?

According to documentation the CANID should not matter.

http://www.infineonforums.com/archive/index.php/t-1928.html?s=a8c3f47f1403e20f6cff065c9ad77be9

Some sort of init/handshake protocol?

http://www.infineon.com/dgdl/ap1609211_CAN_Bootloader_.pdf?fileId=db3a304412b407950112b409da25039f

tada

Thanks for the file!
The CANID 0x555 is mentioned in this document, but it still isn't a match to the log I made.
Perhaps there's something wrong/missing in my log, or we miss some vital piece of info ...


Rgs H2Deetoo

Welcome.   Perhaps not exact doc.

I think my logger is messing up.
I read in the datasheet something about DOMINANT bit being set by mcu, so this might be the reason why some frames aren't showing up in my log.

Anyway I will try different hardware to log now ...


Regards,
H2Deetoo

More reading mate, can is well, can and made by Bosch lol.

http://www.totalphase.com/support/articles/200472276-CAN-Background

You seem to miss the bootloader upload itself and only logged the exchange between the software and the bootloader (apparently reading the MCU ID before preparing for other stuff). The fact that it uses the same CAN ID for requests and response is a simple way to obfuscate a bit the exchanges but it does not matter.

For the password transaction itself, it is well detailed in the Infineon documentation and should not be hard to spot in a bootmode trace.

Could be so .. but the problem is then why my logger isn't showing the initial bootloader upload.
Perhaps it uses a different baudrate, and only later they switch to 500 kbps.

I guess I need to hook up a scope and do some measuring ...

>The fact that it uses the same CAN ID for requests and response is a simple way to obfuscate a bit the exchanges but it does not matter.
Yes it doesn't matter.

>For the password transaction itself, it is well detailed in the Infineon documentation
Do you have documentation describing this then?


Mery Christmas en best wishes to all here!

Rgs Bonny

Some well known tools out there use some CAN tricks to detect sniffing and won't start the bootloader upload in that case.


You can find it on the Infineon website:
http://www.infineon.com/dgdl/TC1797_UM_v1.1.pdf?fileId=db3a30431ed1d7b2011efeae5efc6b76 (http://www.infineon.com/dgdl/TC1797_UM_v1.1.pdf?fileId=db3a30431ed1d7b2011efeae5efc6b76)

Look for "Command Sequence Definitions" in the PMU chapter of the Tricore user manual.

Merry Christmas

Good to know re sniffing guess test turning ack off would fix?

It should. But not all CAN devices/controllers allow you to do that easily.

A simple chipkit for example can, silent mode or something iirc.

Does  this proc run on Simos 8.4?

>Look for "Command Sequence Definitions" in the PMU chapter of the Tricore user manual.

Pollux, you're wrong here.
The password they are talking about in the datasheet is for flash sector protection. This has got nothing to do with the password used to authenticate with the loader.


Rgs H2Deetoo

So far I haven't seen any authentication with a loader. If you need authentication, this is specific to the loader you're using. The Tricore MCU itself does not enforce such thing. Anyway, you don't need any authentication if you're using your own loader.

Yes of course I agree completely.
But my bet is that most tools use the same loader ;-)

Same practice with clusters; there is one smart guy (perhaps even employee of VDO) who writes a loader, even with some form of authentication, and each and every tool out there uses this loader.


Rgs H2Deetoo

Implementing some strong authentication in a loader is a tricky thing. Since you can potentially sniff the upload, dump the binary in IDA and figure out how the authentication works.

If the upload of the loader is plain then you're right of course.
But once you encrypt the loader (for example with RSA) then you'll have a hard time decrypting it before you can start analyzing.

Fortunately the tools, which support the authentication algo, are often easier to crack to extract the needed algos.

But in case of Tricore the loader is indeed plain ...


Rgs H2Deetoo

are you making your own loader?  I'm reading the datasheet stage so a bit behind. lol  Weird how Simos is lo-hi

No no I have no intentions of writing a loader.
I just was curious to which loader was used by Galletto and Byteshooter for example, and how they do the password transaction.

Anyways, a log is made (indeed in silent mode) and enough is clear now about this subject.


Regards,
H2Deetoo

Can you share the raw logs pleeeeease?  Which ECU?

I have the vag loader info for simos 8.4 which I *think* uses that cpu or the tc1766xx (TBC).

??

Galletto and Byteshooter  may change baudrate due to communication to ECU. In this case you can't make log easy. To unlock Tricore they send 16 bytes password to ECU.

Begin at 250kbps for sent the loader and after open a connection at 500kbps.