Pages: 1 2 [3]
Author Topic: R32 ME7.1.1 OLS300 Simulator  (Read 21405 times)
Rittersport
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 13


« Reply #30 on: April 27, 2017, 06:39:32 AM »

Yes, but very very rarely.

1. Search for "47 F8 55 00 CC 00 CC 00" (1 match)
2. Search forward for "E6 F4 FF DF", notice the address, save the last 4 bytes (0x69E0A -> 9E0A)
3. Change "47 F8 55 00 CC 00 CC 00" to "47 F8 55 00 EA 00 0A 9E" (use the last 4 bytes loHi)

In EEPROM change 69 C1, A5 to 8E 5A, D2. On page 01 and 02.

This approach works on pretty much everything. Technically if WinOLS is correcting checksums you can only do the EEPROM.
The first patch is to check checksum when ECU is powering up (IGNITION ON). The EEPROM mod is to disable checksums while ECU is running, which is the really important part.
Maybe a silly question. Will this work on Volvo ME7 ? They have the same problem.. when changing on the Fly with OLS 300 ECU dies.. (8bit values can be modified without ecu fuckup but 16 bit values can't)
I have searced for the Hex values in the Volvo files and not found the 47 F8 55 00 CC 00 CC 00. But E6 F4 FF DF can be found in numerous places.
Logged
vwaudiguy
Hero Member
*****

Karma: +48/-35
Offline Offline

Posts: 1990



« Reply #31 on: December 06, 2017, 09:44:52 AM »

I'm going to say if you aren't finding hex string "47 F8 55 00 CC 00 CC 00" in your binary, then there is another string of hex for your particular ecu. I'm positive there's a way to do it, but unfortunately, I don't know how. Time to get cozy with IDA.
Logged

"If you have a chinese turbo, that you are worried is going to blow up when you floor it, then LOL."
pizzaschnitzer
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 17


« Reply #32 on: March 28, 2018, 03:46:52 AM »

Yes, but very very rarely.

1. Search for "47 F8 55 00 CC 00 CC 00" (1 match)
2. Search forward for "E6 F4 FF DF", notice the address, save the last 4 bytes (0x69E0A -> 9E0A)
3. Change "47 F8 55 00 CC 00 CC 00" to "47 F8 55 00 EA 00 0A 9E" (use the last 4 bytes loHi)

In EEPROM change 69 C1, A5 to 8E 5A, D2. On page 01 and 02.

This approach works on pretty much everything. Technically if WinOLS is correcting checksums you can only do the EEPROM.
The first patch is to check checksum when ECU is powering up (IGNITION ON). The EEPROM mod is to disable checksums while ECU is running, which is the really important part.

This thread is the same problem i have on 2.7t ecu 4z7907551N, but i already tried the checksumfree mod on my emulator ecu (roadrunner) the car starts once, now i have the eeprom-error code in it. i think i need to reflash the mpc. can you give me a litte slap on my ass how to come clear with it?
i want to use tunerpro/roadrunner and neet to endian the file for using it with tunerpro, but it would be okay if its working like that.
thankyou! PS: your info about 550cc injectors works perfectly. i tuned them now on LTFT +0,8/-0,8 left/right bank. the car runs like stock and has beatiful idle. THANKALOT!
Logged
prj
Hero Member
*****

Karma: +309/-41
Offline Offline

Posts: 3652


« Reply #33 on: March 28, 2018, 06:05:27 AM »

Your ECU does not have a flashable mpc. It only has ROM OTP.
To fix the additional problem with this checksum on this ECU search for "9A ?? ?? ?? DA ?? ?? ?? 49 81 3D 19" (question marks are wildcards).
Replace with "CC 00 CC 00 CC 00 CC 00 CC 00 CC 00".

The code should clear on next ignition and car should start.
Logged
360trev
Full Member
***

Karma: +29/-1
Offline Offline

Posts: 145


« Reply #34 on: November 05, 2019, 03:20:57 AM »

I've attached a screenshot so people can understand a bit more all of these what look like magic numbers prj has been posting.

Its really not very difficult if you have a basic grasp of Siemens C167 Assembly language and the resultant conversion of those opcodes into hex codes. A lot is described in the free to download pdf of the instruction set from the web. I also wrote a c167 disassembler in C (part of the Swiss Army Knife tool) that I posted on github for free if you want to understand it more.

So the magic numbers;

47 F8 55 00

{ 47 opcode} { F8 register } { ?? ?? 16 bit data in little endian byte format }

which means;

cmpb    rl14, #55

or translated into c;

     if(CW_NOROMCHKRESET == 0x55)
     {
               // ... do something
     }
..

As you can see after the comparison opcode there are 2 nop's represented by ;

CC 00               nop
CC 00               nop

All this tells the processor to do is 'nothing'. I.e. idle. It can be used to pad or 'nop' out instructions and its used very commonly to modify binary code by patching the instructions.. 

What's going on here is that Bosch themselves disabled the use of the CW_NOROMCHKRESET control word feature which normally if it was set to 0x55 in hex then it would have disabled the rom checksum feature which forces a reset if the rom checksums fail. By modifying code in realtime the checksums fail and the code is designed to detect this and reboot.

In some Bosch ME7 roms I have seen this nop nop isn't present. What prj is doing is simply replacing to 2 nops with a JMP instruction to the address (offset) where its necessary to exit the checking. This way it bypasses the checking.
 
If anyone is really interested on how all of this works I am happy to write a few tutorials if there aren't any good ones already here. I must admit I haven't done too much searching.

I think all this searching for magic numbers doesn't really help peoples understanding. Just even having a basic knowledge of what's going on will help a lot of people and stop many of the what appears to be 'dumb' questions.
Logged
prj
Hero Member
*****

Karma: +309/-41
Offline Offline

Posts: 3652


« Reply #35 on: November 05, 2019, 11:53:40 AM »

99% people have no idea about this. For those who know asm no explanation is necessary.
Logged
nyet
Administrator
Hero Member
*****

Karma: +440/-60
Offline Offline

Posts: 10014


WWW
« Reply #36 on: November 05, 2019, 12:03:44 PM »

     if(CW_NOROMCHKRESET == 0x55)
     {
               // ... do something
     }

Just to close the loop, the noops look like this:

Code:
void checksum_test()
{
     if(CW_NOROMCHKRESET == 0x55)
     {
             // nop
             // nop
     }
     ....
     if (checksum fails)
       throw code
out:
     return
}

The nops can be replaced with goto out, which would make the 0x55 test actually bypass the checks.

I don't think it is immediately obvious to everyone (even those familiar with disassembly) that Bosch intentionally undermined their own checksum disable mechanism, in any case. When disassembling code, it is very confusing when the code you're trying to figure out does not do what you expect the original author wanted.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please 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 experience.
BlackT
Sr. Member
****

Karma: +15/-8
Offline Offline

Posts: 492



« Reply #37 on: November 06, 2019, 04:04:28 AM »

99% people have no idea about this. For those who know asm no explanation is necessary.
Yes but with every detail explanation, we are a step closer to understand it( at least in my case)
Logged
360trev
Full Member
***

Karma: +29/-1
Offline Offline

Posts: 145


« Reply #38 on: November 06, 2019, 08:38:18 AM »

I don't think it is immediately obvious to everyone (even those familiar with disassembly) that Bosch intentionally undermined their own checksum disable mechanism, in any case. When disassembling code, it is very confusing when the code you're trying to figure out does not do what you expect the original author wanted.

Agreed as most people would assume they would conditionally compile the feature out completely.

However I have seen this technique used before a few times. Way back when I was an embedded developer on RTOS's like VxWorks and pSOS, STOS, etc. in Assembly and C back in the 90's I saw this applied quite a bit. I.e. of inserting NOP's to remove a conditional branches for testing or forcing code to behave a certain way (e.g. in Safety critical systems like Medical, etc.). The rationale is its a defensive test strategy. The theory goes, you do multi-million dollar exhaustive testing on every route through the compiled code. By changing physical lines of code and re-compiling it could actually introduce other bug not seen before simply by the fact the code may have 'moved' or you did something you didn't mean to do. By simply removing the conditional branch on the original tested and already compiled branch of code its still the exact same code tested before except that single branched route through the code is no longer operational.
 
Logged
fluke9
Full Member
***

Karma: +10/-1
Offline Offline

Posts: 72


« Reply #39 on: November 10, 2019, 04:19:22 AM »

Very interesting that they left the mov and cmp intact and only killed the jmpa.

But it makes a lot of sense, looks like the customer wanted this to be disabled,
so they wont accidently ship out a version without checksumming or something else.

And the most predictive and pragmatic way to do that was to remove the jump,
as the binary could be intact and no code would move if they recompile it.

It could also be some old asm module they include like in every me7.
Looks like some code is already precompiled and included and some is compiled for every build.

The McMess routines for example are 99% identical in all ME7, even registers used match, so looks like it is legacy assembly.
Logged
360trev
Full Member
***

Karma: +29/-1
Offline Offline

Posts: 145


« Reply #40 on: November 10, 2019, 04:24:45 AM »

Exactly as you've stated, I'm sure they exhaustively test on a per module basis.

Think about what can happen if they conditionally compile out code. The memory profile will change and some obscure bugs may end presenting themselves in subtle ways. I've seen this module disabled with nops and then enabled (jump left intact) and then subsequently disabled in newer versions of the same rom destined for same model year cars. Perhaps their testing strategy sometimes isn't as rigorous as they expect Smiley
Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 17 queries. (Pretty URLs adds 0s, 0q)