Allowing map modifications on Nissan Connect

The maps on the Nissan Connect aren’t great, if you look at the metadata on the sd card the actual data used in the latest version is always at least a year old. Another personal annoyance is that the maps think the speed limit on several roads around my house is 20mph, which is not true and never has been. I have over-speed warning turned on, so I get lots of annoying and incorrect warnings when driving near the house. I have no expectation that this will ever get fixed in the maps officially, so I started to wonder about fixing it myself.

Having looked at files on the sd card I’m not convinced that’s going to be very likely, unless there are some tools out there on the internet but a quick google hasn’t found anything. Possibly no one has made any effort to understand the maps because if you edit them they probably work on the system – the contents of the sd card appear to be signed. The file cryptnav/data/data/misc/sdx_meta.dat contains a list of files that are hashed (or in some cases just the first 2kb of them) and signed. These files look like they’re probably key to the rest of the map data, so it’s likely any change to the map data will break the signature. A file of md5 checksums for the nav application update files is also included in the hash list, to ensure they aren’t modified either.

Other interesting things of note in sdx_meta.dat is a start date (seems unnecessary) and an end date (happily this is blank so they don’t expire). Guessing from the acronyms, it also looks like there’s the option to tie the contents to an sd card (via cid) or to a specific vehicle (by vin), again these are both blank values so not currently in use.

In order to edit the maps we either need to sign the edited version (not possible without the private key) or bypass the signature check. The latter is easy. The signature is ultimately verified by the function BPCL_EC_DSA_Verify in /opt/bosch/processes/libosal_linux_so.so and the return code can simply be patched so it always returns 0 (success).

If you want to play with map modifications (please do, I want to know how to fix my local speed limits!) I have added a script to my lcn-patcher tool to modify libosal_linux_so.so for you. The patch will need to be tailored for each version of the library, as it will have been re-compiled with each version of the firmware. The patch currently works with firmware versions F16A, D554 and D605, and uses md5 to check the file before modification (it also makes a backup and there is a script to restore the backup). For unknown versions, it will copy it to the sd card so it can be analysed for patching. As always, you modify your head unit at your own risk!

Update: See here from some initial work on understanding the map data formats.

Removing Alerts_0913.ntq from Nissan Connect

Shows Alerts_0913.ntq removed from device.

Following on from my previous post, I quickly found one useful thing that root access gets us. It allows us to remove the built-in speed camera data. This is good for two reasons: 1) it’s from 2013 so some of it is out of date 2) if you add your own speed camera database you get duplicate warnings. The old camera database comes with the head unit firmware, not the maps sd card, in a file called Alerts_0913.ntq. You can see this filename if you go through the menus to look at myPOI settings. You cannot normally remove this database, and the only way to update it was to replace it with a newer copy purchased from Nissan. With no way to remove these they become increasingly out of date and inconvenient, which is probably a deliberate tactic to get you to pay for the update. Only now they don’t even sell the update, so you’re stuck with 8 year old speed camera data! You can install a third party database of speed cameras, but then you get duplicate alerts where they appear in both.

Removing the old set of alerts is as simple as removing the folder /var/opt/bosch/dynamic/ffs/myPOIs (and its contents), using root access over ssh. If you’re not familiar with Linux, don’t have a laptop, don’t want to order a usb network adapter from china (wait weeks, and then maybe find it’s not the right type when it arrives), etc. then you need a simpler way. So I’ve written a little script that uses the technique from ea to produce a usb stick image that will do it for you. You just plug in the stick and it does the job, wait for the reboot, remove the stick during the boot up Nissan logo (if you don’t remove the stick it’ll keep doing it and keep rebooting) and you’re done.

The code to create the image is on GitHub. I’ve written it as a tool that can create an image based on one or more included scripts. So far the scripts include a test script (to see if your device is compatible with the method used to gain access), a script to enable sshd and a script to remove the built in POIs (note it will also remove any custom ones, but you can put these back on afterwards of course). Sadly you will need a Linux system to create the image, but once created you can share them and write them in Windows so ask a friend if you don’t have one.

Update – bit more info on the internal POIs. The ntq files that you used to be able to purchase from Nissan were encrypted, and in some way tied to the device (that’s why a device ID is displayed on the screen where it tells you the name of the built in file). When you install them from a usb stick they are decrypted and copied to the internal filesystem at /var/opt/bosch/dynamic/ffs/myPOIs/myPOIWarnings. The file retains it’s ntq extension, despite no longer being encrypted, and is now just a csv file. The ntq extension ensures that it will not get deleted when you choose to delete POIs from the menu. Along side the ntq file is a file called DInfoCW.dat which is also a csv file, containing: Alerts_0913.ntq,953088,8,37,15,16,9,2013
Which appears to be: filename, filesize (of the ntq file), time and date. Filesize is off by a few bytes, but I suspect that’s an error in the file.

When you add your own csv file of camera locations the csv is copied to the same location as the ntq, and a file is created alongside it called DirInfo.dat with the same format as DInfoCW.dat (the filesize it contains is exactly that of the csv file). Another identical is also created in the folder above (/var/opt/bosch/dynamic/ffs/myPOIs).

Also in /var/opt/bosch/dynamic/ffs/myPOIs is the file completequadtree.dat which contains all the POIs in some more efficient binary format. This is regenerated when you install a new csv/ntq file or when you delete your custom POIs (assuming you have the built-in ntq, if you don’t then the file and the folder containing it is removed completely).

Playing with Nissan Connect

A few weeks ago I found an article on Hackaday reporting ea‘s success in getting root access to a Nissan Connect LCN2kai sat nav head unit. I have one of these in my Nissan Pulsar, and my wife has an older version (LCN1) in her Qashqai, and I’ve always fancied playing with them but never had the time (or wanted to risking break it! – ea bought a spare to play with). Now someone else has done the hard work and got access, it prompted me to have play. The question is – what can I to do with it now? Very often the answer to that is ‘nothing useful’, but at least there’s some fun to be had in the playing.

Anyway, from initial playing I found a few interesting things which aren’t mentioned in the original write-up:

  • The system starts in runlevel 4.
  • The device comes with developer scripts, and can be switched into development mode. This enables sshd and I think enables a serial terminal. There is also a script to mount /opt/bosch over NFS (presumably for testing new builds).
  • Most of the user applications are not updatable, without a complete firmware update of the unit. The satnav application is the exception – it is symlinked to a writeable partition and can be updated by a newer version shipped on the maps sd card.
  • Most of the programs in /bin are provided by busybox, but there are more utilities compiled in to busybox than are symlinked. E.g. md5sum is provided in /usr/bin so you don’t have access while using the mount trick (which has mounted over /usr/bin). This is unfortunate if you want to create an easy way for users to modify their system just via usb stick, as you’d probably want to use md5sum to check files on the system before modifying them to avoid breaking an incompatible system. Luckily, busybox also provides md5sum. As there is no symlink in /bin you need to call /bin/busybox md5sum <file> instead.
  • The system is quite happy to use a usb hub, so you can connect a usb stick and network adapter at the same time. This means you can image the filesystem for offline research. At ~900mb for the system partition, it took half an hour to dd it to a usb stick and required the engine running to keep the unit powered on that long. On the other hand, if you download a system update you can access the complete filesystem there which is a lot less effort. In fact, looking at how ea worked out how to exploit the mounting of a usb stick to get root access to the system, this could have been worked out entirely from examining the firmware update without any need to get serial access to the device itself!