Nach Löschen der locksettings.db u.a. keine Entschlüsselung der /data mehr

[Daytrader147]

Hallo liebes Forum,
habe diesen Thread schon unter Forum -> Betriebssysteme & Apps -> Android Allgemein -> Allgemeines zu Root, Kernel und Custom-ROMs erstellt, hier nochmal im REDMI-Forum, weil es mir echt wichtig ist. Hoffe, das ist in Ordnung, sonst bitte kurze Nachricht, dann lösche ich einen Thread wieder.
(/data wird nicht entschlüsselt -> keymaster Fehler? (Allgemeines zum Custom-Recovery))

Meine Tochter hat das Entsperr-Muster ihres Handys verändert und anschließend wieder vergessen....
Um wieder ins Telefon zu kommen habe ich die Files locksettings.db, locksettings.db-shm, locksettings.db-wal, gatekeeper.password.key, gatekeeper.pattern.key and vielleicht noch andere *.keys erst umbenannt und anchließend gelöscht. Führte zum Zugriff aufs Telefon - startet wieder,
aber auch zum Verlust des Zugriffs auf die Partition /daten (verschlüsselt). Damit startet zwar das MIUI aber nicht die einzelne App. Wenn überhaupt, kommt die Nachricht "Vor dem Ausführen von Apps warten ,bis das Gerät vollständig neu gestartet ist". Nur einige wenige Punkte der Einstellungen sind aufrufbar...
Selbstverständlich gibt es kein Backup für die Bilder der letzten 3 Jahre!

Habe schon viel versucht (neues ROM, altes ROM, anderes FW eingespielt -meist Bootloop in's original-Recovery, verschiedene Versionen von TWRP und OrangeFox per ADB gestartet, ....) kein Erfolg. Möchte auf keinen Fall WIPEN oder FORMATieren, vielleicht hat einer in der nächsten Zeit noch eine Idee für mich...

Was mich stutzig macht, ist, wenn ich die oben genannten Daten gelöscht oder auch die Sperrmuster abgeschalten habe, fragt TWRP in den aktuellen Versionen immer noch nach einem Passwort. Gibt es hier noch eine Datei, die ich übersehen habe, auf die TWRP zum decrypten zugreift?

Meine RECOVERY.LOG habe ich beigefügt, 2 Stellen scheinen ein Fehler zu sein, kenne mich hier aber leider nicht ausreichend aus:

I:File Based Encryption is present​

e4crypt_initialize_global_de​

Determining wrapped-key support for /data​

fbe.data.wrappedkey = false​

calling retrieveAndInstallKey​

Key exists, using: /data/unencrypted/key​

Using Keymaster HAL: 4 from QTI for encryption. Security level: TRUSTED_ENVIRONMENT, HAL: android.hardware.keymaster@4.0::IKeymasterDevice/default​

begin failed, code -62​

Upgrading key in memory only: /data/unencrypted/key​

Key upgraded in memory but not updated in folder: /data/unencrypted/key​

und

I:Is encrypted, do decrypt page first​

I:Switching packages (TWRP)​

I:Set page: 'decrypt'​

I:Set page: 'trydecrypt'​

Iperation_start: 'Decrypt'​

Attempting to decrypt FBE for user 0...​

Using synthetic password method​

Handle is 'b7bfd29d3f1a9bf4'​

Using synthetic password method​

Handle is 'b7bfd29d3f1a9bf4'​

using secdis​

gatekeeper verification failed​

Failed to decrypt user 0​

Es handelt sich um ein XIAOMI Redmi 8, Android 10, MIU12.5.2
Bootloader ist unlocked, Telefon gerootet, usb-debugging aktiviert.

Für jede Idee oder für jeden Kontakt bin ich dankbar!

Schöne Ostern,

DAYTRADER

 

[Klaus986]

@Daytrader147 Nur zum Verständnis: Du hast diese Dateien ohne Sicherung gelöscht? Es hätte gereicht, nur die locksettings.db zu löschen. Ich schaue mal, ob man das irgendwie recovern kann und melde mich.

Beiträge automatisch zusammengeführt: 30.03.2024

@Daytrader147 Denkfehler von mir, die Daten sind weg. Da hilft nur ein Factory Reset. Sorry, aber du hast dich selbst aus /data ausgesperrt und da ist nix mit recovern.

 

[Daytrader147]

@Klaus986 Danke, dass du dich meiner annimmst...

JA, löschen ohne Sicherung, wurde in verschiedenen Foren (auch in Foren, die ich länger nutze und die bisher immer gute Tipps weitergegeben haben kuketz, xda-developers...) so empfohlen. Die Daten werden nach dem reboot auch wieder neu geschrieben, werden aber scheinbar nicht mehr von TWRP erkannt... Dachte, dass die Verschlüsselung weitgehend aus den Hardware-Schlüsseln bezogen wird... Wohl falsch gedacht

Kannst du zu den Fehlern "fbe.data.wrappedkey = false" oder "gatekeeper verification failed" was sagen?
Kann man evtl. über EDL noch was machen (da kenne ich mich leider nicht aus, würde evtl. jemand für mich machen)

Wäre schade um die Bilder meiner Tochter, aber so lernen wir beide was (Backup + BACKUP!!)

Beiträge automatisch zusammengeführt: 30.03.2024

Kann man rekonstruieren, welche TWRP-Version zum verschlüsseln genutzt wurde? Aus Berichten in anderen Verzeichnissen / Partitionen?

 

[Klaus986]

@Daytrader147 Ich reproduziere deinen Fehler aktuell. Melde mich nachher. ;-)

 

