• Guest would you be interested in CUPRA or SEAT valve caps? let us know in the poll

  • Welcome to our new sponsor Lecatona, a brand dedicated to enhancing performance for VAG group sports cars, including SEAT, Audi, Volkswagen and Škoda. Specializing in High Pressure Fuel Pump (HPFP) upgrades.
Tell

Updating the inbuilt Mib2 Satnav / Mib2 tricks and Mib1

Tell

Full Member
Staff member
Moderator
The MIB2 cards at least have a hidden partition on them, they are special SD cards

http://www.seatcupra.net/forums/showthread.php?t=388586&page=26

It was notabenem in November started this one off in post 501 with those key filenames. Then it was Exciter that found the patent to the storage method of the files in post 525. That NDS file.

It's the CID which is cloned if an additional card is made but isn't required unless you are worried about messing the card up. It's the CID which is out of range of a format or delete and it's that which marries the card to the unit.

https://richard.burtons.org/2016/07/01/changing-the-cid-on-an-sd-card/

That bit was covered in Exciters PDF but isn't required if your not manufacturing a new copy of existing card linked to the unit. Notabenem 1-3 are the only things required as long as a copy of the original SD card is made before reformatting it. The CID isn't important since that doesn't get touched in the format.

Why the NDF business works I guess it's something like having the top level index, that's linked to the database release on CID but works with the updated map data that is indexed from the top level, which was probably an oversight in how they thought it was locked down. The front page of the phone book works with each update even thou the pages below change:). You got to respect the geo information system programmers who were looking at the card.
 

Stevan

Active Member
Apr 8, 2017
96
6
Musselburgh
I seem to have the following recurring fault in OBDeleven:
B126CF2 - Navigation system Navigation database not enabled

Navigation works fine, I updated the maps twice using the overall.nds method. A quick Google suggests it could be because I used a used v2 6P0.919.855.D card that I bought from ebay rather than the card that came with the car, just in case I did something wrong and could go back to the original card.

Has anyone else seen this or have a way to clear the fault?
 

Tell

Full Member
Staff member
Moderator
I seem to have the following recurring fault in OBDeleven:


Navigation works fine, I updated the maps twice using the overall.nds method. A quick Google suggests it could be because I used a used v2 6P0.919.855.D card that I bought from ebay rather than the card that came with the car, just in case I did something wrong and could go back to the original card.

Has anyone else seen this or have a way to clear the fault?

Ouch. I've seen that fault. Bearing in mind I got the SSD version so I can't play card games of editting the contents. I did notice one report of that fault on internet but there wasn't a solution put against the issue. I suspect by using another Mib2 card you have introduced new maps to it so it blows a raspberry at you. Have you tried your old card again, did you clear down the fault code. If it keeps seeing the wrong maps in it, it will keep regenerating that code. Now I don't know whether that fault code will stick even thou you reintroduce the old map card.

Take it you mean navigation did work fine. I expect what you see is navigation works then it sticks up a pane saying that the navigation data isn't valid, or does the navigation work and it's just an Obdeleven fault.... think it's the former. Morel behind this for mib2 is not to use another card, you won't damage the card if you have a back up copy. You can't write or delete the cid under normal processes so it wont get corrupted.

Reading a German forum where it didn't mention that code but was talking about upgrading the maps without Mapcare it said you have to deactivate the installed map, leave the unit off for a few minutes, then reactive again, that's all done by ODIS in the dealer network. Perhaps there are some ODIS experts around. Would be nice if there was an Obdeleven solution. Anyone. I hesitate to say snap since we are playing a different game :). I can't find ODIS procedures documented on the net, think they are hidden.

addendum

There was this here, post 527 where Kong further down tells Sebastalian to alter his long string. Mine never changed before and after. Sebastalian disappeared so I didn't think that was the solution myself.

http://www.seatcupra.net/forums/showthread.php?t=432976&page=27
 
Last edited:

Stevan

Active Member
Apr 8, 2017
96
6
Musselburgh
Thanks - nope, it works fine, it's just the code appears under an OBDeleven scan. I'll try the original card to see if it goes away, then re introduce the ebay card to see if it returns.
 

Tell

Full Member
Staff member
Moderator
I do wonder whether the mib1 lack of success with some cards is linked to the three year time span that the Mapcare upgrade has / had. One would have to look at all the historic posts and work out whether it was that...

Now Skoda has said they will never enforce that time span on Mapcare, you get it free now I believe in the UK, ditto VW. Seat UK just drags its heals on not including mapcare on the cars either inclusive or as an option leading to rip off map upgrade costs via the dealer for a job you can do yourself if they rolled out Mapcare.
 

