The Navman iCN 330 - now with linux

By Rasmus Rohde

Intro and warning

This document should help you to put linux on your Navman iCN 330 (other models might work, but you probably need to do some work on your own). At the moment I have not put together a root fs so you will only see Tux and some console output, however this is a nice start for moving further.
To the people who do not know what this device is I can quickly summarize it as a handheld GPS sporting an Intel PXA255, 32 MB RAM a 2.8" color LCD at 320x240 and a GPS connected to a serial port. Put in other words - an obvious device for Tux to assimilate.

I will skip the usual warnings and disclaimers and let you do the math yourself, but let me make a few points:

1. You may need to open the device in order to power it off again. This is easily done by removing the front plate, unscrewing 4 Torx screws and taking the top off.
2. This is purely a software hack and will thus leave the bootloader in the flash intact. Thus this should be safe to play around with, but you never know when lightning strikes
3. Do not try to mess with your original Navman card as this will most likely render the maps useless, and you will have to buy a new one.

Identified devices

• Intel PXA 255
• Samsung TFT display
• Spansion Flash?
• UDA1334 audio DAC

Building the software

Getting into the iCN 330 and running homebrew

As the iCN 330 will only run signed elf files (seems to me they use an RSA-512 signature together with hashing that is either sha-1 or md5) we need to exploit a little buffer overflow in the loading of Navman/system/poitypes.dat, but before all that we need to build a lot of stuff.

Building a cross compiler

First let's detail how we build all the code we need and then how it should be put on an MMC card for the Navman to boot.
The very first step is to build a cross-compiler and I suggest you use buildroot for this. Buildroot is pretty straight-forward to use so the only help you are going to get is we neeed a cross compiler for ARM little endian XScale and that binutils-2.17.50.0.3 and gcc-3.4.6 should work for you.

Building u-boot

Download u-boot-2006-06-30-2020 and apply this patch. Type CROSS_COMPILE=arm-linux- make and you should now have u-boot.bin

Building linux

Download the latest 2.6.18 kernel and apply this patch together with this .config. The just type ARCH=arm CROSS_COMPILE=arm-linux- make oldconfig uImage and you should have a kernel in some minutes named arch/arm/boot/uImage. Note that you need mkimage, which is found in the tools directory of u-boot.

Building u-boot bootloader

The last thing we need to build is the code that will allow us to bypass the security mechanisms in the iCN 330 and boot u-boot. Get icn330-hack.tar.gz, unpack and build with make. Construct the file poitypes.dat that will allow us to take control over the iCN 330 with cat boot.bin stackcon >poitypes.data.

Setting up the filesystem

We now have all that is needed and just need to make an MMC card with the right contents. To do this you need an original Navman iCN 330 card because we need to lift some files from this. On the card you should make a structure looking like this:

./iCN320u.elf                - Comes from the original card and is named Navman/system/iCN320.elf. It must have md5sum c34fbb9bc203a21c5d5710d754b492f8
./Navman
./Navman/system
./Navman/system/config.ini   - Comes from original card
./Navman/system/iCN320.bm    - Comes from original card
./Navman/system/poitypes.dat - Generated earlier on
./Navman/cdkeys.dat          - Comes from original card
./code.bin                   - Rename bootuboot.bin to this
./uImage                     - The linux kernel we built
./u-boot.bin                 - The u-boot we built

That's it!

Ok - that is basically it. You should now have a card that will boot linux. TODOs includes building a file system for our linux and making an app to control the unit. Mainly a way of switching it off so you do not need to open it and pull the battery :)

For all you lazy folks who just want to see Tux here is a package of the binaries I am able to redistribute. Note that Navman copyrighted files are not included.

Updates

• It plays Doom! Thanks to the iDoom guys porting Doom over was a breeze. Get the modified source, compile it yourself and grab the needed binary files from the iDoom site.
• Data from the GPS can be read from /dev/ttyS0 at 9600 baud with no parity.
• A working driver for the sound card has been made and the final details of the buttons have been determined. Download the kernel patch and config which also includes some code that will eventually (and hopefully :) make the device run Tomtom software.
• Some dummy drivers for most of the hardware found in the Tomtom has been made
• A Tomtom specific sound driver has now been made and it seems to work ok
• The kernel above now also includes support for the onboard flash 1 MB AMD flash
• The PCB includes a pad for adding your own USB serial port to the device. Just mount a connector and put a 1k5 ohm resistor in R56 and it should be working
• Should you ever want to make changes to the second stage bootloader which is found in the flash at 0x40000 here are a couple of hints. 0x40000 contains the length of the second stage bootloader and 0x40004 contains a checksum of the bootloader. If you change the bootloader you might want to calculate a new checksum, which can be done with the following little tool. The checksum is just a standard crc32 and could also be calculated with the built-in crc32 function in zlib. And btw - do not come crying if you brick anything in an attempt to flash something fancy into the unit.

A little about card security

You may be wondering why you cannot just copy the maps from an original card to your own favorite card so I will try to detail why. Upon startup the Navman application will try to authenticate the card using a well-known signature scheme involving sha1 and rsa-1024. The steps involved are as follows:

1. Construct a buffer consisting of the unique card id (CID), a key from cdkeys.dat and one of two keys found in the Navman application.
2. Do a sha1 of this buffer and you will end up with 20 bytes.
3. Search sigreg.dat for these 20 bytes. If found it will be followed by 4 zero bytes and then 128 bytes of rsa-1024 encrypted bytes. These bytes will be decrypted by a modulus and exponent found in the Navman application. This results in a buffer looking like 01FFFF .... FFFF00 + 20 bytes of signature.
4. The 20 bytes decrypted signature should also match the calculated signature.

Ok - so this is pretty much it and by now you have probably figured out that by putting the maps on a new card step 1 will result in an "incorrect" buffer because the CID has changed. Not a big problem so far as we can just calculate what comes out of step 2 and put that into sigreg.dat. But what we cannot do is to calculate the rsa-1024 encrypted buffer which also needs to match the new sha1 value. To do this we need the secret rsa exponent which is pretty hard to come by.
Put in other words: Making a copy of your card is probably only going to happen by removing this check from the Navman application. This is pretty easy except for the fact that changing the application is a no go too since the bootloader does a signature check on loaded elf files. Fixing this little issue can be done by patching the bootloader located in flash and after these steps you should be in business.