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
).
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):
The SWDL menu long press the Menu key assumes that developer mode has been activated with 32GB SD card inserted:
Can select software manual download, then start download:
Next
Next if on SD
Next
Next
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:
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.
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.
