Turbo Quattro

Everyone knows in what format the public key is stored in the *_public_signed.bin files?

If the signture is 1024 bits (128bytes) than the public modulus must 1024 bits (128 bytes) too. But here the bytes are stored in 288bytes (in mmi3g the 1024bit public keys is stored on 256byte).
I played many times with openssl and crypto++ but without success...

Read that https://reverseengineering.stackexchang ... tion/12287
And pay attention to my comment at the end
Regards.

Not necessarily change.
I think I will have 1st version of patch for MIB1/2 around 20th of January.

Thanks, I tested it and worked like a charm

It was more than enought...

Yet I know everything about fsc and public keys in mmi3g, rns850, MIB1 head units...
For mmi3g and rns850 is not to hard to inject own keys and maybe there is one (or maybe two) methods for MIB too...

congo писал(а):Read that https://reverseengineering.stackexchang ... tion/12287
And pay attention to my comment at the end
Regards.

Have you tried this on FEC keys too?
It seems than is working on Data and Metinfo keys (all are the sames) but not on FEC Keys...
And of course the same logic works on MMI3G family too.

leader писал(а):Have you tried this on FEC keys too?
It seems than is working on Data and Metinfo keys (all are the sames) but not on FEC Keys...
And of course the same logic works on MMI3G family too.

Now I discovered the trick....

FEC files are not self signed. They are signed with Metainfo/Data key...

You made it work w/o patch of mibroot or mmi3gapp....?
I’ve tested on metainfo and fec and both don’t work with stock firmware.

congo писал(а):You made it work w/o patch of mibroot or mmi3gapp....?
I’ve tested on metainfo and fec and both don’t work with stock firmware.

No yet.
Have you recallculated the MetainfoChecksum correctly before sign it?
Have you replaced all 4 Metainfo keys in MIB?
What error message do you receive when try to update the unit?

At the moment I have only mmi3g bnav, hnav, hnav+ on my desk. So I can test only FSC now...

Next step can be to reverse the structure of FecContainer.fec file. I think FEC codes are stored there.

If you send me your new PubKeys and Metainfo than I can help you to doble check them. Two heads are better than one...

What do you mean "mibroot"?

This is the secret key file?

алексей 3012 писал(а):[ATTACH=CONFIG]60800[/ATTACH]

This is the secret key file?

I think it must be an important file. If you check the filename it's "maybe" the container file for FeC codes (like in RMC where FSC are stored in Container too).
If you reverse the fec binary in IDA you can found some FeC related functions to handle FeC requests....

Currently I have only 2 fec container files from 2 different devices. One is empty (contains only 4 bytes header) and other has some data inside.
Next days. I will try to get more container files to check them....
I don't know (but I hope) if I'm on the right way....

I have one FecContainer.fec from VW's discover pro (MIB2HIGH). I did some basic check... The file size should be 4 + (195 x FeC counts). The first 4 bytes means how much FeCs inside the container.
For each FeCs, Start with 0x000000AB and end with 0x000000FF (little endian)
For each offset of individual FeCs
byte00 ~ byte03: 0x000000AB
byte04~ byte05: 0x0211
byte06 ~ byte09 : FeCs in big endian (i.e. FeC 0931002f would be 09 31 00 2f)
byte11 ~ byte15 : VCRN code
byte16 ~ byte33 : VIN + \0 (18bytes)
byte34 ~ byte37 : Date time of the FeCs (Epoch time in big endian)
byte38 ~ byte46 : All 0x00
byte47 ~ byte174 : variant data, signature? (128 bytes)
byte175 ~ byte 178: 0x00000001
byte179 ~ byte182: FeCs in little endian (i.e. FeC 0931002f would be 0x0931002f)
byte183 ~ byte186: 0x00000001
byte187 ~ byte190: 0x00000003
byte191 ~ byte194: 0x000000FF

jvkk писал(а):I have one FecContainer.fec from VW's discover pro (MIB2HIGH). I did some basic check... The file size should be 4 + (195 x FeC counts). The first 4 bytes means how much FeCs inside the container.
For each FeCs, Start with 0x000000AB and end with 0x000000FF (little endian)
For each offset of individual FeCs
byte00 ~ byte03: 0x000000AB
byte04~ byte05: 0x0211
byte06 ~ byte09 : FeCs in big endian (i.e. FeC 0931002f would be 09 31 00 2f)
byte11 ~ byte15 : VCRN code
byte16 ~ byte33 : VIN + \0 (18bytes)
byte34 ~ byte37 : Date time of the FeCs (Epoch time in big endian)
byte38 ~ byte46 : All 0x00
byte47 ~ byte174 : variant data, signature? (128 bytes)
byte175 ~ byte 178: 0x00000001
byte179 ~ byte182: FeCs in little endian (i.e. FeC 0931002f would be 0x0931002f)
byte183 ~ byte186: 0x00000001
byte187 ~ byte190: 0x00000003
byte191 ~ byte194: 0x000000FF

