Tell

Updating the inbuilt Mib2 Satnav / Mib2 tricks and Mib1

explorer

Active Member
Jul 8, 2016
100
27
I'm writing about the whole lot... and mostly the map keys :).

You will find a file in this thread (post 28 dated 2015) which are (said to be) the public keys for all VAG cars by each area and this is where you will see the firmware public keys as well as the rest.

http://turbo-quattro.com/archive/index.php/t-19874.html

For Seat they are all the same.... least last time I looked. The FEC is the SWAP. Metafile2.txt keys once decoded and processed are the same as the one on post 700 read off a unit and that's the one I used to test the reversing engineering methodology on Metafile2.txt map files and it works, but of no use if you haven't got the primary key since you can't sign anything you edit. An older version of the VAG firmware is suppose to ignore these signatures. Some people try / do to move back to the older release. These are Audi people with older DVD based systems.

I used Hex Editor Neo to look at file linked above. It gives the DataKey. FECKey and MetaInfoKey. All public keys. For Seat you get this bank of codes back for each of them as I recall:

9a 49 9b 04 8b ae bf ac 83 3f de 81 ba 80 30 93
05 b6 6f ed 54 59 c3 8f 60 f6 10 a9 aa 5a 19 10
05 17 05 8f ea 49 d3 75 e3 f9 e1 54 4e 17 ee c9
c3 c1 dd 7d 30 16 de b1 55 45 fd 9e 18 00 51 22
d6 a1 33 10 95 c0 dd cf 43 a1 c2 fe c0 bc aa 1c
fe 48 49 25 89 9e dd 71 b0 d4 08 cf 16 bf 10 e2
e1 bc 70 a3 52 f2 e6 54 0b 60 05 5a a7 52 ec 4a
83 65 f7 68 19 66 f4 d5 46 c7 38 b1 6b 5a 1f 13
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
1e 0b 93 73 dc b4 93 b6 12 ce 09 c4 03 e9 21 fc
9b 4e 97 ce 55 c5 b4 c0 80 ad 17 2d ca 91 4d c1
87 45 52 ca 4a 95 96 9e 61 ff c3 24 a5 91 5b d1
83 80 85 90 8f 99 8f 76 ba 5f b2 09 86 db 86 c1
b5 89 b9 58 75 4e d5 d5 aa 08 af 2f 16 3e 33 a6
c6 46 77 dd 32 e0 98 f0 ec f9 14 6b af 35 05 3c
23 aa 8b a8 76 fb 2d 0c 6e d7 2f 0b b3 dc 77 6e
b8 74 14 1c 95 c1 6f ff 0c bb 4a e9 ee 70 a2 3c

Basically if you are so inclined you can take those keys plus any download file in any of those areas run it through to validate using the reversing engineering methodology in post 700. So you can test the public keys. It doesn't get you any further forward thou it just carries out the procedure that would be executed in the unit to validate the signature.

Your best bet is to read the thread from 2.5 years ago onto June 2017 to work out why some people had MIB1 success with buying a new SD card off ebay and others didn't. It's probably there somewhere and also MIB1 cards stopped being able to be updated as well last June for some people you will see that. Whatever the old card MIB1 workaround was it doesn't work for everyone and it also stops working for some people. There are a lot of silent people on this thread that pop up from time to time looking for a MIB1 solution but haven't got one. MIB2 card one does exist thou.

As I wrote. Mib2 SEAT use different keypairs as mib1 SEAT and all mib1 contains similar keys . And YES these keys are all PUBLIC so you can only validate signature but with own generated key pairs is situation similar (waste of time) because new public key chain must be signed by root key. I am sw engineer so I know these mechanisms :)

Mib1 standard map card (not for unit with HDD) dont have metainfo2.txt file. Metainfo2.txt is for update only - so its usable only for units with HDD where maps are stored in HDD.
 
Last edited:

Tell

Full Member
Staff member
Moderator
The SSD is the only one I look at most where the public keys remain the same whether Mib 1 or 2 or the mapping database upload or the personal Poi file. The public is the same. So no, not different key pairs. It's all the same public key across their products, if it wasn't the map uploads wouldn't be common across VAG (which they are) and the user poi update file signature manufacturers by the VAG site which is common across mib1 or mib2 and is used on the SD based unit as well. Afraid you are wrong they didn't change the keys between mib 1 and mib2. I got my two maths degrees and push the codes threw the logic (post 700) where I've tested the public keys as I said for the map file and the common poi upload file, both are the same whilst as I said that published file shows all Seat keys are the same.