Andy1977

Active Member
Jul 10, 2017
92
18
Managed to restore my MIB1 0059 card for now at least I have 2016/017.

Hi Andrew, I have an MIB1 unit with the original V2 2013 card. Is there anyway to download older (2016) map data? I tried the latest update but it wouldn't fit on my original V2 2013 card.

I dont think it will work due to the map care issue on the early mk3's anyway but I just want to try and see with my own eyes really.
 
Last edited:

Andy1977

Active Member
Jul 10, 2017
92
18
Nah the 0059 file cant be found online now, Luckily mine was backed up.

I guess i'll have to look out for a used card then if i'm ever going to get an update with out going to the dealer, and even then its not guaranteed to work.
 

Andy1977

Active Member
Jul 10, 2017
92
18
Hmm, seems to be quite a few new VW RNS315 cards that claim to work on Seats, is that BS?
 

sebastalian

Active Member
Jan 30, 2017
62
13
Manchester
Ouch. I've seen that fault. Bearing in mind I got the SSD version so I can't play card games of editting the contents. I did notice one report of that fault on internet but there wasn't a solution put against the issue. I suspect by using another Mib2 card you have introduced new maps to it so it blows a raspberry at you. Have you tried your old card again, did you clear down the fault code. If it keeps seeing the wrong maps in it, it will keep regenerating that code. Now I don't know whether that fault code will stick even thou you reintroduce the old map card.

Take it you mean navigation did work fine. I expect what you see is navigation works then it sticks up a pane saying that the navigation data isn't valid, or does the navigation work and it's just an Obdeleven fault.... think it's the former. Morel behind this for mib2 is not to use another card, you won't damage the card if you have a back up copy. You can't write or delete the cid under normal processes so it wont get corrupted.

Reading a German forum where it didn't mention that code but was talking about upgrading the maps without Mapcare it said you have to deactivate the installed map, leave the unit off for a few minutes, then reactive again, that's all done by ODIS in the dealer network. Perhaps there are some ODIS experts around. Would be nice if there was an Obdeleven solution. Anyone. I hesitate to say snap since we are playing a different game :). I can't find ODIS procedures documented on the net, think they are hidden.

addendum

There was this here, post 527 where Kong further down tells Sebastalian to alter his long string. Mine never changed before and after. Sebastalian disappeared so I didn't think that was the solution myself.

http://www.seatcupra.net/forums/showthread.php?t=432976&page=27

Hi, I still have the error code B126CF2 on OBDeleven, I've updated the map to version 0820. I didn't find a solution to delete the error. The navigation is working very good and doesn't bother me if everything is working fine.
Still in search for the solution....
 

brinco218

Active Member
Mar 17, 2017
1
0
Hello, AndrewJB. It seams that I can't send you PM. My car is 2014 cupra 280 with MIB1 5F0 original maps. The ones from website (P67_N60) seams not to work for me. Do you have the generation before that worked and can share somehow via dropbox for us all ?

Thank you in advance
 

AndrewJB

Friend to SEAT UK & Cupra Racing
Aug 16, 2007
11,209
485
Maranello
TBH I don't think 0059 will work either. I tried it previously and it didn't.

it only started working after I installed a newer SD card which came from Spain, I think somehow the newer SD card might have had Mapcare enabled on it and it has enabled Mapcare onto my system. The 0064 update wont work but the error is on MacOS/Windows rather than the system not accepting it.
 

Tell

Full Member
Staff member
Moderator
Hi, I still have the error code B126CF2 on OBDeleven, I've updated the map to version 0820. I didn't find a solution to delete the error. The navigation is working very good and doesn't bother me if everything is working fine.
Still in search for the solution....

Thanks Sebastalian. Mine does the code but not a lot else since I did sort of carry out an experiment which would have been fine if it worked like a retrofit. SSD with or without Mapcare is like a lock and key on entry to the storage. You can load up via the SWDL menu but it spits back at you locking you out of navigation. Retrofit units don't. Pity. Pity Seat UK don't stop being stupid and sell Mapcare in the UK or just wrap it in the cost. Expecting to get the unit sorted out soon with a map upgrade... all this hassle over the odd one off 110 Euros is just stupid.
 

Stevan

Active Member
Apr 8, 2017
96
6
Musselburgh
Hi, I still have the error code B126CF2 on OBDeleven, I've updated the map to version 0820. I didn't find a solution to delete the error. The navigation is working very good and doesn't bother me if everything is working fine.
Still in search for the solution....

