Toyota Touch And Go Map Update Download

• Toyota Touch And Go Update Download
• Toyota Touch And Go Map Update Download Free
• Toyota Touch And Go Map Update Downloads

. The 'Map Update ID' can be checked only on the screen of the navigation system. Make sure to check the 'Map Update ID' and record its number. It is impossible to obtain a license key number without the 'Map Update ID'. The steps to display the 'Map Update ID' di˚ers depending on the area.

Before I start, here's the TL;DR: Custom firmwares are not possible for Touch & Go without breaking open the device and possibly soldering stuff on it. Don't try it – you'll most probably ruin your device.

Now that we have that out of the way, let's continue.

Out of curiosity, I wanted to find out what's lurking inside the Touch & Go unit I have on my car. The device itself reveals very little information about its internals, but a firmware update image provided by the manufacturer was a great source for lots of interesting information.

As has already been determined, the head unit runs the QNX Neutrino operating system. The board appears to be based on a TI DM3730 (OMAP3 ARMv7) SoC and all the radio, navigation, etc. functionality is provided by a Toyota-specific extension box which may be running a Renesas V850 and a firmware of it's own.

The board has a NAND flash chip which is divided between IPL, IFS and ETFS partitions. The first two are read-only and loaded into RAM on bootup. The ETFS is a read/write filesystem, so the updater scripts can delete, replace and add individual files on it.

Additionally, an MMC card (probably not a physical card, though) is mounted on /fs/mmc0/ifs for system data.

Updating the device completely replaces the IPL and IFS images in the onboard NAND, so looking at /usr/share/IFS/ifs-extbox.bin in the ISO image probably lets us see something close to what's currently on the device's IFS.

Dumping the IFS image reveals a bunch of interesting stuff, such as the boot scripts, validation keys and various ARM binaries. So let's take a short look at what happens when the device boots up for updating.

On powerup, the execution starts from the IPL, which is something akin to the BIOS and MBR on PCs. The IPL locates the system image, loads the process manager (procnto-instr) and transfers control to it, which then continues the boot process by starting the boot script off the IFS.

The boot script first starts several system services and then calls another script called /bin/bootmode.sh. This script first reads the FRAM at offset 3 and checks whether the byte contained there is ‘U'. If true, the system is determined to be in update mode.

The update package is expected to be delivered on an USB mass storage device, so the boot script waits up to 10 seconds for /fs/usb0/swdl.iso to appear. Once found, it will proceed to authenticate the ISO image.

It first calculates an SHA256 digest from the ISO image and stores it into /tmp/swdl.iso.digest. The utility isodigest apparently either ignores the first 64 bytes or just regards them as zeroes. We'll assume the latter.

Once a digest has been made, the signature is extracted from the beginning of the ISO image. The first 64 bytes contain the signature and it's stored into /tmp/isodigest.sha256.

For example, signature on swdl.iso for 2011-12-08 update:

The startup script will then scan all .pub files stored in /etc/keys/ on the IFS. Currently there are five public keys in PEM format:

