NefMoto

Hello,

Has anyone deactivated the rsa check from this file?

Even if i put the ecu in TEST mode by changing the bytes from the eeprom and also the codewrods from
flash i get the death code bytes when doing changes outside the maps area after 2 3 days.

I have corrected the checksum with 4 different tools but nothings seems to make the correct rsa key for this version...

ME7Sum should have no problem generating the correct RSA MD5 for this file

I used winols, Cmd, Ktag, Map3d,

I did not try the me7sum but for example if i add the als nls code here in 2 days the car will through 2 x AA bytes in the second and third page inside the eeprom and car will not start..I assume this comes from the rsa cause car runs perfeclty under all cases.

ran through ecufix.

the NLS code that has been floating around is bad and overwrites RAM used by the RSA code. ECUfix disables RSA completely, which, IMO, is the wrong approach.

I have no intention of doing that in ME7Sum since that is supporting bad practice and bad code.

Get the NLS fixed.

Thanks for that will check it out as soon as possible.

So where is the bug on that one? Is there something wrong with any Register in the code or the 384ff0 is a bad address for the function counter?

Yes. The ram address being used is reserved for the RSA.

Thank you for the answer and which would be a tested address space for the rsa equiped ecus?


As for the RSA deactivation, Since i do not own the ecufix after some research i did with IDA pro in various files with rsa, a quick way to deactivate it would be to search for the following hexstring :

c1 47 fc 10 00 8d eb 98 60 db 00 xx xx xx xx (word_fd9x.x, locret_8xxxxx in most cases)

replace the xx with db 00 db 00 and the first jump is off

The xx xx xx xx bytes do also include the memory address of the next jump that you will need to disable so if you load the file in ida pro you will quickly find out the next address.However if you search for the 8b db 00 xx xx xx xx after the first jump you will most likely find the second one.

I checked this in 3 sw versions Me7.5 (polo - seat leon - audi a4 ) and found that it was the same procedure.

so assuming that ecufix disables the rsa completly that way, even if i use the same address ecu will not lock down or ?

Maybe 385ff0? i do not see something there in this a4 bin.anyway i will test it...

try 0x386000

Anyway  I was told there are other issues in this NLS code... I'd probably ditch it until it is fixed or you know enough to fix all the problems in it yourself.

Works on one polo...Will try to the a4 aswell.

What NLS code are you talking about? Are you refering to this  http://www.nefariousmotorsports.com/wiki/index.php/Adding_anti-lag_launch_control_and_no-lift_shift ?

Don't know about that code. Was referring to Mazer's script.

yes but after some days happened the same again with 386000 unfortunatly...in order to inject though i wrote my own tool but maybe there is a bug on that aswell...will check it soon enough.

i also had the rsa disabled (andy`s way) but i do not think that this was the problem.... i will use the launch.exe from the forum and cross check with my tool first.

Well i crossed checked it with my Gui tool and code output is fine.

The tests i did were various starting from different code locations - variable locations - different tools for correcting rsa checksums - manual deactivation of the rsa and different counter addresses 384ff0 and 386000...In every case i got the bad "brick" or "Death" Bytes in the second and third line of the 95040 eeprom.


Btw Should i post my Gui Tool here or to the 2 step and antilag topic?

Attached i have a polo version that produces the same problems as other members in the forum have already pointed out.

Post your tool here. I haven't disassembled the code yet, but is it only one ram address accessed by that code? Are used registers free? Everything push:ed and pop:ed correctly?

If you disabled RSA checksumming and still had the same problem, i'd look elsewhere.

setzi has a full emulator where he can see what binary will do (he's already helped me with a bunch of oddball binaries)

prj probably could help if you can convince him..

I have this problem only on RSA binaries so that is why i assumed it was the rsa algo that was conflicting with something on the code...

As i have seen on other posts there are a some users that had the same problem but i did not checked the code myself instead i wrote a gui tool to make things faster for the implementation.

As for the emulator i would like some info so i can set one up by myself either with keil or anyother sw/hw combination.

No need to convince someone here about anything since all of you are kind enough to provide a lot of usefull information which made our life easier...Further more since my contribution was not much i am willing to change that somehow if i have the time in the future.

My frist step is to share the tool i developed for that code:

Simple Gui wrote in visual studio with c#. It still needs your me7info .ecu output but you need to type the addresses by hand since i was too lazy to make a parser for it. Nothing is needed to run(no php), just .net which i am sure everyone has.

I am also working in a better version that locates ftomn and other addresses and can fix eeprom errors and checksum on the 95040 but it is still based on the initial code that is published here.

The bitmask table that will be needed :

40001.0     mask:0001   -> 00h
40001.1     mask:0002   -> 10h
40001.2     mask:0004   -> 20h
40001.3     mask:0008   -> 30h
40001.4     mask:0010   -> 40h
40001.5     mask:0020   -> 50h
40001.6     mask:0040   -> 60h
40001.7     mask:0080   -> 70h
40001.8     mask:0100   -> 80h
40001.9     mask:0200   -> 90h
40001.10     mask:0400  -> A0h
40001.11     mask:0800  -> B0h
40001.12     mask:1000  -> C0h
40001.13     mask:2000  -> D0h
40001.14     mask:4000  -> E0h
40001.15     mask:8000  -> F0h


To locate Ftomn on 1.8T i search for a0a0a08080(05) in hex

nls counter 0x384ff0 for non rsa ecus.

Wow! Ok. That is very curious. That tells me maybe the "RSA" disables you tried missed one (or some part of something else).

As far as setzi's emu, I have NO clue how he does it.

Well if that is the case then Rsa occupies both 384ff0 and 386000 ? Maybe Setzi or someone else can enlgihten us on this..

Link dead is this still kicking around?

Talking this thread from death I will try to ask here. I am curious about this too. I have same problem with a similar A4 ME7.5. 8E0909518AR RSA ECU. I have been doing tests and looking for an answer. I have mixed results bricked at once or after several on-off cycles. Then may I ask which will be the way to solve this problem, different RSA RAM address or RSA totally disable?

Did you put NLS in file?

Yes

Share your file?

Ok attached

Remove NLS unless you've been able to walk through the RSA code and determine why NLS is interfering with it

I have send NLS rpm limit to a higher value than actual car rpm limit in order to deactivate it. LC function works but in few hours or during the second day it bricks again.

Read sticky themes about RSA and NLS. Set NLS counter to 0x38600 and that is it.

Ok thanks for that idea. I test 0x385FF0 without sucess.

Well friends, finally I think the solution was using 0x386000 for NLS Counter variable. After several days using car everything is working properly for my case. 8E0909518AR RSA software.

It is posted before but it was not only that...It is a combination of things and fixes...

Thanks Thanos I read your post and other's recommendations posts. I have 3 steps: different NLS counter address, RSA disable and finally make ECU in test mode. Now 1st step is apparently working.

Enviado desde mi Redmi Note 8 mediante Tapatalk

ECU in test mode you can do via eeprom changes

BR