Datenrettung von gerade eben gelöschten Dateien auf einem gerooteten Samsung Galaxy S6 Edge (Android 7) möglich?

[Kreacher]

Hallo,
gerade eben ist mir durch eine kleine Unachtsamkeit ein gesamter Ordner mit verschiedenen Mediendateien (Bilder, Videos, etc) abhanden gekommen. Das heißt, das System hat ihn eigenmächtig gelöscht, sodass er nicht noch irgendwo im Papierkorb wäre und ich ihn von dort wieder holen könnte.

Habe sofort den Flugmodus aktiviert und suche jetzt nach einer Möglichkeit, diese gelöschten Dateien (viele sind es nicht, aber einige wichtige) wiederherstellen zu können. Habe das Handy bereits mit USB-Debugging und aktiviertem MTP-Protokoll an den PC angeschlossen, aber meine kostenpflichtige Datenrettungssoftware (Disk Drill), die sogar damit wirbt, dass es auch von angeschlossenen Android-Geräten Daten wiederherstellen könnte, "findet" nicht einmal das angeschlossene Gerät.
Recuva sieht das angeschlossene Gerät anscheinend auch nicht.

Nach etwas Recherche lese ich, dass gelöschte Dateien auf einem Androidgerät nicht mehr herstellbar wären, da der Android-Speicher verschlüsselt sei und mit den gelöschten Dateien gleichzeitig auch der jeweilige Schlüssel für jede einzelne verschlüsselte Datei gelöscht worden wäre. Stimmt das so?

Mein Gerät ist zum Glück gerootet / offener Bootloader, Android 7. Ich weiß allerdings nicht, ob mir das aktuell weiterhelfen würde.

Meinungen / Erfahrungen?

Vielen Dank

 

[swa00]

Nach etwas Recherche lese ich, dass gelöschte Dateien auf einem Androidgerät nicht mehr herstellbar wären, .....

sodass er nicht noch irgendwo im Papierkorb

Den gibt es bei API 24 auch noch nicht

Mein Gerät ist zum Glück gerootet / offener Bootloader, Android 7. Ich weiß allerdings nicht, ob mir das aktuell weiterhelfen würde.

Na wenn du dann selbst als su (ls -la) nichts siehst, sind die Daten weg.
Mögliche Folder : /data, /data/cache, /storage/sdcard1, /data/media/0 , /lost+found

Viel Erfolg

 

[Kreacher]

Ich lese gerade was von wegen ADB Bridge. Da ich ja eh schon Root habe, soll man angeblich damit gelöschte Daten wiederherstellen können?

Die Live-Verbindung per USB zum Computer mittels MTP-Protokoll kann nicht klappen, da der Handyspeicher durch MTP am Computer nur "simuliert" wird. Ein echter Zugriff ist so nicht möglich. Wahrscheinlich wird das Gerät deshalb auch nicht von Datenrettungstools auf dem PC "gefunden".

 

[swa00]

Und was möchtest du mit ADB und MTP rumfummeln, wenn du eh Rootzugriff hast ?

Wenn, dann musst du ADB aktivieren und den Shell öffnen

adb devices
adb shell
su

Dann hast du (nahezu) Vollzugriff auf dein Gerät und kannst ganz normal weitermachen

 

[Kreacher]

ChatGPT schlägt vor, mittels ADB ein komplettes Image des internen Handyspeichers zu erstellen, um ihn dann mit Hilfe gängiger Wiederherstellungstools am PC zu analysieren. Ich glaube, das klingt ganz vielversprechend.

 

[Klaus986]

@Kreacher Du brauchst Termux.

Installiere darüber folgende Packages:

pkg install root-repo
pkg install tsu
pkg install testdisk

Danach führst du folgende Befehle aus:
tsu
photorec /dev/block/by-name/userdata

oder

photorec /dev/block/mmcblk0p[Nummer der Partition "userdata"]

Beiträge automatisch zusammengeführt: Gestern um 13:21

Eine bessere Lösung gibt es IMHO nicht. Du brauchst 2 Dinge für eine Datenrettung:
1. Vollen Zugriff auf das Dateisystem
2. Ein Tool, das nach Dateisignaturen sucht.
Beides hast du mit Testdisk und Root.

 

[Kreacher]

@Klaus986

Termux läuft bereits standardmäßig auf dem gerooteten Gerät. Das müsste ich also nicht erst holen.

Allerdings läuft gerade die Datensicherung mittels

adb shell "su -c 'dd if=/dev/block/dm-0 bs=4096'" > handy-internal-storage.img

Was mir ChatGPT vergeschlagen hat?

Danach würde ich das Image auf dem PC dann mit DiskDrill nach verlorenen Daten auslesen.

 

[Klaus986]

@Kreacher Ein Image zu erstellen für Datenrettungszwecke ist natürlich vorbildlich. Dann kann nichts mehr passieren.

