NefMoto

Any further updates on the port or even bench flashing on this platform?

Last I heard APR was still busy working on it.

Yeah like yesterday Autotuner released bench R/W solution, others to follow.

autotuner released bench for all flavors of mdg1 yesterday.

I hear there's been quite a few hard bricks already :D

I would expect it´s possible to recover in bench-mode?

"Bench full read (full backup file available)"

Anyway a lot of guys with autotuner only buy files from reseller and dont know what they are doing, also some resellers dont know what they are doing or only sell "quick and dirty". The business is really weird, who knows what happened. I have AT too, but i will not touch such ecu at all. This is nothing for semi-professional.

I heard from other things in AT which are not working. I had one ecu too which was not working as expected and used other tool then. It was a pretty fast development, so i´m not surprised there are bugs. But support seems to be good.

Interesting!  This is quite exciting, the pressure is on now for the other suppliers to do the same, got to keep that market edge.

i tested the bench for mg1 today. works ok for me. chksums on the way in, no issues at all.

You are always ahead of your time!

Random note, I was scrolling through google trying to find info on seadoo tuning... I believe the rxt-600/spark tuning page and low and behold K0mpresd comes up! What dont you tune!? Keep up the good work, it doesn't go unnoticed.

Awesome, which vehicle was it?  Probably one of the first to flash-tune whatever it was.

2017 b9 a4. about 9 test flashes in so far, at about +30/30 whp/wtq.

still just going through it all. i did not prepare well so yesterday was my first look at an mg1 damos.

What's nice is that your tunes will soon be available to anyone after using that POS of a tool.

i sense a bit of hostility coming from this direction towards the aforementioned "tool".

the tool and the tools behind it, oh YES.

There is always agressiveness coupled with his posts so its normal I'd say :)

so after spending some time on mg1, lol.
should have stuck to simos if they want to make it difficult for tuners.

The main firewall was probably meant to be the protocols needed to flash/methods to overcome the infosec measures.

Good news for tuners!

In fact no good news that these ecu are readable now because soon newer ecu will be locked again for read/write, and then maybe forever. In my opinion the release was too early. The manufactorers paid for hard security and will force Bosch to enable it again. Maybe there will even be a recall, who knows...

And then those will be cracked...

You're right, I can already see VAG BMW MB and god knows who else went with MDG1 as being "uncrackable" taking Bosch to court and asking them for their money back after this fiasco.

Do you really think it was "cracked"? They left a special backdoor for whatever and "wrong" person got knowledge from it. And maybe these backdoors will never ever be there after this "fiasco". I think the personal security will be improved, not the technical...

Btw i did a quick look to MG1CS111 Audi A1 / Polo GTI file with OPF, looks not more complicated than MED17. I think this is what k0mpresd mean...

There are several different areas in computer science that things are said to be un-crackable but once in a while someone finds something that will help...

That is why actually most of us are paying those companies to do such things... I believe the fight at some point will be taken to them.
 

yes, that is what i mean.

By the sound of it and to my knowledge, this wasn't a backdoor left "open"...

Think about it this way: this is the exact same problem space as iPhone updates / security (consumer owns and has full access to hardware but you want to keep them from running unapproved code or modifying the system). Apple employ some of the premier security engineers and researchers in the world to build the security for iPhones and they are invariably jailbroken at some point. ECU manufacturers do not exactly seem to employ the greatest software engineers and most of their solutions are cobbled together off the shelf anyway as software is not their product. The surface area is smaller because ECUs don't do a lot of dangerous stuff like parsing arbitrary data from the Internet, but the level of effort applied is equally smaller.

So far we have mostly seen and exploited boot security schemes that are conceptually broken: fixed key/IV systems that only need to be dumped once, security-by-obscurity non cryptographic systems like checksum routines and seed/key which only need to be understood to be bypassed, or mis-implemented cryptography systems like RSA signatures using a key embedded in the software itself. Once someone manages to build a real trusted boot solution we will move on to discovering implementation vulnerabilities in the software itself which can be used to inject code, of which I'm sure there are many. The "state of the art" is so far behind the rest of the industry that it's unlikely we'll see an "uncrackable" ECU soon.

IMO , even then if there is a "uncrackable" ecu in the future ( which probably will never happen due to reasons) , tuners will always find a modify things. No matter what in the end its still basic electricity, current, resistance, pulses etc, and if you do things correctly you can always fool the car within boundaries, it has been done for years and will be done.

And if electricity is the way to go( after we figure out non polluting batteries or power) , then there you go, even easier.

