Pages: 1 2 [3]
Author Topic: SSM protocol as used by KTAG for PCR21 for example  (Read 2925 times)
Basano
Full Member
***

Karma: +78/-2
Offline Offline

Posts: 184


« Reply #30 on: April 04, 2020, 06:28:47 AM »

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
Logged
Basano
Full Member
***

Karma: +78/-2
Offline Offline

Posts: 184


« Reply #31 on: April 04, 2020, 07:00:15 AM »

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.

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?
Logged
H2Deetoo
Full Member
***

Karma: +14/-0
Offline Offline

Posts: 206


« Reply #32 on: April 04, 2020, 02:49:57 PM »

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

Anyway sniffing is the most easiest next step indeed Smiley
Logged
prj
Hero Member
*****

Karma: +352/-76
Offline Offline

Posts: 3917


« Reply #33 on: April 04, 2020, 03:13:16 PM »

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.
Logged
H2Deetoo
Full Member
***

Karma: +14/-0
Offline Offline

Posts: 206


« Reply #34 on: April 04, 2020, 06:08:14 PM »

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

Karma: +5/-2
Online Online

Posts: 19


« Reply #35 on: April 04, 2020, 06:16:52 PM »

No, that’s cb (Bosch) or cboot (Continental).
Logged
Basano
Full Member
***

Karma: +78/-2
Offline Offline

Posts: 184


« Reply #36 on: April 05, 2020, 01:35:32 AM »

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.

Logged
H2Deetoo
Full Member
***

Karma: +14/-0
Offline Offline

Posts: 206


« Reply #37 on: April 05, 2020, 06:20:42 AM »

If the cmds 34-37 are handled by cboot, then I don't understand where or when sboot comes to play Sad
Logged
prj
Hero Member
*****

Karma: +352/-76
Offline Offline

Posts: 3917


« Reply #38 on: April 05, 2020, 09:00:06 AM »

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.
« Last Edit: April 05, 2020, 09:04:52 AM by prj » Logged
H2Deetoo
Full Member
***

Karma: +14/-0
Offline Offline

Posts: 206


« Reply #39 on: April 05, 2020, 02:24:00 PM »

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 Smiley


Thanks again,
H2Deetoo
Logged
prj
Hero Member
*****

Karma: +352/-76
Offline Offline

Posts: 3917


« Reply #40 on: April 06, 2020, 04:39:58 AM »

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.
Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.02 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)