NefMoto

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!

Good job.
What is pretty unfortunate though is that the booting S18 requires a lot of wiring, as the CAN isn't hooked up by default.

great work as always!

This is some seriously cool stuff! Thanks for sharing, this will definitely help with what I'm trying to learn wrt exploit dev

Thanks d3irb. I think Bosch VAG ECU's are different in details but are the same in general.
Do you think this is logical?

Impressive, thank you!


Rgs H2Deetoo

Since this has inspired me to take a look at the related albeit older Simos 8.x ECU, I guess I'll also share what I could gather so far using the clues from the data and code you posted. I know, it's a lot less relevant than Simos 18 and hardly of interest to many people, but anyway. Seems like the boot passwords are in the same location in both 8 and 18, 8001420c, and recovery shell is also easy to find. As of know, I don't yet understand if 8 is enforcing any conditions on the range bounds for the crc header you mentioned. I.e. seems like almost any addresses can be supplied, but I'm not 100% positive on this. Not sure where the intermediate checksum value is stored in the memory either, perhaps I just need to set the sboot up in qemu and try to run it.

I've been working on PCR due to a message I received here, and the basic concept is identical. In the case of PCR, the bootloader has the same commands (albeit totally different addresses due to the different CPU), and similar bounds checking (albeit slightly weaker) - but, the RSA public key is different - and, the RSA is also 1024 bit instead of 2048 bit, so everything is half the size (the seed/key as well as the RSA key).

There's also some subtle difference in the way the seed is constructed that I haven't nailed down completely yet which is breaking my code - although I expect it to be a stupid off by one mistake somewhere.

In older Simos ECUs there is also an exploit that can gain arbitrary code execution this way, due to a buffer overflow in the RSA signature checking which was fixed in a newer aslarm/nvmcrypt - once the seed/key is passed, a code block crafted to defeat the signature checking can be constructed and executed.

Given that enumerating the entire 31-bit keyspace should take less than an hour on available modern/super fast hardware, I think this means that older Simos may be possible to exploit without needing to open the ECU, so I've been investigating this route. Simos18 will always need to open the ECU - in order to access the RST and HWCFG pins to descend into the Tricore BSL and dump the CRC. But for older Simos, if the Seed/Key can be passed without needing to control the RST timing too carefully, that means arbitrary code can be uploaded using the RSA exploit, much like the Bosch TSW exploit.

Thanks for your reply! In general, it would be nice to have something open-source which could allow reading, backing up, and writing "eBay ecus", i.e. ecus without matching immobilizer system modules. For the time being, however, I'm just trying to back my ecu up in case I brick it. In principle, given that I can flash my ECU with PCM Flash, I could probably extract the boot passwords by, say, modifying the UDS service 22 table and repoint some of the "measuring blocks" to boot password location:
Say, change the address from 0xa0040090 to 0x8001420c and get them out. Caveat here is that this asw change might brick it if there's something else I don't know about.

Simos12.1 and 12.2 and PCR bench (TSW exploit) has been out for quite some time now.

Without opening ECU?

With opening ECU for RST/HWCFG (CRC RGH / memory inspection exploit), all Simos is identical to Simos18 just with different addresses and RSA keys.

Without opening ECU is more interesting since it involves chaining the old RSA exploit into the process as well.

I know some tools do the Seed/Key process online with a pre-generated prefix tree / rainbow table too (which in addition to being fast, also makes the exploit harder to steal).

Yes, nothing I have discovered is new, I just like figuring it out clean and providing documentation instead of stealing everything and hoarding it. I don't try to claim I'm doing original research here, just actually sharing what's going on :)

Yes, if you don't have immo-lock and you have a CBOOT/port-flash exploit, you can go this route - by altering the read handlers or you can just write your own UDS handler which directly reads the passwords. Most people just hang it off 3E since the logic is simple. But, this doesn't help for immo-locked ECUs of course.

IIRC everything older than SIMOS18/SIMOS16(?) can be r/w without opening the ECU.

Thanks, sounds like everyone else is already using the exploit chain I have in mind then!

Yes, without opening the ECU, duuuh.

I did some tests with PCR and I have no problem generating the RSA response, so contact me if you want to work out your problem.

And it's also possible to reset by switching VCC which gives me reasonable constant timing results, so neeed to open to find a RST signal.


Rgs H2Deetoo

This all reminds me (with a smile) of when the original concept of emulating old computers and arcade machines was in its infancy.

Many people thought it would never ever work and it would be impossible to get it working perfectly. At the time none of those proprietary custom chips like sound and graphics hardware could be emulated and it all seemed like a mission to develop all that code (which it was!) however slowly but surely a few maverick individuals armed with nothing more than lots of time and the hardware chipset register manuals and a few example programs got to work. The results are virtually 100% emulation of the vast majority of old arcade and home computers like the Amiga (it was not at all easy to emulate with cycle accurate timing the copper chip with all its bugs!). I thought long and hard myself about emulating an entire full C167 based Motronic firmware so that I can run the ME7.x software in QEMU. Its easy to under-estimate the sheer amount of work required to do this with cycle perfect accuracy, it is possible but the effort required is enormous.