[Klaus986]

@Daytrader147 Die schlechte Nachricht: Die Daten sind weg, solange du den neu definierten PIN deiner Tochter nicht kennst. Hättest du ihn, könntest du über TWRP die Daten entschlüsseln. Übers System geht es definitiv nicht.

Ich versuche dir zu erklären, warum das so ist:

Bis zu Android 6 wurden Geräte ab Werk nicht verschlüsselt. Eine Verschlüsselung konnte zwar freiwillig vorgenommen werden, aber nur die wenigsten User taten dies auch. Hatte man damals seine PIN etc. vergessen, konnte man durch deine Methode wieder Zugang zum Gerät bekommen, da einfach die Information, dass eine Displaysperre gesetzt war, somit entfernt wurde.

Seit Android 6 sind jedoch alle Geräte ab Werk verschlüsselt. Diese Verschlüsselung funktioniert ganz einfach, indem beim ersten Boot ein sog. Master Key generiert wird, der verschlüsselt in einer geschützen Umgebung auf deinem SoC gespeichert ist. Setzt der User nun eine Displaysperre fest, wird diese PIN etc dazu genutzt, den Master Key erneut zu verschlüsseln. Dadurch ist die komplette Entschlüsselung der Datenpartition von deiner Displaysperre abhängig!
Erst, wenn das Display nach Neustart erstmalig entsperrt wurde, wird die zweite Verschlüsselung des Master Keys aufgehoben und er wird zugänglich für den Entschlüsselungsprozess im Speicher abgelegt. Bis zum nächsten Neustart.
source.android.com - Full-Disk Encrytion

Du hast nun durch Löschung der besagten Dateien dem System gesagt, dass es keine Displaysperre gibt. Das führt natürlich zu einem Konflikt in den Abläufen, weil der Master Key nicht bereitgestellt werden kann. Ergo, die Datenpartition bleibt verschlüsselt. Diese Methode ist nur anzuwenden, wenn die Datenpartition nicht verschlüsselt ist!
Reset PIN from adb shell

Spoiler: Warum das System trotzdem bootet und Einstellungen zugänglich sind

Das nennt sich "Direct Boot". Bestimmte Systemkomponenten sollen aufgrund der Nutzerfreundlichkeit zugänglich sein, auch wenn nach Neustart das Display noch nicht entsperrt wurde. Das dient bspw. dazu, um Anrufe zu empfangen oder den gestellten Wecker klingeln zu lassen.

TWRP hingegen entschlüsselt die Datenpartition glücklicherweise auf eine sehr rudimentäre Art, bei der einige Sicherheitsmechnismen aufgrund der Gegebenheiten in der Recovery wegfallen. Die Verschlüsselung wird natürlich durch gewisse Merkmale erkannt, die im System hinterlegt sind. Daher fordert dich TWRP - trotz der gelöschten Dateien - weiterhin zur Eingabe der PIN etc. auf. Es wäre auch problemlos möglich, die Daten mithilfe der korrekten PIN etc. zu entschlüsseln. Habe es selbst getestet und es funktioniert definitiv.

Kannst du zu den Fehlern "fbe.data.wrappedkey = false" oder "gatekeeper verification failed" was sagen?
Kann man evtl. über EDL noch was machen (da kenne ich mich leider nicht aus, würde evtl. jemand für mich machen)

fbe.data.wrappedkey: Dies ist eine Funktion, die nicht im AOSP steht und von TWRP selbst programmiert wurde. Sie stellt lediglich eine von mehreren Formen der Überprüfung dar, wie deine Datenpartition entschlüsselt werden kann. Also ist der Wert "false" nur als ein Abfrageergebnis zu verstehen, um dann eine andere Methode zu nutzen. Das steht auch bei mir, trotz erfolgreicher Entschlüsselung. Falls es dich interessiert, hier der Quellcode:
partition.cpp - android_bootable_recovery - Gitiles

gatekeeper.verification.failed: Naja, wenn man die dazugehörigen Dateien löscht und diese bei einer Abfrage nicht gefunden werden... Es gibt aber auch andere Verschlüsselungsmethoden, die nicht auf Gatekeeper basieren, wie bei meinem Gerät. Nur leider basiert deine darauf.

Hoffe, es ist verständlich...

 

[Daytrader147]

WOW, danke für deine ausführliche Antwort. Die führt mich leider zu meiner nächsten Frage. Sag bitte, wenn's nervt...

