Wie funktioniert eigentlich Android? – Teil 4
Im letzten Teil der Artikelreihe haben wir festgestellt, dass der Bootloader unseres Moto G3 aus irgendwelchen Gründen auch immer nicht die standardmäßigen Firmwares akzeptiert, wenn man versucht diese manuell zu flashen.
Wir erinnern uns: Beim Versuch via Fastboot die standardmäßigen Firmwares zu installieren, sind wir auf folgende Fehlermeldung gestoßen: „preflash validation failed“. Wir hatten auch geklärt was diese Fehlermeldung meldet (Lexikon-Eintrag). Die Frage die sich nun stellt ist simpel: Warum akzeptiert der Bootloader die Firmware nicht? Kurzes googeln nach exakt dieser Fehlermeldung im Bezug auf das Moto G3 liefert schon einen ersten durchaus schlüssigen Hinweis. Denn recht schnell stößt man auf Foreneinträge, welche erwähnen, dass man das Moto G3 bei gesperrtem Bootloader nicht downgraden kann.
Lexikon
Downgrade
Der Wortlaut lässt einen, wenn man weiß, was ein Upgrade ist, eigentlich schon erahnen, was hier gemeint ist. Ein UP-grade ist in unserem Kontext schließlich die Installation bzw. das Ersetzten einer älteren durch eine neuere Firmware. Ein DOWN-grade ist nun also die Installation von einer neuen hin zu einer älteren Firmware.
Nun sind Foreneintäge im Regelfall auch immer nur von Semiprofessionellen verfasst, ergo sollte man diese auch immer mit einer gewissen Vorsicht genießen und wenn möglich nach verlässlicheren Quellen suchen. Motorola ist zum Beispiel eine solche Quelle. Und wenn man auf der Supportseite für das Moto G3 nach der aktuellsten Bekanntgabe eines bevorstehenden Softwareupdates sucht, stößt man auf eine Seite wo folgender interessanter Satz geschrieben ist:
Von wann ist unsere Firmware?
Wir haben hier also die ganz offizielle Bestätigung, dass Downgrades schlicht nicht möglich sind, zumindest nicht mit einem gesperrten Bootloader. Jetzt müssten wir nur noch herausfinden, ob die Firmware Images welche wir von XDA-Developers bezogen haben ein Downgrade darstellen oder nicht. Hier kommt uns netterweise wieder Fastboot zur Hilfe. Der Befehl fastboot getvar all liefert (get) schlicht alle (all) Variablen (var) die der Bootloader auslesen kann.
Am interessanteste ist nun die Variable „kernel.version[2]“, denn diese liefert und das Datum, an dem der Kernel der Firmware kompiliert wurde. Und dieser Tag hat das Datum des 16.01.2017! Passenderweise existiert obig verlinkte Supportseite auch für ein Sicherheitsupdate aus exakt diesem Zeitraum. Es gab zu dieser Zeit also wirklich ein offizielles OTA-Update. Ergo wird dies die Firmware sein, die wir auf dem Moto G3 installiert haben.
Lexikon
Kernel
Der Kernel ist im Prinzip nichts weiter als das buchstäbliche Fundament des Betriebssystems. In ihm ist festgelegt wie Prozesse und Daten organisiert werden, wodurch es die unterste Ebene eines Betriebssystems darstellt.
Und von wann ist nun die XDA-Firmware?
Aus dem glücklichen (und zugegebenermaßen auch logischen) Zustand heraus, dass der Bootloader (welcher mit einem Systemupdate i. d. R. auch ein Update erhält) unserer Firmware Images ohne Fehlermeldung problemlos geflasht wurde, können wir nun auch nachschauen, aus welchen Zeitraum die Firmware in etwa kommt, welche wir versucht haben zu flashen. Denn im Fastboot-Modus steht ebenfalls das Datum, an dem Der Bootloader das erste mal auf einem Gerät bzw. Datenträger geflasht wurde.
Schauen wir nun in der ersten Zeile nach finden wir folgendes Datum. 27.06.2016! Wir haben also versucht eine Firmware vom Juni 2016 auf einem Moto G3 zu flashen, auf dem eine Firmware aus dem Januar 2017 (nicht) läuft. Wir sind also folgerichtigerweise daran gescheitert ein Downgrade durchzuführen. Sucht man nun nach aktuelleren Firmware Images im Internet, wird man leider nicht fündig und wenn man den Motorola Support um Herausgabe entsprechend aktuellerer Firmware Images bittet, bittet dieser einen schlicht, das Gerät einzuschicken. Wir bekommen also schlicht keine neuere Firmware.
Back to the Root (-Verzeichnis)
Gehen wir also zurück zur Ausgangssituation, der ersten auftauchenden Fehlermeldung als wir ganz zu Anfang versucht haben den Bootloader zu entsperren. Dort haben wir gesagt bekommen, dass wir doch bitte die Option „OEM-Entsperrung zulassen“ aktivieren sollen. Nun stellt sich die frage ob man den händischen „Klick“ in den Entwicklereinstellungen auch irgendwie auf anderem, komandozeilenmäßigerem Weg tätigen kann? Hätten wir nämlich die OEM-Entsperrung erlaubt, wäre das Problem quasi gelöst.
Wenn man sich nun also sehr lange und größtenteils sehr planlos durch den Quellcode und den jeweiligen Partitionen von Android wühlt findet man irgendwann in der Git Repository für Android eine Java-Datei mit dem vielsagenden Namen „PersistentDataBlockService.java„. Wühlt man sich nun ebenfalls durch diesen Code – und mit Wühlen meine ich die Seite mittels Strg+F nach dem Schlagwort „OEM“ durchsuchen lassen – so wird man schließlich ab der Zeile 307ff. fündig. In den folgenden für den normalsterblichen Menschen unverständlichen Zeilen Code ist geregelt, was es mit dieser „OEM-Entsperrung zulassen“-Einstellung auf sich hat. Konkret schreibt dieses Schnipselchen Code schlicht einen Byte in eine der – man hätte es sich auch nur fast denken können – im Root-Verzeichnis von Android liegenden Partitionen.
Lexikon
Root-Verzeichnis
Das Root- oder Stammverzeichnis eines Betriebssystems ist schlicht die oberste Ebene des Dateisystems eines Betriebssystems. Dort sind alle für das Funktionieren des Betriebssystems relevanten Dateien gespeichert. Würde man an diesen Dateien bspw. etwas ändern oder diese auch nur auslesen wollen, so benötigt man einen Kernel, der dem Nutzer die dafür nötigen Zugangs-, Lese- und Schreibechte gibt um auf diesen Teil des Dateisystems effektiv zugreifen zu können. Man benötigt also die viel besagten Root-Rechte. Der Kernel agiert nun als Schloss wobei die Root-Rechte der Schlüssel sind.
Für das Vorhaben uns diese Einstellung per Tastatur zu erlauben stoßen wir nun also auf gleich zwei Hürden. Hürde Nummer eins wären schlicht die fehlenden Root-Rechte, da die Firmware ja noch im völligen Originalzustand ist. Problem Nummer zwei wäre jedoch auch nicht aus der Welt geschaffen, wenn Root-Rechte von Anfang an gegeben wären. Denn wir können unser Smartphone nur in den Fastboot- bzw. Recovery-Modus starten. Von dort aus hat man aber keinen Zugriff auf die Android Debug Bridge (ADB) geschweige denn die Android Kommandozeile (Shell).
Andere in den Kopf schießende Ideen zur Problemlösung müssen also wieder am Bootloader und der Sache mit dem Downgrading ansetzten. Im Prinzip gäbe es zwei Möglichkeiten. Entweder man verändert die Android Firmwareimages und die darin wahrscheinlich irgendwo enthaltenen Datumsstempel so, dass der Bootloader denkt, es handele sich wieder um ein Upgrade, oder man verändert schlicht den Bootloader und entsperrt ihn, wenn man so will, mit Gewalt. Dazu aber mehr in Teil fünf!