I mean sure, the solution there is just a standalone ECU, running an engine isn't _that_ complicated at the end of the day.

I don't know what world you've been living in, but standalone ECU's haven't been feasible in anything but dedicated drag racing / sports cars, that has been manufactured in the past 10 years due to lack of integration.
There are very few exceptions (such as Syvecs on certain cars for example), but in the vast majority it is that way.

Hell, most ECU's can't even drive a 2.0 EA888 Gen3. There's only a couple on the market that can manage everything.
And this is before we get to the CAN integration.

I just mean such early release was not good for the business in future. Maybe in future guys search "older" mdg1 ecu which can still be done...  ;)

If you just drop the "I dont know what world you've been living in" your post turns from asshole into informative...  just saying brah... luv yah.

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.

Syvecs does these ECU's for very expensive cars at prices, which are 6000+ EUR before tuning.
This is viable only for the very top-end. Because every platform and every car is different, this will never ever be viable on your every day car.
Also, there are no viable standalone options for Diesels, which are over 50% in europe, and which account also for over 60% of the tuning market.

You are talking theory, but it is apparent from the way you are talking about this (hell, comparing iphones to a dedicated microcontroller), is that you have zero clue what you're on about.
You probably don't even know what CBOOT, SBOOT and ASW are.

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.

Don't talk shit. For as long as they offer a re writable flash, there will always be someone able to "crack". It goes back to the old saying of "if man can make it, man can break it". The only way to make an ECU truly un-flashable is to install the software on an OTP ROM and treat the ECUs as disposable.

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.

Security is improving, technology is getting more feature-rich and more complicated, but new coders are less smart than before, that's the hope.

If they wish that - good luck. More people are getting into tech because of the world. In 1980's and etc it wasnt that accessible also , there were other things going , wars , communism etc. not everybody had the chance.

Point is with years and tech more people are getting into it not vice versa.

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

The criticism of the engineers is ridiculously misplaced.

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

I'd like to invite you to drive one of the RS3's I've tuned on Syvecs. My guess is you wouldn't know it wasn't a stock ECU.

Morning, Nick  ;D

the train picks up speed....  ;)
https://www.magicmotorsport.com/flex-ver-3-9-0-0-mdg1-release/

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

Mag pro finally released mg1!!!

Only PPC, No Aurix.

Seems there is also a CMD beta version for MDG1. I expect other tools will follow soon.

There is a fundamental misunderstanding as to what the purpose of encryption is.

It is to secure a channel between two trusted parties against attack by a *3rd* party.

In this case, there are only two parties, only one of which is trusted.

I think you're the on who's misunderstood encryption
the 2nd case is a perfectly valid use case(to protect code/calibration from any party other than the OEM)

https://en.wikipedia.org/wiki/Encryption

Entirely incorrect. The 2nd party is either in possession of the private key(s), or the hardware can be compromised to be forced to use a different public key (or none at all) for verification.

Encryption was NEVER meant to solve this problem, because fundamentally it cannot as long as the untrusted party has physical access.

How do you think corporate firewalls do MITM?

This was the point I was trying to make. Outside of highly-research-oriented and never practically implemented homomorphic encryption, there is no theoretical way to fully protect an endpoint for which the untrusted party has physical access.

However, there are practical hardening methods that are commonly employed in the industry for these situations: a scenario where a manufacturer wishes to remotely update consumer-owned hardware without giving the consumer access. Where do we find those situations? Mobile phones and game consoles. Rather than being dismissive and rude like others in this thread, we would do well to learn from the trust chain and boot process protections in these kind of devices as this is the direction ECUs will go.

can not upload 7mb
MG1 2,0 R4 4V TFSI EA888 GEN3 BZ MQB A1_8V0907115C_0002.rar

Public key cryptography wasn't meant to solve this problem.
Encryption by definition doesn't have any such limitation

I've not been at school too much, but here encryption is used for fw upgrade over an insecure channel (canbus), to avoid 3rd party to grab it and load it into idapro for static analysis.
RSA is used for authentication and integrity verification (signed hash), for the trust chain (same as consoles, smartphones...).
But this happens in ecus since years, nothing new in mg1, except a more secure locking of MCU (where the trust chain starts).

Encryption absolutely has that limitation, whether public cryptography is used or not. The decryption key is in the hands of an untrusted party. There are only two parties here, not three.

Which means private information (and associated challenge/response code) that is stored inside the ecu itself which is difficult (but not impossible) to physically disable, modify, or extract.

