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.

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:

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.

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.