Magisk über Patchen der boot.img ohne Odin und fastboot installieren

[MarkF]

Ich beschreibe nachfolgend einen Weg, wie man über das TWRP-backup eine z.B. durch den Magisk-Manager gepatchte) boot.img flashen kann, wenn warum auch immer ein flash weder über Odin noch über fastboot möglich ist/funktioniert. Durchgeführt habe ich es mit einem GT-i9001, aber es sollte eigentlich bei allen Geräten funktionieren.

Ich verzweifele seit über einer Woche an dem Problem, Magisk auf einem GT-i9001 unter LineageOS 14.1 (7.1.2) mit installiertem TWRP 2.8.1.0 zu installieren. Ziel war es, den Root vor der DKB-Tan2Go-App zu verstecken, da diese App unter dem originalen 2.3.6 nicht läuft, wenigstens 4.4 fordert (das es für das Gerät aber nicht gibt), und auch unter keinem der getesteten Custom-OS laufen mag.

Das Problem war, daß
- einerseits der Magisk-Manager das System bzw. boot-image von LineageOS 14.1/TWRP 2.8.1.0 nicht patcht - Abbruch mit Fehler
- andererseits es ums Verrecken nicht möglich war, mit Odin (4.4.3) die aus dem LineageOS entnommene und mit dem Magisk-Manager gepatchte boot.img ins Gerät zu flashen: Die "Konvertierung" in eine .tar-Datei hat zwar funktioniert (7zip, lz4, tar), aber in die Box PDA (früher wohl AP) geladen führt - übrigens bei allen .tar-Files, auch dem über BOOT (BL) problemlos flashbaren bootloader - es zur Fehlermeldung, daß die Datei ungültig sei ("invalid image type"). Das Gerät selbst wird von Odin im Download-Modus erkannt, z.B. bootloader.tar läßt sich auch flashen (mußte ich nach der ersten Installation von TWRP auch durchführen) und in eine andere Box geladen, z.B. BOOT, wird auch die boot.img.tar-Datei akzeptiert
- und schließlich fastboot das Gerät im Download-Modus nicht erkennt - Odin erkennt es aber! Egal was ich tue, welches Kabel, welcher USB-Port, welcher PC, welche Treiber ich Win7 aufzwänge - im Gerätemanager erscheint es im Download-Modus nur als "Samsung USB Composite Device" (ebenso auch im laufenden Zustand), nicht aber irgendwie als Android- oder Samsung-bootloader- oder ADB-Gerät, wie es wohl sein soll und auch bei anderen Geräten der Fall ist. Anscheinend wird ein dafür erforderlicher Treiber nicht installiert, keiner der nicht wenigen, wenn auch überschaubaren Tricks, mit denen das angeblich gehen soll, hat funktioniert.
Dies alles getestet mit zwei der i9001.

Als einzig verbleibende Möglichkeit, dem Gerät ein gepatchtes boot.img unterzuschieben, habe ich den Mißbrauch der Backup-Funktion von TWRP gesehen. Da angeblich die damit gespeicherte Datei boot.emmc.win identisch sei mit boot.img (was aber jedenfalls insgesamt, als Datei betrachtet, nicht stimmt, denn die boot.img aus z.B. dem lineageOS14.1-.zip ist anders und kleiner als die entsprechende durch TWRP als backup hergestellte boot.emmc.win) und einfach in boot.img umbenannt als boot-image geflasht werden könne, kam mir der Gedanke, diese boot.emmc.win zu patchen und restoren. Schlimmstenfalls bootet das Gerät damm nicht mehr und ich müßte dann die originale boot.emmc.win drüberflashen - und überhaupt, Versuch macht klug.
Also habe ich ein isoliertes backup der boot-partition hergestellt und dessen boot.emmc.win in boot.emmc.win.img unbenannt dem Magisk-Maganer zum Patchen vorgesetzt. Der hat das auch willig entgegengenommen und ohne Gemecker gepatched. Das Ergebnis habe ich wieder in boot.emmc.win umbenannt und davon den md5-hash erzeugt. Diesen habe ich in die boot.emmc.win.md5 aus dem backup eingefügt und das ganze in eine entsprechend umbenannte Kopie des Ordners des isolierten boot-backups kopiert. Damit wiederum habe ich über TWRP einen Restore durchgeführt und einen Neustart veranlaßt.
Und ... das Gerät fährt anstandslos hoch. Nicht nur dies. Der Magisk-Manager erkennt auch, daß Magisk installiert wurde, und bietet auch die Hide-Option an. Die klandestine boot-image-flash-Operation mit dem gepatchten boot.img bzw. boot.emmc.win war also erfolgreich. Magisk läßt - oder zumindest ließ - sich auch in diesem hartnäckigen Fall installieren.

Allein es bleibt der Wermutstropfen, daß ich mein Ziel dennoch nicht erreicht habe. Trotz des eingestellten Versteckens des Roots vor z.B. der DKB-TAN2Go- und der Postbank-BestSign-Apps erkennen diese den Root dennoch. Die DKB-Apps bricht ab und BestSign warnt vor dem Root. Die ganze Arbeit für die Katz ...

 

[rudolf]

Die boot.img aus dem lineeage zip ist in ihrer gesamten Länge identisch mit der boot.emmc aus dem backup. Das TWRP weiss aber nicht wie gross die boot.img ist, also wird die gesamte bootpartition gesichert. Daher ist das backup grösser.

Neuere TWRP können übrigends boot images flashen, dieser Umweg ist nur nötig wenn man nur ein sehr altes TWRP zur verfügung hat.

 

[MarkF]

Die boot.img aus dem lineeage zip ist in ihrer gesamten Länge identisch mit der boot.emmc aus dem backup. Das TWRP weiss aber nicht wie gross die boot.img ist, also wird die gesamte bootpartition gesichert. Daher ist das backup grösser.

