You literally proved your own point...

There are "a couple" standalones (including Syvecs, which does support the CAN integration) that can drive an engine with relatively available, reasonable, and successful tuning on the stock ECU. If these companies can compete and make it worth their time to produce standalone ECUs for markets with competing stock ECUs, imagine if the stock ECUs weren't flashable!

Anyway, taking it back to the original topic of this thread, MG1 is a small step towards the "smartphone" level of security and a bypass was discovered with relative ease. All the hand-wringing about "early release" is warranted but smacks of the same situation in the iPhone jailbreaking community where people are shamed for "burning exploits." One way or another the software will be taken apart and even if it eventually isn't (again, the surface area for ECUs is much smaller than iPhones although the competence level is also 10000x lower), we have backup options.

Nevermind the fact that every car I've heard about running on Syvecs was totally undriveable. I've been in a twin turbo Huracan running Syvecs and part throttle was dog shit, never mind their "torque calculations" that were totally wrong and made clutches slip even at 0.5 bar boost. Plus a few Porsches "running" their "plug n play" that drive like total crap at anything other than WOT.

It's not about a backdoor leaved open, it's about the main door bosch uses to test/debrick/reflash ecus (TSW). For the ones that thinks about poor security for a "secondary/notused door", this hack is about exploiting at least 2 (not one) bugs to bypass 2 (not one) rsa signatures (don't ask details, i've not and i don't care at all about the mg1).
bosch had improved in security, now using a new (and signature forgering proof) RSA lib (probably bought from someone else), but as usual (and this is valid for all devices implementing rsa) the bugs are in the way they use that lib.
They will fix these bugs, sure, in...2/3/4 years maybe? How long did it take to close the checksum trick in SB?
Furthermore, at such time, actual indian cheap developers will be already fired, the new kids will be too lazy to understand what the prev team did, so they will add their shit over old shit, inserting fresh new bugs (as happened in edc17).
Security is improving, technology is getting more feature-rich and more complicated, but new coders are less smart than before, that's the hope.

perfect example here (and people died because of it): https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

Hey look at that - my exact thesis, they moved towards real cryptography but were unable to write bug-free software!

Also, the assertion made in this thread that trust rooting and early-stage boot verification is dramatically different on a "microcontroller" like TriCore and an SoC like what you'd find in an iPhone or game console is ridiculous, the problem space is almost identical. Yes, I know what CBOOT, SBOOT, and ASW are - you can even find my code that pulls CBOOT ASW_1 ASW_2 ASW_3 and calibration from an SGO... on this very forum. And yes, the surface area on an ECU is much smaller, but the fundamentals remain the same.

I have years of experience in reverse engineering SoC boot security and the ECU world is, by and large, years behind the state of art in the industry, where engineers still produce trivial logic bugs and memory safety implementation issues consistently (not to mention sidechannel/timing leak and fault injection issues that are rarely even considered).

Morning, Nick 

Later I can post damos for this ecu.
2.0tfsi
3.0tfsi