Tool used

[Teitek]

Hi bri3d, what tool are you using to send the BSL?

I have a problem with a Simos18. After trying to use a RSA-Patch writing ASW without erase, in the process the ECU crashed.

The process: (Write cboot / asw1 / erase block 5 and write asw1 with patch, reset communication and erase again block 5. Here the ECU was blocked)

I have a previous KTAG backup but now when read or write the block 0x0001C000 KTAG throws an error and doest not continue. I dont know if CBoot is corrupted but i dont understand why KTAG doesnt restore it...

I wrote a function to read any memory area but i did not see necessary read the passwords having KTAG boot backup. KTAG doest not offer me passwords, i dont know if sniffing the ktag communication i will be able to obtain them or Alientech will be able to give me the complete dump to obtain the password. (SBoot/OTP/Cboot is encrypted in the backup)

Wonderful job Bri3d Regards and than you!!

[bri3d]

Hello @Teitek ,

I am using a Raspberry Pi with a PiCan hat to send the BSL payload. However, any CAN device using SocketCAN should work. The protocol to send the BSL itself once the HWCFG pin configuration has been set up is quite trivial and doesn't require any specialty hardware - you can see it in bootloader.py and there really is nothing to it.

I have not yet pushed the methods in my BSL C code to write to flash up to GitHub, because I have not had the chance to test them and I felt it would not be responsible to let someone else test something possibly destructive. However, if you find yourself in a situation where your ECU is bricked already and you feel they could be useful (that is, you are able to recover your password), I can let you be the guinea pig.

I can work to add erase sector and write sector in the next day or so.

Of course, that depends on you recovering the password.

A bit more on password recovery: I do not know how Simos18 password recovery without existing read access works yet. The process to dump the boot password without an existing copy of Flash does require specialty hardware (although a Pi works well for this too) - a PWM waveform is applied to two pins. This causes SBOOT to enter a "command shell" where it will accept CAN messages after comparing the PWM waveforms using the GPTA waveform analyzer hardware in Tricore. And then something is done using this "command shell" in SBOOT. If you have access to KTAG, I suppose you could try dumping the CAN communications during this process and see if there is anything obvious going on.

I am aware that on past Tricore ECUs from other vendors, this SBOOT command processor (GPT, PWM Mode, SSM, it has several names) was either a simple Read primitive in SBOOT or added a Checksum primitive which was small enough to be reversible (i.e. a single byte or 4-byte region could be Checksummed, and then the checksum simply brute forced forwards to find the actual password). But for Simos18 I don't know yet.

And yes, of course you also have a full flash dump from KTAG, but you will need to contact Alientech to find out why it will not flash and why you cannot decrypt it.

I think that your best approach right now is Alientech support. They should be able to help you fix an issue with their own tools, especially when the issue is caused by their own overzealous protection methods hiding your passwords from you and preventing you from writing CBOOT.

This is a bit of motivation for me and you can look forward to some new commits adding Flash Write / Flash Erase support in the coming days, but unless you can find your passwords somehow, you are still stuck.

[Teitek]

Hi bri3d

Finally and as expected, Alientech does not offer me any kind of support.

I have used a logic analyzer to be able to get PW1 and PW2 so I can experiment with the ECU

I have seen that sending the password using the 0x05 command has been implemented in the BSL source code, but I don't understand what the parameters of the 5,6,7 byte are and in the .py file it is not implemented yet.

I'd like to try reading it first and then writing it down, if you are encouraged ...

[bri3d]

I will add support to my Python script in a few hours, sorry about that!

Since you are curious, the additional bytes are

5: 0x08 for Read Protection, 0x05 for Write Protection. This is the "Protection Type" 6: Which "UCB" (User Configuration Block) the Password being used is stored in. For Read, this is always 0, and for Write, it's usually but not always 1. 7: Which flash controller to use - PMEM0 or PMEM1. You'll have to send Read passwords for both to get a "full read", since CAL and ASW3 are in PMEM1 and everything else is in PMEM0.

Unfortunately once we get here, things are untested, because I do not have the passwords to my only bench ECU. If you'd like, please reach out at my email ( bri3dd @ gmail . com ) and we can collaborate more directly?

[prj]

The reason you can not write is that the ECC of the memory is invalid and KTAG does not have the facilities to fix that. The reason you crashed the ECU is because you most likely did not write on a 256 bit boundary.

[bri3d]

Yes, we worked together over email and fixed this quite some time ago. You are right that it was the ECC issue, I pointed this out to him via email and we were able to recover the ECU by erasing the block. It is very bad IMO that KTAG does not set the correct flag to disable bus fault on double-bit ECC errors or provide a way to erase without trying to read first, they could make their SW able to recover from this situation but for some reason have chosen not to.

[prj]

There are better tools, which allow to recover. KTag is the McDonalds of ECU tuning tools.