The script verifies the signature against each public key. If the calculated digest matches the signature (ie. the ISO has not been tampered with and the signature has been signed with one of Toyota's private keys), the script returns 'Verified OK' and environment variable AUTHENTICATED is set to 1. If after processing all keys the variable is blank, the script will quit with an error.

Authenticating is done by calling OpenSSL with the following command line for each key in /etc/keys/:

If authentication went OK, the ISO image is mounted and the IFS image on the ISO is loaded to RAM. This secondary IFS contains all the system executables required for the actual update process.

Unfortunately swdl.bin is not a standard IFS image, but instead appears to be some (loosely) compressed format with a ‘hbcifs‘ header. Apparently it is decompressed and loaded into RAM by memifs2, but there's no documentation available for this utility. Finding out more about the ‘hbcifs‘ format would potentially require disassembling /usr/bin/memifs2 provided on the primary IFS.

Finally, with the secondary IFS loaded, bootmode.sh turns over control to another script, /usr/share/scripts/install.sh on the ISO image. This script then continues the update process by flashing the new IPL and IFS images and modifying the ETFS and MMC filesystems. The lua scripts used for this are plainly visible on the ISO image.

Of course, without knowing one of the private keys Toyota uses to sign the images, it's impossible to make custom firmware images. The only way around this would be to somehow inject our own public key to /etc/keys/ by modifying the IFS partition on the NAND. The most common way to modify NAND contents in other devices is by opening the device and reflash using possible JTAG pins inside the unit.

Although JTAG headers are ubiquitous on embedded systems, it is very possible that a production device only has solder points without actual pins. In this case we'd have to modify the board by adding the pins in order to be able to use a programmer device.

An alternative to flashing via JTAG is getting shell access on the device via TCP/IP and reflashing the IFS using the built-in tools on the device. The guys at Tarlab Oulu have discovered that the device has an open telnet service on port 23 and presents a login prompt. If a username/password combination for logging into shell with root access is found, the device is open for flashing any images from mounted USB storage devices.

Given the hypothetical situation that we have found the capability to inject our own public key into the system, we could do this by first generating a key pair using OpenSSL:

Now, assuming that the ‘isodigest' utility regards the first 64 bytes as zeroes, we need to first zero out them on our custom update image:

Now generate the signed digest from our custom swdl.iso:

Finally, overwrite the first 64 bytes of the ISO image with the signature:

The script verifies the signature against each public key. If the calculated digest matches the signature (ie. the ISO has not been tampered with and the signature has been signed with one of Toyota's private keys), the script returns 'Verified OK' and environment variable AUTHENTICATED is set to 1. If after processing all keys the variable is blank, the script will quit with an error.

Authenticating is done by calling OpenSSL with the following command line for each key in /etc/keys/:

If authentication went OK, the ISO image is mounted and the IFS image on the ISO is loaded to RAM. This secondary IFS contains all the system executables required for the actual update process.

Unfortunately swdl.bin is not a standard IFS image, but instead appears to be some (loosely) compressed format with a ‘hbcifs‘ header. Apparently it is decompressed and loaded into RAM by memifs2, but there's no documentation available for this utility. Finding out more about the ‘hbcifs‘ format would potentially require disassembling /usr/bin/memifs2 provided on the primary IFS.

Finally, with the secondary IFS loaded, bootmode.sh turns over control to another script, /usr/share/scripts/install.sh on the ISO image. This script then continues the update process by flashing the new IPL and IFS images and modifying the ETFS and MMC filesystems. The lua scripts used for this are plainly visible on the ISO image.

Of course, without knowing one of the private keys Toyota uses to sign the images, it's impossible to make custom firmware images. The only way around this would be to somehow inject our own public key to /etc/keys/ by modifying the IFS partition on the NAND. The most common way to modify NAND contents in other devices is by opening the device and reflash using possible JTAG pins inside the unit.

Although JTAG headers are ubiquitous on embedded systems, it is very possible that a production device only has solder points without actual pins. In this case we'd have to modify the board by adding the pins in order to be able to use a programmer device.

An alternative to flashing via JTAG is getting shell access on the device via TCP/IP and reflashing the IFS using the built-in tools on the device. The guys at Tarlab Oulu have discovered that the device has an open telnet service on port 23 and presents a login prompt. If a username/password combination for logging into shell with root access is found, the device is open for flashing any images from mounted USB storage devices.

Given the hypothetical situation that we have found the capability to inject our own public key into the system, we could do this by first generating a key pair using OpenSSL:

Now, assuming that the ‘isodigest' utility regards the first 64 bytes as zeroes, we need to first zero out them on our custom update image:

Now generate the signed digest from our custom swdl.iso:

Finally, overwrite the first 64 bytes of the ISO image with the signature:

Now, assuming that we have somehow managed to inject our public.pem to the device as, for example /etc/keys/custom.pub, our custom swdl.iso should pass the validation in the update script.

However, given the number of uncertainties and assumptions, the above procedure is pretty much academical and, with a high probability, would not work. Further research would require hands-on experimentation on an actual ARMv7 platform, such as the BeagleBoard-XM, which is also based on the DM3730.

While this little research project didn't result in a procedure for custom firmwares, it was certainly interesting to see how a modern embedded device, similar to mobile phones and game consoles, performs firmware updates securely even when the user has physical access to the device. I tip my hat to all hackers who have successfully discovered ways to jailbreak their various devices.

Toyota Touch And Go Update Download

Toyota Touch And Go Map Update Download Free

Toyota Touch And Go Map Update Downloads

Ultra fast delivery. All worked, done the update and all working fine.

Thank you 5*

Was a bit sceptical of buying a non-dealer upgrade, but shouldn't have worried.

Product delivery was really fast and communications excellent.

Will certainly use again for future upgrades

Thanks