In the longer term all these old proprietary ecu's micro-controllers will die and the only way forward may be emulation for reasons of software preservation. Either via FPGA's or via software emulation on vastly more powerful general purposes cpu's like we have on the desktop. Whether we still have the fuel available to actually run them will be another matter altogether, fingers crossed for Porsche to develop their synthetic fuels!

Hi People.
How can I find the public key in OTP? I work on Bosch ECU so my issue is different probably.

Right, and to my total amazement just a couple of weeks ago it came to my attention that there is this whole MiSTer thing going on, which in itself is not surprising (I was very much aware of small single old chips being reimplemented on FPGA-s), but the amount of currently supported and fully replicated complete systems is just overwhelming. And of course I have one coming to me in some days now, if it is what I expect it to be, my RetroPie will be decommissioned...

Apologies for OT ;)

Great work.  I have a B9 A4...if there's anything I can help test, let me know!

I may have an idea how to perform a similar exploit on simos 8.5, but struggling to identify what connections need to be made to the ecu pcb. I was searching for bench reading setup descriptions, but they don't seem to match the 8.5 ecu I have. Does anybody have any pics or diagrams showing where boot, hwcfg pins etc can be accessed on the pcb? I was trying to trace the chip (tc1796) pins but no luck, I'm not even sure what the correct orientation is for comparing with Infineon's docs. Plus it's a BGA chip and all the pins are hidden under it.

I don't know if this is what you're looking for. This is bootmode pin locations simos 8.5 s4 3.0t. FLex tool

Thanks, it looks similar to simos 8.6 schematics I found. Unfortunately, neither indicate which tricore chip pins these contact points correspond to (HWCFG, boot etc).

Yes, good job for .....having sniffed a commercial tool, understood the exploit and replicated it. Now you know (at least i hope so) why commercial tools costs money then.

Where do you get the impression or idea that this work came from sniffing a commercial tool? I don't even own a commercial tool capable of doing bench/boot for any ECU. This is a bold accusation against the level of research posted here. Your other posts seem competent so I would prefer we could collaborate instead of resorting to baseless accusations.

Several respected members here can tell you about our communications and collaboration throughout this process and that no commercial dumps were involved. Furthermore, in reading my documentation you can find a large amount of information which would not even have been meaningfully useful if I were trying to reverse engineer a sniffed log.

I'm sure you reversed the bigint functions, i'm sure you reversed the mersenne twist (not 100% standard btw), i've some doubt you spot yourself the partial crc trick without a sniff (but still possible, why not), i'm not convinced at all you found freq and phase shift by only static analysis (why a phase shift and not a different duty?)

Sincerely thank you for replying, these are more of the kinds of conversations I like to have rather than random accusations!

The partial CRC trick was one of the more obvious parts to me actually, since the bounds checks stand out like a sore thumb and any time you see bounds checks in security code like this it gets the wheels turning... from there I kept thinking backwards to "how can I possibly exploit this" and "stop the process" wasn't a massive logical leap. I guess this goes to show how people think differently about these sorts of things.

The frequency and phase shift was honestly a massive pain and took me quite some time and was the closest I came to giving up and asking for a commercial dump. But, in my documentation on GitHub you can clearly see how I did this: https://github.com/bri3d/Simos18_SBOOT#recovery-shell-entry-details-gptpwmpw .

Figuring out that it was phase shift this using static analysis was not actually that hard - I used the TriCore manual to understand what the GPTA register setup was doing. The method which compares the values (screenshot of my Ghidra pseudocode attached in case you don't believe I went through all of this) makes the use of phase shift vs. duty cycle somewhat evident, because the edge1->edge1 and edge1->edge2 values must match multiple times to be valid, so it must be a constant offset between two signals (phase shift) versus a rolling offset or duty cycle comparison.

What was a pain with static analysis was figuring out the base frequency which those cycle counts were derived from. I had to go deep into the PLL documentation and setup code to figure out what was going on there.

I will admit that I did take one part which isn't even the one you've accused me of stealing - I used a Facebook post with a picture of a Simos18 bench setup on it to figure out where the test points were. Actually, I sacrificed one Raspberry Pi to getting this wrong, too, as they have horrible protection on the GPIO pins. If I hadn't have had this piece of information I would have had to do another few weeks of work - I knew from the data sheet which balls on the processor package corresponded with each necessary pin for BSL, of course, so I would have had to rework the chip and go hunting for test points. I did initially actually try to probe directly underneath the chip package but due to the ball grid layout this proved implausible.

this looks eerily similar:)

That's the point, there are at least 4 potential flaws in sboot, simos18 has 1 working, other ecus have more than 1. If you walked thru all the code in the hope to find a bug, PCR would be a piece of cake then, but if you walked thru the code already knowing what you were looking for, then pcr is a mistery. That's what i think.

