NefMoto

Hi guys.
I try to find more document and data to learn GPT Programming Function.
But I did not get anything.
Can anyone give me more help to understand it?

This is what I understand from GPT.
First you need to apply 2 signals on specific pins.
One signal is 10KHz, the other is 8KHz.

When you start the ecu with these signals it allows a special protocol using CANID 523/524.
Here is an example to see if this protocol is allowed by the ecu:
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

The only thing you can do with this protocol is brute specific bytes in flash, which in the end allows you to retreive the Tricore passwords used in bootmode.


Rgs H2Deetoo

Thanks H2Deetoo.
I try to implement this protocol. I gave it both signals, and now I could connect to ECU.BUT:
1- It seems the communication protocol use K-Line Protocol. I have:

Tool: 81 FE F1 81 F1
ECU: 00 03 C1 D6 8F 29
Tool: 00 03 80 E1 00 64
ECU: 00 0C C0 E1 01 9B 01 93 00 91 00 01 BF 01 2F
Tool: 00 01 3E 3F
ECU: 00 01 7E 7F

2- It's so weird for me, but it uses of 0x27 with 10 bytes of seed. So I have:
Tool: 00 02 27 7F A8
ECU: 00 0D 67 7F 55 55 . . (10 Byte) . . 55 34 79

OK. Here I'm so confused. You said this uses CANID 523/524(I couldn't find more stuff of that) but it can use K-line protocol, too.
And what kind of 0x27 command? 10 byte seed?

Sorry, all EDC17 ecu's I tried this one all use CAN bus.
I have never worked on K-line.

Thanks H2Deetoo.
In this case, ECU programming done by CAN protocol.
Only at the beginning of the operation several K-Line command sent to ECU. Here, The most important command is 0x27.
Done. Continuation is done with the CAN protocol.
Anyway, I try to read more and if I find out, I will explain here.
Thanks.

This statement is false.
You can also upload and execute your own bootloader. An exploit is required to bypass the signature check.

Can you more explanation? I think you are right. Because I saw some data that look like BSL or etc (I sniffed all data of Kess:) ).
And all of this data sent by CAN protocol. Interesting.
So, In the beginning of operation, use the K-line protocol for initializing and security access, and in Continuation sent data by CAN protocol.

Is this a tool in bench mode with the HWCFG and RST pins attached?

And, do you see a message from tool to ECU with data length 8 and starting with 55 55 as the message data, at the beginning of the CAN protocol part of the process on your ECU?

In that case, this message is the "knock" for the low-level Boot ROM backed Tricore BSL and if so, the tool very well may have gotten what it needed from SBOOT (if you are sure it is even talking to SBOOT) and then just reset the MCU into Tricore BSL itself.

Let me be more clear:
When applying one signal 10KHz, and other 8KHz, then you cannot do more besides using this protocol with CANID 523/524.
I dont see using this protocol you cant do much besides brute force a part of flash.

However if you apply other frequencies to the same 2 GPT pins then you start Bosch service mode (or whatever is called).
Then you have a special way of communicating with the ecu and using the known exploit you have full access.

If I'm wrong about the limitations of protocol 523/524 then please correct me, preferably with an example log.

- No, the operation done without opening ECU box and there is not RST pin on ECU pinout.
-Yes, always.

OK, But "knock" command comes after K-line commands. What happens in this time? I say:
" It seems, two signal cause the ECU goes to GPT mode. Then, Tool send initial and security access command to ECU by K-line Protocol (my first problem is here, why seed length is 10 bytes? How I can find the key?). Then, after all of this, communication with CAN protocol started"

Am I wrong somewhere?  ???

OP - what ECU are you connecting to? What is your tool plugged into on the other end? (MED17.x, EDC17.x, SIMOS x, something else entirely?)

Out of curiosity I am trying this with an old MED17.5 (TC1766) I found at the back of my garage shelf. However, the ECU is so old (datestamp Jan 2009) that it doesn't respond to UDS/ISO-TP but only KWP/TP2.0.

While I get no response with 524/523, maybe that CANID (and the multipart ISO-TP message thereupon) is just not appropriate for an ECU this old with only TP2.0 stack...?

TP2.0 and UDS have nothing to do with this, the application never loads, nor does the CBOOT.

The idea seemed straightforward enough. Apply a pair of frequencies to two specific pins, power up the ECU and in the course of starting it will encounter the frequencies on the pins and open some communications doorway. I’m fairly sure I got the physical pins correct as there are a plethora of pinouts for bench mode tools that specifically show MED17.5 GPT1 & GPT2 connections. It’s hardly new now.

The test pattern given in the example earlier in this thread (524 - 31 01 01 7F 90 01 7F 90 12 34) is bigger than one CAN frame and so gets split up for transmission. The example log also showed the multi parts formatted for ISO-TP:

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 55 55 55
523 [8] 02 71 01 00 00 00 00 00

I learnt that the example was done with EDC17C64 and all I had to hand was MED17.5 (TC1766) so obviously that’s a difference. And what the OP used is anyone’s guess.

But the steps are simple enough in themselves:

1. The physical pins for GPT – I’m reasonably sure I’ve got the right ones
2. The frequencies – I’ve used 10khz and 8khz. Maybe there are others?
3. The comms – maybe this bit is more family-specific? I used CANID 524/523 and got nothing. Not an ACK or even a NACK. Just nothing at all. So either it’s a different comms or the application wasn’t running (if I got step 1 or step 2 wrong)

This is much more than I ever wanted to do with MED17.5. It was simply the closest one I had to hand! My real interest is SIMOS18, but learn to walk before I run etc

(As a total aside, CCP does respond on the MED17.5, but that is totally, totally separate to the whole frequency thing which I was interested in to start with)

can0  7C3   [4]  01 00 01 AD
can0  7C4   [8]  FF 00 00 02 01 00 00 00
can0  7C3   [4]  1B 01 01 01
can0  7C4   [8]  FF 00 01 02 01 00 00 00

CCP runs in the ASW. If you got that far then it already jumped out of SBOOT.
The frequencies are listed in the SBOOT data area, they might just be different for your ECU.

Hi,

524 [8] 10 0A 31 01 01 7F 90 01 ( 31 01 stand for a Routine Control )
523 [8] 30 00 00 00 00 00 00 00
524 [8] 21 7F 90 12 34 55 55 55
523 [8] 02 71 01 00 00 00 00 00 ( 31 + "40" stand for a Positive response of Routine Control , 71 01 )

It's a UDS protocol over CAN  ;)

Med17.1.62 example For the Can ID

PFLASH:8080EB60                 .word loc_7E8           ; CAN ID
PFLASH:8080EB64                 .word loc_700           ; CAN ID
PFLASH:8080EB68                 .word loc_7E8           ; CAN ID 
PFLASH:8080EB6C                 .word loc_7E0           ; CAN ID
PFLASH:8080EB70                 .word loc_524           ; CAN ID  ---> This one
PFLASH:8080EB74                 .word 0xCAFEAFFE

Notice the 0xCAFEAFFE so you can spot the list Easily after the end of the cboot code. There You will also Find the DID List for the rdbi Function.
The DIDs are the same.

Example :

PFLASH:8080EC34                 .word 0x40F             ; read logical-block lockvalues
PFLASH:8080EC38                 .word unk_D0013F37      ; BASSVRAPPL_VWLOGICALSOFTWAREBLOCKLOCKVALUE_E
PFLASH:8080EC3C                 .word off_8+2
PFLASH:8080EC40                 .word 0
PFLASH:8080EC44                 .word loc_F1F4          ; read boot-loader identification
PFLASH:8080EC48                 .word unk_D000FF30      ; BASSVRAPPL_CBVWVERSION_E
PFLASH:8080EC4C                 .word 0x1D

On a UDS Med17.5 (1.4 tsi ) it seems that the can ID is different

PFLASH:8000D3B0                 .word unk_7E8           ; CAN ID
PFLASH:8000D3B4                 .word unk_700           ; CAN ID
PFLASH:8000D3B8                 .word unk_7E8           ; CAN ID
PFLASH:8000D3BC                 .word unk_7E0           ; CAN ID
PFLASH:8000D3C0                 .word off_6F0           ; CAN ID ---> This one