Die Daten sind weg, solange du den neu definierten PIN deiner Tochter nicht kennst. Hättest du ihn, könntest du über TWRP die Daten entschlüsseln.

Wenn ich also den Key (in diesem Fall das Muster) hätte, könnte ich entschlüsseln... Das heißt, eine bruteforce mit "ADB SHELL TWRP DECRYPT xxxxxx" könnte die Daten retten? Auf die Frage nach Anzahl der Punkte kam leider "So 6-8, angefangen aber wahrscheinlich mit X"

Kannst du mir sagen, ob die richtige Version von TWRP (die, mit der verschlüsselt wurde) wichtig ist oder ob auch eine andere geht? Wenn fühere Versionen nicht nach PIN/Passcode fragen, kann ich die aussortieren? - Habe einfach schon zu viel rumprobiert....

Danke dir vielmals, schöne Ostern

 

[Klaus986]

Das heißt, eine bruteforce mit "ADB SHELL TWRP DECRYPT xxxxxx" könnte die Daten retten?

Ganz genau. Nimm das TWRP, mit dem du das Log erstellt hast.

Wenn fühere Versionen nicht nach PIN/Passcode fragen, kann ich die aussortieren?

Auf jeden Fall.

Dir auch frohe Ostern und viel Erfolg!

 

[Daytrader147]

Kurzes Update nach mehreren Tagen brute force:
Bisher kein Erfolg. Die Eingrenzung auf Anzahl Musterpunkte und nicht vorkommende Zahlen war wohl nicht ganz korrekt...

Im Log habe ich diese Meldung (immer wieder):

I:Set page: 'main2'​

I:Command 'decrypt 9346782' received​

I:Set page: 'singleaction_page'​

Iperation_start: 'TWRP CLI Command'​

Attempting to decrypt data partition or user data via command line.​

Attempting to decrypt FBE for user 0...​

Using synthetic password method​

Handle is 'b7bfd29d3f1a9bf4'​

Using synthetic password method​

Handle is 'b7bfd29d3f1a9bf4'​

using secdis​

gatekeeper verification failed​

Failed to decrypt user 0​

Ione reading ORS command from command line​

Iperation_end - status=0​

Kann die Entschlüsselung ohne die richtige gatekeeper-datei überhaupt funktionieren?
Oder sind die beiden Prozesse erst einmal unabhängig voneinander? D.h. erst mal PIN/Pattern "erraten" und dann den nächsten Schritt machen?

 

[Klaus986]

@Daytrader147 Bei mir wird nicht Gatekeeper, sondern eine andere Methode angewandt. Der Aufbau ist aber in etwa derselbe. Habe auch mehrere Dateien, die von TWRP gesucht werden, um den Entschlüsselungsprozess festzulegen. Nach Löschung dieser Dateien, konnte ich trotzdem durch Eingabe der korrekten PIN die Partition entschlüsseln.

Hier die Stelle im Quelltext:

#ifdef TW_INCLUDE_FBE

        ExcludeAll(Mount_Point + "/convert_fbe");

        ExcludeAll(Mount_Point + "/unencrypted");

        //ExcludeAll(Mount_Point + "/system/users/0"); // we WILL need to retain some of this if multiple users are present or we just need to delete more folders for the extra users somewhere else

        ExcludeAll(Mount_Point + "/misc/vold/user_keys");

        //ExcludeAll(Mount_Point + "/system_ce");

        //ExcludeAll(Mount_Point + "/system_de");

        //ExcludeAll(Mount_Point + "/misc_ce");

        //ExcludeAll(Mount_Point + "/misc_de");

        ExcludeAll(Mount_Point + "/system/gatekeeper.password.key");

        ExcludeAll(Mount_Point + "/system/gatekeeper.pattern.key");

        ExcludeAll(Mount_Point + "/system/locksettings.db");

        //ExcludeAll(Mount_Point + "/system/locksettings.db-shm"); // don't seem to need this one, but the other 2 are needed

        ExcludeAll(Mount_Point + "/system/locksettings.db-wal");

        //ExcludeAll(Mount_Point + "/user_de");

        //ExcludeAll(Mount_Point + "/misc/profiles/cur/0"); // might be important later

        ExcludeAll(Mount_Point + "/misc/gatekeeper");

        ExcludeAll(Mount_Point + "/misc/keystore");

        ExcludeAll(Mount_Point + "/drm/kek.dat");

        ExcludeAll(Mount_Point + "/system_de/0/spblob"); // contains data needed to decrypt pixel 2

Das sind alle Verzeichnisse und Dateien, die von TWRP durchsucht werden. In der letzten Zeile ist der Pfad, der für mich wichtig wäre und diesen hatte ich komplett gelöscht. Aber die Entschlüsselung funktionierte.

Ich denke, der Error "gatekeeper.verification=failed" wird so oder so ausgegeben. Ist aber unabhängig davon, ob es funktioniert. Garantieren kann ich hierbei nichts, aber versuchen würde ich es trotzdem.