Sounds just like me - did you overwrite your original pre-supplied SDCard with the 2017/18 maps + overall.nds?
I still haven't gotten around to bunging in the original (2016/17) SDCard and clearing the error...wait...re-scan to see if the error returns...
 

Tell

Full Member
Staff member
Moderator
Sounds just like me - did you overwrite your original pre-supplied SDCard with the 2017/18 maps + overall.nds?
I still haven't gotten around to bunging in the original (2016/17) SDCard and clearing the error...wait...re-scan to see if the error returns...

I'm wondering whether everyone who did the nds trick got the B126CF2 code but don't have an obd reader to know. Then I guess you might get it with mib1. Cue Seat UK damming and swearing on not supporting Mapcare. They don't read Which that got very upset by the cost of Seat map upgrades and just want to stay the poor relative of Skoda and VW that have written this cost off as a cynical scam.
 

Tell

Full Member
Staff member
Moderator
MIB2 High – Seat Navigation Plus / Discover Pro / Columbus

In post 609 on the thread I covered that it was possible to read in the SD Map Updates for the SSD via the Developers Menu option with the SWDL command but warned at the bottom “Don’t Do It” (if you don’t have Mapcare or a Retrofit unit fitted with navigation enabled). After reading around the subject I tried an experiment and found that it rendered my satnav inoperable. 18 days later I got it back again after uploading the SD card downloaded that related to the original version of the software on the unit.

Basically the maps are protected on the unit (NavDB) to the release whilst the speech and other files are not (Eggnog, Truffles, SpeechResVDE) (SD upload card directory names which can be related back to what is in them). Suitable use of the SWDL menu can be used to update everything other than the road network if you did not buy Mapcare or it was not offered in your region. Essentially the update, updates four different areas, independently, only one is protected from update, NavDB.

For anyone who frigs about with this it’s very important to identify which version of the maps are installed on your car’s MIB2 High by reading the version information screen, mine were ECE 2016/2017. You then find the VW download file for this and make an SD card observing all those things of issue, you need FAT32, 32GB card, series 10 etc, preferable not MAC created and using 7Zip. The directories MIB1, MIB2 and files metainfo2.txt plus MD5 file are put in the route directory. That’s your fail safe card to return to.

Candidates for this and other updates (use Google for the rest):

ECE 2016 (circa November 2016 release, serial 134):

http://vw.download.navigation.com/a...High1_Single_File_EU/P134_N60S5MIBH3_EU_NT.7z

ECE 2016-2017 (circa June 2016 release, serial 153):

http://vw.download.navigation.com/a...High2_Single_File_EU/P153_N60S5MIBH3_EU_NT.7z

ECE 2017 (circa November 2016 release, serial 157):

http://vw.download.navigation.com/a...igh2_Single_Files_EU/P157_N60S5MIBH3_EU_NT.7z

ECE 2017-2018 (circa June 2017 release, serial 161):

http://vw.download.navigation.com/a...High2_Single_File_EU/P161_N60S5MIBH3_EU_NT.7z

ECE 2018 (circa November release, serial 166):

http://vw.download.navigation.com/a...High2_Single_File_EU/P166_N60S5MIBH3_EU_NT.7z

If you upload another database e.g. ECE 2017/2018 via the SWDL menu including the NavDB directory and it doesn't correspond to what you have on the unit e.g. ECE 2016/2017, it will lock you out of the screen navigation. Speech navigation works fine if you get your destination in quick enough before it locks you out. (18 days of this, it wouldn’t have been 18 days but 1 day if I hadn’t labelled up the 2017 map release as 2016/2017 :cry:).

Error screen:


Much frigging. The question remains as to how the unit identifies it’s preferred release of the maps which is the one that it came with. The metainfo2.txt file in the MIB2 directory which is digitally signed and contains assorted control bytes to stop you editing it. The signature might be used but I have the hunch that it is the version code that appears throughout the upload file which one suspects is cross checked with what the unit holds. What the unit holds is locked to the version first installed for the NavDB directory, rather than the metafile signature. Least that's how I believe it works. The individual NavDB files are not signed by the version number contained inthem but by the metainfo2.txt script

At one point I copied the DBInfo.txt database from ECE 2016/2017 into ECE 2017/2018

Mib2\NavDB\DBInfo\0\default\DBInfo.txt