Beiträge automatisch zusammengeführt: Gestern um 13:29

Ist ~/dm-0 auch wirklich die Datenpartition?

Beiträge automatisch zusammengeführt: Gestern um 13:36

Das erstellte Image beinhaltet an der Blockadresse (Hex) 0x488 den Eintrag mit dem Namen der Partition. Einfach mit einem Hexviewer öffnen.

Bei meinem LOS22 ist z.B. die Partition ~/dm-0 = /system

 

[Kreacher]

Ist ~/dm-0 auch wirklich die Datenpartition?

Laut ChatGPT schon. Ich habe ihm einfach sämtliche Fehlermeldungen aus CMD rauskopiert dann hat der das für mich herausgefunden. Ich kenne mich da ja gar nicht so gut aus

Ich:
ls: /dev/block/bootdevice/by-name/: No such file or directory1|zenlte:/ #

ChatGPT:

Ah, alles klar – danke für die Rückmeldung!

Das erklärt einiges:
Nicht jedes Gerät (vor allem ältere Geräte wie deins mit Android 7) hat den Pfad /dev/block/bootdevice/by-name/.
Aber keine Sorge, es gibt andere Wege, um die richtige Partition zu finden!

---

Alternativen, um die Partition zu finden:​

1. Schau direkt in /dev/block/​

Gib folgendes ein:

ls -l /dev/block/
→ Dort siehst du vermutlich Einträge wie mmcblk0, mmcblk0p1, mmcblk0p2, etc.

Beispielausgabe könnte sein:
python-repl
KopierenBearbeiten
mmcblk0
mmcblk0p1
mmcblk0p2
mmcblk0p3

Ich:

1|zenlte:/ # ls -l /dev/block/total 0brw------- 1 root root 254, 0 2025-04-27 09:12 dm-0brw------- 1 root root 7, 0 2025-04-27 09:12 loop0brw------- 1 root root 7, 1 2025-04-27 09:12 loop1brw------- 1 root root 7, 2 2025-04-27 09:12 loop2brw------- 1 root root 7, 3 2025-04-27 09:12 loop3brw------- 1 root root 7, 4 2025-04-27 09:12 loop4brw------- 1 root root 7, 5 2025-04-27 09:12 loop5brw------- 1 root root 7, 6 2025-04-27 09:12 loop6brw------- 1 root root 7, 7 2025-04-27 09:12 loop7lrwxrwxrwx 1 root root 46 2025-04-27 09:12 param -> /dev/block/platform/15570000.ufs/by-name/PARAMlrwxrwxrwx 1 root root 51 2025-04-27 09:12 persistent -> /dev/block/platform/15570000.ufs/by-name/PERSISTENTdrwxr-xr-x 3 root root 60 2025-04-27 09:12 platformbrw------- 1 root root 1, 0 2025-04-27 09:12 ram0brw------- 1 root root 1, 1 2025-04-27 09:12 ram1brw------- 1 root root 1, 10 2025-04-27 09:12 ram10brw------- 1 root root 1, 11 2025-04-27 09:12 ram11brw------- 1 root root 1, 12 2025-04-27 09:12 ram12brw------- 1 root root 1, 13 2025-04-27 09:12 ram13brw------- 1 root root 1, 14 2025-04-27 09:12 ram14brw------- 1 root root 1, 15 2025-04-27 09:12 ram15brw------- 1 root root 1, 2 2025-04-27 09:12 ram2brw------- 1 root root 1, 3 2025-04-27 09:12 ram3brw------- 1 root root 1, 4 2025-04-27 09:12 ram4brw------- 1 root root 1, 5 2025-04-27 09:12 ram5brw------- 1 root root 1, 6 2025-04-27 09:12 ram6brw------- 1 root root 1, 7 2025-04-27 09:12 ram7brw------- 1 root root 1, 8 2025-04-27 09:12 ram8brw------- 1 root root 1, 9 2025-04-27 09:12 ram9brw------- 1 root root 8, 0 2025-04-27 09:12 sdabrw------- 1 root root 8, 1 2025-04-27 09:12 sda1brw-rw---- 1 system system 8, 10 2025-04-27 09:12 sda10brw-rw---- 1 system system 8, 11 2025-04-27 10:39 sda11brw-rw---- 1 system system 8, 12 2025-04-27 09:12 sda12brw------- 1 root root 8, 13 2025-04-27 09:12 sda13brw------- 1 root root 8, 14 2025-04-27 09:12 sda14brw------- 1 root root 8, 15 2025-04-27 09:12 sda15brw------- 1 root root 259, 0 2025-04-27 09:12 sda16brw------- 1 root root 259, 1 2025-04-27 09:12 sda17brw------- 1 root root 8, 2 2025-04-27 09:12 sda2brw------- 1 root root 8, 3 2025-04-27 09:12 sda3brw-rw---- 1 system system 8, 4 2025-04-27 09:13 sda4brw------- 1 root root 8, 5 2025-04-27 09:12 sda5brw------- 1 root root 8, 6 2025-04-27 09:12 sda6brw------- 1 root root 8, 7 2025-04-27 09:12 sda7brw-rw---- 1 system radio 8, 8 2025-04-27 09:12 sda8brw------- 1 root root 8, 9 2025-04-27 09:12 sda9brw------- 1 root root 8, 16 2025-04-27 09:12 sdbbrw------- 1 root root 8, 32 2025-04-27 09:12 sdcbrw------- 1 root root 8, 48 2025-04-27 09:12 sddbrw------- 1 root root 8, 49 2025-04-27 09:12 sdd1lrwxrwxrwx 1 root root 47 2025-04-27 09:12 steady -> /dev/block/platform/15570000.ufs/by-name/STEADYbrw------- 1 root root 253, 0 2025-04-27 09:12 vnswap0drwx------ 2 root root 40 2025-04-27 09:12 voldzenlte:/ #

