Projekt: wie funktionieren OTA Updates mit der CCU2?

[jab]

Sehr cool. Wir haben jetzt ja auch einen USB dump für den Hm usb cfg Stick. Da habe ich schon etwas experimentiert aber bin leider noch nicht ganz durch. Dann hätten wir zwei Geräte die 100k unterstützen.

Außerdem will ich einen atmel bootloader bauen der auch update per 100k Mode unterstützt. Dann kann man die custom Firmware auch damit updaten.

Allerdings Alles noch wip. Kann noch ein paar Tage dauern.


Gruß
Jan

[mgernoth]

Sehr cool. Wir haben jetzt ja auch einen USB dump für den Hm usb cfg Stick. Da habe ich schon etwas experimentiert aber bin leider noch nicht ganz durch. Dann hätten wir zwei Geräte die 100k unterstützen.

Nice

Habe jetzt mal die Parameter in die culfw commited: http://sourceforge.net/p/culfw/code/401/

Um den Code zu benutzen, muss man "HAS_ASKSIN_FUP" in der Board-config definieren und dann den FUP-Modus mit "AR" aktivieren. Ein "Ar" schaltet wieder auf den normalen AskSin-Modus zurück.

Getestet habe ich den Empfang jetzt nicht, da das remote ohne Firmware-Update relativ schlecht geht, habe aber gedacht, dass es evtl. für jemand anderes schonmal nützlich ist. Ohne das zusätzliche Board-Flag ändert sich nichts, das habe ich auch (remote) getestet.

