AudioMate Firmware

By | 25 Jan 2009
3 Comments

Download

Details

Looking at the firmware file, the header starts – as usual – at 0x00. It consists of the string UMDA! followed by the firmware revision in octets. For the v1.2.2.1 I found the bytes 01 02 02 01. After that are some bytes which might be a checksum. The line looks like this:

55 4d 44 41 21 00 01 02 01 02 02 01 00 06 c5 c9   UMDA!...........

At 0x10 starts the .tar.gz compressed kernel image kernel.bin and it ends at 0x0e1474. After that there’s a lot of room for more code in the future.

The kernel seems to be version 2.4.26-uc0 for MIPS architecture. At least I found the string somewhere there.

At 0x0ff000 the boot logo starts – a 128×64 pixel black-white-BMP. Since I don’t like the original logo, I made a new one. Here’s the comparison:

And now for the interesting part:

At 0x100000 the cramfs starts. You can unpack it in Windows using e.g. the FSExtractor or uncramfs from the Firmware-Mod-Kit. You could also mount it using the cramfstools or fusecram.

After mounting the kernel image, you’ll find some interesting things. Here are some examples:

/etc/customer.info:

AudioMate U-MEDIA Communications, Inc http://www.u-media.com.tw

/etc/buildtime:

2005 Dec 22, 12:20 PM

Below /etc/ringbell/ you’ll find a MP3 file ringbell.mp3 which is the alarm sound. I formerly guessed it is made of sinus waves – but this discovery open new possibilities for tuning the device. The file is recorded at 44.1 kHz with 64kbps and mono signal.

Under /etc/icons/ are all used icons in BMP format. Even the boot logo is found there – don’t know why. Also a “screenshot” of the main menu.

For time synchronization, the NTP server 0.pool.ntp.org is used – good choice! This entry is found in /etc/conf_def.dat.

Finally you’ll find all pre-defined radio stations in the binary file /bin/dma_ui. Sadly this throws all my plans away. I hoped these are defined in a text file which I could change easily and re-insert into the kernel. I don’t need those 500+ Asian radio stations. I’d like to have my own favorite stations – because the 20 favorites the device supports are not enough to hold ALL the stations I’d like it to hold.

Well, there still is the way of having lots of .m3u playlists with links to your favorite stations on a USB drive.

I still have to find out how the firmware gets checked for validity – because without knowing it, the firmware containing my custom logo gets rejected. Seems like they didn’t use a common checksum (CRC16 or CRC32) – or I didn’t find the correct range of where the checksum gets calculated.

Checksum

A user called “tidy” has found out what the header bytes are meaning and how checksum is compiled:

bytes 0-3: file magic UMDA
byte 4: Platform *
byte 5+7: Customer * * (whatever that means its extracted from decompiling the header parse code)
byte 6: Model *
byte 8-10: Version number
byte 11-12: build number (little endian)
byte 13: flags seem to have impact on the update process but I’m not sure in which function
byte 14-15: checksum

The checksum is calculated by interpreting the file as a little endian int16 stream, adding up its
values, truncating the 16LSBs after every addition and calculating the value that is missing to
sum up to 0x10000. I.e. if one calculates the checksum as described over the whole file including
the calculated checksum the result has to be zero.

3 thoughts on “AudioMate Firmware”

  1. tidy

    Hi,
    I know it’s a little outdated but have you ever been able to find out more about the file header?
    I have a TEAC-WAP8900R and under the hood there is a HVA1500 from U-Media with very similar firmware images.
    Here are my two cents:
    UMDA is the file magic from umedia, the ‘!’ is more or less by accident valid ascii. In my case this byte assigns the image to that certain TEAC device.
    Then there are three more bytes of unknown meaning and as you already figured out the firmware version.

    There seems to be some kind of checksum even over the header since if I simply change the firmware version bytes the tinkering will be detected.

    Reply ↓
      1. tidy

        Hi Markus,
        I figure you aren’t interested anymore. Anyway just for the records here is finaly my understanding of the firmware header U-Media used back in the 200x years:

        bytes 0-3: file magic ‘UMDA’
        byte 4: Platform *
        byte 5+7: Customer * *(whatever that means its extracted from decompiling the header parse code)
        byte 6: Model *
        byte 8-10: Version number (
        byte 11-12: build number (little endian)
        byte 13: flags seem to have impact on the update process but I’m not sure in which function
        byte 14-15: checksum

        The checksum is calculated by interpreting the file as a little endian int16 stream, adding up its values, truncating the 16LSBs after every addition and calculating the value that is missing to sum up to 0x10000. I.e. if one calculates the checksum as described over the whole file including the calculated checksum the result has to be zero.

        Reply ↓

Leave a Reply