2015-02-25 23:22:00 +00:00
|
|
|
---
|
|
|
|
|
title: AudioMate Firmware
|
|
|
|
|
layout: default
|
|
|
|
|
created: 2009-01-26 00:47:15 +0100
|
2016-12-27 12:36:27 +00:00
|
|
|
updated: 2016-02-01 17:42:11 +0100
|
2015-02-25 23:22:00 +00:00
|
|
|
toc: false
|
|
|
|
|
tags:
|
|
|
|
|
- know-how
|
|
|
|
|
- hacking
|
|
|
|
|
- hardware
|
|
|
|
|
- audiomate
|
|
|
|
|
- allsound
|
|
|
|
|
- firmware
|
|
|
|
|
---
|
|
|
|
|
Download
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
* **1.2.2.1** BETA: [megaupload.com](http://www.megaupload.com/de/?d=HTVF7XZA)
|
|
|
|
|
* **Source Code**: [allnet.de](http://www.allnet.de/downloads.php?produkt=ALLSOUND)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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:
|
|
|
|
|
|
|
|
|
|
At `0x100000` the [cramfs](http://en.wikipedia.org/wiki/cramfs) starts. You can unpack it in Windows using e.g. the
|
|
|
|
|
[FSExtractor](https://sourceforge.net/project/showfiles.php?group_id=99199&package_id=108962&release_id=263019) or
|
|
|
|
|
*uncramfs* from the [Firmware-Mod-Kit](http://code.google.com/p/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.
|
2016-12-27 12:36:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Checksum
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
A user called "tidy" has found out what the header bytes are meaning and how checksum is compiled:
|
|
|
|
|
|
2016-12-27 12:39:36 +00:00
|
|
|
> 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
|
2016-12-27 12:36:27 +00:00
|
|
|
> byte 14-15: checksum
|
2016-12-27 12:39:36 +00:00
|
|
|
>
|
2016-12-27 12:36:27 +00:00
|
|
|
> 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.
|
