Wie kann man Daten aus dem adaptiven Speicher wiederherstellen, während das gerootete Telefon beim Booten hängen bleibt?

Bevor Sie beginnen, würde ich empfehlen, eine VOLLSTÄNDIGE Sicherung Ihrer SD-Karte über ein RAW-Image zu erstellen (googlen Sie den Befehl „dd“ in Linux).

Ich bin der Anleitung hier gefolgt; Beschädigte SD-Karte als interner Speicher formatiert

ABER mit einigen WICHTIGEN MODIFIKATIONEN von mir!

1. Das Telefon blieb in BOOTLOOP und später bei BOOT Animation hängen, kein Zugriff auf ein übliches Dateimanager-Dienstprogramm. Wohlgemerkt, dies ist eine SEHR schwerwiegende Situation, da es keine triviale Methode gibt, um Zugriff auf Ihre SD-Karte zu erhalten (sie wird im TWRP-Dateimanager als 0 MB angezeigt), um Ihre wertvollen Daten, Bilder und Erinnerungen zu sichern. Außerdem ist dies der einzige Teil, der etwas wackelig ist, da ich nicht ganz sicher bin, ob mein Telefon gerootet war oder nicht (da sich mein Problem von Bootloop zu Boot-Animation geändert hat, als ich versuchte, über TWRP auf SuperSu zu installieren) und den Verschlüsselungsschlüssel abrufen ist zentral, um dies zu lösen. Ich musste mir die .key-Datei besorgen, da diese ausschlaggebend dafür war, die Verschlüsselung der SD-Karte zu knacken. Inmitten all der Panik konnte ich also über den TWRP-Dateimanager zum Ordner /data/misc/vold navigieren und die .key-Datei finden. Dies war ein GROSSER Durchbruch!

2. Als nächstes , um die Datei zu extrahieren. Ich habe eine andere, UNVERSCHLÜSSELTE SD-Karte verwendet und die .key-Datei über den TWRP-Dateimanager auf diese Karte übertragen, diese SD-Karte in den Laptop eingelesen und die .key-Datei auf Ubuntu (16.04) heruntergeladen. Entschlüsselte die .key-Datei und erhielt den 16-Byte-Schlüssel. Es gibt zwei Möglichkeiten, dies zu tun ... entweder öffnen Sie die Datei über einen Hex-Editor (ich habe BLESS verwendet) und kopieren Sie die 16 Paare von Hex-Ziffern, die Sie sehen, ODER verwenden Sie diesen Befehl;

hexdump -e '1/1 "%.2x"' expand_8838e738a18746b6e435bb0d04c15ccd.key

Stellen Sie sicher, dass Sie sich im selben Verzeichnis wie die .key-Datei befinden, wenn Sie diesen Befehl ausführen (fortgeschrittene Linux-Benutzer werden sich darum kümmern, aber ich möchte, dass es so anfängerfreundlich wie möglich ist).

Also, ich habe den 32-stelligen / 16-Byte-Schlüssel.

3. Als nächstes entschlüsseln Sie die SD-Karte und lassen Linux sie erkennen. Als ich es über den Kartenleser einlas, wurde es in Nautilus (dem Ubuntu-Dateimanager) nicht angezeigt, aber beim Ausführen von fdisk-l und parted -l sah ich

"parted -l Ausgabe"

http://pasteboard.co/5klviklR8.jpg

"fdisk -l Ausgabe"

http://pasteboard.co/POGvyBOxO.png

Beachten Sie die android_meta und android_expand , diese Namen gaben mir Hoffnung, dass meine Daten noch intakt waren. BESONDERS, da ich zu Beginn des Problems Partitionen und Partitionstabellen auf der SD-Karte über das fdisk-Dienstprogramm erstellt hatte (aber ich habe Strg + C gedrückt, sodass es möglich ist, dass die Änderungen nicht geschrieben wurden, Puh!)

Das unbekannte Dateisystem war der größte Schmerz in diesem ganzen Fiasko ... da laut den wenigen Anleitungen und Diskussionen zu diesem Problem SD-Karten, die von Marshmallow als intern formatiert wurden, ein ext4-Dateisystem sein sollten. aber das war nicht der Fall, zumindest nicht hier.

4. Also, um die Karte zu entschlüsseln, habe ich verwendet

dmsetup create crypt1 --table "0 `blockdev --getsize /dev/mmcblk0p2` crypt aes-cbc-essiv:sha256 "insert your 16-byte key here w/out double quotes" 0 /dev/mmcblk0p2 0"

Wenn Sie einen ioctl-bezogenen Fehler erhalten, verwenden Sie stattdessen dieses Format (dies ist das EXAKTE Format, das ich heute verwendet habe, mit meinem Schlüssel und allem).

dmsetup create crypt7 --table "0 `blockdev --getsize /dev/mmcblk0p2` crypt aes-cbc-essiv:sha256 07147CFFB77F249A5DBD2AD204610E7D  0 /dev/mmcblk0p2 0"

Bitte beachten Sie, dass das Dienstprogramm dmsetup unter Linux installiert werden sollte. (Google es ) . Beachten Sie auch, dass ich mich für die Parition 'mmcblk0p2' entschieden habe, da diese die größere war und die offensichtliche Schlussfolgerung hatte, alle Daten zu enthalten!

das ging gut, ohne Fehler abgeschlossen. Der nächste Teil machte mich jedoch ABSOLUT verrückt und dauerte ungefähr 20 Stunden (einschließlich meiner Schlafzeit), um richtig gelöst zu werden.

5. das GADDAMN-Dateisystem ! Es wurde ÜBERALL geschrieben, dass Adoptivspeicher als ext4 formatiert ist, also als ich den Befehl ausführte

# mount -t ext4 /dev/mapper/crypt1 /mnt/1/

(Bitte beachten Sie, dass mnt/1/ als Verzeichnis in Ihrem Stammordner existieren sollte, wenn nicht, verwenden Sie mkdir, um es zu erstellen)

es ergab den verdammten Fehler

falsche fs oder schlechte Option.

und das brachte mich zum nachdenken ... wenn die sd - karte NICHT vom typ ext4 ist , wie um alles in der welt soll ich dann wissen , um welches dateisystem es sich bei allen möglichen handelt !

Ich suchte und suchte nach einem Befehl, der ALLE Möglichkeiten in einer Brute-Force-Methode durchlaufen könnte, oder nach einem Eintrag, den ich in der /etc/fstab-Datei vornehmen könnte, der das Dateisystem irgendwie AUTOMATISCH erkennen könnte, aber ohne Erfolg ...

5 . Am Ende erinnerte ich mich ... dass vielleicht, nur MÖGLICHERWEISE das Dateisystem f2fs (Flash-freundliches Dateisystem) war. Und das erwies sich als aufschlussreiche Erinnerung ...

für diesen Code ;

mount -t f2fs /dev/mapper/crypt1 /mnt/1

erwies sich als SIEGENDES ZIEL!

Ich konnte dann in /mnt/1 cd und sah einige sehr vertraute Android-ähnliche Dateien und von da an war es Eternal BLISS!