diff --git a/know-how/hacking/audiomate/_posts/2009-06-26-firmware.md b/know-how/hacking/audiomate/_posts/2016-02-01-firmware.md
similarity index 79%
rename from know-how/hacking/audiomate/_posts/2009-06-26-firmware.md
rename to know-how/hacking/audiomate/_posts/2016-02-01-firmware.md
index f7c4985..5528f91 100644
--- a/know-how/hacking/audiomate/_posts/2009-06-26-firmware.md
+++ b/know-how/hacking/audiomate/_posts/2016-02-01-firmware.md
@@ -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.