Pages: 1 2 3 [4] 5 6 ... 10
 31 
 on: March 04, 2021, 12:37:03 PM 
Started by d3irb - Last post by d3irb
Hi All,

I am sure some of you had followed along with my thread jack before at : http://nefariousmotorsports.com/forum/index.php?topic=18870.msg143053#msg143053 .

I have been researching Simos18 SBOOT's Service Mode functionality.

The quick summary is:

Simos SBOOT is similar to Bosch GPT/Service only in that it uses two PWM pins as the "break in" signal. Otherwise, the principles and methodology seem quite different. From what I am told about Bosch Service it usually works over something CCP/UDS like, and has direct access to Flash.

The Simos Service Mode works differently. It uses a custom protocol over ISO-TP (at least, I am not aware of any other protocol using the same command values), which allows the tester to upload a signed code block into RAM, just like the signed code blocks which are used for CBOOT/ASW.

Unlike low-level Tricore BSL where Flash is locked, this signed code block is then executed with Flash unlocked for write, so the factory could use this to upload a flasher. But, the Simos18 sigchecking seems pretty sound so far (the application-level exploit for port flashing is to bypass the sigchecking entirely, not an exploit in the actual signature mechanism). So, we can't use Service Mode to run code on Simos18 as far as I can tell.

The Service Mode is also protected by a Seed/Key mechanism. The Seed/Key mechanism seems quite sound on its surface - an RSA public key stored in OTP is used to encrypt 256 bytes of random data and that is sent as the Seed, and the tester is expected to send the data back decrypted as the Key, which should require the corresponding RSA factors (private key).

However, this Seed/Key mechanism it has a fatal flaw: there is no real entropy used in the seed generation.

The PRNG (Mersenne Twister) is seeded using only 31 bits of data taken from the system timer. This is vulnerable in two ways:

* A timer isn't an entropy source, so the attacker can simply control the timing of _when_ they ask for the Seed in order to predict the value of the system timer. It seems Continental may have known about this idea as they added a "minimum wait" time before the Seed can be generated using a timer task, but, a simple fixed minimum wait time doesn't make the timing any less controllable.

* Worse, there are only 31 bits (2^31) of possible key space to begin with. Modern hardware can easily calculate hundreds of thousands or even millions of Mersenne Twister -> RSA exponentiation operations per second, so even if the seed were generated off of a true entropy source, the entire key space can easily be enumerated in a matter of minutes on a fast workstation.

The combination of these two weaknesses makes prediction trivial - even using a Raspberry Pi (no real-time OS, high level code in Python) as the tester, the timer values I have observed when the Seed is generated are always within a few hundred thousand timer iterations. And, with a single core of a modern laptop able to calculate 100,000 signatures/second, it takes only 1-2 seconds to brute-force a Seed/Key match starting from an observed timing offset.

Of course, if the calculation were slower, it would also be possible to generate a table mapping Seed values back to Keys, which I spent a bit of time on before deeming it unnecessary as I can simply spend 2-3 seconds brute-forcing a match to the Seed/Key each time.

Now, once we are past the Seed/Key mechanism, we can't upload a valid code block, at least as far as I can tell. Again, the actual sigchecking in S18 seems pretty sound, and for those thinking about a block reuse attack, the signed SHA256 used in the RSA signature has addresses mixed in to prevent this very thing.

But, just like all other Simos18 software blocks, the code block also has a CRC header, and this header has very weak bounds checking. By manipulating the CRC header, we can ask the Service Mode command shell to checksum the Tricore boot passwords, then quickly RST into a normal Tricore BSL which has access to RAM.

Next, we can dump the CRC values from the temporary area where they are being stored in RAM. Since CRC is a reversible (non-cryptographic) hash, by sliding the CRC start value along by the values, we can infer boot passwords from Flash.

Here is a more detailed write-up, including some other odd bits of SBOOT : https://github.com/bri3d/Simos18_SBOOT .

Here is a Seed/Key brute force tool. It takes two command-line parameters as hex strings: the "initial" timer value to start from (to speed up the process, once you've run the exploit once with a given tool, you know the general range of where the timer values will land), and the first 32 bits of the Seed data sent from the ECU (I haven't found a collision yet... maybe I should expand the matcher to a few more bits though!). Once a match is recovered, will return the full Seed/Key data as well as the timer value used to create them.

https://github.com/bri3d/Simos18_SBOOT/blob/main/twister.c

And here is an implementation of the CAN comms stack and the overall break-in process, including the necessary PWM signals (sorry, it is mixed with normal Tricore BSL since the exploit requires doing an RST into the Tricore BSL to dump RAM):

https://github.com/bri3d/TC1791_CAN_BSL/blob/main/bootloader.py

Cheers and enjoy!

 32 
 on: March 04, 2021, 12:24:02 PM 
