Nabaztagtag (Nabaztag v2) Dissection

I received a Nabaztag/tag from my girlfriend this Christmas, bless her soul:) For those not familiar with the Nabaztag, check out Wikipedia’s page about it.

The Nabaztag/tag is made by a company called Violet. It is Violet’s 2nd generation Nabaztag and adds a few new features on top of the 1st generation. There is a relatively strong Nabaztag community on the internet. Quite a few sites exists with neat software hacks and documentation that allow users to have some control of the device. However, I hadn’t seen anyone really take advantage of the hardware in any way other than what Nabaztag’s inventors intended. From what I gather, its possible to run bytecode on a “virtual machine” on the Nabaztag, but that doesn’t give you full access to the Nabaztag’s hardware.

It would be great to gain complete control of the Nabaztag – ie download a custom version of the firmware such that you would have complete control of the processor and peripherals. This would be a fun project, and might open up the possibility of adding additional sensors or output devices to the Nabaztag to expand its features. Additionally, it would open the door to using server implementations completely unassociated with Violet, which occasionally has “service problems”.

In a perfect world, the firmware for the Nabaztag would be stored in a nice, neat, extractable flash chip which could be easily removed, backed-up, replaced, modified, etc. Alas, Violet was not so considerate:) During my investigation I had to dismantle the Nabaztag. I snapped some pictures during this process:

 

“Important” Component Summary

OKI ML67Q4051 33MHz ARM7-TDMI processor

• 128 KB of “secure” internal flash
• 8KB “Boot Flash ROM”
• 16 KB internal RAM
• Supports 32-bit instructions or 16-bit thumb instructions
• JTAG interface
• External memory controller
• Peripherals – I2C, SPI, watchdog, RTC, timers, 4 ADCs, DMA controller, 2 UARTs

OKI ML60842 USB 2.0 OTG controller

• Used to interface ARM processor with Ralink 80211b/g module

Samsung K6X8016T3B 512K x 16 bit CMOS SRAM

• Additional 1MB of RAM available to ARM processor

(1 MB)VLSI VS1003B MP3/WMA/WAV/MIDI decoder, ADPCM encoder

• Play streamed audio, encode voice commands

Texas Instruments TLC5922 16-bit LED driver

• Drive belly button and nose LEDs
• Serial data interface, SPI compatible

Ralink RT2571W-based USB 802.11b/g module

• 802.11b/g adapter
• USB interface

STMicro CR14 contactless coupler with anti-collision, CRC management

• Used for RFID
• Supports ISO14443 type-B protocol
• I2C interface

 

Analysis

It looks like Violet did their homework and made it relatively hard to extract the firmware from the Nabaztag. The 128 KB of internal flash that is used to store the firmware has a security feature which will make it difficult to read. After Violet has programmed the firmware, they can put the enable a “security mode”. When this security mode is enabled, external devices (eg JTAG or parallel programmer) can no longer read or with the flash, or use the standard JTAG debug functionality of the chip. OKI describes this feature as follows:

When a security bit is set, the contents of Flash ROM cannot be read or rewritten in Flash-JTAG mode. A debugging interface (ie JTAG) can no longer be used. The security bit can be reset after the chip contents are erased in Flash-JTAG mode or parallel programmer mode.

So if one were willing to erase their processor’s flash, they could then reprogram it with their own image. This means the Nabaztag is pretty easily reprogrammable, but it would be pretty difficult to reprogram it with any sort of useful image since its not possible to inspect the current Nabaztag firmware. Without reverse engineering the current firmware, it would be VERY difficult to port/write some of the current Nabaztag features such as the wireless card driver.

Possible Workarounds

A few possible ways to read the flash on the ARM processor came to mind. All would require a significant amount of work (and maybe not be possible at all:).

Make Sure “Security Mode” is Enabled

I made the assumption that Violet enabled the security mode on the processor do prevent reverse engineering. Unfortunately I don’t have a JTAG debugger compatible with the L67Q4051 to test this. The first thing to do would be to verify that security mode is in fact enabled. If anyone has an ARM JTAG debugger lying around or wanted to donate one to the cause, I’d be happy to look into it:)

Use Serial Programming Interface

The ARM processor has some configuration pins that affect how it operates when it comes out of reset. One combination of these configuration pins forces the processor to execute the Boot ROM flash (the 8KB, non-user reprogrammable flash) and allows the user to erase and reprogram the 128 KB of flash by downloading an image over the serial port. You can do it with a standard terminal emulator such as TeraTerm or minicom or with OKI’s own utility called ISFP which is available their its website.

The ISFP utility can actually dump the flash for other OKI chips like the ML674001 and ML675001. However, OKI says this feature is not available on the L67Q4051 which the Nabaztag uses. Its not clear to me whether this feature is truly disabled on the L67Q4051, or if OKI’s ISFP software just doesn’t allow it. Its a bit risky, but it may be possible to issue the same serial commands to the L67Q4051 that are known to work on the ML674001/ML675001.

Use “User Mode” Programming interface to read the flash

Code executing on the L67Q4051 is able to read the 128 KB of flash even when the “security mode” is enabled. If the code executing on the L67Q4051 could be comprised, it may be possible to execute a program which would read the flash contents and print it to the serial port. I imagine comprimising the L67Q4051 would be no trivial matter…

Reverse Engineer Nabaztag Firmware Published by Violet

Violet provides a firmware image at www.nabaztag.com/firmware/firmware.0.0.0.10.sim.txt. I’ve looked at this file a bit, and its not clear to me what format it is in or how the Nabaztag firmware interprets it. Its possible that this file could be reverse engineered to provide a firmware image that could be inspected in order to make a custom image for the Nabaztag.

Reprogram “Fresh” Image

Documentation for most of the peripherals are readily available. Source code is also available for the more complex components such as the VS1003B and Ralink wireless adapter. In theory, it would be possible to write Nabaztag firmware from scratch and not use the stock Nabaztag firmware as a reference at all. However, this would be VERY time consuming, and frankly, I don’t have that much time on my hands:)

Conclusion

Reprogramming the Nabaztag is straightforward and could be done with little effort. However, first extracting the firmware image to reverse engineer would pose a significant risk to bricking the Nabaztag and could take significant effort. If others have any additional info or thoughts, please let me know!