VoIP-Phone zerflasht, Wiederherstellung der Firmware

[Wechsler]

Zitat von DarkAngel2401

Witzigerweise ist mir was Ähnliches vorige Woche mit einem SIP-Telefon passiert, hier hat der Hersteller versehentlich eine neuere Firmware eines anderen Telefons mit der HW-ID meines Modells versehen. Telefon fraß das Update und war nach nem Reboot tot. Serielle Pins waren vorhanden, Telefon bootet bis zum Entpacken des Linux Kernels, danach hängt sich das auf, weil anderer CPU-Typ.
Der Bootloader hat noch einen Recovery-Teil an Bord, hierzu will mir der Hersteller aber das notwendige Tool nicht rausrücken

Der Hersteller macht also fahrlässig dein Telefon kaputt und weigert sich dann, es zu reparieren?

[DarkAngel2401]

Das war leider nur eine Firmware, die auf dessen ftp-Server herumlungerte. Direkt verlinkt war die auf der Support-Seite nicht. Mein Skript hat die trotzdem gefunden

[Wechsler]

Zitat von DarkAngel2401

Das war leider nur eine Firmware, die auf dessen ftp-Server herumlungerte. Direkt verlinkt war die auf der Support-Seite nicht. Mein Skript hat die trotzdem gefunden

Achso, dann hast du also selbst die falsche Firmware draufgebraten. Dein Posting las sich so, als hätte der Hersteller (via Updater) dem Telefon eine falsche Firmware untergejubelt.

Hast du wenigstens was draus gelernt?

[DarkAngel2401]

Draufgebügelt hab das schon ich manuell, aber die Hardware-ID im Binary passte zu meinem Telefon. Auch ist der Dateiname passend aufgebaut gewesen, <Modellbezeichnung>_<HWID>_<FW-Ver.>_<Timestamp>.

Dass das aber tatsächlich den Kernel und rootFS vom Nachfolgermodell (selbe Modellbezeichnung, daher im selben Verzeichnis auf dem Server, aber andere Hardware und damit eigentlich auch andere HW-ID) enthält, war erst nach dem Reboot ersichtlich. Da hab ich dann das Binary zerpflückt.

Ich war schon immer ein wenig Bleeding-Edge-Jünger. Es betraf auch nur das Telefon für's Gästezimmer, insofern nicht weiter tragisch. Kommt meinem Elektronik-Hobby sogar etwas entgegen. Einzig das Aus/Einlöten des NAND mit 0.5mm Pitch wird spannend, da hängen die Kondensatoren (0201) teilweise direkt an den TSOP48-Pads mit dran.
Gelernt? Ich würde es vermutlich wieder so tun




So, jetzt aber zurück zum Devolo 1200+

[robert_s]

Zitat von DarkAngel2401

Mein Flash hat immer 2 Firmware-Stände "im Bauch", das aktuelle aktive und das vorige, inaktiv geschaltete.

Dann sollte der Bootloader eigentlich auch so schlau sein, dass wenn ein Firmware-Slot nicht gebootet werden kann (was die Firmware in diesem nach dem Boot irgendwo im Flash abspeichern sollte), wieder auf den vorigen gewechselt wird. Die Frage ist, ob der Bootloader-Code wirklich so mangelhaft ist, dass dieser Mechanismus komplett fehlt, oder ob Du nur noch nicht herausgefunden hast, welche Tasten Du drücken musst, damit der Bootloader das macht ...

[DarkAngel2401]

Zitat von robert_s

Dann sollte der Bootloader eigentlich auch so schlau sein, dass wenn ein Firmware-Slot nicht gebootet werden kann (was die Firmware in diesem nach dem Boot irgendwo im Flash abspeichern sollte), wieder auf den vorigen gewechselt wird. Die Frage ist, ob der Bootloader-Code wirklich so mangelhaft ist, dass dieser Mechanismus komplett fehlt, oder ob Du nur noch nicht herausgefunden hast, welche Tasten Du drücken musst, damit der Bootloader das macht ...

Also dann doch noch nicht ganz btt ...



Der Bootloader besteht aus 2 Stages, die erste initiiert die Hardware, die 2. habe ich in Ghidra teilweise zerlegt (ARMv7). Der jetzt als aktiv markierte Teil lässt sich ja booten - zumindest aus Bootloader-Sicht. Alle CRCs passen, der Kernel (zum falschen Prozessor) lässt sich laden und entpacken, der Absprung in den Kernel-Code klappt und danach ist erst Ende Gelände, da der Code nicht zur Prozessorarchitektur passt bzw. der Code nicht zur Hardware (Ich hab den falschen Kernel zugegebenerweise nicht angeschaut)..

Ein Menü wie bspw. in uboot gibt es nicht, lediglich per beliebigem Key-Input / seriellem Input wird der Bootprozess an einer Stelle unterbrochen (da wartet er 1 Sekunde auf Input) und falls hier der Bootprozess unterbrochen wird, wird auf den download-Modus per seriellem Input gewechselt. Hier ist die anschließende Decodierung der übermittelten Daten allerdings komplexer als gedacht.


Aber: Im Bootprozess wird eines der mtd im NAND eingelesen. Hier enthalten die ersten 404 Bytes alle Informationen zu aktivem Image, diverseste CRCs, Size-Angaben zu beiden Image Kernels und root-FSen, Namen, Timestamps und dann nochmal eine letzte CRC über diese 404 Bytes.
Welches Byte genau das aktive Image angibt und wie die CRCs berechnet werden, war ein wenig tricky, aber genau hier setze ich jetzt an, indem ich das Byte zum aktiven Image abändere und die globale CRC neu berechne. Dann kann ich diese Page wieder ins NAND reinschreiben und das Telefon sollte vom vorigen, funktionierenden Image booten.


Leider gibt es wirklich keine Möglichkeit, das Aktiv-Flag per Tastendruck am Telefon, serieller Konsole oder Jumper auf dem Board zu überschreiben.

[DarkAngel2401]

Hab den Thread mal herausgelöst aus dem originalen devolo 1200+ Thread, weil Offtopic.


Initialer Offtopic-Kommentar war:


Witzigerweise ist mir was Ähnliches vorige Woche mit einem SIP-Telefon passiert, hier hat der Hersteller versehentlich eine neuere Firmware eines anderen Telefons mit der HW-ID meines Modells versehen. Telefon fraß das Update und war nach nem Reboot tot. Serielle Pins waren vorhanden, Telefon bootet bis zum Entpacken des Linux Kernels, danach hängt sich das auf, weil anderer CPU-Typ.
Der Bootloader hat noch einen Recovery-Teil an Bord, hierzu will mir der Hersteller aber das notwendige Tool nicht rausrücken.
Mein Flash hat immer 2 Firmware-Stände "im Bauch", das aktuelle aktive und das vorige, inaktiv geschaltete. Habe den Bootloader von nem 2. Telefon ausgelesen und reverse engineered um zu verstehen, wie die CRCs berechnet werden und wie das Partitionslayout aussieht. Aktuell warte ich noch auf einen TSOP48-Sockel. Werde dann den Flash IC auslöten, die aktive Partition abändern, einlöten und dann sollte das Ding wieder rennen.