NefMoto

Hi guys,


See topic, does anyone have some information about this SSM protocol, and what it can be used for?


Regards,
H2Deetoo

I just read this on Alientech site:

Connection cable for the Continental Simos PCR 2.1 Ecus
This is needed to retrieve the Password from the ECU when working on the bench.


Can somebody explain why/when a password is needed?
I have never needed any password yet in the EDC17 I've done on table ..


Rgs H2Deetoo

LOL

LOL

Wrong hobby maybe ?
 ;D

Not so respectful this guys!

I'm an expert on VW clusters and can do many things with them others can't.

But I'm a novice regarding ecu's, I agree.
That's why I ask a question about it and I get such answers..... blegh!

Keep on the (not so) good work then !

Stupid question gets stupid answer!

The user manuals for all the TriCore chips are public, and you can read how flash is accessed.
If you spend even 5 minutes on that, you will see why what you said is very funny.

I agree I found it in the manual.
The question that then arises is how to find out the password for the older TPROT versions?

Next thing is which tricks or protocols they use to read passwords for TPROT8+ ?

As far as I am concerned there are no stupid questions!

Not being a programmer per se, all I know about older TPROT versions is that the pw is calculated with some XOR values on the CPU ID, each byte having a different XOR value as far as I can remember, but don't quote me on that, I am not a programmer.

Thanks, I'll check that out !

Older TPROT upto v5 the password was a simple algorithm from MCUID.
So once that was found out, it was pretty much useless, as you didn't even need the password.

Then on most ECU's CCP was active and it was possible to read it via CCP through ECU pins.
After that CCP got closed, but in the SBOOT there was a function that allowed you to checksum any area. This function was not protected by authentication(!)
So it would ask checksum for where the password was stored byte by byte and then because the algorithm was known and you were "checksumming" 1 byte, you could read the password. This was called "GPT" mode.

This was patched, for example in MED17.1.62 this approach no longer worked...
And then the "silver bullet" got released - by exploiting a vulnerability in the SBOOT you could upload your own unsigned bootloader. After this even opening the ECU became unnecessary.

On SIMOS the "SSM" is basically SBOOT access, and I don't know exactly how it works, but there is also a vulnerability that allows you to read the password. In some (PCR2.1 for example) it has been exploited to allow full R/W too.

The weakness of TC17xx is that the password to r/w the flash is stored in the flash. Otherwise updating the ECU would be impossible in the field.

They fixed that in Aurix. It's stored in the HSM, and the HSM decides everything. So you can't read it out even if you can run unsigned code.
The MG1 bench r/w is also a full SBOOT exploit that allows you to upload and run an unsigned bootloader.
MPC5557 is another thing entirely, but because the SBOOT is the same the same exploit works there. But also the password can not be read out.

Not that the password is very important - unless you mess up the SBOOT you already have a full exploit. This is similar to a DFU exploit on an iPhone. The SBOOT can not be updated in the field, so all the ECU's ever released are vulnerable to it and always will be.

Hope you enjoyed a brief lesson.

And yes, there are IMO stupid questions. If it's something you can learn from a publicly available datasheet, and it is not obscure in any way (literally: How do i program the flash?) then that is a pretty stupid question.
In my language there is a saying - 1 dumb man can ask more questions than 10 wise men can ever answer. I am not saying you are dumb, but you could have expended at least a little effort.

Thank you for your nice explanation.
I have a habit of when doing research I ask and read and ask and read, not necessarily in the right order. 
So yes I could have found my answer before asking the question.

But still I dont like such answers and will let that know regardless. Most likely anyone will give a sh*t though.

Thanks again,
H2Deetoo

