[inotherwords]

No need to match it with vin in any way as its already matched by signing fsc with fscs private

Okay, thank you! I understand that update code will be different from code issued by BMW for that VIN, but it's not important for cars which weren't retrofitted with CIC. Also we can use lifetime code to forget forever about update codes.

[aknight720]

If you RSA decrypt the extension data ID 12, you will see it contains a MD5 sum of the FSC header to make sure the FSC has not been modified.

[intel123]

If you RSA decrypt the extension data ID 12, you will see it contains a MD5 sum of the FSC header to make sure the FSC has not been modified.

Is it updated automatically by FStool or E-SYS as CIC accepts signed cert without modifying it ? Ill check that out and thanks for the info.

[inotherwords]

If you RSA decrypt the extension data ID 12, you will see it contains a MD5 sum of the FSC header to make sure the FSC has not been modified.

Hmm, it's very interesting. BTW I don't have decryption key for this RSA. Is there any way to decrypt it without a key?

[intel123]

If you RSA decrypt the extension data ID 12, you will see it contains a MD5 sum of the FSC header to make sure the FSC has not been modified.

Hmm, it's very interesting. BTW I don't have decryption key for this RSA.

Ill perform some testing today

[aknight720]

Ill perform some testing today

Here is a set out nice example:-

   

   

   

[intel123]

Here is a set out nice example:-
...

ok so another key in dump np, thanks.

[pshoey]

From my testing with self generated FSC sets for NBT, it doesn't care what is contained in the extension data. I fill it with 128 random bytes and NBT, at least, is happy to use the FSC.

I don't have any experience with CIC (yet).

[intel123]

From my testing with self generated FSC sets for NBT, it doesn't care what is contained in the extension data. I fill it with 128 random bytes and NBT, at least, is happy to use the FSC.

I don't have any experience with CIC (yet).

CIC acts the same it accepts cert but i want to get to the bottom of this as hack wont be complete without this element. I got enough pointers and ill see today which combination is in question here. Worst thing is and it came up my mind only later that from beginning ive chosen wrong path. I should of just modify function which checks vin against the cas 0x380 and let it accept any certificate like with emulator on i just had alot problems with sh4 asm, but things will look much better on NBT since x86 running ELFs

[pshoey]

Making NBT accept a custom set of FSCs is trivial - just patch in the new root certificate and voila. But I agree, X86 makes it a little easier.

And yes, for a complete solution, understanding what the classic FSC extension data is used for and generating genuine data is an interesting intellectual challenge - if only I didn't need to sleep!!

As the extension data appears to be ignored by the HU, and @aknight720 says it is RSA encrypted, maybe the data is signed by the sig cert - which I have not found a use for previously. I'm not sure how @aknight720 has decrypted the data - presumably the private key is in the HU binary?? That would mean the sig cert is not used (unless the private key for that is in the binary, which I doubt). Of course the sig cert public key can be used to verify the extention data has not been tampered with but then the MD5 hash inside isn't a great deal of use!

I'm sure it will all become clear.