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

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

Anyway sniffing is the most easiest next step indeed

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

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.

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.

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.