Here are some painstaking notes from blind (I don't own/have access to any commercial tools, so this is all from disassembly) reversing Simos18 SBOOT: https://github.com/bri3d/Simos18_SBOOT . Still incomplete (most notably, lacking the useful exploit part to dump passwords...) but hopefully interesting. I did have a bit of help verifying the PWM waveforms as I was never quite sure of the final frequency that ended up locked at this stage.

While the concept on Simos18 seems similar to other Tricore ECUs (use GPTA comparator cells to compare some waveforms and then do something over CAN), the details seem quite markedly different - totally different frequency structure and seemingly a totally different command set too. By my reading S18 provides only an extremely limited, state machine based command shell providing ISOTP-CAN commands which allow a CRC-validated and RSA signed bootloader to be uploaded to RAM and executed with flash unlocked for Write, no evidence of any other commands available.

I am not sure what the exploit commercial tools use to read boot passwords is yet. My guess is it's one of: the weak bounds checking on the CRC checksum areas being used to overflow the length back into something that will actually complete, the weak bounds checking being exploited in a more complex way (i.e. RST the CPU in the middle of running the CRC and use BSL to dump RAM to find the temp value), there's something in the RSA I haven't found yet, or there's a stolen signed SBOOT-BSL out there somewhere. I plan to try out some of these avenues this week and will of course report back if I make it in.

I haven't been able to get past the signature decryption stage of the S18 SBOOT shell, it uses a different pubkey from the firmware so I can't just send a signature block from an existing firmware component. Furthermore, upon more disassembly, it seems there is yet another "GPT" style shell in Simos18, but this time in CBOOT. How many of these damn things do we need? I am now reversing this CBOOT shell. It seems that VW were a lot worse than Continental at security systemically, so I'm expecting the CBOOT one to be more exploitable.

(edit, upon more disassembly of CBOOT, there is definitely some undocumented behavior, including a trapdoor back into SBOOT, but I'm not sure how much of it is exploitable either. I've dead-ended myself for now. If anyone with commercial tools can drop me a hint if the tools are using a stolen signed loader, that would really help - I'm trying to do this clean, and I don't want anything like a full dump, but knowing that it's stolen IP vs an exploit would really help me. My worry right now is that I spend hours and hours hunting an exploit in the SBOOT load procedure and it turns out there was just a valid signature in use instead).

There was no leak from Continental on the Service Mode, there is no signed loader being used.

Thank you, this helps a lot - I know that my time is not wasted continuing to look. Appreciate it!

I work with the guy who developed this a long time ago on SIMOS8.5.

The SIMOS service mode exploit is nicknamed “twitch”, that should point you in the right direction.

On S8.5 (also 8.3, 8.4, 12) you get a full exploit, which actually allows you to read and write memory through it.
S18 there is only password reading.

A riddle AND disassembly to play with now, I love it! Thank you!

I did figure out that I was wrong about what I thought was "just" the RSA signature being passed in. Instead it's a seed/key that seems based on some combination of that material and a Mersenne Twister seeded with the system timer. Fun stuff.

I was so fixated on the first task (the ISO-TP command shell) that I didn't notice the other task running out of RAM that seems to send arbitrary data out a GPIO - that's definitely a good prospect to say the least.

I did figure out how the ISO-TP command shell seed/key works and barring an issue I haven't seen yet, the principle is very smart and secure - it seeds an area of random data with a Mersenne Twister seeded with the system timer, then encrypts that data with the 0x136 RSA Public Key and sends it to the tester. It expects to get the raw data back decrypted, meaning the tester needs to have the corresponding RSA Private Key. In this way, even a leak of a signed boot loader wouldn't be enough to re-use, because without key material, the ECU won't allow it to be uploaded. This of course requires the tester to have the Private Key, which is not practical for a diagnostics tool (as the key would be dumped and leaked in a heartbeat) but is quite practical for a manufacturer-only engineering tool that is presumably only used in edge cases (reverse engineering tuned ECUs mailed in, debugging, etc.).

Interesting, Therefore, by having a private key, the key can be obtained. Do you think the KESS tool have this private key?
How we can get this key?

I sniffed data that there was on K-line  and in 0x27 CMD saw this:

TOOL: 0x00,0x02,0x27,0x7F,0xA8
ECU:   0x00,0x0D,0x67,0x7F,0xA3,0x27,0xFE,0x33,0x01,0xA1,0x96,0x97,0xCF,0x3B,0x34,0xFB   Seeds are red
TOOL: 0x00,0x82,0x27,0x80,0x00, .. .Up to 85. .. ,
          0x01,0x42,0x8A,0x2F,0x98,0xD7,0x28,0xAE,0x22,0x08,0x19,0x04,0x7C,0x44,0xF3,0x9A,0xB1,0x15,0x4A,0x53,0xE1,0x37,0xA4,
0xF1,0xE4,0xA1,0xF9,0x50,0xA3,0xA7,0x3A,0x9C,0xE2,0x69,0x89,0x7A,0x05,0x94,0x39,0x3F,0x6E,0xEA,0xA9,0x5C     Keys are red

So, As you see, seed is 10 byte and key 21 bytes. What am I facing? Can the RSA algorithm convert one byte to two bytes?

This RSA seed/key is in Simos18 - I believe the Bosch ECUs are completely different. We should split up this thread from "Tricore GPT" since it is different for each ECU, to Simos Service Mode and Bosch Service Mode. Let's do it this way: I will start a new thread with any new findings I have on S18 and we can leave this thread back to Bosch, since they two are not the same.

For example, the Simos18 protocol does not use anything that looks like KWP/UDS or CCP at all, it is just a full custom command shell, while it seems the Bosch stuff is based on standard protocols. The only similarity really is the use of square-wave/rising-edge waveforms to access the modes.

So all I am doing here is confusing the original purpose of the thread, which was for Bosch.

As for whether or not tools have any private key, that was a worry of mine (as a leaked file would render reverse engineering a gigantic waste of time, I could spend forever looking for an exploit only to learn there never was one), but as you can see up the thread, at least for Simos, I have been told there was no leak and it is all real exploits.

Thanks. I was encouraged to learn Simos18.  ;D
I change this thread name, and It does not matter what the result. It is Important that how I have to do it. I'm looking for a way that help me to solve this challenge.
So, I try to trace commands in dump and get some result then write here in details.

Hello unicornux ,  any progress?

Hi,

I try to do a bootstrap loader on my Bosch MEVD17.2.G (TC1797 mcu) in bench mode without opening the ecu as my PCMflash tool does but I am stuck at the security access before transfering the bootloader. I think it is a sort of seed key : ecu sends 10 kind of random bytes and the host must answer with 20 bytes. I was sure the algorithm was in the BootRom (0x8FFFC000-0x8FFFFFFF) but after successfully dumped and disassembled it I haven’t found the algorithm in the code (only 16kb). Maybe someone know where is located this algorithm in the code ?