Hi jvkk,

It's very usefull infromation.
Thank you for sharing...

I think the 128 bytes must be the signature, because the keys are 1024bits (128 bytes) too.

regards,
leader

I also found something interesting when I use 'file' to identify content of dumped data...
Is this useful or just no use because it's a public key?
dump/> file HBpersistence/Keys/*/*
HBpersistence/Keys/DataKey/AU_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/BY_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/PO_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/SE_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/SK_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/VW_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/FECKey/AU_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/BY_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/PO_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/SE_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/SK_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/VW_MIB-High_FEC_public_signed.bin: PGP\011Secret Sub-key -
HBpersistence/Keys/MetainfoKey/AU_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/BY_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/PO_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/SE_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/SK_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/VW_MIB-High_MI_public_signed.bin: data

jvkk писал(а):I also found something interesting when I use 'file' to identify content of dumped data...
Is this useful or just no use because it's a public key?
dump/> file HBpersistence/Keys/*/*
HBpersistence/Keys/DataKey/AU_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/BY_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/PO_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/SE_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/SK_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/DataKey/VW_MIB-High_DK_public_signed.bin: data
HBpersistence/Keys/FECKey/AU_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/BY_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/PO_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/SE_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/SK_MIB-High_FEC_public_signed.bin: data
HBpersistence/Keys/FECKey/VW_MIB-High_FEC_public_signed.bin: PGP\011Secret Sub-key -
HBpersistence/Keys/MetainfoKey/AU_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/BY_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/PO_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/SE_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/SK_MIB-High_MI_public_signed.bin: data
HBpersistence/Keys/MetainfoKey/VW_MIB-High_MI_public_signed.bin: data

These files contains the public keys to check signature in FEC, Metainfo and data files....

Any update on this? Any way to add FSC to FecContainer.fec

Any further break throughs? I have Q7 FecContainer.fec that is 227 bytes in size. VIN starts at byte 20 and it has 5 FeC codes... Wondering how this compares to jvkk.

What I have been able to deduce:

Bytes 00-03 01 00 00 00
Bytes 04-19 B7 00 00 00 11 07 FF FF FF FF 03 61 69 DE D4 A7
Bytes 20-37 VIN + 00 (18 bytes)
Bytes 38-42 56 4F 19 4F 05
Bytes 43-46 FeC #1 Big Endian
Bytes 47-50 FeC #2 Big Endian
Bytes 51-54 Fec #3 Big Endian
Bytes 55-58 Fec #4 Big Endian
Bytes 59-62 FeC #5 Big Endian
Bytes 63-79 85 18 6F 42 EA D4 9B CD B1 D8 4F E3 F0 64 7E 13
Bytes 80 - 95 A3 84 37 24 B3 05 34 67 DD 05 DB A5 DC 18 97 5B
Bytes 96 - 111 A3 F5 C9 74 29 4D 55 23 E4 85 8D B0 81 AB CB 9D
Bytes 112 -127 AC 95 39 6F 46 39 7A E5 00 88 E3 7B 24 C9 69 D5
Bytes 128 - 143 30 8B BD D2 9A A8 05 A4 01 A2 09 6F 92 30 87 69
Bytes 144- 159 0B 59 F0 44 33 6C B2 8E 99 20 3B 8E 4B FE F7 EC
Bytes 160 - 175 B3 6C 7B 3D 79 DA B7 FE 9A ED 97 B0 D0 DD 60 25
Bytes 176 - 191 73 16 BB 40 3F A4 5C 4F E2 75 B1 6E 39 F8 6E 05
Bytes 192 - 194 00 00 00
Bytes 195-198 FeC #1 Little Endian
Bytes 199-202 FeC #2 Little Endian
Bytes 203-206 Fec #3 Little Endian
Bytes 207-210 Fec #4 Little Endian
Bytes 211-214 FeC #5 Little Endian
Bytes 215 -226 01 00 00 00 03 00 00 00 FF 00 00 00

Further