Whilst the 2017/2018 maps read in well (NavDB), it subsequently hung on the rest and I rebooted the unit with a long hold on the volume control. The net effect was it wiped the NavDB 2017/2018 database from the unit with a message that no navigation files were installed. The 2016/2017 card when put in via the SWDL command showed an inviting OK to the NavDB part of the upload. 40 or so minutes later the update chose not to install Eggnog, Truffles, SpeechResVDE but the 2016/2017 NavDB data was installed fine.

A selective overwrite with an updated card of Eggnog, Truffles, SpeechResVDE via the SWDL menu leads to the same effect. This process once started takes about 15 minutes - exclude the NavDB menu. You select, selective download, select the entity and click on it for an update, the file may be marked up as ERR but will update. This requires you to click on each country in those three areas and any other supporting files then click start. The menus show the serial release of each component of these three file types which is why the downgrade left the more up to date release intact. Fair amount of tapping before the update can be started.

Essentially this was an accidental discovery after the reboot wiped the navigation database for the road network but retained the other geographical elements of the system as the update back to the "correct" year ignored the geographical elements since there was more recent data in the system.

The geographical areas of the NavDB database with the Truffles and Speech database is different. The system matches these up geographically. Inspection of the metainfo2.txt file in the MIB2 directory shows that the developers sub divided the NavDB files within country overtime as presumably new roads were built e.g. the now deleted geographies of Russia, Germany etc as they were subdivided Russia 2, 3 etc. This could have been an issue for using an updated POI database within Truffles if the new and old geographies have to match. They don't.

The navigation database (NavDB) getting totally deleted after I hung the update during a reboot does beg the question of whether the unit would have showed a welcoming OK status to the 2017/2018 NavDB if I had put that in rather than an F as it did with unit previously. E.g. whether in the forced reboot of the infotainment system during the update when it hung on the uploads of things after the NavDB did delete as well what it was using to validate against. Did try to replicate my actions again but this time it didn't delete the 2017/2018 so the jury is still out on whether the validation is in there or not, elsewhere in the unit or on the card. Heart beating moment when you hang the infotainment unit and force a reboot - probably won't be checking that one again.

Using the SWDL menu you need to keep power onto the infotainment unit during this one hour or so process for the whole of Europe. You can’t run the engine (instructions). You either keep the door open to keep the power on or return to the car every 15 minutes or so to open and close the door so as to keep the infotainment unit powered up. Circa 20 minutes is when the infotainment unit will power off, so have 5 minutes spare buffer. It's a different process updating the system via SWDL than the normal one from the infotainment systems inbuilt menu for database update where you can drive about, switch the engine off and it restarts from where it left off.

If you are just updating the Eggnog, Truffles, SpeechResVDE files this can be done in about 15 minutes with say 10 minutes picking off all the files selectively (just remember to open the door every 15 minutes or so). It's the NavDB database which can't currently be updated which takes 30 minutes or so bringing the process just short of one hour.

The developers menu in MIB2 High unit has to be enabled via OBDEleven or other tools. - see post 34:

http://www.seatcupra.net/forums/showthread.php?t=438134&page=2

The update retains user destinations and user POIs since these are held outside of the four areas (NavDB, Eggnog, Truffles, SpeechResVDE).

The signed and check summed metainfo2.txt file in the MIB2 directory gives another challenge which Audi and VW Mib2 owners have previously cogitated over, there may be a solution. The metainfo2.txt file / accessed databases cannot be edited or changed if the signature and check sums are not recalculated. The file swap that I did on the DBInfo.txt file was of the same size so escaped validation although subsequently hung the upload since the year validation was failing. I believe that if you could generate the signature for the metainfo2.txt file in the mib2 directory after editing the update file to the version code of the one the unit is matched against and did an update it would probably update the unit's NavDB side. Some people have for earlier Mib units generated checksums to add to these files after editting. Internet searches indicate the Mib2 firmware has been hacked by the Polish for commercial gain at VW type of prices (retrofits), these read the map updates, whilst asn.1 signature and Metachecksum of the Mib2 directory continue to protect the map updates for those people that have factory units without Mapcare.

