|
phila_dot
|
 |
« Reply #60 on: January 02, 2013, 08:00:35 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #61 on: January 02, 2013, 09:53:58 PM »
|
|
|
I have the checksum searching working.
Checked in to git. i have made ini loading optional (since eventually we shouldn't need the inis)
360trev: the autodetection doesn't work for your bin, since your main range block 1 is different from ALL of my ME7 audi images (0x800000-0x80FBFF vs 0x800000-0x80FE6D). I could loosen up the search, but i'd like to have somebody else find other binaries or soemthing so i have more datapoints.
ETA: i have added masks to the search, so the 360 search works now too.
All thats left is the CRC search; sounds like it is critical.
|
|
|
|
« Last Edit: January 03, 2013, 12:04:17 AM by nyet »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #62 on: January 02, 2013, 11:10:33 PM »
|
|
|
Hmm. Unless i'm crazy, i don't see winols fixing the CRCs..
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #63 on: January 03, 2013, 03:13:20 AM »
|
|
|
551c
0x810000 - 0x814000 @ 0x86BD8A
0x814300 - 0x817F68 @ 0x86BD90
0x818191 - 0x81FC00 @ 0x86BD96
It looks like what needs detection are the checksum locations, but this is very easy to do.
|
|
|
|
« Last Edit: January 03, 2013, 03:17:02 AM by prj »
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
 Offline
Posts: 235
|
|
« Reply #64 on: January 03, 2013, 04:22:24 AM »
|
|
|
551c
0x810000 - 0x814000 @ 0x86BD8A
0x814300 - 0x817F68 @ 0x86BD90
0x818191 - 0x81FC00 @ 0x86BD96
It looks like what needs detection are the checksum locations, but this is very easy to do.
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.. crc32 = do_crc32(start,length);
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; CALLR rel Call relative subroutine
PCALL reg, caddr Push direct word register onto system stack and call absolute subroutine
CALLA cc, caddr Call absolute subroutine if condition is met
CALLI cc, [Rw] Call indirect subroutine if condition is met
CALLS seg, caddr Call absolute subroutine in any code segment
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? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #65 on: January 03, 2013, 04:33:56 AM »
|
|
|
You are over thinking it slightly, but this is the general idea. Also for the C box, if you compare to the locations I gave you will see that these ranges are correct  Adr: 0x010000-0x013FFF @0x6693c CRC: 0xF4F209DD CalcCRC: 0x22402F9B ** NOT OK **
Adr: 0x014300-0x017F67 @0x66942 CRC: 0xA5A2F442 CalcCRC: 0xE359D549 ** NOT OK **
Adr: 0x018191-0x01FBFF @0x66948 CRC: 0xF57425E0 CalcCRC: 0x3E37E205 ** NOT OK ** Here is something useful from my good old hacking days: DWORD FindMemoryClone(DWORD start, DWORD end, const UCHAR *clone, UINT size, HANDLE processHandle)
{
for (DWORD curAddress = start; (curAddress + size) < end; curAddress++)
{
if (CompareMemory(curAddress, clone, size, processHandle))
return curAddress;
}
throw "Offset not found!\n";
return NULL;
} BOOL CompareMemory(DWORD address, const UCHAR *mask, UINT size, HANDLE processHandle)
{
for (UINT i = 0; i < size; i++, address++)
{
UCHAR curbyte;
ReadProcessMemory(processHandle, (LPCVOID)address, (void*)&curbyte, sizeof(UCHAR), NULL);
if ((curbyte != mask[i]) && (mask[i] != 0xFF)) {
return FALSE;
}
}
return TRUE;
} And the mask you have to find: E6 F4 FF FF E6 F5 FF FF DA 00 D8 7E FF - masked out byte. You need to find all matches of that mask, the first FF FF is the low word of the address, the second FF FF is the high word. There should be three sequential ones, where the the pointed values are 6 bytes apart, these are the checksum locations. I am sure you guys can adapt this function or the idea behind it to work on a file instead of RAM |
|
|
|
« Last Edit: January 03, 2013, 04:36:33 AM by prj »
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #66 on: January 03, 2013, 04:49:24 AM »
|
|
|
And the mask you have to find: E6 F4 FF FF E6 F5 FF FF DA 00 D8 7E FF - masked out byte. You need to find all matches of that mask, the first FF FF is the low word of the address, the second FF FF is the high word. There should be three sequential ones, where the the pointed values are 6 bytes apart, these are the checksum locations. I am sure you guys can adapt this function or the idea behind it to work on a file instead of RAM 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 |
|
|
|
« Last Edit: January 03, 2013, 05:04:16 AM by 360trev »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #67 on: January 03, 2013, 05:05:03 AM »
|
|
|
You got the endianness wrong, but other than that you are right.
However, if you note, then I gave another set of criteria which will filter out the false positives.
I told to look for three consecutive addresses in the form of YYYYXXXX that are 6 bytes apart.
This should work for almost any VAG ME7 dump.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #68 on: January 03, 2013, 05:09:17 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #69 on: January 03, 2013, 05:11:46 AM »
|
|
|
You got the endianness wrong, but other than that you are right.
However, if you note, then I gave another set of criteria which will filter out the false positives.
I told to look for three consecutive addresses in the form of YYYYXXXX that are 6 bytes apart.
This should work for almost any VAG ME7 dump.
Ah, I see. and thanks for the endian thing! I wrote assembly language for a decade (in a former life as a games programmer!) so I'm very familar with asm but not the C166 (yet!). I think I will modify the open source TinyC compiler as a cross compiler target to C166, that would help me in 2 way, (get VERY familar with the instructions) and also make it VERY easy to provide the community a way to automatically patch in C code into ROM's (!). I.e we could search for free space filled with FF's and then patch it in (all automatically) after compilation... Nice idea? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #70 on: January 03, 2013, 05:17:56 AM »
|
|
|
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...
|
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #71 on: January 03, 2013, 05:20:48 AM »
|
|
|
You got the endianness wrong, but other than that you are right.
However, if you note, then I gave another set of criteria which will filter out the false positives.
I told to look for three consecutive addresses in the form of YYYYXXXX that are 6 bytes apart.
This should work for almost any VAG ME7 dump.
Thinking about this a little further... I can understand and follow the logic well.. i.e. instead of looking for just one call to a function with 2 arguments .e..g result = anyfunc(address1, address2);
we are looking for 3 of them in succession. i.e. result = anyfunc(address1, address2);
result = anyfunc(address2, address3);
result = anyfunc(address4, address5);
Which roughly translates to something like this... crc32_number_1 = calc_crc32(start_1,end_1);
crc32_number_2 = calc_crc32(start_2,end_2);
crc32_number_3 = calc_crc32(start_3,end_3);
I can fully appreciate this would indeed be quite unique however what in non VAG rom's? Is there ALWAYS 3 checksums? In the method I originally gave, finding the actual CRC32 routine itself and then ALL references to it should lead to perfect results every time with zero false positives... No? However its obviously a bit more work to code.... |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #72 on: January 03, 2013, 05:23:48 AM »
|
|
|
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... ) |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #73 on: January 03, 2013, 05:38:18 AM »
|
|
|
I suppose if I want to get the 360's final crc32's found i'm going to have to crack open the old disassembler...
I think I may actually write my own (anyone written an open source C166 disasm yet?) or cpu emulator? This is a relatively simple (by modern standards) cpu and I have an excellent reference document (the Instruction set is freely downloadable on the web). Would be quite fun...
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #74 on: January 03, 2013, 05:38:57 AM »
|
|
|
I can fully appreciate this would indeed be quite unique however what in non VAG rom's? Is there ALWAYS 3 checksums? 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. In the method I originally gave, finding the actual CRC32 routine itself and then ALL references to it should lead to perfect results every time with zero false positives... No? However its obviously a bit more work to code.... 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 |
|
|
|
|
Logged
|
|
|
|
|