I'm not telling you copied anything, there is nothing to copy, having a sniff is just about having a red cross in the treasure map, then it needs a lot of reversing to pass the s/k and some coding for reverting crc and making a custom code to exec, and believe me some comemrcial tool developers are not as skilled as you, some others are so lazy morons that never arrived to a conclusion, but now it's all on github and i bet they are within the ones that gives you glory and asks you for pcr.

I respect your work, but i'm not giving glory, hope you understand.

HI chaps

Is there an easy way to read (and clone) a Simos18.1 on the bench?
What tools are recommended?

I have PCM Flash but S18.1 is not on the supported list

THanks

Use the search button and read...

1. Don`t spoil threads/posts that have to do with technical stuff without even reading them.
2. Pcmflash will soon support most of the simos variants.
3. If you search and look a bit better you will find a free python solution to flash simos ecus made by "d3irb" and hosted on Github

Works on windows too...

did something very similar for an older simos 8.5 and posting here:
https://github.com/fastboatster/TC1796_CAN_BSL
instructions are not quite complete yet

Very nice work! Congrats!

Thanks, appreciate the kind words! Wouldn’t be able to do it if d3irb hadn’t described simos18 exploit, though

could you please share the file (bin or odx) you have been working on or at least the software id?
Maybe I was inattentive, but I did not find it on the forum.

In the VW_Flash writeups about CBOOT and patching, the addresses are all from 8V0906259H__0001.frf , for no reason other than this is the file that came on my car. This is SC8 project, E0 CBOOT, O20 ASW. This should be in the documentation somewhere.

In the Simos18_SBOOT write-ups about SBOOT, the addresses are all from a Simos 18.1 SBOOT/TSW. I think the TSW version identifier for this is REGEE5F401E1_TSW--v10. You need a full read to get SBOOT of course, since it isn't in the update container.

Thank you. You are right it was always there
https://github.com/bri3d/VW_Flash/blob/master/docs/cli.md

Thank you, d3irb and fastboatster !!

Your findings and knowledge sharing have really helped me to better understand the Siemen's MSD81 ECU (TC1796) in my BMW.

So far I can trigger a jump to SBOOT, but have not yet located the RSA private key needed to satisfy the $65 service response. Needless to say, I am way behind you guys.

I compared a SIMOS 8.5 bin with a MSD80 bin and noticed byte for byte SBOOT code reuse. That being said, it wouldn't surprise me if commercial exploits that upload code to RAM via SBOOT and dump PFLASH, etc. are reusable between platforms.

You know, I was looking at IKMOS MSD81 firmware very recently, too, and noticed a lot of very similar things in general, not just in terms of boot firmware. I haven't looked for an RSA key yet, and haven't tried to put an MSD81/80 into SBOOT mode since I don't have any of these on hand - my guess is it just needs to have PWM voltage applied to some cam sensor or Vanos solenoid pins, right? I sort of put this on the back burner for now since I'm busy with my job search, and just don't feel like working on this DME right now and desoldering and retracing boot pins on PCB. I might get to it eventually, but by that time, I think you will figure it out already. I am just lazily looking at e9x MEVD17, but not spending too much time on that, either

I'm sorry to hear that. I wish you the best of luck! I gave up on my job search quite a while ago.

You can jump to SBOOT via CAN, no PWM required.

I compared a MSD80 dump to the SIMOS 8.5 SBOOT bin you posted in the thread below (example attached):
https://nefariousmotorsports.com/forum/index.php?topic=14906.msg153252#msg153252 (https://nefariousmotorsports.com/forum/index.php?topic=14906.msg153252#msg153252)

I ordered a SIMOS 8.4 from eBay to check it out.

For the Simos8.5/8.4/12/MSD81/MSD85/ etc SBOOT there is an exploit without having to jump into BSL mode to examine memory.
This was closed in the newer ECU's.

Since there is a ton of tools that can do it, it probably is easiest to just sniff an existing tool rather than reinvent the wheel.

I  came across this KWP2000 reset payload for SIMOS 18 in some ETAS ProF files... "52 73 74 4B". It might be the jump from ASW to SBOOT. The expected response is "44 6F 6E 65".

well, at least for me, this was a moderately difficult but somewhat useful *exercise*. not too difficult as the general workflow had been described, but challenging enough for somebody who had never looked into any DME/ECU firmware before. It did provide something I could use as an alternative to some commercial tools. I have a general idea of what's going on with commercial exploit - i.e., likely, something like Nintendo 3ds bootloader hack. I'm not really inclined to spend more time on this as these are 2 very old and increasingly irrelevant ECU/DMEs, but if there's some low-hanging fruit and some free time then maybe why not - i.e., commercial tool sniff etc.
@808AWD325xi - there're no bootloader differences between the 8.5 and 8.4 aside from the RSA keys. When I was saying that msd is closer to 8.4, I meant to say that both have their eeproms on the external chips, while 8.5 stores it in the internal d flash.

In some gearboxes is sequence started at BC xx xx xx xx ;-)