siemens SBOOT hack (recently used in pcr21, but it's an old hack used in other siemens ecu since 3 years, like MSD85 for example), in few words is similar to bosch SB benchmode hack: bypass a couple of RSA and exec your piece of code = full access

Alright, I have worked out the CCP protocol to retreive the password for TPROT8+
The CANID's for CCP are described in the ecu's A2L and are often (always?) 0x7C3/7C4.

I've found another log of a similar approach to get the password but it seems to use UDS with CANID's 0x524/523.
Does anybody which protocol (name) this is?

Here's an example:
524 [8] 10 0A 31 01 01 7F 90 01
523 [8] 30 00 00 00 00 00 00 00
524 [8] 21 7F 90 12 34 00 00 00
523 [8] 02 71 01 00 00 00 00 00


Rgs H2Deetoo

There is no point to read it via CCP, much better to implement SBOOT exploit.

Can you give me some more information on SBOOT and that exploit?
I've searched on SBOOT but can't find anything related to Tricore :(

CCP isn't active on PCR2.1 anyway, and activating it can be a complete *&@>

Yeah I tested PCR21, not active indeed.
But CCP was working on my CP14 TPROT2 and CP46 TPROT10, so you can use it to read any part of (protected) flash.
I don't have access to TPROT11+ ecu's so can't test further..

@prj, you are referring to SBOOT but I can't find anything about it.
Can you explain some more about it?

I mean, i know Tricore can boot directly to user code or to an internal bootrom which can be used by CAN or ASC (serial).
But both require setting some bootpins and have the same functionality, to upload a BSL, so I assume that's not what you mean with SBOOT.


Regards,
Bonny

SBOOT is similar to SB in EDC17.

Continental isn't Bosch.

Hi Bonny,

I’m curious about SBOOT as well (although not specifically PCR 2.1 but more about Tricore in Continental in general)

Maybe this helps with some background?

Section 21 ECRP ECU Reprogramming is an high level introduction to SBOOT & CBOOT.

https://drive.google.com/file/d/1LZxppNiWJKe2GIEbNQTpSSY34RPEd5iW/view?usp=sharing

Thanks, more study material ! :)

After a quick read I see where I got confused.
SBOOT or SB means Secondary bootloader? (In respect to a Primary bootloader?)

I was solely thinking about Tricore bootmode where there is a very limited hardcoded bootloader, which only allows you to send your own loader and execute it. And that's it.

But you are talking about the code which gets copied to ram while upgrading an ecu in normal mode?
When going to programming diagnostic mode?
(The code that handles your commands 34,35,36,37 etc)

So that code is what you refer to as SBOOT or SB ? And in that code some bug/exploits are found?

Or am I completely missing the ball here?
Excuse me on forehand ..


Regards,
H2Deetoo

SBOOT means Supplier Bootloader. It is the limited hardcoded bootloader. In normal operation it loads the second stage loader, CBOOT, or Customer Bootloader.

Okay, thats the case for Simos, but how does that relate to Tricore?

? I lost you here.

Tricore is a family of microprocessors made by Infineon Semiconductor.

Both Bosch (MEDCxxx) and Continental (Simos) use the Tricore hardware in their products

But I don't think that's what you meant?

Sorry to be confusing, It's not clear to me.

In Tricore bootmode, there is really nothing you can do besides upload custom code (a bootstrap loader) and execute it.
There is nothing to exploit there besides writing a custom BSL which does something special (if possible).

However if you look at normal mode, how a fw update is done by go to programming diagnostics mode (some code is copied to ram which handles the erase/writes, this is the so called secondary loader? or SBOOT?)


Rgs H2Deetoo

So the SBOOT exploits prj is referring to, is that related to that code when going to programming diagnostics mode?

Again sorry to sound stupid, these terms are new to me.

ECU boots.
It loads the hardware bootloader.
The hardware bootloader loads the supplier bootloader (sboot).
The supplier bootloader verifies checksum and customer bootloader (cboot).

The latter two have NOTHING to do with tricore.
They are implementation specific.

It is just how it was chosen to do by Bosch and Continental.
The hardware boot is used to program the SBOOT, and the SBOOT is used to program everything else.
SBOOT takes a signed loader and executes it.

Sooo you can get a tool that does bench mode and sniff it or you can try to reverse the code and look for an exploit.
Good luck.

CBOOT does UDS 34, 35 etc

Get hold of an a2l for your desired target (actually anything would do for the purposes of this discussion)

https://drive.google.com/open?id=13P0HZ5PHiFLjqyZPAatxgut9zEomDjpb

Take a look inside it, you should find something along these lines (obviously addresses are target/architecture specific). In theory, those addresses should help to locate the sections of ASM in the bin corresponding to the various sections. I haven’t tried this yet but every day is a school day...

            "Calibration Data 'Access-by-ECU' Area" 
            DATA
            FLASH
            EXTERN
            0xa0800000
            0x80000

         /begin MEMORY_SEGMENT _ROM_ECU1   
            "ECU Software (internal flash)"
            CODE
            FLASH
            INTERN
            0x80040000
            0x100000

         /begin MEMORY_SEGMENT _ROM_ECU2
            "ECU Software (internal flash)"
            CODE
            FLASH
            INTERN
            0x80140000
            0xc0000

         /begin MEMORY_SEGMENT _ROM_FBB_CBOOT
            "Customer's Boot Software"
            CODE
            FLASH
            INTERN
            0x8001c000
            0x24000

         /begin MEMORY_SEGMENT _ROM_NBB_SBOOT
            "Supplier Boot Software"
            CODE
            FLASH
            INTERN
            0x80000000
            0x14000

I read ASM at a snails pace, so sniffing would be a practical next step

What prj said.

I'm guessing a bit here, but by exploiting the SBOOT (however that is accomplished) you can get the SBOOT to load a modified CBOOT and then the modified CBOOT does all the $34 $35 etc services without checking signatures too closely?

Maybe so.
But maybe they SBOOT exploit itself is enough to write unsigned code...

Anyway sniffing is the most easiest next step indeed :)

