unicornux
Full Member
Karma: +2/-6
 Offline
Posts: 83
|
 |
« on: December 23, 2020, 05:37:36 AM »
|
|
|
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?
|
|
|
|
« Last Edit: February 07, 2021, 10:24:27 PM by unicornux »
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #1 on: December 23, 2020, 02:01:10 PM »
|
|
|
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
|
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #2 on: December 23, 2020, 11:03:21 PM »
|
|
|
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? |
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #3 on: December 24, 2020, 05:09:55 PM »
|
|
|
Sorry, all EDC17 ecu's I tried this one all use CAN bus.
I have never worked on K-line.
|
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #4 on: December 26, 2020, 01:56:13 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #5 on: December 26, 2020, 10:10:47 AM »
|
|
|
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. This statement is false. You can also upload and execute your own bootloader. An exploit is required to bypass the signature check. |
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #6 on: December 26, 2020, 11:57:59 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« Reply #7 on: December 26, 2020, 12:50:56 PM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #8 on: December 26, 2020, 05:39:36 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #9 on: December 26, 2020, 05:41:59 PM »
|
|
|
If I'm wrong about the limitations of protocol 523/524 then please correct me, preferably with an example log.
|
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #10 on: December 27, 2020, 12:49:05 AM »
|
|
|
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.
- 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?  |
|
|
|
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #11 on: January 02, 2021, 02:00:07 PM »
|
|
|
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...? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #12 on: January 02, 2021, 03:58:41 PM »
|
|
|
TP2.0 and UDS have nothing to do with this, the application never loads, nor does the CBOOT.
|
|
|
|
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #13 on: January 03, 2021, 02:46:43 AM »
|
|
|
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
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #14 on: January 03, 2021, 04:17:18 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
