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!

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

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.

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).

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.

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.

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.