Obviously I have been trying to edit metainfo2 since that's how I believe you would frig the unit to take a new map by changing its release code to one below that fixed to the unit (only for SSD based units). I know you can't unless you got access to a spy agencies hardware. A Google study said you needed about £100,000 of computer time to crack the primary key hence why the SHA1 system Vag currently use isn't now industry supported since it's deemed too insecure, still you need £100,000 thou. I'm sure the primary key is out there thou.

It's got nothing to do with public keys for mib 1 / 2 why the workaround works on one and not the other, it's the mapping files under them. It was "Noterbin" et al that determined how the map files worked and found a copyright submission of the file structure. Changing a file doesn't effect the signature or size check sums. It happened that the top database index file tethered to the unit via the CID worked worked with any updates and the rest is history. Mib1 sd people need to find something similar .
 

explorer

Active Member
Jul 8, 2016
100
27
The SSD is the only one I look at most where the public keys remain the same whether Mib 1 or 2 or the mapping database upload or the personal Poi file. The public is the same. So no, not different key pairs. It's all the same public key across their products, if it wasn't the map uploads wouldn't be common across VAG (which they are) and the user poi update file signature manufacturers by the VAG site which is common across mib1 or mib2 and is used on the SD based unit as well. Afraid you are wrong they didn't change the keys between mib 1 and mib2. I got my two maths degrees and push the codes threw the logic (post 700) where I've tested the public keys as I said for the map file and the common poi upload file, both are the same whilst as I said that published file shows all Seat keys are the same.

Obviously I have been trying to edit metainfo2 since that's how I believe you would frig the unit to take a new map by changing its release code to one below that fixed to the unit (only for SSD based units). I know you can't unless you got access to a spy agencies hardware. A Google study said you needed about £100,000 of computer time to crack the primary key hence why the SHA1 system Vag currently use isn't now industry supported since it's deemed too insecure, still you need £100,000 thou. I'm sure the primary key is out there thou.

It's got nothing to do with public keys for mib 1 / 2 why the workaround works on one and not the other, it's the mapping files under them. It was "Noterbin" et al that determined how the map files worked and found a copyright submission of the file structure. Changing a file doesn't effect the signature or size check sums. It happened that the top database index file tethered to the unit via the CID worked worked with any updates and the rest is history. Mib1 sd people need to find something similar .

Ok so otherwise. I have extracted signature from MIB1 map file, and validated by public key (data.key, fec.key) from SWAP and result is wrong key :) I dont know better demonstration of my theory. In mib1 is another mechanism to check validity of the map card as in mib2. It isnt similar card (data are different). In mib1 all files are partially validated! Partially so if you change first byte hash is similar, cpu power is limited.
 
Last edited:

Tell

Full Member
Staff member
Moderator
You should use the post 700 methodology and key given. I will look at it when I have a spare moment but I'm 100 percent sure the key and methodology will work on Mib1 SD unit upload file. The key doesn't change, the public key is the block, take out the spaces, do the string manipulation as post 700.

C0 F3 89 EE C7 B6 6C 9D C7 36 50 8F F8 8A EB 1F B1 13 94 2E AD 02 08 14 D0 8D 29 E8 68 F1 4B 20 86 BC D7 DD CC BA 75 59 F9 99 E7 6D 24 61 96 60 BB E1 74 34 DA 59 98 80 87 F2 A9 9C D4 65 B1 FF 42 35 22 B7 8C B0 DE 46 3A 66 96 13 D3 56 DF A9 E8 6E 0E 2E 0B 6D AB 5D E8 91 31 C5 A0 72 7A EA B1 76 72 78 AB 10 1D CD 9C 3C FC 10 26 70 5C 1D AB 3B F5 3B F5 0A FA FB 3F 52 DA 2C EB 0B EE 57

You have to do the other processes as outlined and the cross check with the signature removed.

Either way it's a bit academic if one doesn't have the private key.
 

explorer

Active Member
Jul 8, 2016
100
27
I am not idiot. My tool validate public key signature correctly. This is my last post about nothing.
And mib1 keys are different as mib2 :)
Data.key=Metainfo.key start with sequence CD3CB067 ...
Fec.key start with sequence D9182185 ...
Only public exponent is simiar mib1 vs mib2.

And you can study some Public-key cryptography publication because signature is possible validate or decrypt by same public key (in validation process signature is firstly decrypted and next parsed) so when I write that key is invalid so key is invalid no hash is invalid.
 
