In-Tech wrote:Hiya Folks,
The conglomeration of ideas and testing... I really think this will end up super stupid/smart/simple when we get there. At the end of the day it's just us understanding the required protocol.
I am out for the night. 1:39am for me. I bet it's all simple if we can just log enough data for comparison/learning.
Yeah I dont function tool well at early mornings either
Going through the security function that has the EECV defined, it does look like there is a bit going on. Since Im trying to do this with minimal time spent, I think generating all 65k combinations will be a faster and smarter outcome, that way a lookup table can just be used.
The function I can attach to shows the following:
undefined SECALG_ComputeSecurityKey(int SecurityType,undefined1 *param_2,undefined2 param_3,undefined3 param_4,undefined4 param_5,
undefined5 param_6)
I know the first parameter is an integer, as it compares the value against predefined names (What I screenshot previously), where value of 1000 (0x3E8) is for the EECV's.
Its understanding what the rest of the values are.
I believe the return function value is a pointer, but I will need to step through this function being used to better understand what is going on.
One of the more effective methods is making a little shim dll that will sit in its place. This will allow seeing what data is being passed into the function which can be matched up with the seed passed in and other details found.
A guess at some of the other parameters:
1) Seed bytes (Could be in an array, Maybe param2?)
2) Security level (1,3,5 ect).
3) Fix bytes (what is normally used for 3byte).
There is usually 5bytes used for the fix. this could be passed as a pointer to a array.
Next step forward is either to either see if my Ford ecus on the bench also call to this function (Which I believe they do), and then log what is being passed into the function. so that it can be replicated for EECV.
I do see something of interest although again, I am not 100% certain yet what exactly is being passed in.:
Code: Select all
undefined4 __fastcall FUN_10001400(int param_1)
{
ushort uVar1; //16bit
int iVar2; //32bit signed
if (1 < *(uint *)(param_1 + 0x10c)) { //if 1 < *PointerValue(Param1+0x10C)
iVar2 = ((uint)*(ushort *)(param_1 + 8) * 2 + -0xfd) * (uint)*(ushort *)(param_1 + 8); //(*PointerValue(Param1+8) *2 -0xFD) * (*PointerValue(Param1+8)
uVar1 = (ushort)(iVar2 >> 0x1f); //shift 0x1F bits right
**(short **)(param_1 + 4) = ((ushort)iVar2 ^ uVar1) - uVar1; //store key at offset 4 0
}
return DAT_1000d10c; //value is 2
}
I believe this is the EECV algorithm. I have added some of my own comments here.
A memory array of 0x10C is alloated, I believe our first if statement is validating that it does have the memory space available.
This next part is where it gets a little hazy due to the memory pointer not being exactly well descrived.
My understanding here is the seed which is 2bytes, or also titled as ushort, is stroed at offset 8 in the memory pointer.
It then multiples by 2, minus 0xFD, then multiple by the original value. This value is then shifted 0x1F to the right (31 bits).
Finally we do an XOR between the two variables then stores the key at offset 0x4 of the pointer.
See if your 9f xor'd or subtracted from FF makes the seed/key work.