You can downgrade segments of the NavDB folder to a previous release but cannot upgrade above the one that the car came with if you do not have Mapcare or it's not a retrofit unit. I tested that one out. Thus if it is possible to edit the Metainfo2.txt file in the MIB2 directory re-manufacturing the signature it would be possible most likely to edit a NavDB series release into it say of 100 to begin with and as each upgrade occurred in the future increment that counter by one, this would keep the release number below the car's release number for the database it was delivered with. This is assuming that it's the release serial number of the map that is the guiding factor rather than anything else. Hint, for checking things out just load up Iceland, gives a fast turnaround. Before that you would have to master the cryto stuff and the tools (winter project, summer, winter etc) which is dependent on finding the public key and working on that to derive the private key based on the signature and the contents of the meta file check sum. Suppose to be symmetry, there are python tools and openssl etc which are used, if it's right the key it will stick out like a sore finger. Once you found it you wouldn't give it out since you are in difficult water. The public key is suppose to be known, being public. The asn1 signature and Metachecksum is recalculated to fall inline with the public key. Seen a patchy worked example on the net. Replicating that with the correct public keys. They may be them. Failing that, there is a backend way of fishing inside the unit which I haven't tried yet.

https://reverseengineering.stackexchange.com/questions/12286/defeat-rsa-hash-verification