Aha. So, wie Du es formulierst, ist das aber nicht der Fall. Die Datei boot.emmc.win ist definitiv größer als und nicht identisch mit boot.img aus dem lineageOS-zip. Zweifellos ist es so, daß die boot.img komplett in boot.emmc.win enthalten ist. Aber die Dateien sind eben nicht identisch. Vielleicht kann man auch die "überlüssigen" Teile irgendwie entfernen. Aber das ändert nichts daran, daß boot.img und das TWRP-backup der Bootpartition - die Datei boot.emmc.win - eben nicht identisch sind. Ich weiß zwar nicht, warum der workaround mit dem Patchen des Backups der Bootpartition dennoch funktioniert (ich weiß ja nicht einmal, was dabei gepatched wird), aber anscheinend ist der Magisk Manager sehr clever programmiert, so daß die relevanten Teile von boot.img erkannt und gepatcht werden. Aber was man nicht machen könnte wäre, das Backup der Bootpartition anderweitig als Ersatz für eine verlorengegangene boot.img zu verwenden - was die Behauptung, boot.emmc.win sei identisch mit boot.img, suggeriert.

Neuere TWRP können übrigends boot images flashen, dieser Umweg ist nur nötig wenn man nur ein sehr altes TWRP zur verfügung hat.

Ja, das hatte ich auch gelernt/erfahren, aber leider gibt es für das fragliche Gerät GT-i9001 keine neuere TWRP als die Version 2.8.1.0., und so war mir auch dieser einfache Weg versperrt. Insofern wird dieser workaround wohl nur für ähnlich ältere Geräte erforderlich sein.

 

[rudolf]

"12345" ist in “x12345x“ zwar vollständig enthalten, aber nur "12345“ und “12345xx“ sind in der Länge von “12345“ identisch.
Hätte also das Backup nicht nur am Ende sondern auch am Anfang zusätzlich Bytes, dann würde das nicht funktionieren.

 

[MarkF]

Ich weiß nicht, ob boot.img am Anfang von boot.emmc.win steht. Und ich weiß auch nicht, wie der Dateipatcher von Magisk programmiert ist. Vielleicht erwartet der überhaupt keinen "gültigen" boot.img-Beginn des Files sondern sucht innerhalb der angebotenen Datei nur nach einem unveränderlich gleichen Code .... Sollte aber wirklich boot.emmc.win vom Beginn an über die Länge von boot.img mit boot.img identisch und der Magisk-Dateipatcher (nur) eine solcherart beginnende boot.img-Datei erwarten, dann wäre dies die Erklärung dafür, warum dieser workaround funktioniert.

 

[rudolf]

Ich sagte ja, über die (kürzere) Länge von img sind img und emmc identisch. Der Entwickler von Magisk weiss auch das es beides gibt, entweder nur das was zum img gehört, oder halt das Abbild der boot Partition, also img plus datenmüll bis hin zur Partitionsgrösse. Und bearbeitet schlauerweise beides. Es ist auch nicht verwunderlich, dass einer der dermassen schlau ist um Magisk zu programmieren auch schlau genug ist, beide Möglichkeiten zu berücksichtigen
Ich hoffe du verstehst jetzt was ich meine. Wenn einer sich so durchkämpft wie du, dann erkenne ich das auch mit geduld an.
[doublepost=1563975291,1563975208][/doublepost]

Ich weiß nicht, ob boot.img am Anfang von boot.emmc.win steht.

Genauso ist es.

 

[MarkF]

Danke für die Geduld, aber ich habe nach Deinem zweiten Post (das erste war mißverständlich formuliert) verstanden, was Du meinst. Ich kann lediglich nicht beurteilen, ob Deine "es ist so und so"-Darstellung zutreffend ist und sehe Deine Vermutung bzw. sichere Annahme hinsichtlich der Programmierung des Magisk-Dateipatchers keineswegs als zwingend kann. Seit nahezu 40 Jahren erlebe ich Auslassungen, Fehler, Nicht- und Fehlfunktion bei Software, die nach dieser Logik niemals geschehen dürften. Da m.W. in der Dokumentation von Magisk nicht darauf hingewiesen wird, daß man auch die boot.emmc.win verwenden kann, erscheint es mir plausibler, da dieses workaround nicht im Fokus des Programmierers stand.
Aber das ist letztlich auch egal. Es funktioniert und dies ist entscheidend.

 

[rudolf]

Warum vergleichst du nicht beide Dateien mit diff, fc oder ähnlichem? Irgendwie machst du es dir schwer.

 

[MarkF]

Jetzt verstehe ich nicht mehr, worauf Du hinaus willst. Mir ist eigentlich ziemlich egal, ob boot.emmc.win und boot.img am Anfang, in der Mitte oder am Ende übereinstimmen und/oder ob der Programmierer des Magisk-Patchers auch das Patchen der boot.emmc.win abdecken wollte. Ich habe es auf gut Glück ausprobiert, es funktioniert und das habe ich hier als Handreichung für alle anderen mit einem ähnlichen Problem geschildert.
Deine Erklärung für den (Größen)Unterschied zwischen boot.emmc.win und boot.img habe ich zur Kenntnis genommen und gespeichert, falls es mal wichtig werden sollte, aber da es für mich jetzt nicht wichtig ist sehe ich davon ab, dies zu überprüfen. Und über die Programmierung des Magisk-Patchers kann man ohnehin nur spekulieren ....
Ich habe eigentlich überhaupt kein Interesse an dieser Smartphone-Manipuliererei, das hat sich leider nur als Notwendigkeit ergeben, das mag vielleicht erklären, warum ich dem nicht weiter nachgehe.