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!

Honeywell Galaxy Ethernet Adapter RS485 Protocol

This is a belated follow-up to my previous posts, this time about the Honeywell Galaxy RS485 protocol, covering the Ethernet adapter. The adapter normally provides reports to an Alarm Receiving Centre (ARC). It can also be used to configure the alarm panel through Honeywell software. It does not, as far as I know, provide any direct interface to the alarm to allow it to be set/unset/etc. Devices like the LCE-01 provide this via a virtual keypad interface, by emulating a keypad on the RS485 bus (i.e. it does not interact with the panel through the normal panel<->ethernet interface, but instead through the panel<->keypad interface).
Continue reading Honeywell Galaxy Ethernet Adapter RS485 Protocol

Honeywell Galaxy Keypad (CP038) RS485 Protocol

The KeyProx model contains two logical devices, the keypad itself and the RFID reader. Logically these appear to be completely independent, though a quick look in the case confirms there is only really one device as you’d expect. This means the keypad information will be the same for a non-prox model. The prox part will probably be the same for the separate max3/4 RFID reader but I don’t have one of those to compare against.

The device ID is set using the rotary selection switch on the PCB. Although it has 16 positions only 0-3 are valid for keypad ID. Positions 0/1/2/3 correspond to RS485 bus IDs of 10/20/30/40 respectively for the Keypads and 90/91/92/93 for the associated prox readers. A strange pair of numeric sequences. You’ll also note from the startup polling sequence in my previous post that the prox readers are polled separately from the keypads and in reverse order. I’ll just deal with the keypad in this post, as I haven’t played with the prox reader much.

When the keypad is powered on it will beep and flash until it starts to receive commands. Once running, if it does not receive a command within a certain amount of time (e.g. lost contact with panel) it will revert to this beeping state.
Continue reading Honeywell Galaxy Keypad (CP038) RS485 Protocol

Honeywell Galaxy G2 RS485 Bus

I always fancied adding Ethernet to my home Alarm system, even though I don’t have any particular use for it. I live in a pretty safe area and it rarely has false alarms or anything else I really need to monitor. Besides, if you’re at work, miles from home and in the middle of something, what what are you going to do if you get a notification that your house alarm has gone off?

Eventually, by chance, I picked up a second hand official Ethernet adapter for the alarm at a car boot sale, but it turned out the firmware was too old and the cable to update it is surprisingly expensive, and the update itself not publicly available anyway. I was already aware of the LCE-01 from SM Security Alarms as a cheaper alternative, with more functions like a Virtual Key Pad app, but £66 for a device I didn’t really have a use for was still a bit steep for someone who hates to part with money. I contacted the maker to find out about updating the firmware on mine and he offered me a good deal on a part exchange so I went for it.
Continue reading Honeywell Galaxy G2 RS485 Bus

The clock is ticking…

The escapement works – it’s alive! The escapement has been installed and the lifting arms trimmed to the correct length. According to the books we’ve read the pendulum should swing 3 degrees (each way), but nowhere does it say what positions the arms should be lifted to before the pendulum reaches them and how much further they should be moved by the pendulum. The more they are lifted by the pendulum the more energy the pendulum will lose on the upswing and so the less of a push, relatively, will be given to the pendulum on the downswing. This was a simple bit of trial and error, positioning our temporary pendulum manually (the arch pattern was helpful for holding the pendulum, see the pictures below) and seeing where the arm rests on the block and how much the block moves with the rest of the swing. The result we were happy with was lifting the arms to a position reached with the pendulum at 2.5 degrees. This let the arm of the escapement sit about about a third of the way on to the block. When the pendulum pushes the arm the rest of the way to 3 degrees it moves the block enough to unlock the escape wheel with a reasonable looking clearance.

I have uploaded two videos to YouTube showing the escapement in action. In the first video the clock would only run for 5-10 minutes at a time. In the second, after all the new parts had bedded in a little it will run for hours. The blocks you see next to the bracket are in place of the banking pins, which haven’t been made yet. There is a extra collar on the pin at the bottom of the left arm because the arm needs a slight tweak to it’s angle. The pendulum is temporary and too short, so the clock is running faster than it should.

Constructing the double three-legged gravity escapement