ChatGPT:

Sehr gut, danke für die ausführliche Ausgabe – jetzt wird einiges klarer!

Dein Handy hat einen Samsung Exynos-Chipsatz (wegen 15570000.ufs) → da ist das Blocklayout etwas anders.
Wichtig zu verstehen: Deine echten Speicher-Partitionen heißen hier z.B. sda1, sda2, sda12, sdb, usw.

Was wir daraus sehen:​

• Es gibt Geräte: sda, sdb, sdc, sdd
• und viele Partitionen wie sda1, sda2, ..., sda17
• Wahrscheinlich liegt dein interner Speicher auf einer Partition von sda!

Jetzt der nächste Schritt:

Wir müssen herausfinden, welche dieser Partitionen für den Nutzerspeicher (/data, /sdcard) zuständig ist.

Dafür machen wir folgendes:

Bitte in der adb shell eintippen:​

mount

→ und die Ausgabe hierher kopieren (oder die wichtigen Zeilen).

Ich:

rootfs on / type rootfs (ro,seclabel)magisk on /sbin type tmpfs (rw,seclabel,relatime,size=1875752k,nr_inodes=468938,mode=755)tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1875752k,nr_inodes=468938,mode=755)devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)sysfs on /sys type sysfs (rw,seclabel,relatime)selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,seclabel,relatime)none on /acct type cgroup (rw,relatime,cpuacct)tmpfs on /mnt type tmpfs (rw,seclabel,relatime,size=1875752k,nr_inodes=468938,mode=755,gid=1000)none on /config type configfs (rw,relatime)none on /dev/cpuctl type cgroup (rw,relatime,cpu)pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)/dev/block/sda14 on /system type ext4 (ro,seclabel,relatime,norecovery)/dev/block/sda3 on /efs type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered)/dev/block/sda15 on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc)/dev/block/sdd1 on /cpefs type ext4 (ro,seclabel,relatime,norecovery)/dev/block/sda13 on /persdata/absolute type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered)tmpfs on /storage type tmpfs (rw,seclabel,relatime,size=1875752k,nr_inodes=468938,mode=755,gid=1000)/dev/block/sda16 on /preload type ext4 (ro,seclabel,nosuid,nodev,relatime)/dev/block/dm-0 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc)/data/knox/tmp_sdcard on /mnt/knox type sdcardfs (rw,nosuid,nodev,relatime,mask=0077)/data/knox/sdcard on /mnt/knox/default/knox-emulated type sdcardfs (rw,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=1015,multi_user,mask=0006)/data/knox/sdcard on /mnt/knox/read/knox-emulated type sdcardfs (rw,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0027)/data/knox/sdcard on /mnt/knox/write/knox-emulated type sdcardfs (rw,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0007)/data/knox/secure_fs/enc_media on /mnt/shell/enc_media type sdcardfs (rw,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,reserved=20MB)/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,low_uid=1023,low_gid=1023,gid=1015,multi_user,mask=0006,reserved=20MB)/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,low_uid=1023,low_gid=1023,gid=1015,multi_user,mask=0006,reserved=20MB)/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,low_uid=1023,low_gid=1023,gid=9997,multi_user,mask=0027,reserved=20MB)/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,low_uid=1023,low_gid=1023,gid=9997,multi_user,mask=0007,reserved=20MB)zenlte:/ #

ChatGPT:

Wichtige Punkte:​

Dein /data (also Benutzerbereich + interne SD-Emulation /storage/emulated/0) liegt auf
/dev/block/dm-0

Das sieht man hier:

/dev/block/dm-0 on /data type ext4 (rw, ...)