(being a mathematician I'm allowed to be interested in these things)

MIB1 High users may be able to use a similar approach on the poi / postcode / address updating. The update for both MIB1 High and MIB2 High are held in the same release and the release is common across the VAG group. In fact some of the update files for Mib2 are held in the Mib1 directory.

So some good news and some bad news for owners of MIB2 High units that don’t have mapcare or retrofit navigation. Some extra understanding of what is in the file upload and what can and can't be updated. Will let you know of any other breakthroughs.

----

Some screens from the process:

Identify which mapping database the unit is currently on so that you can download a backup to restore the NavDB database if it gets updated by accident (described above):

7J9ZiVX.png


The SWDL menu long press the Menu key assumes that developer mode has been activated with 32GB SD card inserted:

CC1dnD5.png


Can select software manual download, then start download:

rsUKHKE.png


Next

nIz1p3q.png


Next if on SD

E5KARjF.png


Next

rKq2MxP.png


Next

m6n88sF.png


The next two screens which is just one screen on the unit is key to how you load the data in and also not mess up the unit:

A63OWv3.png


IOnzW5m.png


The top screen of the two, "Select all" and "Start" will action the import of the SD map data for the four areas but you will note that NavDB is marked up as F (fail) and the other three Err. You can force the import but if you import the NavDB in this state it will freeze up the unit till you sort it out with the mapping download that matches the unit. (so you don't want that)

However the three geo information / voice file directories can be updated and are usable as an update. It is possible to just import these three directories (Eggnog, Truffles, SpeechResVDE) retaining the existing road NavDB database you pick the files off within the three directories. This can be done since you selected "software manual download", then "start download" in the steps above.

The final screen after the process is shown below. Hit cancel... it's an ambiguous screen, I leave it about 30 seconds and hit the on button of the infotainment and that's it.

oSZ0MZE.png


Essentially for updating everything other than the road network, pick off each area to be updated to the latest version and it will work. Forth screen down select "Software Download Manual Download" the "Start Download", page down to "Eggnog", select all areas where an update exists (it gives you the version codes) and back out to the screen again, select "Truffles" and repeat, back out and select "SpeechResVDE" highlight the updates again. Backout and tap "Start". 15 Minutes later after a couple of reboots the system will be updated with the latest POIs, address mapping, postcodes and voice file but not any road changes that may have occurred between years [they are in the NavDB database that can't be updated].

Lastly for those people who want to make it appear that it's updated the maps when it hasn't you can add DBInfo, InfoFile & Region_EU to the map update list, these aren't protected and the screen gets painted as if it's on an updated release for the maps when it isn't. The other files in the NavDB database are protected from an upgrade. But as said the POI files, postcodes / address database are updated using the SWDL approach covered above.

The update actually also updates the 3D emblematic buildings since in December 2017 I saw features never shown in Trier / Luxembourg before, Roman bridges, old cranes and all the new buildings in Luxembourg. Think that's the truffle file. I also get told I'm approaching a toll gate on the Severn river crossing now which I never got before.
 
Last edited:

Tell

Full Member
Staff member
Moderator
I can confirm that those are the public keys for the MIB2 High in the link (will also be the standard MIB2 as well).

https://reverseengineering.stackexchange.com/questions/12286/defeat-rsa-hash-verification

Since they work and can be tested. Not too sure what this means since my crypto skills are on a learning curve. I was a bit concerned that the ones posted were for a different model then I thought, well the QNX programmers probably use the same keys on whatever they do.

Asking for a bit of help on this section "taking the signature s raised to the power of 3 modulus n we wind up with the following value" you do it via python

384fc032192a20fd1e242ad64af5b509a76a7432f754aff0d6b74a7ec2072cbb11e91f68f569508b77712d1869edd6d0b9923eb77ba815dba8e44d5e09412cdf2e830518f3b38d48df892a3a0c65cc67f109e5e0f5f06ce0376d032ab21051510f3dab7f75fcdf54a96d8aa7f3c617f76d
e=3
n=0xC0F389EEC7B66C9DC736508FF88AEB1FB113942EAD020814D08D29E868F14B2086BCD7DDCCBA7559F999E76D24619660BBE17434DA59988087F2A99CD465B1FF423522B78CB0DE463A669613D356DFA9E86E0E2E0B6DAB5DE89131C5A0727AEAB1767278AB101DCD9C3CFC1026705C1DAB3BF53BF50AFAFB3F52DA2CEB0BEE57
Calculation can be done in any calculator supporting long numbers. I usually use Python, since it has the pow function which accepts the modulo.
>>> x = pow(s, e, n)
>>> hex(x)
'0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038L'
(ignore the space in the ffs)

I never got Windows OpenSSL to work with the task of getting the hash but this link does the job

https://lapo.it/asn1js/#3021300906052B0E03021A05000414A9BC4DC6DBF5A02B19E87DD56D9236EBADA47A2A

You drop into the box the

3021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038

bit. This gives you the hash.

Taking a working November 2016 VW POI download file (the ones since then haven't but that's something different). I took the route metainfo2.txt file.

Concatenated the signatures and put a leading 0x in front as per the worked example above. Gives us a new s

b23cf0dbe1d0baf902e43229a07cfb92813c76dea04775d174ac4f937445ae538b84d056d12279144f13341a7ccec3a7a239120b41cbf137351aa6a08c732b35215a224666234d8700e6c46bf2a943452cb06daa662fc8d9a1aee981c0a5df7c1a4bcd566ead66604069d58ab0a9f77d14

Through python with the same public keys and the same power value this generates

Hex (ignore spaces put in below by the board software)

'0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a050004142ff0f3e76e3a632f5aab4ce172a4b90f3c2c8f05' (ignore the gap in the f's again formatting issue with the screen)

Which is hash

OCTET STRING(20 byte)

2FF0F3E76E3A632F5AAB4CE172A4B90F3C2C8F05

We take the original metainfo2.txt file and delete the signature row and resave as something else. We run this through

https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility/

The SHA-1 hash tallies. This is how they signature these types of files.

Work in progress.... what you got to do is resign the files after they have been changed. You can claim your own private key and generate a new public key to match. This would have to go in the box which would be unrealistic, that's what the guy was going to do in the post. I think there is a way to overcome this although as said on a learning curve. There are QNX commands that say ignore the signature but these don't work with the map update, only POI loading, so it appears. Probably find my hunch on how to update the unit won't work after one has mastered this:rolleyes:.

Edit... September 2017

Where I'm at is all in this thread in a nutshell.

http://turbo-quattro.com/showthread.php?19874-Audi-A6-4G-MIB-Head-Unit-HIGH

Somebody has added the reverse engineering link recently... wasn't there before but that doesn't really help if you can't create the signatures unless you edit into the box your own public key based on your own private key which was the guys question. The file that can be downloaded on that link contain the same public keys for the signed metainfo keys as the one we know that works and they are common across the VAG group. There is only one private key to one public key, so one private key unlocks everything in so far as being able to edit the map upload file. That key is also shared apart from the FEC side of things.

The other concept is that the POI upload file doesn't use the SHA-1 signature so whether that check is turned off by the assorted commands that you see in the user POI upload file or whether for the map update it needs the SHA-1 signature (that's how you currently do the user POI updates for the High unit fishing out a sub directory since VW incorrectly generates the SHA-1 signature on the top level file that covers standard and high units - so that work around has been know including an episode when they messed up the standard unit's person POI update). Had a go at that but didn't get that to work for the maps - might retry that and decompose the update. That appears as a suggestion elsewhere but then I haven't found anyone saying it's possible just floating it up - probably the same people on all the threads.

It does seem thou that the acceptance of the update is solely based on the version number being below or at the one that the software it is married to in the unit. Frig that via a notepad edit of the version number (did) and get past the signature check (can't) and you are away (can do the Meta file checks thou - the link explains how you do that). Till then I'll be doing the allowable updates via the back end method of everything other than the road maps which I stumbled across was possible :). Can't but help think that the primary key is know but I just haven't found it.:blink:
 
Last edited:
Adrian Flux insurance services - discount for forum members.