Bytes 00-03 01 00 00 00
Bytes 04-19 B7 00 00 00 11 07 FF FF FF FF 03 61 69 DE D4 A7
Bytes 20-37 VIN + 00 (18 bytes)
Bytes 38-42 56 4F 19 4F Epoch time
Byte 42: 05 #Number of FeCs
Bytes 43-46 FeC #1 Big Endian
Bytes 47-50 FeC #2 Big Endian
Bytes 51-54 Fec #3 Big Endian
Bytes 55-58 Fec #4 Big Endian
Bytes 59-62 FeC #5 Big Endian
Bytes 63-79 85 18 6F 42 EA D4 9B CD B1 D8 4F E3 F0 64 7E 13
Bytes 80 - 95 A3 84 37 24 B3 05 34 67 DD 05 DB A5 DC 18 97 5B
Bytes 96 - 111 A3 F5 C9 74 29 4D 55 23 E4 85 8D B0 81 AB CB 9D
Bytes 112 -127 AC 95 39 6F 46 39 7A E5 00 88 E3 7B 24 C9 69 D5
Bytes 128 - 143 30 8B BD D2 9A A8 05 A4 01 A2 09 6F 92 30 87 69
Bytes 144- 159 0B 59 F0 44 33 6C B2 8E 99 20 3B 8E 4B FE F7 EC
Bytes 160 - 175 B3 6C 7B 3D 79 DA B7 FE 9A ED 97 B0 D0 DD 60 25
Bytes 176 - 191 73 16 BB 40 3F A4 5C 4F E2 75 B1 6E 39 F8 6E 05
Bytes 192 - 194 00 00 00
Bytes 195-198 FeC #1 Little Endian
Bytes 199-202 FeC #2 Little Endian
Bytes 203-206 Fec #3 Little Endian
Bytes 207-210 Fec #4 Little Endian
Bytes 211-214 FeC #5 Little Endian
Bytes 215 -226 01 00 00 00 03 00 00 00 FF 00 00 00

Bytes 00-03 01 00 00 00 # 1 FeC collections
Bytes 04-07 B7 00 00 00 # Size of following contents (i.e. B7 = 183, 183 + 8 = 191)
Bytes 08-13 11 07 FF FF FF FF
Bytes 14-19 03 61 69 DE D4 A7 # 03 + VCRN (I have no idea what 03 means)
Bytes 20-37 VIN + 00 (18 bytes)
Bytes 38-42 56 4F 19 4F Epoch time
Byte 42: 05 #Number of FeCs
Bytes 43-46 FeC #1 Big Endian
Bytes 47-50 FeC #2 Big Endian
Bytes 51-54 Fec #3 Big Endian
Bytes 55-58 Fec #4 Big Endian
Bytes 59-62 FeC #5 Big Endian
# Bytes 63 ~ 190 were signature for identification. 128 bytes
Bytes 63-79 85 18 6F 42 EA D4 9B CD B1 D8 4F E3 F0 64 7E 13
Bytes 80 - 95 A3 84 37 24 B3 05 34 67 DD 05 DB A5 DC 18 97 5B
Bytes 96 - 111 A3 F5 C9 74 29 4D 55 23 E4 85 8D B0 81 AB CB 9D
Bytes 112 -127 AC 95 39 6F 46 39 7A E5 00 88 E3 7B 24 C9 69 D5
Bytes 128 - 143 30 8B BD D2 9A A8 05 A4 01 A2 09 6F 92 30 87 69
Bytes 144- 159 0B 59 F0 44 33 6C B2 8E 99 20 3B 8E 4B FE F7 EC
Bytes 160 - 175 B3 6C 7B 3D 79 DA B7 FE 9A ED 97 B0 D0 DD 60 25
Bytes 176 - 190 73 16 BB 40 3F A4 5C 4F E2 75 B1 6E 39 F8 6E
Bytes 191 - 194 05 00 00 00 # Counts of FeC
Bytes 195-198 FeC #1 Little Endian
Bytes 199-202 FeC #2 Little Endian
Bytes 203-206 Fec #3 Little Endian
Bytes 207-210 Fec #4 Little Endian
Bytes 211-214 FeC #5 Little Endian
Bytes 215 -226 01 00 00 00 03 00 00 00 FF 00 00 00 # These are identify flags

It is almost not possible to produce an valid FecContainer.fec until you have the private key.
or I think you can replace the public key inside MU with one related to your own private key.
This may make some sense, but would be less convenient for later update.

Makes sense.