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.

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!

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.

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


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.

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.
 

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

Because it does not affect RSA.
To bypass RSA there's another mod that is required. Look where it's set (fault) and change the jump to always go the other way.
That will not only prevent it from getting set but will instantly clear if it was set previously.

How about scrolling up a few posts and patching the mask besides only doing the 1st post?