Last edited:

Tell

Full Member
Staff member
Moderator
Had a look at MIB1 and MIB2 SD card downloads and neither are signed as far as I can see with SHA1 so it's a red herring.

P72_N60S3MIBS2_EU_NT - Mib1

0915_MP171-1284.xEUR1 - Mib2

The combined Mib2 / Mib1 SSD files are SHA1 signed map files so they are tamper proof from edits and file changes.

Glad we sorted that out.
 

zeffania

Active Member
Nov 4, 2016
476
159
For me, the update was too big for my card. Then again it's a 1 which we know doesn't work
 

Tell

Full Member
Staff member
Moderator
For me, the update was too big for my card. Then again it's a 1 which we know doesn't work

On threads I have come across instruction to set the sector size in the reformat where the maps dont fit to 2048. Although Im not picking up much on a Google now, but it was an issue for people with Mapcare on sd based systems at one stage that found they couldn't copy across the maps due to space.
 

zeffania

Active Member
Nov 4, 2016
476
159
On threads I have come across instruction to set the sector size in the reformat where the maps dont fit to 2048. Although Im not picking up much on a Google now, but it was an issue for people with Mapcare on sd based systems at one stage that found they couldn't copy across the maps due to space.
Hmm, interesting. When I spoke to seat CS, they did I had a year of map care. If you have s link, that would be brilliant
 

explorer

Active Member
Jul 8, 2016
100
27
Hi, so after a long time of research I definitely found the solution for MIB1 but it isnt so easy as with MIB2. I can adapt new maps (from navigation.com) for mib1 without mapcare or for mib1 with expired mapcare BUT I need physical access to main mib unit. So if someone is interrested it is needed send MIB unit. As I wrote before time MIB1 map card is good protected and only one solution is via main unit.
 
Last edited:

Titchy

Active Member
Jun 10, 2017
519
208
Buckinghamshire
Hi, so after a long time of research I definitely found the solution for MIB1 but it isnt so easy as with MIB2. I can adapt new maps (from navigation.com) for mib1 without mapcare or for mib1 with expired mapcare BUT I need physical access to main mib unit. So if someone is interrested it is needed send MIB unit. As I wrote before time MIB1 map card is good protected and only one solution is via main unit.



Where are you based?


Sent from my iPhone using Tapatalk
 

Grouty31

Active Member
Dec 10, 2017
1
0
Navigation maps 0430

I like others attempted the updates and failed also.

Therefore has anyone got a Seat Navigation AS Europe version 0430 I could possible download to get my nav working again?

I so wish I found this forum prior to attempting this. I have sent a very strong worded email to the navigation.com site along with Seat dealers.

I will let you know the outcome, but in the meantime if anyone has the version I had so I can get this back I will be very very great full

Steve
 

Tell

Full Member
Staff member
Moderator
Hi, I have unit without original navi card but I know that unit is paired with card 5f0919866C. I need data from this card. If someone have dump from this card please send me pm. I have dump from 5F0919866K but this card is not working. No mapcare in my unit.

Yes but you have a Mib1 but not a working card ?. So you need another one.

If like Mib2 you pay the official VAG dealer to take protection off. Then you change the firmware. Taking protection off disables sat nav, so you then pay to enable sat nav, which at that stage it starts to look expensive. So I discounted that solution as a way of getting rid of Mapcare. It has no thief protection at that stage but of course your burglar doesn't know that when they brake the glass. That's what you are paying for in VAG managing the peripherals.
 

explorer

Active Member
Jul 8, 2016
100
27
Yes but you have a Mib1 but not a working card ?. So you need another one.

If like Mib2 you pay the official VAG dealer to take protection off. Then you change the firmware. Taking protection off disables sat nav, so you then pay to enable sat nav, which at that stage it starts to look expensive. So I discounted that solution as a way of getting rid of Mapcare. It has no thief protection at that stage but of course your burglar doesn't know that when they brake the glass. That's what you are paying for in VAG managing the peripherals.

Tell You have already readed my new posts or you are only spammer? Please you dont quote my OLD messages. I found solution for MIB1 map cards as I wrote, I can pair any card with MIB1, I dont have MIB2. Its possible to pair standard sd or original sd.
Check the cid ;) All functions are working as before. I am adapting map card in clear way without touching vw base protection so still possible adapt new functions via vw. I dont touch component protection.

23vdrir.jpg
 
Last edited:
Chris Knott Insurance - Competitive quotes for forum members