SBOOT allows you to upload your own bootloader and execute it from memory.
The uploaded package must be signed. You need to bypass the signature check.

SBOOT is what you call the code that handles the 34,35,36,37 commands then (running from ram), correct?

No, that’s cb (Bosch) or cboot (Continental).

There’s “upload” as in using a full network stack that has $34, $35 and so forth for transferring data. Then there’s “upload” as in doing some kind of basic network boot (like PXE)?

I’m not clear whether “uploading the bootloader” refers to the first or the second.

If the cmds 34-37 are handled by cboot, then I don't understand where or when sboot comes to play :(

The hardware starts the SBOOT.
The SBOOT verifies the CBOOT and starts the CBOOT.
The CBOOT verifies the ASW and starts it.

During the very moment that the ECU is booting up, you can send some signals to SBOOT to get it to talk...
Not rocket science.

You need to open IDA and the TriCore manual and see exactly where what is and how it's loaded.
Talking about this on a forum will get you nowhere.

You can NOT access the SBOOT over OBD ever EVER.
OBD stuff is CBOOT, for you to communicate with CBOOT the SBOOT has already verified and started it and the ASW was not valid, so it remained there! You're too late.
Or you rebooted into CBOOT from ASW.

SBOOT is similar to the hardware bootloader, in that you can upload your own code and execute it, but it checks that the code is signed.

Hi prj, thanks for making things clear, I am starting to understand it better now.
I do still feel a bit of negativity? Why? A forum exists to ask questions and get answers and leave a nice historic discussion for future visitors :)


Thanks again,
H2Deetoo

Talk about the subject.
There is no point to ask things that are clear/can be cleared easily.

If you are serious about this you will get a tool that does bench mode and sniff the signals.
And then all will be clear.
As I said before, talking about this will not get you anywhere.

Btw, CCP is blocked by GW, so you need to do it in bench mode anyway, so better directly implement method that works on everything.