Xirrr

Original poster
Beta Tester
8 August 2021
16
Hallo zusammen,

ich habe die Anleitung aus https://forum.shiftphones.com/threads/bootloader-unlock-root-custom-recoveries-roms.3207/ für das rooten durchgeführt und es hat alles wunderbar geklappt. Ich hatte Magisk und war Root meines Geräts mit der ShiftOS-Version "SHIFT6MQ.SOS.3.3.L.20210709"

Bei jedem Neustart kommt danach immer die Meldung, dass mein Bootloader nun "unlocked" ist und das wollte ich nun damit beheben, dass ich mit "fastboot flashing lock" den bootloader wieder schließe/lock.
Nachdem ich das tat kam beim erwarteten Neustart ein "Can´t load Andriod system. Your data may be corrupt (weiteren Text leider vergessen)" und ich kam nicht ins shiftphoneOS. Dann dachte ich ich kehre den Vorgang um und öffne/unlock mit "fastboot flashing unlock" die Situation und damit sollte es wieder tun. Leider ist das nicht der Fall.

Ich habe ab jetzt ein Gerät, dass beim hochfahren immer in "Fastboot mode" einsteigt. Egal welche settings ich auswähle in den Menü ("START" oder "Restart bootloader" oder "Recovery mode" oder "Boot to FFBM" oder "Boot to QMMI"). Der Menüpunkt "Power off" macht das was es soll und fährt das Gerät herunter.

Kann mir jemand bitte weiterhelfen? Ich bin auch bereit wieder die Stockversion usw. aufzuspielen, so dass es zumindest wieder in das shiftphoneOS startet.
 
Zuletzt bearbeitet:
Ich kann nur mit fastboot Befehle absetzen und mit "continue" kommt folgendes.

Code:
➜  ~ fastboot continue
resuming boot...
FAILED (remote: Failed to load image from partition: Load Error)
finished. total time: 0.001s
➜  ~

Weitere ausgeführte Befehle führen zum loaden in den fastboot-mode.
Code:
➜  ~ fastboot reboot bootloader         
rebooting into bootloader...
OKAY [  0.000s]
finished. total time: 0.050s
➜  ~
Code:
➜  ~ fastboot reboot emergency   
rebooting into emergency download (EDL) mode...
OKAY [  0.000s]
finished. total time: 0.050s
➜  ~
 
Ja, den Bootloader musst du entsperrt lassen, sonst greift AVB (Android Verified Boot) und blockiert den Bootvorgang, da du das Boot-Image mit Rooten verändert hast und die Checksummen und Signaturen nichtmehr übereinstimmen.

Die Warnung am Anfang lässt sich aus Sicherheitsgründen nicht ausblenden, kannst sie aber relativ schnell überspringen, indem du 2x auf den Power-Knopf drückst, wenn die Warnung angezeigt wird.
 
Danke für die Erklärung @amartinz . Vielleicht könntest du @Ene einen Disclaimer setzen, dass niemand auf die Idee kommt den Bootloader wieder zu schließen/lock? Das wäre recht hilfreich für die Community. :)
 
  • Like
Reaktionen: amartinz und danielp
Danke für die Erklärung @amartinz . Vielleicht könntest du @Ene einen Disclaimer setzen, dass niemand auf die Idee kommt den Bootloader wieder zu schließen/lock? Das wäre recht hilfreich für die Community. :)
hab ich. Wobei ich gehofft hatte, dass das schon durch den ersten Satz "ONLY PROCEED IF YOU KNOW WHAT YOU'RE DOING" abgedeckt sein sollte ;)
 
Es war tatsächlich irgendwo in dem Thread besprochen, dass man rootet und dann wieder bootloader schließt... aber das hat da auch bei denjenigen, der es dann versucht hat, nicht funktioniert. Aber so ein bisschen Hoffnung hatte ich, dass es vielleicht möglich wäre. Bei manche OnePlus-Geräte ging das, wenn ich das richtig in Erinnerung hatte. Wäre bei dem ganzen SafetyNet-Quatsch hilfreich gewesen...
 
Ist dafür nicht Magisk und diese Prüfung von Safety Net da. Bei mir wurde da immer bescheinigt das ich bestanden hab?

Am Shift 6mq war das meine ich auch gewesen.
 
Ist dafür nicht Magisk und diese Prüfung von Safety Net da. Bei mir wurde da immer bescheinigt das ich bestanden hab?

Am Shift 6mq war das meine ich auch gewesen.
Soweit ich weiß gibt es verschiedene Stufen von SafetyNet. Nie niedrigste kann Magisk umgehen (Magisk Hide), die verbesserten Varianten nutzen Hardware Attestation, prüfen also auch ob etwa der Bootloader entsperrt ist. Das kann man zum Teil mit Magisk Modulen umgehen aber nicht bei allen Implementierungen. Welche SafteNet Stufe eine App vorraussetzt ist dem App Entwickler überlassen.
 
Also wenn ich das richtig verstehe, gibt es im Prinzip zwei Niveaus: Basic (ohne Hardware Attestation), und das volle (mit Hardware Attestation). Die Hardware Attestation an sich kann man nicht nachmachen, allerdings ist es in der Regel möglich, die Hardware Attestation umzugehen, um trotzdem das volle SafetyNet-Niveau zu erreichen. Ich hab bisher relativ erfolgreich diese Anleitung verwendet.
 
