F8X mevd17.2.G BootStrap Loader - Security access

[MpowerE36]

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 ?

[NamGrandPaa]

Newbie here

[NamGrandPaa]

How many posts do I need to PM?

[MpowerE36]

I've finally succeeded to find where is located this algorithm. It is on hwel1 and hwel2 (OTP area). I translated it in Python (approximately 3000 lines of code). I now understand why some programming tools don't succeed to pass the security test on last version of this ecu. It is because bmw had modified their algorithm on the last version of hwel1 and hwel2.

[MpowerE36]

It works like this :
1) ecu uses the seed it sends to the host to calculate an internal 20 bytes key thanks to a first algorithm
2) ecu receives the 128 bytes host key and calculates another internal 20 bytes key thanks to a second algorithm
3) if both internal 20 bytes keys are identical, then the security test has been passed

[MpowerE36]

I am looking for the d exponent (private key) of the 1024 bits rsa encryption to pass the bench mode security test of the mevd17.2.G after 07/2020. Indeed they have increased the security of their algorithm from this date (complete verification of the pkcs#1 v1.5 RSA signature). Does someone know in which bmw software can I find this huge number ?

I know some algorithms exist to find it but it will take too much time with the current computing power (n has 309 digits).

I give below the public key (e,n) :

e=3

n=151482974395813378797403505644940953425994861811 95123144725177053397197327094171306973835484030067 88923510315885278060212866463145040678741531498000 06266150566185331559500046028432118701124472196179 76524838522200787221602392945464347802351089403600 38751077792491068201336733171121515017214676015355 88880226919

[ppm008]

i guess you will not find anywhere the private key.
In Esys flash file *.pdx you will find security files inside.

[MpowerE36]

I agree. This type of key must be in very special debugging tool.

[MpowerE36]

I've found a backdoor to avoid the rsa mechanism. It's strange to put an armoured door on one side and a wooden door on the other.

[bingflash]

I am looking for the d exponent (private key) of the 1024 bits rsa encryption to pass the bench mode security test of the mevd17.2.G after 07/2020. Indeed they have increased the security of their algorithm from this date (complete verification of the pkcs#1 v1.5 RSA signature). Does someone know in which bmw software can I find this huge number ?

I know some algorithms exist to find it but it will take too much time with the current computing power (n has 309 digits).

I give below the public key (e,n) :

e=3

n=151482974395813378797403505644940953425994861811 95123144725177053397197327094171306973835484030067 88923510315885278060212866463145040678741531498000 06266150566185331559500046028432118701124472196179 76524838522200787221602392945464347802351089403600 38751077792491068201336733171121515017214676015355 88880226919

hello, love your work

start your factoring of n from
D7B80AE1F3D336AB
83BD6CB71616A30D
292C9D94D9BFDC80
D612B49404D56B61
AC4F3D3CEB78D83E
7B17954949F4983A
F3A5DE795251BA31
AD360AC6C74C1D2A

to sqrt(n)

its a significant leg up, if you were extra bold, you could use a gpu to start threads, one counting up, one counting down(--from sqrt(n)) and one generating random primes in this range(which is constrained as both the up count and down count increment), one from mid point between suggested point to sqrt(n), counting both up & down, one from sqrt(bottom 50% of bits from n)+suggested number, counting up and down, with additional constrained rand generators for these ranges. each thread can save its progress, the rand generators need not save prior attempts, it generates too much data, the double processing of some numbers < potential factoring benefit in solving the equation

https://ask.sagemath.org/question/65884/can-sagemath-use-gpu-or-multiple-nodes-or-multiple-cpus/

@NSA how did I do ? lol

[MpowerE36]

It could be a good idea but there are always too many possibilities. Currently, the best solution to decompose a big number in two prime numbers is CADO NFS but even with a powerful computer 200 digits is approximately the limit (the current record is 250 digits with lots of cpu). CADO NFS doesn't work on gpu.