und deine /storage/emulated/0 (wo normale Dateien sind) ist ein virtuelles Dateisystem (sdcardfs) auf /data/media.

Was bedeutet das praktisch?​

Du musst /dev/block/dm-0 sichern!
(und nicht /dev/block/sdaX, das wäre falsch und unvollständig.)

Ich vertraue ihm hier jetzt einfach mal und bin nach wie vor wieder total begeistert, wie fortschrittlich und arbeitserleichternd KIs geworden sind. Unglaublich. Da zahl ich die 20€ monatlich für die Pro-Variante doch gerne.
Als Informatik-Laie hätte ich sowas nie ohne stundenlanges Einlesen und Nachfragen hinbekommen.

 

[Klaus986]

@Kreacher Ja, ChatGPT hat recht. Das sieht man am Eintrag /dev/block/dm-0 on /data type ext4, wie es auch geschrieben wurde in der Antwort.

 

[Kreacher]

Leider gibt es keine Fortschrittsanzeige im CMD. ChatGPT hätte mir da was mit Chocolatey und "pv" mittels GIT vorgeschlagen, aber das klappte irgendwie nicht. Jetzt läuft es eben ohne Fortschrittsanzeige und ich weiß nicht, wann die internen 64GB auf dem PC sind.

Ein Aktualisieren der Ordneransicht bringt nichts. Da hat die Datei immer noch 0 byte.

 

[Klaus986]

@Kreacher Versuch mal die Größe der Datei mit Rechtsklick -> Eigenschaften abzufragen.

Beiträge automatisch zusammengeführt: Gestern um 13:55

Leider gibt es keine Fortschrittsanzeige im CMD.

Das hat was mit deiner Binary "dd" auf dem Handy zu tun. Manche unterstützen eine Anzeige, manche nicht.

 

[Kreacher]

@Klaus986
Oh, gar nicht mehr nötig.

Gerade eben nachgeschaut und CMD war fertig. Gesamtgröße der Image-Datei 55,4GB

Na dann wollen wir mal mit Disk Drill. Ab hier betrete ich wieder vertrauteres Terrain.

 

[Klaus986]

@Kreacher Dann viel Erfolg!

 

[Kreacher]

Wohl zu früh gefreut:
Disk Drill zickt rum und kann nur komplette unkomprimierte Roh-Images auslesen...

ChatGPT sagt:

• dm-0 ist ein "logical volume" (kein komplettes Blockdevice wie eine physische Festplatte).
• DiskDrill will eher ein komplettes physisches Gerät oder einen "richtigen" Partitionsdump, wo Partitionstabellen vorhanden sind (MBR, GPT).

→ Dein .img ist korrekt für Datei-Wiederherstellung (Photorec, Testdisk),
aber DiskDrill erwartet leider einen "kompletten" Roh-Datenträger (Blockdevice wie /dev/block/mmcblk0).

Tja... Mit TestDisk kenne ich mich nicht aus. Alternative: den gesamten NAND-Speicher als Image rüberziehen.

 

[Klaus986]

@Kreacher Hast du eine Pro-Version von Disk Drill? Mit der kostenlosen Variante kannst du nur 500MB recovern. Wenn du die kostenlose Variante hast, würde ich Testdisk nehmen. Ansonsten den ganzen Speicher kopieren. Sind ja nur ein paar GB mehr.

Testdisk sollte jedenfalls auch mit der dm-0 Partition klarkommen und ist auch als Desktopversion verfügbar.

 

[Kreacher]

Hast du eine Pro-Version von Disk Drill?

Ja

Vielleicht das Image als Windows-Laufwerk mounten und dann mit DiskDrill drauf zugreifen?

UPDATE:
Habe das Image mit Arsenal Image Mounter gemountet. Nun erkennt Disk Drill es als "Laufwerk" und macht gerade einen "Deep Search" nach gelöschten Dateien.

------------------------------------------------------------------------------

Zusammenfassung am Ende:
Das Erstellen des internen Handyspeichers mittels dd und ADB funktioniert tadellos.
Das Einbinden des Images mittels Arsenal Image Mounter ebenfalls.

Leider aber scheinen die Daten verloren zu sein. Disk Drill findet selbst mit seinem "Deep Search" kaum noch verwertbare Daten. Obwohl das Gerät sofort nach Löschen des Ordners in den Flugmodus kam und sonst keine Schreibvorgänge mehr stattfanden.

Offenbar bewirkt die Löschung auf Android-Geräten, anders als bei herkömmlichen SSDs am PC, selbst nach sofortigen Wiederherstellungsversuchen eine endgültige und nicht wiederherstellbare Löschung.

Bei SSD-Platten am PC ist zumindest noch was zu retten, sofern die Daten nach dem Löschen nicht überschrieben wurden. Weiß nicht, was da bei Android anders abläuft.
Naja, schade. Ein Versuch war's wert.