In einem Blackout - fragt bitte nicht warum :cry: - habe ich den Bootloader gelockt. Jetzt bin ich in dem von k.bartha oben beschriebenen Bootloop, das Gerät startet ewig in den FastBoot Mode. Ihre Lösung per "fastboot boot" die Recovery.img des 6mq zu flashen, hat leider mit dem Hinweis: "Fastboot boot command is not available in locked device" nicht funktioniert. Gibt es Abhilfe?
 
Bootloader wieder öffnen, letztes Shift-Image in beiden Slots installieren um die Grundstruktur wieder herzustellen (oder den Bootloader einfach offen lassen) und Bootloader wieder schließen. Da du den Bootloader bereits vorher geschlossen hast, verlierst du durch die Aktion keine Daten mehr...die sind schon durch die vorhergehende Aktion gelöscht worden 😔.
Sorry dafür.
Greetz
 
Danke für Deine Hilfe! Der Versuch, das Phone per fastboot zu unlocken, gibt die Fehlermeldung, dass der Befehl "not allowed" ist und wenn ich den Recovery Mode starten will, startet er nur wieder ins Fastboot Menü, aus dem ich nicht raus komme.
 
Das hört sich nicht so gut an.
Mit ein bisschen Glück lässt sich das über den "Emergency Download Mode" (EDL) wieder richten. Ein spezieller Modus nur für Qualcolm-Geräte.
Dafür braucht man allerdings auch eine entsprechende "Firehose"-Datei.

Ich sehen hier zwei Möglichkeiten.
Entweder a) einschicken oder b) mal nett beim ShiftStaff fragen, ob die diese Datei zur Verfügung stellen können. Dann könnte man das ggfs selbst machen.
Hab die Datei jetzt bei meinen Recherchen nicht gefunden.
Mehr fällt mir jetzt bei geschlossenem Bootloader der nicht mehr zu öffnen geht auch nicht mehr ein.
Greetz
 
Zuletzt bearbeitet:
  • Like
Reaktionen: jefla
Ja, danke für Deinen Beistand, einschicken ist meine Präferenz. Ich habe mit Try and Error schon ausreichend Schaden angerichtet. :cry:
(Und in der smartphonefreien Zeit gilt die Devise: "There is no greater gift for you today than the next 24 hours. Use them wisely, people are more important than machines.")
 
  • Like
Reaktionen: @Lhotze
Nur nochmal so. Seh ich das richtig? Ohne Root (Magisk) kann (darf sollte) ich den Bootloader wieder schliessen. Gerootet auf keinen Fall?
 
Seh ich das richtig? Ohne Root (Magisk) kann (darf sollte) ich den Bootloader wieder schliessen. Gerootet auf keinen Fall?
Der Bootloader sollte unter keinen Umständen geschlossen werden, wenn irgendwelche Veränderung am System vorgenommen wurden. Das beinhaltet: Kernel, Recovery oder System.
Root manipuliert Kernel, Custom-Rom manipuliert Kernel, Recovery und System und TWRP bspw. manipuliert das Recovery.

Ein Sicherheitsmechanismus von Android ist es, die Systemintegrität zu Prüfen. Passt der Kernel und das Recovery zum System und ist dieses verifiziert?
Ist das nicht der Fall, startet das System nicht mehr. Im schlimmsten Fall nicht mal mehr ins Recovery.

Bei @jefla ist durch das schließen des Bootloaders die gesamte Datenpartition gelöscht worden. Damit ist die OEM-Entsperrung, die man in den Entwickleroptionen zum öffnen des Bootloaders aktivieren muss zurückgesetzt. Wenn das System startet könnte man das wieder aktivieren und den Bootloader neu entsperren.
Geht aber nicht, da wahrscheinlich noch Magisk im Kernel installiert ist.
Mit geschlossenem Bootloader lässt sich allerdings kein, werksseitiger Kernel installieren.
Bliebe nur noch das Recovery. Das startet aber nicht (keine Ahnung warum). Über das könnte man das reguläre Firmware-Image installieren um den Fehler zwischen Kernel ≠ System auszugleichen.
Aktuell ist das Shift ein Backstein. Kann nix, geht nix.
Über das Emergency Interface könnte jetzt noch das System notinstalliert werden. Dafür braucht es aber (Smartphonetyp-individuell) eine extra Initialisierungsdatei. Soll aber niemand einfach so machen können, wäre ja blöd wenn diese Dateien öffentliche sind, kann dann ja jeder bspw ein geklautes Gerät zurücksetzen und komplett neu Auflegen. Das soll erschwert sein. Deswegen ist diese Datei auch normalerweise nirgendwo zu finden und sollte den Fachstellen vorbehalten sein. Manchmal leakt so eine Datei, dann kann man so nen Hard-Brick tatsächlich selbst ausbügeln. Spricht also eigentlich für Shift, dass die Datei nicht verfügbar ist. Eure Geräte (und Daten) sind so sicherer im Falle eines Abhandenkommens.
Greetz
 
Herzlichen Dank @Lohtze für die Erklärung!
Ich muss an dieser Stelle ein ganz dickes Lob für den Service von Shiftphone aussprechen. Am Montag Abend habe ich das gebrickte Smartphone eingeschickt, am Freitag habe ich ein Austauschgerät erhalten. Chapeau! (y)(y)(y)