I was definitely wrong when I said that the CRC checks aren't important. They are checked constantly, one zone at a time, and are responsible for the P0601 DTC.

I will try to take a look at other files when I get the chance.

Hmm. Unless i'm crazy, i don't see winols fixing the CRCs..

Surely if we can identify the CRC32 function itself with a simple binary search once we find it with IDA or similar dissassembler. (I'm guessing that code doesn't change that much between different firmwares, probably identical or very few variants).

..We should then be able to find all function call's which make reference to it (i.e. call it) by searching for 'call/jsr' asm functions which reference it in any subsequent code blocks. e.g. calls in the code itself. Perhaps any jmp's too? and then look back a few instructions to determine their arguments (parameters passed).

e.g. it must be using the function something like this..


Q. Do we not just need to understand the binary machine code signature of those calls (i.e. the raw hex format of the machine code?).

Then once we know the file offsets which are actually calling the crc32() function (which we stored in a simple array or table) we can identify the "start address" and "end address" (or length and derive the end address from that) and the scan the C16x m/c for any variants of call it can make.

Looking at the C166 instruction set guide these variants are;

So a search for all call functions signatures referencing the CRC32 code block address we found earlier in the binary signature search should tell us everything we need to know right? Or am I missing something?

We've already loaded the entire firmware now into ram in the latest app.

Again looking at the C166 Instruction reference manual, the hex signature you've provided us means;

{ E6 F4 xx xx }, MOV reg, #data16 { E6 RR xx xx }
{ E6 F5 yy yy }, MOV reg, #data16 { E6 RR yy yy }
{ DA 00 D8 7E }, CALLS seg, caddr { DA SS MM MM }

(where the xx and yy are the address ranges we want)

e.g. does this (roughly) translate to;
{
 MOV r4, #xxxx      // load the value of xxxx (e.g. 0x1111) into register R4
 MOV r5, #yyyy     // load the value of yyyy (e.g. 0x2222) into register R5
 CALLS 0, 0xD87E  // execute function in segment 0, offset 0xD87E
}

Q. So looking at your signature, your looking for 2 mov's and one CALLS.

Is that really enough to make an exact match? I'm surprise it doesn't find calls to other functions too if searching over the entire rom. Is this because of the segmentation register meaning its unique for this particular region. I need to read up more on the C166x asm architecture! Also what happens if the CRC routine is in a different location than 0xD87e segment 0. It wouldn't find it right?

Can someone point me to the exact dump that this works with so I can see myself.

-T

2nd part is to make some masks that will identify the regions as well, as they do vary a bit, I found at least three different ones.
The routines between 29F400 and 29F800 are a bit different too.

I prefer to just write in ASM...
But regardless, someone needs to implement the pattern finding and I can give the rest of the patterns as well.

I am not very fond of C/C++, I'd rather just help with ASM.

I know it's not much help with your Ferrari, but oh well...

Lol. I used to be like that... swore by assembly but in my older age I've got very used to C. (laziness i guess.. having to think less... )

You can find at least 3 checksums, and then see if there are any other matches, and if there are other matches, then see if any of them are around there 6 bytes off, if you want to do it.

As for other then VAG roms, I am clueless. I just mainly tune VAG for now.
However, if you donated me a Ferrari, I might be more inclined to figure things about Ferraris.

There is no "actual CRC32 routine" it just compares the calculated sum to stored value...
If you looked and understood the ECU routine, you'd see what I mean. For now you will have to trust me and implement it the way I say