Falls das weitere Datenformat BidCos-ähnlich ist (d.h. Längen-Byte als erstes Byte und danach wie bei BidCos ge-XORte Daten, dann sollte sogar das senden mit "As" funktionieren.

Außerdem will ich einen atmel bootloader bauen der auch update per 100k Mode unterstützt. Dann kann man die custom Firmware auch damit updaten.

Hört sich gut an

Gruß
  Michael

[trilu]

@jan
wird die firmware plain übertragen? ansonsten müsstest du doch an die verschlüsselung ran?
ich bin immer noch auf der suche meiner lib das aes protokoll beizubringen

[jab]

Hi,

@horst: im USB ist eh nichts verschlüsselt. Sieht mit aber auch alles unverschlüsselt aus da er vorher aes resettet im code.

@michael: ist relativ sicher normales Bidcos. Er nutzt die gleichen messages wie vorher im code. Kann höchstens sein dass der USB Stick das ändert.


Gruß
Jan

[trilu]

d.h. man könnte das Firmware Update durch einen Disassembler jagen?

Ich hätte vermutet das die Firmware verschlüsselt übertragen wird, im seriellen EEprom verschlüsselt abgelegt wird und
dann über den Bootloader entschlüsselt und ins Flash geschrieben wird.

Damit würde dann auch nichts passieren falls bei der Update Übertragung was schief geht. Aber wie gesagt, dass
war nur eine Vermutung...

[jab]

Hi Horst,

Ja disassembler geht. Daher habe ich die Infos ja.

Man kann die RTs definitiv kaputt flashen. Man bekommt sie aber immer noch in den bootloader.


Gruß
Jan

[mgernoth]

So, die culfw kann mit AR das Firmwareupdate mitschneiden und sollte auch mit As senden können.
Im Anhang der 100k-Teil eines Updates.

EDIT: Irgendwie fehlt da ziemlich viel, vielleicht ist das mit dem Längenbyte doch anders... Anscheinend sind das immer nur die letzten Bytes eines Update-Pakets...

Gruß
  Michael

[jab]

Abend,

das sieht schon gut aus. Allerdings fehlt da wirklich einiges. Im USB sieht es so aus:

Code Auswählen Erweitern


    00000000: 53 00 00 08 21 00 00 00 00 00 01 00 08 f1 c4 13
    00000010: 2a 20 ca 12 04 08 22 0f 80 ba 6e 4f 6d 7d 9c 38
    00000020: 2a 2a 80 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    00000000: 53 00 00 08 2a 00 00 00 00 00 01 00 08 f1 c4 13
    00000010: 2b 20 ca 12 04 08 22 0f 80 22 2b 8d 24 c1 72 d7
    00000020: 92 db e8 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


In deinem Dump (unterschiedliche HMID aber sonst gleiche Msg):

Code Auswählen Erweitern


A132A20CA00000021B983BA6E4F6D7D9C382A2A80
A132B20CA00000021B983222B8D24C172D792DBE8


Den Code zum lesen der Firmware kann man relativ einfach bekommen. Da gibt es potentiell zwei Quellen: CCU2 Firmware (Binary rfd; C++ Code mit Debug symbols) oder den Firmware Updater (.NET habe ich im Debugger nicht auf bekommen).


Gruß,
Jan

[jab]

Abend,

so ich habe mal etwas geschaut. Die Firmware ist in 580 Byte Blöcke (jeweils 4Byte Länge und dann die Daten) organisiert. Parsen kann man das ganze mit folgendem Code:

Code Auswählen Erweitern


<?php
$f = fopen("hm-cc-rt-dn_update.eq3", "r");

while(! feof($f)) {
        $lenStr = fread($f, 4);
        if (feof($f)) {
                break;
        }
        $len = hexdec($lenStr) * 2;
        $bytes = fread($f, $len);
        echo $bytes . "\n";
}


Das deckt sich auch mit dem alignment im Funk.

EDIT: Der Debugger kann mit dem resultierenden Binary auch was anfangen (mit xxd kann man es von hex nach bin konvertieren). Weiß jemand was für ein Controller auf dem HM-CC-RT-DN genau drauf ist?



Gruß,
Jan

[mgernoth]

EDIT: Der Debugger kann mit dem resultierenden Binary auch was anfangen (mit xxd kann man es von hex nach bin konvertieren). Weiß jemand was für ein Controller auf dem HM-CC-RT-DN genau drauf ist?

Ich bin mir ziemlich sicher, dass das Ding verschlüsselt ist und der Bootloader auf dem HM-CC-RT-DN die Daten vor dem Flashen entschlüsselt. Sonst hätten wir jetzt den Default-AES-Key im Klartext.
Selbst die Firmware für das Wired-Zeugs ist verschlüsselt, genauso wie die Firmware für den USB-Stick (den man seit gerade eben auch unter Linux flashen kann).

Kannst Du mir evtl. den USB-Dump zukommen lassen?
Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.

Gruß
  Michael

[Dirk]

Selbst die Firmware für das Wired-Zeugs ist verschlüsselt

Ist sie nicht.

Gruß
Dirk

[mgernoth]

Ist sie nicht.

Ok, dann bin ich schon still. Das sind gute Nachrichten.
Dann ist es die Funk-Firmware hoffentlich auch nicht

Gruß
  Michael

[betateilchen]

USB-Stick (den man seit gerade eben auch unter Linux flashen kann)

Hab ich was verpaßt?

[mgernoth]

Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.

Das war zu einfach, die Pakete sind länger als die 30 hartkodierten Bytes in der culfw.

Neuer Sniff im Anhang.

Hab ich was verpaßt?

Nur das hier: http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb/commit/b5e57d268fe86cf58116c03166d45c130280dfb6

Gruß
  Michael

[jab]

Abend,

Ich bin mir ziemlich sicher, dass das Ding verschlüsselt ist und der Bootloader auf dem HM-CC-RT-DN die Daten vor dem Flashen entschlüsselt. Sonst hätten wir jetzt den Default-AES-Key im Klartext.
Selbst die Firmware für das Wired-Zeugs ist verschlüsselt, genauso wie die Firmware für den USB-Stick (den man seit gerade eben auch unter Linux flashen kann).

Das ist nicht verschlüsselt. Dafür zeigt mir mein Debugger zu viele gültige AVR Opcodes an. Allerdings habe ich den richtigen Atmega noch nicht erraten und die Configuration der Datensegmente muss ich mir noch mal angucken. Daher die Frage ob jemand mal reingeguckt hat und mir sagen kann was das für ein Controller ist.

Den AES Key + den genauen Input für AES sollte man da drin finden denke ich.

Kannst Du mir evtl. den USB-Dump zukommen lassen?
Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.

Den Dump hat Mr P für mich netterweise gemacht. Leider kein Wireshark Format aber trotzdem fast selbsterklärend:
https://owncloud.isengard.at/public.php?service=files&t=ad61f7970e54b8fe7683a8c78d353cff

EDIT: Dein Dump sieht super aus! Entspricht genau dem Firmware File. Format ist so:

Vorne weg: A134420CA00000021B983 (ist klar denke ich) dann jeweils 70 Byte Teile der Firmware (inkl der 4 Byte Längenangabe). Solange bis der Block zu ende ist. In unserem Sample sind das immer 580Bytes außer beim letzten Block. Die letzte Nachricht (außer beim letzten Block) ist also nur noch 20 Byte groß. Der ganze Block wird vom Gerät bestätigt. Dann geht es mit dem nächsten weiter.


Gruß,
Jan