It’s been a while since my last post about the turret clock restoration project, not least because there wasn’t a lot of progress over the winter. For a long time we were struggling to work out how the double three-legged gravity escapement itself was constructed. Unfortunately, several offers of help with this didn’t come through but we have managed to work something out that that fits the brief. As always there are a number of ways something like this could be done, but we wanted to replicate the original. Visually we have done that so we must be pretty close, but we don’t know how close.

The method we used was to turn down a hexagonal bar to make the arbour, leaving a short hexagonal section on which to mount the two escape wheels. The hexagonal mount gives the wheels good solid attachment to the arbour preventing any rotation as they hit on to the blocks and stop moving. We can see no way that they could have been pinned to a round arbour and we didn’t think silver soldering them would be sufficient due to the repeated blows they must endure. A small section of brass tube fits over the hexagonal section between the two wheels to keep them the correct distance apart. The three lifting pins are installed between the two wheels in simple holes straight through. A boss fits on either side to sandwich the wheels and tube together and keep then in place, as well as covering the pin holes to keep the pins in. The bosses could be pinned to the arbour, but they don’t appear to be on the original. The arbour isn’t a large diameter and the bosses don’t have a lot of depth to take a pin. As they only need to hold the parts of the escape wheel together, they don’t take any force, we decided to silver solder them on to the arbour. Overall we think our construction technique must be pretty close to that used on the original, but it’s hard to inspect this part on a working clock – our reference clock is viewed from eight feet up a ladder, with the escapement at the back and everything is moving.

BT Infinity with IPv6 on Linux

If you’re building your own Linux based router to connect to BT Infinity you’ll probably want IPv6 working too. Address assignment works differently in IPv6 to IPv4 – we aren’t going to be given a single address we are going to be given a 56 bit prefix. From a 128 bit address that leave us a lot of bits available to use to address hosts on many sub-networks in our network. We are going to assign 64 bit prefixes to our interfaces (we can create 256 prefixes at 64 bits each) each with vastly more addresses than the entire IPv4 address space. To get our prefix from BT and delegate prefixes to our own networks we need an IPv6 DHCP client. This is where lots of other guides, forum posts, and the like, are a bit out of date (or don’t apply to BT Infinity) using wide-dhcpv6, dibbler, radvd, sysctl settings and custom scripts. Having played with various options I’ve found what works for BT Infinity in 2017, resulting in a really clean and simple method that boils down to a very simple configuration.

Continue reading BT Infinity with IPv6 on Linux

MTU 1500 for BT ADSL with OpenWrt

Just a handy tip if you’re using BT ADSL with an OpenWrt router. I didn’t know you could get an MTU of 1500 on ADSL. I have that on my Infinity connection at home, but it wasn’t until I played with the router at my Father’s that I found it was possible on ADSL too.

Why do you want an MTU of 1500? Without going into all the technical details of Ethernet, here is the simple version: Your home network (wired or wireless) is Ethernet based and as standard Ethernet uses packets of 1500 bytes but traditionally ADSL routers in the UK were configured to use 1492. This meant any time you sent a full size packet to the router, to forward on to the internet, it had to break it down in to two packets. This adds overhead and is inefficient, resulting in reduced throughput (slower speeds).

If you are using OpenWrt connected to a modem that supports an MTU of >1500 you can fix this. I suggest the OpenReach white modems originally provided for Infinity, which can also be configured as PPPoE modems to connect an Ethernet OpenWrt router to ADSL.

To get the MTU up to 1500 for the PPP connection you need to increase the MTU of network interface to 1508. That’s easy, simply edit the WAN interface in the OpenWrt Luci GUI (no need to edit WAN6 as well). Or edit /etc/config/network (example from Netgear WNDR3700, interface names will vary by device):


config interface 'wan'
  option ifname 'eth1'
  option _orig_ifname 'eth1'
  option _orig_bridge 'false'
  option proto 'pppoe'
  option username 'user@isp.net'
  option password 'password'
  option mtu '1508'

This will only set the MTU for the physical interface. The PPPoE connection will still use 1492 and there doesn’t appear to be any way to fix this in the GUI. So add the following to a new file called /etc/hotplug.d/iface/99-mtufix (you’ll need to connect via SSH to do this):


#!/bin/sh

[ "$ACTION" = "ifup" ] || exit 0
[ "$DEVICE" = "pppoe-wan" ] || exit 0

logger -t mtufix "Setting MTU of $DEVICE to 1500."
/sbin/ifconfig $DEVICE mtu 1500