Started by Peterb5 - Last post by Peterb5
Thank you very much

Στάλθηκε από το MAR-LX1A μου χρησιμοποιώντας Tapatalk


 33 
 on: March 04, 2021, 12:13:36 PM 
Started by mrmusicmajor - Last post by nyet
One hint is by comparing boot rom version reported by ME7Sum

 34 
 on: March 04, 2021, 12:06:21 PM 
Started by unicornux - Last post by terminator
Thanks for the answer. I hope I understood it right.

By default, the stack grows downward in memory, so newer values are placed at lower memory addresses.
sub.a        sp, #0x20
lea              a4, [sp]0x14     // 0xD000C380 - 0x20 + 0x14 = 0xD000C374 ?
ld.bu        d15, [a4]0x00      // load byte from 0xD000C374 to d15? right?



 35 
 on: March 04, 2021, 10:24:37 AM 
Started by Peterb5 - Last post by stuydub
Here u go

 36 
 on: March 04, 2021, 10:24:03 AM 
Started by mrmusicmajor - Last post by grayjay
Your  2005 1.8t ME7.5 A4 ECU (8E0909518BC) should be cross-flashable with the 2004 (8E0909518AK) which has well defined .xdf available and which was used as the basis of the community stage 1 tuning project. You will likely have an easier time following and using the community tune 1.8T project if you cross flash to the 8E0909518AK. The latest .xdf and .bin from this tuning project are available in first post of thread at;
http://nefariousmotorsports.com/forum/index.php?topic=6955.0

Ive included discussion of another alternate .xdf for the 8E0909518AK which I prefer to use later in this same thread at;
http://nefariousmotorsports.com/forum/index.php?topic=6955.msg141439#msg141439

cheers-

 37 
 on: March 04, 2021, 10:16:19 AM 
Started by unicornux - Last post by prj
You need to read a book about programming basics or you need some formal education on that matter.

This Wiki article is pretty good:
https://en.wikipedia.org/wiki/Stack_register

Your first comment is already wrong. A4 is loaded with address that is 0x14 offset from current sp.

 38 
 on: March 04, 2021, 10:01:32 AM 
Started by unicornux - Last post by terminator
What is a stack pointer?
I know the basics like push and pop, sp points to the value stored on the stack.
From the instruction set I read:

SUB.A A[10], const8
Decrement the Stack Pointer (A[10]) by the zero-extended value of const8 (a range of 0 through to 255).

sp is actually a10 and like a0, a1, a8, a9 in most cases set up only once:
movh.a          sp, #@HIS(unk_D000C380)
lea                 sp, [sp]@LOS(unk_D000C380)


I would appreciate if anyone could comment on this part of the code.

 0x80006EA8       sub.a        sp, #0x20        // allocate a space   
 0x80006EAA       movh.a       a15, #0xD000
 0x80006EAE       lea          a4, [sp]0x14     // load address to a4.  0xD000C380 + 0x14?
 0x80006EB2       lea          a15, [a15]0xBF4      
 0x80006EB6       ld.w         d4, [a15]0x00
 0x80006EB8       call         0x80007086
 0x80006EBC       ld.w         d4, [a15]0x01
 0x80006EBE       lea          a4, [sp]0x08      
 0x80006EC2       call         0x80007086
 0x80006EC6       ld.hu        d2, [sp]0x16
 0x80006ECA       jeq          d2, #0x00, 0x80006F1A
 0x80006ECE       ld.hu        d1, [sp]0x0A
 0x80006ED2       jeq          d1, #0x00, 0x80006F1A
 0x80006ED6       ld.w         d15, [sp], #0x07
 0x80006ED8       jlt.u        d15, #0x02, 0x80006F1A
 0x80006EDC       ld.w         d15, [sp], #0x04
 0x80006EDE       jlt.u        d15, #0x02, 0x80006F1A
 0x80006EE2       ld.hu        d0, [sp]0x18
 0x80006EE6       ld.hu        d15, [sp]0x0C
 0x80006EEA       jeq          d0, d15, 0x80006F1A
 0x80006EEE       mov          d0, #0x00
 0x80006EF0       mov.aa       a15, sp


 39 
 on: March 04, 2021, 09:11:23 AM 
Started by amd is the best - Last post by terminator
for me7
http://nefariousmotorsports.com/forum/index.php?topic=16741


 40 
 on: March 04, 2021, 08:55:04 AM 
Started by gonzarace - Last post by Auriaka
Find a damos or mappack thats close to what ypu have, make your own.

There is a few defs rolling around here depending on your ecu...but your gonna have to go through the fprum and dig for it

Pages: 1 2 3 [4] 5 6 ... 10
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.02 seconds with 14 queries. (Pretty URLs adds 0s, 0q)