Wenn der mitgelieferte Updater nicht funktioniert...

  • ... dann muss man sich halt selber einen basteln 8)


    Vorhin hatte ich ein Stündchen Zeit, dabei ist das hier herausgekommen:
    [Blockierte Grafik: https://drive.google.com/file/d/0Bw-uKAR6CDhHdnRXUExpZlR5TEU/edit?usp=sharing]
    Hm, an dieser Stelle wollte ich eigentlich einen Screen einbetten, das scheint aber nicht zu funktionieren...


    Müsst ihr bei Interesse also den Link manuell verfolgen.


    Im ersten Absatz wird geprüft, ob Gerät/System/Onlinestatus für ein Update überhaupt geeignet ist.


    Im zweiten Absatz käme der Seitenbetreiber ins Spiel, die App muss ja irgendwie herausfinden, welche Version aktuell auf der Seite zum Download angeboten wird.
    Da das mit dem mitgelieferten Updater früher mal funktioniert hat, sollte die Infrastruktur dafür aber eigentlich bereits vorhanden sein und ich bräuchte nur eine Doku
    8)


    Die App würde die entsprechende .zip Datei dann herunterladen (als update.zip) und in der minimalversion anschließend bei Klick auf entsprechenden Button ins revoery booten, wo mandann nur noch "install update.zip" auswählt und dann fertig ist.
    Allerdings besteht noch die Chance, das auch dies automatisch erledigt werden kann, offenbar kann man Kommandos ans recovery übergeben (an alle? welche?), und wenn ich dazu eine Doku auftreiben kann, dann würde der Vorgang vereinfacht zu: man drückt den Knopf, das Gerät bootet, installiert und startet dann mit der neusten Version :)
    Beim Auftreiben der (englischen) Dokus nehme ich gerne Hilfe an ;)


    Die fertige App würde ich hier selbstverständlich kostenlos zum Download bereitstellen.


    Fragen also:
    1. Besteht daran seitens der Mitleser überhaupt Interesse?
    2. Besteht seitens des Forenbetreibers Interesse? Ohne den (bzw. die Bereitstellung der Versionsdaten) müsste ein Interpeter für die Downloadseite her, und das wäre mir im Moment zu aufwendig)
    3. Als "normale" App werden beim Klick auf "reboot" root Rechte angefordert; da das sicher einige abgeschaltet haben, könnte das problematisch sein - bei meinem Test erschien eine entsprechende Box mit OK/Abbruch, bei OK passierte aber nix.
    Daher wäre es vielleicht sinnvoll, die App nach Fertigstellung ins ROM aufzunehmen, wodurch bestimmt die Möglichkeit eröffnet wird, das sie automatisch root Rechte hat und den Anwender nicht belästigt.
    In diesem Fall würde ich selbstverständlich den Sourcecode zur Verfügung stellen damit zweifelsfrei verifiziert werden kann, das mit der App alles seine Ordnung hat.



    ...und jetzt kommt ihr ;)

  • Mit andy hatte ich letzte Tage schon wegen einer ähnlichen Thematik Kontakt, auf meinen Konzeptvorschlag hat er sich dann aber nicht mehr gemeldet - was immer das bedeuten mag :whistling:


    Gibt auch schon ein Update zum recovery: wenn unsere Version auf der von Android beruht (da habe ich gerade in den Source geschaut), dann kann die Installation des Update vollständig automatisiert werden :D


    Damit wären wir dem vorinstallierten Updater dann funktional ebenbürtig - nur das unserer tatsächlich funktioniert 8)

  • Zitat

    Interesse besteht.


    Prima, ich hatte schon angefangen über Plan-B nachzudenken ;-)

    Zitat

    Hier ist die Source vom Mi-Recovery

    Danke, und ja, der ist unzweifelhaft von Googles Code "abgeleitet", d.h. wenn die Entwickler es nicht irgendwo im Detail verbockt haben, dann bekommen wir eine vollautomatische Installation hin.
    Allerdings gehe ich davon aus, das der vorinstallierte Updater bei der Installation ebenfalls so vorgeht, daher bin ich recht zuversichtlich.



    Zitat

    Doku über die Infrastruktur werde ich dir die Tage zukommen lassen

    OK.


    Wäre das neu zu machen, dann wäre das hier mein Plan gewesen:
    - App ermittelt Gerätenamen vom System (Beispiel: "MI 3W")
    - App übermittelt diesen per URL an diese Seite, etwa "http://miui-germany.de/version.php?MI-3W"
    - Server liefert aktuell bereitstehende Versionsnummer als Antwort ("4.6.27"), oder einen leeren String, falls das Gerät nicht supportet wird
    - App vergleicht diesen Wert mit der vom System erfragten Versionsnummer
    - App fordert ggf Download vom Server an, etwa "http://miui-germany.de/download.php?MI-3W"
    - Server liefert die .zip als Antwort


    So könnten wir das ganze leicht auf alle unterstützten Geräte ans Laufen bekommen, und es bräuchte kein Update, wenn neue Geräte hinzukommen.


    Aber wenn ihr schon was fertiges habt, dann lass uns das erstmal anschauen, wäre ja weniger Arbeit für euch.

  • Zwischenbericht FirmwareUpdate App:


    - die üblichen Tests sind alle implementiert
    -- MIUI installiert
    -- Device wird unterstützt
    -- Gerät ist online (WLAN oder nach Bestätigung des Anwenders auch Funkturm)
    -- Akku > 50% oder ladend
    - Download funktioniert
    -- derzeit mit der Plan-B Methode (download-v5.php?device=16)
    -- Portrait, Screen-Lock
    - Reboot ins Recovery funktioniert (root)
    - Recovery erkennt, das ein Update installiert werden soll (laut Logfile)


    Leider wird die Installation dann aber nicht durchgeführt...
    Stattdessen erscheint das übliche Menü, im Hintergrund kann man das Android-Männchen zusammen mit einem Dreieck erkennen;
    Jedoch werden keine Hinweise geliefert, warum die Installation fehlschlug, was vermutlich daran liegt:

    Code
    "can't open /dev/tty0: No such file or directory"


    Der relevante Ausschnitt aus dem Log:

    Code
    ...
    I:Update location: /sdcard/MIUI-GER-MI-3W-4.7.4.zip
    I:Saving locale "de_DE"
    void ScreenRecoveryUI::draw_screenview_locked(screenview*): scr->child_count=0
    virtual void ScreenRecoveryUI::StartGraphicMenu(const char*, int): menu id <menu_choose_language>
    ...



    Im Source des MI-Recovery sind wir also hier:




    1: zeichnet wohl das Android-Männchen (nicht überprüft)
    2: nirgends zu sehen (ui_print ist ein define für printf(), was wohl auf /dev/tty0 ausgeben möchte und damit obige Fehlermeldung verursacht)
    3: Die Ausgabe im Log (LOGI ist ein define für fprintf(stdout) und stdout wird via freopen() aufs Logfile umgelenkt)
    4: schlauerweise ist LOGE ein define für ui_print, siehe 2:


    Mit anderen Worten kann ich ohne selber gebasteltes Recovery nicht herausfinden, was das Problem bei der Installation ist :-/
    - das /sdcard nicht gemounted ist, halte ich nicht für wahrscheinlich, da ich ein "/sdcard/update.zip" manuell im Recovery installieren könnte
    - das mit dem .zip etwas nicht stimmt ist ebenfalls unwahrscheinlich, denn via Updater verlief die Installation problemlos



    Hier sind also die Flash-Erfahrenen Mitleser gefragt:
    was könnte da schief gehen bzw. was kann ich tun um das Problem einzugrenzen?

  • ...und noch ein Update...


    Es scheint so zu sein, das "/sdcard" erst gemounted wird, wenn man im Recovery "install update.zip" wählt;
    also habe ich meinen Code so erweitert, das die heruntergeladene Datei zunächst in die /cache Partition kopiert wird, die muss ja zugänglich sein, weil da auch die Kommandosequenz hinterlegt wird.


    Tatsächlich ergibt sich daraus auch ein geändertes Log: (Zeilen beginnend mit "--" sind von mir als Kommentar eingefügt worden)

    Code
    -- Datei liegt nicht mehr auf /sdcard, sondern auf /cache
    I:Update location: /cache/u.zip
    -- die nächsten 3 Zeilen sind neu und warten auf eine Interpretation
    I:read key e=3 hash=20
    I:1 key(s) loaded from /res/keys
    I:verify_file returned 1
    -- ab hier kommt wieder das, was immer im Log steht...
    I:Saving locale "de_DE"
    void ScreenRecoveryUI::draw_screenview_locked(screenview*): scr->child_count=0
    virtual void ScreenRecoveryUI::StartGraphicMenu(const char*, int): menu id <menu_choose_language>


    Kann das jemand erklären?


    Ich wollte jetzt eigentlich nicht erst zum Kernel-Hacker werden müssen, um diese App fertigstellen zu können, insbesondere vor dem Hintergrund, dass sich das Interesse an einer Lösung hier im Forum ja doch stark in Grenzen hält.

  • Danke, aber Hilfe beim Programmieren brauche ich eigentlich nicht, eher Hilfe beim Interpretieren der Meldungen...
    Ich hätte eigentlich gedacht, das hier viele Flash-Erfahrene unterwegs sind, die mit solchen Meldungen etwas anfangen können, oder gar welche, die vielleicht schon selber an irgendwelchen Custom-ROMs gebastelt haben, aber da habe ich mich wohl geirrt.

  • ich könntd des an jemanden weiterleiten, falls das was bringen kann? grad kurz ne pm an mich schicken dann wirds erledigt. kann aber bisschen dauern

    Xiaomi 12 Pro ~New Love<3
    Mi3 <3, Mi5 Pro & Mi9 8/128~ <3 Four Big Loves ~ soooo happy and grateful ~ <3

  • Code
    I:Update location: /cache/u.zip
    -- die nächsten 3 Zeilen sind neu und warten auf eine Interpretation
    I:read key e=3 hash=20
    I:1 key(s) loaded from /res/keys
    I:verify_file returned 1


    1. Wird die Datei /cache/u.zip gefunden.
    2. Kommentar
    3. Wird ein Hash berechnet. Das Ergebnis wird ausgegeben (Hash == 20)
    4. Hier wird eine Datei geladen die erwartete (fixe???) Hashwerte enthält. (in dem Fall sollte der Hash == 3 (e(expected)=3) sein. Aber der Hash der Datei u.zip ergibt 20. (Ich könnte mir jetzt den Sourcecode angucken, wie der Hash berechnet wird, habe dazu derzeit aber keine Zeit. Vielleicht morgen.)
    5. Weil der Hash nicht passt, wird 1 statt 0 returned.
    Würde der Hash passen, würde 0 returned und alles wäre schick. (C++ basics) 1 löst hier offensichtlich einen break aus.


    Aufgabe: Hash-Algorithmus finden, verstehen, anpassen.


    Vermutung: Ein Hash Wert von 3 wird erwartet, einer von 20 berechnet - viel kann hier nicht passieren. Evtl. reicht schon der Dateiname um diese Abweichung zu erzeugen. Ich will mich an dieser Stelle nicht zu weit aus dem Fenster lehnen - auch weil ein Hash eigentlich eine fixe Länge hat, was hier offensichtlich nicht der Fall ist.



    Anmerkung: Das Interesse ist meinerseits schon vorhanden. Leider habe ich den Thread bisher übersehen. Die Struktur des Forums von MIUI Germany ist eben nicht die optimalste. ;(



    Trotzdem DANKE! für dein Engagement.

  • Zu prüfen wäre auch, warum 3 gefordert wird, bevor /res/keys überhaupt geladen wird. Hardcoded?
    Das kann aber auch ein log-fault sein.


    Für mich logisch wäre:


    - Update Datei finden
    - Update Datei hashen, Ergebnis speichern
    - Erwartete Hashes laden
    - Vergleichen


    Die Frage ist nun: Wenn die 3 als Hash fix ist, die Datei /res/keys vor dem Update gelesen wird.... woher kommt diese Datei, was steht darin?
    Ein Hash abgleich ist IMHO an dieser Stelle zwecklos - wenn der hash den INHALT des Updates darstellt.
    Zwei möglichkeiten: 1. Der Hash ist sinnlos.
    2. Der Hash dient nur einer nicht variablen Überprüfung. Also einer Konstante wie bsp. weise des Dateinamens.

  • Danke für die Beiträge.
    Das hat mich zu mehr Recherche motiviert und der Stand ist nun:


    Wenn die Log-Ausgaben vom mi-revovery vollständig wären, dann würden sie wohl so aussehen:

    Code
    Finding update package…
    I:Update location: /cache/u.zip
    Opening update package…
    I:1 key(s) loaded from /res/keys
    Verifying update package…
    I:verify_file returned 1
    E:signature verification failed
    Installation aborted.


    Die These wäre dann: bei manueller Installation im recovery, und offenbar auch bei Installation mittels "updater" wird demnach ein anderer Key verwendet als bei automatischer Installation via recovery.
    Der der Sourcecode vom mi-recovery keine Anzeichen einer Option zum Bestimmen des Keys (oder zum Abschalten des verify) zeigt (genau so wenig wie eine Option zur Bestimmung des Installations-Ziels, also System1 oder System 2), sind wir mMn an dieser Stelle am Ende, es sei denn der Hersteller der ROMs könnte einen passenden Key zum Signieren des .zip verwenden (welcher auch immer das dann sein mag).


    Mag jemand diese These widerlegen? Würde mich freuen ;)


    Mquadrat: jo, die "hash" Zeile kommt mir auch seltsam vor, keine Ahnung was die bedeuten könnte...
    Tatsächlich kommt die nicht mal aus dem Recovery (zumindest nicht aus dem Stand, vom dem ich den Source habe), so das keinerlei Basis für eine Interpretation vorliegt.

  • Zitat


    3. Wird ein Hash berechnet. Das Ergebnis wird ausgegeben (Hash == 20)
    4. Hier wird eine Datei geladen die erwartete (fixe???) Hashwerte enthält. (in dem Fall sollte der Hash == 3 (e(expected)=3) sein. Aber der Hash der Datei u.zip ergibt 20


    Hm, wenn der Hash tatsächlich "falsch" wäre, warum lassen sich die .zip dann via Updater und manuell via recovery installieren?
    Weil diese Prüfung dort nicht durchgeführt wird?


    Zitat

    Aufgabe: Hash-Algorithmus finden, verstehen, anpassen.


    Das wäre dann die Aufgabe des ROM-Erstellers, oder wie meinst du das jetzt?

  • Super. Danke für das Log.


    Das bestätigt meine Vermutung:

    Code
    Verifying update package…
    I:verify_file returned 1


    Was passiert hier?
    Der Quellcode der diese results ausgibt wäre sicher hilfreich.
    Fakt ist, dass ein hash-check fehlschlägt. Nun ist die Frage: Was wird gehasht? Woher stammt der erwartete Wert?


    Da praktisch jedes neue Update einen anderen Hash hat, kann an dieser Stelle kein Hashing auf den Inhalt stattfinden. Es muss etwas oberflächiges sein.

  • Hm, wenn der Hash tatsächlich "falsch" wäre, warum lassen sich die .zip dann via Updater und manuell via recovery installieren?
    Weil diese Prüfung dort nicht durchgeführt wird?



    Das wäre dann die Aufgabe des ROM-Erstellers, oder wie meinst du das jetzt?


    Evtl. wird eine "Quell"-Prüfung durchgeführt? Hier könnte die IP, die URL oder sonstwas des files geprüft werden.
    Ich mag solche blind-Vermutungen nicht. Ich bin aber inzwischen sicher, dass es nichts mit der Datei an sich zu tun hat.

  • Bitte entschuldigt den tripple post.


    Ich habe inzwischen schnell mal in den Quellcode geschaut.


    folgendes ist der Punkt, an welchem man ansetzen sollte:


    Datei: https://github.com/MiCode/miui…lob/master/src/verifier.c


    function: verify_file() //Welche sonst?...



    Die Frage scheint also: Wie signiert man die custom-OTA-ROM, damit diese vom MiRecovery angenommen wird? Ich denke, das könnte schwierig werden ohne die entsprechenden Zertifikate.

  • Die Roms sind mit den Standard Testkeys signiert die auch unter "/system/etc/security/otacerts.zip" zu finden sind.



    Deshalb dürfte die Signatur-Prüfung eigentlich nicht fehlschlagen.


    Alle MI-Geräte bist auf das HongMi 1 erwarten Testkeys

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!