|
nyet
|
 |
« Reply #60 on: August 17, 2019, 08:54:33 AM »
|
|
|
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. |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
cherry
|
|
« Reply #61 on: August 17, 2019, 09:58:50 AM »
|
|
|
Seems Bflash made beta release today for MDG1 with Aurix TC2xx...
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
 Offline
Posts: 195
|
|
« Reply #62 on: August 18, 2019, 09:24:44 PM »
|
|
|
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
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. |
|
|
|
|
Logged
|
|
|
|
hammersword
Full Member
Karma: +31/-2
Offline
Posts: 136
Revlimit ECU tuning
|
|
« Reply #63 on: September 17, 2019, 08:07:41 AM »
|
|
|
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?
|
|
|
|
|
Logged
|
|
|
|
Ano
Newbie
Karma: +0/-2
 Online
Posts: 11
|
|
« Reply #64 on: September 18, 2019, 08:07:48 AM »
|
|
|
Have you tried original file with Odis ?
My first quess is that the ecu locked itself.
best regards
|
|
|
|
|
Logged
|
|
|
|
hammersword
Full Member
Karma: +31/-2
Offline
Posts: 136
Revlimit ECU tuning
|
|
« Reply #65 on: September 18, 2019, 08:29:17 AM »
|
|
|
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
|
|
|
|
|
Logged
|
|
|
|
Ano
Newbie
Karma: +0/-2
Online
Posts: 11
|
|
« Reply #66 on: September 18, 2019, 10:22:53 AM »
|
|
|
Nice!
first time with new protokoll is always a gamble.
|
|
|
|
|
Logged
|
|
|
|
|
IamwhoIam
|
|
« Reply #67 on: September 18, 2019, 11:21:26 AM »
|
|
|
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! |
|
|
|
|
Logged
|
I have no logs because I have a boost gauge (makes things easier)
|
|
|
|
gt-innovation
|
|
« Reply #68 on: September 18, 2019, 01:20:09 PM »
|
|
|
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...
|
|
|
|
« Last Edit: September 19, 2019, 02:20:55 AM by gt-innovation »
|
Logged
|
|
|
|
Geremia
Jr. Member
Karma: +11/-10
Offline
Posts: 27
|
|
« Reply #69 on: October 02, 2019, 08:24:38 AM »
|
|
|
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.
Bad ECC in a specific flash address, not all tools can handle such cases. |
|
|
|
|
Logged
|
|
|
|
Aurélien
Full Member
Karma: +4/-0
Offline
Posts: 60
|
|
« Reply #70 on: October 05, 2019, 05:01:40 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
dragon187
Full Member
Karma: +13/-15
Offline
Posts: 106
|
|
« Reply #71 on: March 01, 2020, 10:04:01 AM »
|
|
|
Here the present, bit late but better than nothing.
|
|
|
|
|
Logged
|
|
|
|
romano21
Jr. Member
Karma: +0/-5
Offline
Posts: 29
|
|
« Reply #72 on: March 22, 2020, 08:53:24 AM »
|
|
|
Thank's dragon !
|
|
|
|
|
Logged
|
|
|
|
automan001
Full Member
Karma: +47/-0
Offline
Posts: 153
|
|
« Reply #73 on: December 01, 2020, 05:19:23 PM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