Most of these mechanisms (e.g. TCPM) are sold by people who are not being honest about what cryptography can and can't do. They're adding physical security to mathematical encryption to artificially provide the trusted 2nd party, making the user the untrusted 3rd party. Mathematical encryption alone CANNOT provide the solution they are selling.

They never tell the truth, and most people have zero idea what is actually being sold.

Maybe split file on smaller pieces :)

Just because a method doesn't exist ATM doesn't mean it never will
Encryption from wiki- encryption is the process of encoding a message or information in such a way that only authorized parties can access it and those who are not authorized cannot.

Authorized and unauthorized parties. No limit on the number.

That is a ridiculously simplistic definition of encryption and not at all representative of reality, nor does it even vaguely describe actual real life implementations which have fundamental limitations which are not from the technology, but rather from the math and information theory as a whole.

I have NO idea why you think that dumbed down one sentence summary from WP is somehow magically authoritative.

I'm not talking about existing systems, I'm talking about you limiting the definition to a minimum of 2 authorized parties
I'd like to see a source that says that 2 is the lower limit and NO research is being done in this regard and mathematicians have completely given up hope on encryption in a 1 authorized party system

Edited for clarity

There is no meaning to a "1 authorized party system"

In that case, there is zero need to transfer any information.

Seems Bflash made beta release today for MDG1 with Aurix TC2xx...

Again, homomorphic encryption. I've mentioned it repeatedly in this thread. It's not actually a real thing yet. Tons of research is being done and none of it works.

I 110% agree with nyet and I think we share the same understanding - in a system where the consumer controls the hardware (fundamentally, a 2-party schema although things like "Secure Enclave" and "Trusted Platform" systems as well as hardened systems like satellite TV smartcards try to give the first party a stronghold in the second party's castle, so to speak), all protection is only that - protection, not encryption.

Bad luck here today with MG1CS011. 1st reflash done OK and we tested the car on dyno whereas while we did the 2nd reflash we got a "CAN communication error" during the a sector writing.
After this we cannot do anything to the ECU neither recovery with the original read
We checked the everything even writing voltage and it was super stable. 99.9% we gave the responsibilities at the tool protocol

Tool used was New Trasdata with E-GPT connection

After this we tried BFlash and AutoTuner but no luck, none of them could read.

The strange thing is that all tools could Identify the bricked MG1 ECU and give the ECU numbers but while reading or writing a specific sector they stopped.

New Trasdaata: "Can communication error" on reading or writing (after blocking the ECU)
Bflash: stopped at sector #9 while reading with errors (the already bricked ECU from Trasdata)
Autotuner: stopped at the start of reading with an error of "impossible to identify cks of the sector" (from the already bricked ECU from Trasdata)

Any ideas or experience behind this?

Have you tried original file with Odis ?
My first quess is that the ecu locked itself.
best regards

Big thumbs up to bflash team who did the job and recovery the ECU even if the read was done with new Trasdata.

@Ano
I didn't want to plug the dead ECU to car and try with ODIS or VAS because I didn't know what exactly happened in the ECU so I wanted to
let the car outside of this case and I knew that it could be recovered on boot. The problem was the Dimsport weak protocol and no recovery option

Nice!
first time with new protokoll is always a gamble.

First time with new protokoll from people who don't develop things themselves (hint hint) is ALWAYS a gamble, YES!

Bench protocols from all companies that work with tricore service mode or whatever it is called have issues with a number of ecus..

Seems mostly like a timing issue between consecutive sector writes or failure of communication due to unstable power supply units or power supply units that have peak protections in the amperage. All new ecus are peaking to 2.5 , 3.0 even 3.5 amp on boot and a bit lower on reset. I had a similar case on a med17.1.62 but after many attempts and tests with power supply and can termination filters i figured out the problem.

now for this particular case " Bflash: stopped at sector #9 while reading "

You should have known by that moment that bflash could have revived your ecu by only writing to it..Of course Bflash has a funny way to merge everything in a file and add some specific info in the end of it, but by reconstructing the file to a format the bflash could accept you would have had the ability to write it directly.

If someone has a ktag by looking at the blinking leds on the back can understand what is happening and why this can fail...

Bad ECC in a specific flash address, not all tools can handle such cases.

That's correct. This is what I told Fotis. Poor handling of ECC.

Here the present, bit late but better than nothing.

Thank's dragon !

Thanks for sharing MG1 damos! Could someone share link to MG1 Funktionsrahmen ? I've got MED17.5 FR and trying to learn MG1 maps using it, but see some differences :) For example where did KFZW go? It was in MED17.5 but it's not in MG1 damos. Either damos not complete or they have changed ignition calculation.