mirror of
https://github.com/mbirth/wiki.git
synced 2024-12-24 22:54:09 +00:00
Updated post about U-Media AudioMate (Allnet Allsound).
This commit is contained in:
parent
b55425276f
commit
46e47f4d46
@ -2,7 +2,7 @@
|
||||
title: AudioMate Firmware
|
||||
layout: default
|
||||
created: 2009-01-26 00:47:15 +0100
|
||||
updated: 2009-06-26 23:59:11 +0200
|
||||
updated: 2016-02-01 17:42:11 +0100
|
||||
toc: false
|
||||
tags:
|
||||
- know-how
|
||||
@ -74,3 +74,23 @@ Well, there still is the way of having lots of `.m3u` playlists with links to yo
|
||||
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.
|
Loading…
Reference in New Issue
Block a user