djhoke88
Newbie
Karma: +1/-0
 Offline
Posts: 1
|
 |
« Reply #15 on: January 26, 2021, 04:10:59 AM »
|
|
|
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  |
|
|
|
|
Logged
|
|
|
|
|
gt-innovation
|
|
« Reply #16 on: January 27, 2021, 08:32:55 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
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 |
|
|
|
« Last Edit: January 27, 2021, 09:03:00 AM by gt-innovation »
|
Logged
|
|
|
|
|
gt-innovation
|
|
« Reply #17 on: January 27, 2021, 09:39:21 AM »
|
|
|
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
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #18 on: January 27, 2021, 02:13:03 PM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #19 on: January 29, 2021, 10:52:51 AM »
|
|
|
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).
|
|
|
|
« Last Edit: January 29, 2021, 06:35:12 PM by d3irb »
|
Logged
|
|
|
|
BDIX727
Newbie
Karma: +8/-3
Offline
Posts: 21
|
|
« Reply #20 on: January 29, 2021, 08:23:05 PM »
|
|
|
There was no leak from Continental on the Service Mode, there is no signed loader being used.
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #21 on: January 30, 2021, 04:06:39 PM »
|
|
|
Thank you, this helps a lot - I know that my time is not wasted continuing to look. Appreciate it!
|
|
|
|
|
Logged
|
|
|
|
BDIX727
Newbie
Karma: +8/-3
Offline
Posts: 21
|
|
« Reply #22 on: January 31, 2021, 03:10:56 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #23 on: February 01, 2021, 02:57:26 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #24 on: February 01, 2021, 02:00:15 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #25 on: February 06, 2021, 08:06:13 AM »
|
|
|
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.).
|
|
|
|
« Last Edit: February 06, 2021, 12:40:03 PM by d3irb »
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #26 on: February 06, 2021, 10:15:10 PM »
|
|
|
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? |
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #27 on: February 06, 2021, 11:21:50 PM »
|
|
|
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?
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +131/-1
Offline
Posts: 186
|
|
« Reply #28 on: February 07, 2021, 07:39:06 AM »
|
|
|
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?
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. |
|
|
|
|
Logged
|
|
|
|
unicornux
Full Member
Karma: +2/-6
Offline
Posts: 83
|
|
« Reply #29 on: February 07, 2021, 11:13:15 PM »
|
|
|
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.  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. |
|
|
|
|
Logged
|
|
|
|
|
