Logik Dax 1GB DAB/MP3 player

Current Port Status

30 October 2007: Some initial code has been committed to SVN. A simple application can be built and executed on the device, with working LCD driver and button input.

27 April 2021 As of revision 3ba2f6e5c7, the code for this port has been removed from the main Git branch. Consider this a dead port. This page will remain only for historic purposes.

Introduction

Logik is the own-brand of electronics sold by the Dixons and Currys high-street electrical shops in the UK. More info on the Logik DAX is available here: Logik DAX 1GB MP3 Player with Digital DAB Radio

This appears to have been designed by Telechips on behalf of Dixons, and the same design appears to have also been used for the ATMT DAB MP3 (MP170). As of October 2007, the Logik DAX appears to have been discontinued by Dixons/Currys (they are selling the last stock), but ATMT's version is widely available. No firmware updates appear to be available for the ATMT to confirm this suspicion though.

The Alba PRDAB210MP3 also appears to be a clone of the DAX/ATMT MP170, but this hasn't been confirmed, and it is also discontinued.

Alba also sell the PRDAB200MP3 which is a different form factor (2-colour OLED display, SD/MMC card slot), but is based on a Texas Instruments chipset, not Telechips.

Based on markings on the PCBs, the original manufacturer seems to be CCTech and according to 07-Presentation_Eric_Cheung.pdf it appears to have been developed by Telechips.

Some Photos

Hardware

• Telechips TCC773L CPU - ARM946E-S CPU Core (4KB Cache, up to 120MHz)
• Kwang Sung Electronics ARBP-8 DAB Module - contains an Integrant Technologies ITD3020 tuner and Telechips TCC320 decoder. This DAB module is only capable of receiving Band 3 (174-240MHz) broadcasts, not Band L (1452-1492MHz)
• LCD module (seems to have an SSD1815 controller). Has the following markings:

      R G  M1-RGB  B
      0YOOO1B-38-MO2

• Samsung K9K8G08U0M 1GB NAND Flash

Firmware upgrades

A firmware update and other information is available at http://support.thetechguys.com/2921. The firmware is distributed in a self-extracting zip file (called Firmware.exe) - the actual firmware is called player.rom and can be extracted from the .exe using an unzip utility.

To upgrade the firmware, the file player.rom needs to be copied to the root of the device. Upon reboot, the user is prompted to upgrade. If yes is selected, the firmware is upgraded and the file deleted from the FAT partition. A reboot is required to actually start the new firmware - the existing version will continue to run. Random notes/thoughts

Based on the observation that the existing firmware continues to run after a firmware update, it would seem that the firmware itself is executing from RAM, rather than executing in place from a ROM.

The firmware upgrade process itself displays the message "Upgrade NAND firmware". This would suggest the firmware is stored in the main 1GB NAND flash. The firmware doesn't appear to be in the part of the NAND flash visible as a drive via USB, so it is most likely hidden (similar to the Sansa E200R).

The Telechips website states that there is 4KB of "internal boot ROM" with various boot procedure (NAND, UART, USB, EHI). On the main PCB, there are two visible pairs of contacts near the CPU, with one pair marked as "USB" and one pair marked as "NAND". The "NAND" pair of contacts are soldered together. It seems likely that unsoldering the NAND contacts and soldering the USB contacts would cause the device to boot via USB - presumably meaning that you could safely upload and run code without fear of bricking.

If you disassemble the device and physically disconnect the NAND module from the main PCB, and then connect a USB cable, the device doesn't appear to power on (the LCD remains off), but it does make a USB connection to the PC. On a Linux PC, the following entry appears in /proc/bus/usb/devices:

T:  Bus=05 Lev=02 Prnt=03 Port=03 Cnt=02 Dev#= 51 Spd=480 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=140e ProdID=b021 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

These are different Vendor and Product IDs to either UMS or MTP USB modes, which would suggest this is the USB boot mode mentioned on the Telechips website. i.e. the device appears to default to USB boot mode if the NAND boot mode fails.

Running lsusb shows the following info:

Bus 005 Device 043: ID 140e:b021  
  Language IDs: none (cannot get min. string descriptor; got len=-1, error=110:Connection timed out)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 Interface
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x140e 
  idProduct          0xb021 
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
cannot get config descriptor 0, Connection timed out (110)
  Language IDs: none (cannot get min. string descriptor; got len=-1, error=110:Connection timed out)

Safely running our own code

In order to develop an alternative firmware, we need a way to safely run our own code - i.e. be able to recover the device when our attempts inevitably crash and burn. Some possible approaches to this are:

• Upload and run code with the NAND removed - this requires working out how to upload and execute code in the USB boot mode. Entering USB boot mode this way means we can't use the NAND (unless we attempt to reattach it whilst the device is running).
• Modify the PCB to change the boot mode to USB - this also requires working out the USB boot mode, but the NAND would remain accessible. Possibly a switch could be attached to choose the boot mode.
• Find a buffer overflow in the original firmware and use this to start our own code. Removing the battery and rebooting should restart the original firmware after our code crashes.
• Find an entry point in the original firmware (e.g. a cosmetic menu item such as the EQ), and insert our code there - so choosing that menu item runs our code. This would involve installing a modified player.rom each time we change our test code.

Because the Telechips website refers to a "boot ROM", it is probably safe to assume that this is not modifiable by the device manufacturer. So all the various devices using the same Telechips CPUs are very likely to have the same or very similar USB boot mode protocol. So working out how this works on one device should open up all of them to this method of attack.