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 v18.104.22.168 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!...........
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.
0x0ff000 the boot logo starts - a 128x64 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:
After mounting the kernel image, you’ll find some interesting things. Here are some examples:
AudioMate U-MEDIA Communications, Inc http://www.u-media.com.tw
2005 Dec 22, 12:20 PM
/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.
/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
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.
A user called “tidy” has found out what the header bytes are meaning and how checksum is compiled:
bytes 0-3: file magic
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.