AllmysteryNavigation
Menschen Wissenschaft Politik Mystery Kriminalfälle Spiritualität Verschwörungen Technologie Ufologie Natur Umfragen Unterhaltung
weitere Rubriken
PhilosophieTräumeOrteEsoterikLiteraturAstronomieHelpdeskGruppenGamingFilmeMusikClashVerbesserungenAllmysteryEnglish
Diskussions-Übersichten
BesuchtTeilgenommenAlleNeueGeschlossenLesenswertSchlüsselwörter
Schiebe oft benutzte Tabs in die Navigationsleiste (zurücksetzen).

SD-Karte Filesystem Block/Cluster-Versuche

37 Beiträge ▪ Schlüsselwörter: Kris Kremers, Lisanne Froon, SX270 HS ▪ Abonnieren: Feed E-Mail

SD-Karte Filesystem Block/Cluster-Versuche

24.03.2025 um 01:56
Zitat von cycliccyclic schrieb:Das wäre spannend das mit dem vermutlichen Viewer zu machen, den die Panamaer verwendet haben.
Was beim MS-Viewer spezifisch ist, ist der Anhang im Dateinamen "~RFxxxxxx.TMP". Hab ich sonst bei keinem Tool beobachtet.

Du könntest dir Windows 7 Professional SP1 unter VirtualBox installieren. Key brauchste nicht. Der Viewer ist direkt aktiv, weil Windows-Bord-App. Mit USB-SD-Leser, WinHex und PhotoRec kannste dann in Win 7 nahe an der panamaischen Realität testen. Das ist im Moment mein Test-Setting.

Aber mach dir kein Stress, der NFI-Datennachschub stockt grad etwas. :-)


1x zitiertmelden

SD-Karte Filesystem Block/Cluster-Versuche

24.03.2025 um 20:18
Zitat von OFFshore7OFFshore7 schrieb:Aber mach dir kein Stress, der NFI-Datennachschub stockt grad etwas. :-)
Ich habe auch noch einen alten Laptop mit Win7 (und Linux). Ewig nicht probiert, schon damals wollte das Teil nach einem verkorksten Update nicht mehr normal booten. Ich wollte das schon länger mal probieren, aber solange ich nicht weiß wonach ich eigentlich suche, ist die Motivation etwas gedämpft.


melden

SD-Karte Filesystem Block/Cluster-Versuche

24.03.2025 um 22:04
Manchmal muss sich ja nur mal selbst anschubsen. Ich hatte befürchtet, dass schon das Starten ein Problem werden könnte, aber siehe da: er läuft (bis auf das elend lange Booten von einer rotating Disc). Es dürfte keine Relevanz haben, aber der Laptop hat einen integrierten SD-Kartenleser (war damals auch nicht ganz so selten soweit ich mich erinnere). Den habe ich auch genutzt.

Zuerst habe ich mal die 4 Bilder, die ich mit Gwenview gedreht hatte, nochmal mit Win PhotoViewer gedreht. EXIF zeigt, dass meine Programm-Version (Microsoft Windows Photo Viewer 6.1.7600.16385) auch in den Original-Bildern auftaucht allerdings nur bei zwei Bildern.

Hier die EXIF-Daten für zwei meiner Bilder (3105 Original, 3110 mit PhotoViewer gedreht und gespeichert)

Dateianhang: PhotoViewerRotateExif2.csv (8 KB)

Ansonsten sehe ich auf die Schnelle nichts besonderes. Im Gegensatz zu Gwenview, das die meisten EXIF-Werte löscht erhält der Viewer fast alles, auch das was unter "MakerNotes" geführt wird.

Bzgl. Speicher-Belegung verhält sich das Teil wie Gwenview (0_*: Original, 1_*: nach Drehen mit Gwenview, 2_*: nach dem Drehen der Bilder mit PhotoViewer):

56aotrohwfao Rotating4ImageswithGwenviewAndWin7PhotoV

D.h. die Bilder sind zurück in ihre alte Lücke gewandert (weil die ja nun frei war), und wieder hintereinanderweg abgelegt worden (keine Lücken wie bei Gimp).
Nun könnte es immer noch sein, dass der erste freie Bereich genutzt wird, dass also das zweite Bild in die Lücke des ersten wandert, wenn das erste Bild vorwärts gewandert ist. Also dieselben Bilder nochmal gedreht (3_*). Auch da selbes Verhalten wie Gwenview: Bilder hintereinanderweg nach hinten gewandert (erste Lücke wird nicht genutzt). Das scheint mir aber generell das Verhalten der SD-Karte zu sein: es wird nicht wieder zurückgesprungen bevor das Teil nicht neu "gebootet" wurde.

Bedeutet: Wenn alle Bilder in einer Session gedreht wurden ist es plausibel, dass alle Original-Bereiche nicht überschrieben wurden und so die Thumbnails mittels entspr. Forensik-SW auffindbar waren. Es ist nicht notwendig eine größere Lücke (z.B. durch ein gelöschtes Video) anzunehmen, in die die gedrehten Versionen verschoben wurden.

Genauere Speicheranalyse habe ich jetzt aber noch nicht durchgeführt (nur wieder mit filefrag, wie bisher immer)


1x zitiertmelden

SD-Karte Filesystem Block/Cluster-Versuche

26.03.2025 um 06:54
Zitat von cycliccyclic schrieb:Das scheint mir aber generell das Verhalten der SD-Karte zu sein: es wird nicht wieder zurückgesprungen bevor das Teil nicht neu "gebootet" wurde.
...was ich für das oder zumindest einen Teil des Wear-Levelings halte. Prozesse, die häufig (Temp-)Dateien schreiben und wieder löschen, beschreiben so nicht ständig dieselben Bereiche. Erst nach einem "Reboot" der Karte fängt sie wieder bei der ersten freien Lücke an (Winz-Lücken scheinen dabei ignoriert zu werden).


melden

SD-Karte Filesystem Block/Cluster-Versuche

28.05.2025 um 17:56
Auch im Thread, aber hier nun auch nochmal:

Ich habe jetzt endlich mal mit photorec (bzw. der graphischen Oberfläche qphotorec) in der Version 7.1 ein paar Tests gemacht.
Das Ergebnis ist ziemlich trivial:

  1. Erster Scan auf der SD-Karte so wie sie gerade war:
    photorec findet jede Menge gelöschter Bilder und zwar jeweils die 4000x3000 sowie ein 160x120 Thumbnail dazu
    Dass viele Bilder gefunden werden ist keine Überraschung: Ich hatte für meine Tests zwischendurch mal extrem viele Dateien gelöscht, bzw. auch mal die Karte (schnell) formatiert und seitdem nur rel. wenige neue Fotos gemacht.
    Was sich bestätigt ist, dass photorec die eingebetteten Thumbnails extrahiert (allerdings merkt das Programm, dass die Bilder zusammengehören, sie heißen z.B.:
    t0057027.jpg (Thumbnail) und
    f0057027.jpg (4000x3000)
    Und wenn man darauf achtet: sie werden in der Ausgabe, die anzeigt wieviele Dateien gefunden wurden, auch nur als eine Datei gezählt. Interessant ist vielleicht, dass der last-modified Filesystem-Zeitstempel rekonstruiert wird. Da ist mir nicht ganz klar wie, evtl. aus dem EXIF-Daten (könnte man testen).
  2. Formatieren der SD-Karte mit Option "Low-Level" in der Kamera
  3. Zweiter Scan mit photorec: Keine gelöschten / wiederherstellbaren Dateien gefunden.
    Da hätte ich nicht unbedingt drauf gewettet, macht die folgenden Tests aber einfacher / übersichtlicher.
  4. Drei Fotos geschossen, letztes Bild gelöscht, Kamera aus, Kamera ein, noch ein Bild geschossen
  5. Dritter Scan: Es wird wieder keine gelöschte/wiederherstellbare Datei gefunden.
    Wie ich auch erwartet hatte: der Bereich des gelöschten Bildes wird mit dem letzten Bild überschrieben.
  6. Nochmal drei Fotos geschossen, letztes Bild gelöscht, noch ein Fotos geschossen (ohne die Kamera auszuschalten)
  7. Vierter Scan: Das zuletzt gelöschte Foto wird gefunden und kann wiederhergestellt werden (2 Bild-Dateien, 4000x3000 und 160x120)
    Auch wie erwartet: Der Bereich des zuletzt gelöschten Fotos wird nicht überschrieben (Lücke), das neue Bild wird erst dahinter abgelegt.


Also alles wie aufgrund der vorhergehenden Tests mit filefrag erwartet: gelöschte Bilder in nicht neu befüllten Lücken sind wiederherstellbar. Wenn die Lücke überschrieben wird nicht mehr. Daran ändert auch der logische Zwischen-Layer nichts. Jedenfalls nicht bzgl. photorec und das ist ja, soweit bekannt, auch das Tool, welches die Ermittler eingesetzt haben.


melden

SD-Karte Filesystem Block/Cluster-Versuche

31.05.2025 um 12:58
Auch das aus dem Thread auch noch hier (gekürzt) reinkopiert wegen leichterer Auffindbarkeit:

Es ist so, dass das 160x120-Thumbnail innerhalb der Bilddatei zuerst kommt. Dann kommt das 4000x3000-Hauptbild und (kleine Überraschung) erst danach kommt noch das 1440-1080-Preview-Bild, das photorec aber ohnehin ignoriert1).

Bsp: Byte-Ranges innerhalb der Jpeg-Datei2):

  1. Thumbnail (160x120): 5632 ... 10772
  2. Hauptbild: (4000x3000): 13824 ... 2915865
  3. Preview (1440x1080): 2916352 ... 3339982 (Dateiende)




1) Es ist natürlich in der wiederhergestellten Hauptdatei enthalten (genau wie das Thumbnail und alle EXIF-Daten), das Preview-Bild wird nur nicht separat nochmal in eine eigene Datei extrahiert (das Thumbnail aber schon - warum auch immer).

2) Man sucht dafür innerhalb der Datei nach den Byte-Folgen: FFD8 (Jpeg-Start) und FFD9 (Jpeg-End), wobei die Start-Tags jeweils 2x vorkommen (FFD8 FFE1: "EXIF" und FFD8 FFDB: "RAW") - s. stackoverflow.com


melden

SD-Karte Filesystem Block/Cluster-Versuche

02.06.2025 um 22:08
Dies und das:
  • photorec t*.jpg sind tatsächlich extrahierte embedded Thumbnails (wenn kein embedded Thumbnail enthalten wird auch keine Datei t*.jpg wiederhergestellt, sondern nur die Hauptdatei).
  • Speichern mit Gimp oder MS Paint auf der SD-Karte erzeugt offenbar keine *~*.TMP- oder ~*.tmp-Dateien.
  • Windows Live Photogallery erzeugt ebenfalls TMP/tmp-Dateien (durch Umbenennung des Originals), die sofort wieder gelöscht werden. Ebenfalls autom. sobald man zum nächsten Bild wechselt.
  • Umbennen in beide Formen (TMP/tmp) ist problemlos möglich (die Tilde ist ein erlaubtes Zeichen überall im Dateinamen), es kommt nur der Hinweis wegen der Änderung der File-Extension von ".JPG" in ".tmp"/".TMP"


DMDE 4.2.4.818 Free Edition x64 (jeweils mit "Full Scan" und "Include Raw Search")
  • nach Low-Level-Formatierung (auf der Kamera): keine Einträge gefunden d.h. auch nichts wiederherstellbar.
  • 3 Fotos, letztes gelöscht, Kamera aus, Kamera an, 1 Foto: Nur drei Fotos werden gefunden (das gelöschte wird nicht gefunden und ist entspr. nicht wieder herstellbar, weil vom letzten Foto bereits überschrieben)
    hm08qayvjpyc FullScanAfter3PicsDelLast1NewPic
  • Im Full-Scan-Modus identifiziert DMDE sowohl Hauptbild (4000x3000), also auch Thumbnail (160x120) und (anders als photorec) auch das Preview-Bild (1440x1080)
  • Bilder im Std. Viewer ansehen: keine Änderung
  • Alle Bilder im Std. Viewer drehen (2 Bilder 1x, 1 Bild 2x gedreht, alles in einer Session):
    Für jede Drehung findet man 3 gelöschte Dateien:
    • IMG_<Bildnummer>.JPG~<Kryptischer-Key>.TMP mit Größe 0 (leer)
    • IMG_<Bildnummer>.JPG~<Kryptischer-Key>.TMP mit korrekter Größe (5-6 MB)
    • ~MG_<Bildnummer>.JPG ebenfalls mit korrekter Größe (5-6 MB)

    z6udbjydss0c NormalScanAfterRotating3Imgs4Times1)
    Was das genau bedeutet / wie das zustande kommt ist mir noch nicht ganz klar.
    Jedenfalls wären dieses umbenannten Originaldateien mit DMDE tatsächlich auffindbar.2)


Fazit:
  • Bzgl. Auffinden der (ungedrehten/unveränderten) Original-Dateien die in TMP/tmp-Dateien umbenannt wurden kommt in Frage:
    • Auffinden der gelöschten Dateien durch ein Tool wie DMDE3) - allerdings ist dann etwas unklar warum nicht erwähnt wird dass es zusätzlich noch die tmp-Form gibt (offenbar zweimalige Umbenennung) und warum die dann wiederherstellbaren Originalbilder nicht erwähnt werden, sondern nur Miniaturansichten.
    • ggf. Entfernen der SD-Karte wenn diese Dateien schon umbenannt, aber noch nicht gelöscht wurden, was ich in meinem ersten Test gesehen habe, danach aber bisher nicht nochmal.
    • Mindestens diese beiden Programme kommen als Urheber der TMP/tmp-dateien in Frage:
      • Windows-Fotoanzeige
      • Windows Live Photogallery


  • Bzgl. der 40 gelöschten aber wiederherstellbaren Miniaturansichten existierender Bilder
    • Umbenannte und gelöschte gedrehte Original-Bilder sehe ich weiterhin nicht wie das gehen soll. Es würde, außer in einer ggf. partiell überschriebenen Datei, immer auch das Hauptbild gefunden (von DMDE dann noch zwei kleinere Versionen). Niemals können nur 40 kleinere Versionen gefunden worden sein.
    • Ich halte weiterhin eine Software die verkleinerte Versionen der Bilder als separate Dateien ablegt für die wahrscheinlichste Ursache (außer die ganzen Angaben dazu stimmen überhaupt nicht)
    • Die bisher getesteten Programme (Windows-Fotoanzeige, Windows Live Photogallery, Gimp, Paint) legen allerdings keine separaten Dateien mit verkleinerten Bild-Versionen an
    • DMDE stellt keine Bilder aus Thumb.db Dateien wieder her (die allerdings von Windows auf der SD-Karte auch nicht angelegt, sondern eine von mir testweise dahin kopiert und wieder gelöscht wurde)
    • Manche Programme unter Linux haben früher thumbs folder in jedem Verzeichnis mit Bildern angelegt (z.B. Nautilus) (heute zentral unter $HOME/.cache/thumbnails
    • und das sind PNG-Dateien)





1) Offensichtlicher Bug in DMDE: Die letzte Datei (eines der Preview-Bilder) ist natürlich nicht wirklich 2GB groß (so groß wie die ganze SD-Karte)
2) Die "Filesystem-Inhaltsverzeichnis-Einträge" gelöschter, aber noch nicht überschriebener Dateien blieben offenbar erhalten (werden nur von photorec nicht benutzt)
3) Was WinHex finden würde habe ich aus naheliegenden Gründen nicht getestet.


1x zitiert1x verlinktmelden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 07:31
Kurz angemerkt, dass ich hier natürlich weiterhin mitlese. Und ich sehe, du weißt, was du tust. Langsam wird die Sache rund, jetzt mit den DMDE-Tests/Screens. :Y:

Kleines Brainstorming ..

40 wiederhergestellte Bilder:
Angeblich Thumbnails und "andere" Formate. Es ist sicher, dass Bilder gedreht wurden und die zugehörigen Originale nicht überschrieben wurden. Welcher Forensiker versucht nicht alles wiederherzustellen und zu dokumentieren, was geht? Hier scheinen uns bisher Infos zu fehlen. Auch möglich, dass die 2014er PhotoRec-Version nen Bug oder anderen Algo hatte, also anderes agierte als die 7er Version. Interessant ist, dass bei Mehrfach-Drehungen viele wiederherstellbare Dateien entstehen. Also bei 5 Drehungen pro Original quasi 1 Original + 1 Thumb + 4 Gedrehte + 4 Thumb = 10 wiederherstellbare Bilder pro Original. Bei 40 Bildern würden 4 fünffach gedrehte Originale (Original-Dateiname) reichen. :-)

64 nicht wiederherstellbare Bilder:
Angenommen auf der SD-Karte wurden bis Ende 2013 tausende Bilder gemacht, egal mit welcher Kamera und von wem. Vielleicht auch schon 10x formatiert und noch ältere Daten drauf. Anfang Januar formatiert Lisanne die Karte in der SX270 (nicht Low Level) und macht bis April 609 Fotos. Dann müssten Reste von vor den Formatierungen vorhanden sein. Womöglich ist das ne Erklärung für diese 64 Bilder, denn wenn Lisanne neu formatiert, sind ja alle "Lücken" im Dateisystem weg. Es wird wieder bei Cluster 1 (Datenbereich) begonnen, obwohl irgendwo noch alte Daten liegen. Könnte also theoretisch sein, dass die Reste der 64 Bilder gar nicht von Lisanne sind, sondern zB von ihrem Bruder, der ihr die Karte gab.

Bild #509:
Schon getestet, ob wirklich alle Metadaten (DMDE Scan) im Directory weg sind nach Löschen mit Kamera -> Kamera aus -> weitere Bilder in die Lücke? Vermutlich verschwinden die alten Metadaten dann, wenn der Startcluster des gelöschten Bildes (der ja in den Metadaten referenziert wird) überschrieben wird. Dazu müsste ein Mini-Bild in der Lücke reichen, das nur ein paar Cluster belegt, aber Directory-Metadaten und Signaturkopf des gelöschten JPEG-Bildes zerstört. In dem Fall dürfte DMDE (und PhotoRec?) keinen Verzeichniseintrag, kein Thumbnail und kein 4x3k Bild mehr finden, theoretisch aber das Preview ohne Namen.
Zitat von cycliccyclic schrieb:3) Was WinHex finden würde habe ich aus naheliegenden Gründen nicht getestet.
DMDE halte ich für das bessere Programm für unsere Zwecke (auch besser als PhotoRec). 45d Trial bei WinHex nervt eh. :-) Und DMDE hat auch ne brauchbare (Start-)Cluster Anzeige plus grafische Cluster-Map Spoiler

cluster




melden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 18:38
@OFFshore7

Ich storme auch mal Brain:

Die Release-Notes von photorec bzw. testdisk legen nahe, dass die Änderungen in Version 7 ziemlich überschaubar sind und fast ausschließlich das Build-System betreffen um für mehr Ziel-Platformen kompilierbar zu sein (das dürfte dann auch der Grund sein die Major-Versionsnummer hochzuzählen, trotz praktisch unverändertem Funktionsumfang).

Mit photorec scheint man ohnehin nur alle Einträge eines Speichermediums wiederherstellen zu können (ich sehe keine Möglichkeit eines Vorab-Scans und darauffolgender Auswahlmöglichkeit), wenn die Ermittler also photorec genutzt haben, hätten sie zwangsläufig auch alle früheren gelöschten Dateien wiederhergestellt, bei denen das möglich gewesen wäre.

DMDE ist da komfortabler: es macht einen Scan - ggf. kann man noch einen "Full Scan" (mit Raw-Erkennung) über den gesamten Speicher machen.
Full+Raw-Scan hat bisher bei meinen Tests keinen echten Unterschied gemacht (außer dass dann alle drei eingebetteten Bilder einzeln aufgeführt werden), aber für eine partiell überschriebene Datei könnte diese Option den nicht überschriebenen Rest auffinden und der könnte noch ein oder zwei JPG-kodierte Bildversionen enthalten (als erstes geht das Thumbnail hopps, da vorne in der Datei, danach das dahinterliegende Hauptbild und zuletzt erwischt es das Preview-Bild am Ende der Datei). Aber solche Tests mit absichtlichem partiellem Überschreiben stehen noch aus.

Aber immer noch: Partiell ist unter nicht-esoterischen Bedingungen nur eine Datei überschrieben, vielleicht zwei oder meinetwegen drei, aber sicher keine 40 und dass dann immer genau nur das Preview-Bild übrig bleibt wäre noch viel unmöglicher (falls das noch ginge).
Ansonsten müssten die Angaben in den Akten völliger Blödsinn sein (wobei ich das nichtmal ganz ausschließen würde, nur wo soll man dann noch ansetzen, wenn man restlos alles in Frage stellen muss?)

Zu den 64 Dateien: IP behauptet das. Die Akte scheint nichts davon zu erwähnen. Oder doch?
Ich kann mir 64 (oder sind es vielleicht nur 24 = 64-40?) nicht wiederherstellbare Dateien schon vorstellen. Aber nur einen idirekten Nachweis dafür (fehlende Bildnummern, überschriebene Lücken gefunden mit einem Tool wie filefrag). Und dafür hätte man dan schon bewusst die Bilder von vor Ende März analysieren müssen, was man ja angeblich nicht gemacht hat. Auch 64 Dateien können jedenfalls nicht partiell überschreiben worden sein (s.o.).
Stellt sich noch die Frage, woran man bei einem nur indirekten Nachweis vollständig gelöschter Dateien Videos von Bildern unterscheiden kann? Wenn einzelne Dateien gelöscht wurden (also zwischen zwei Dateien nur eine Bild-/Videonummer fehlt) dann vermutlich an der Größe der (überschriebenen) Lücke (oberhalb einer best. Größe kann es nur ein Video gewesen sein). Bei Lücken, wo mehr als eine Nummer fehlt wird es entspr. uneindeutiger.

Jedenfalls macht das für mich schon nochmal einen Unterschied:
Relativ klar ist: Die 40 Bilder haben mit K & L nichts zu tun, die sind später, wahrscheinlich durch irgendetwas entstanden was die Ermittler in Panama angestellt haben (die sie dann vermutlich auch wieder gelöscht haben).

Aber haben auch K & L während ihrer Zeit in Panama Fotos gelöscht? War das sehr selektiv? Wurden jemals einzelne Aufnahmen direkt nach dem Entstehen wieder gelöscht (ggf. mit demselben "Sektor-an-Sektor"-Effekt wie bei #508/#510)? Wenn nicht ist #509 noch mysteriöser, auch wenn es durch seine spezielle Lage ohnehin außergewöhnlich und erklärungsbedürftig ist.

Auch machen es 64 (24) nur indirekt nachweisbare Dateien schon anspruchsvoller diesen Zustand durch Manipulation absichtlich oder zufällig in einer Art und Weise zu erzeugen, die nicht auffällt (jedenfalls bei genauerer Prüfung, die ja aber nicht stattgefunden zu haben scheint). Gibt es nur die 40 offensichtlich später entstandenen und gelöschten verkleinerten Bildversionen ist der Zustand dagegen einfacher auch vom PC erreichbar (je nachdem was man Anstellen will mit oder ohne zusätzliche Manipulation von Dateinamen, EXIF-Daten und Filesystem-Zeitstempeln)


1x zitiertmelden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 19:35
Zitat von cycliccyclic schrieb:Auch 64 Dateien können jedenfalls nicht partiell überschreiben worden sein (s.o.).
Müssen sie auch nicht, Fragmentierung / Clustersprünge und Verlust des FAT-Gedächtnisses durch Formatierung reichen.


1x zitiertmelden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 21:18
Zitat von OFFshore7OFFshore7 schrieb:Müssen sie auch nicht, Fragmentierung / Clustersprünge und Verlust des FAT-Gedächtnisses durch Formatierung reichen.
Verlust des FAT-Gedächtnisses heißt doch aber (mind.) partiell überschrieben. Aber ja wenn man genug Files in einer best. Art fragmentiert könnte man div. Dateianfänge überschreiben während die Enden die alle weiter hinten liegen müssen erhalten bleiben. Ich habe aber Schwierigkeiten mir eine plausible Sequenz vorzustellen mit der dieser Zustand erreicht werden soll (was mir bisher einfällt ist genauso unrealistisch wie die andere dargestellte Lösung).


melden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 21:57
PS: Achso Formatierung. Ob das beim schnellen Formatieren der Fall ist wäre zu prüfen. Beim Löschen aller Dateien ja nicht.


melden

SD-Karte Filesystem Block/Cluster-Versuche

03.06.2025 um 22:20
Eigentlich wollte ich den Rechner heute nicht mehr anmachen, aber jetzt musste ich es doch wissen. Das ist durchaus witzig.

Vorgehen:
  • Low-Level Formatierung
  • 5 Fotos gemacht
  • Schnelle Formatierung

DMDE zeigt erstmal nichts an. Sprich das "Inhaltsverzeichnis"/"FAT-Gedächtnis" ist weg. Aber nach einem Full-Scan hat er das rekonstruiert. Er kennt die Verzeichnisstruktur und die originalen Dateinamen:
qzpbm7brcb5j FullScanAfterLowLevelFormat5ImagesFastFo
Nun sind diese Dateien alle nicht fragmentiert, aber ich gehe mal davon aus, dass das auch mit fragmentierten Dateien funktioniert (teste ich heute nicht mehr)

PhotRec habe ich auch noch schnell laufen lassen, aber das sagt nichts aus. Der findet so zwar auch alle Bilder (inkl. Thumbnails) könnte aber Probleme haben mit fragmentierten Dateien, falls der das Inhaltsverzeichnis ignoriert (allerdings rekonstruiert er den last-modified Zeitstempel). Das muss ich erst mit wirklich fragmentierten Dateien testen.


1x zitiertmelden

SD-Karte Filesystem Block/Cluster-Versuche

04.06.2025 um 07:00
Zitat von cycliccyclic schrieb:DMDE zeigt erstmal nichts an. Sprich das "Inhaltsverzeichnis"/"FAT-Gedächtnis" ist weg. Aber nach einem Full-Scan hat er das rekonstruiert. Er kennt die Verzeichnisstruktur und die originalen Dateinamen:
Das FAT-Gedächtnis in Form der FAT-Tabellen liegt am Anfang der SD-Karte und wird beim Formatieren idR eliminiert. Verzeichnisdaten / Metadaten hingegen sind technisch gesehen nix anderes als Bilder, die 32 Bytes groß sind (bei kurzen Dateinamen).

In einen einzigen 4K-Cluster bekommst du also 128 "Bilder" (Metadaten-Einträge), danach wird das Verzeichnis fragmentiert und quasi hinter den 128 Bildern oder in Lücken gelöschter Bilder fortgesetzt, verknüpft per FAT-Tabelle (Clusterkette). Wobei der Start-Cluster des Directorys im bei Formatierung überschriebenen Boot-Bereich steht, weshalb DMDE ohne Full-Scan auch nix findet.

5 Fotos = 160 Bytes + Ordner. Machst du nach der Schnellformatierung ein einziges Foto, sollte DMDE keine alten Metadaten mehr finden, da der erste Directory-Cluster überschrieben wurde.

Da die Verzeichnis-Cluster fragmentieren und sich quasi zwischen die Bilddateien legen, kann es durchaus sein, dass Programme wie DMDE solche Verzeichnis-Fragmente finden, die vor einer Formatierung auf der Karte waren. Schon hast du evtl. 64 Dateinamen ohne die Möglichkeit, die zughörigen Bilder wiederherzustellen.


melden

SD-Karte Filesystem Block/Cluster-Versuche

04.06.2025 um 18:56
Schnell bevor ich die Hälfte wieder vergesse:

Ich weiß jetzt woher die kleinen Lücken kommen, die nicht mehr befüllt werden: es sind die Verzeichnisse, die ich in filefrag nie habe ausgeben lassen (ich Depp).

Das "Freigeben" von Lücken hängt mit meinem Equipment nicht davon ab, dass die SD-Karte kurz stromlos gemacht wird, sondern davon, dass ich den USB-SD-Karten-Reader trenne. Nur umount und Entnahme und Zurückschieben der SD-Karte reicht nicht!

Stark fragmentierte Datei erzeugt IMG_2965.JPG (viele Mini-Dateien erzeugt, jede zweite gelöscht und normale SX270-JPG geschrieben):
mkbgvwth1jes MaxFragmentedImage
Nach Löschen (nur) dieser Datei kann photorec die Datei vollständig und korrekt wiederherstellen.
Überraschung: DMDE erzeugt beim Wiederherstellen eine korrupte Datei, glaubt außerdem auch ein paar der von IMG_2965 überschriebenen sehr kleinen JPGs wiederherstellen zu können, aber die sind dann nur korrupter Datenmüll (logisch, denn das sind in Wirklichkeit nun zufällige Ausschnitte aus IMG_2965).

Nachdem ich in die erste Mini-Lücke eine weitere noch kleinere Datei gespeichert habe, kann dann auch photorec nichts mehr finden. Auch das ist ein bisschen überraschend, denn das Ende der Datei (in der Grafik nicht mehr mit drauf), sollte das vollständige Preview-Bild in einem zusammenhängenden Bereich enthalten (aber das muss ich nochmal genauer prüfen).
DMDE zeigt IMG_2965 auch nicht mehr an, aber immer noch die lange gelöschten Mini-Dateien in deren Lücken IMG_2965 saß (Wiederherstellungsversuch erzeugt natürlich weiterhin nur korrupte JPG-Dateien).

Bzgl. Datenrettung scheint photorec doch das bessere Tool zu sein, trotz der rudimentären Bedienmöglichkeiten (DMDE hat doch einige Bugs).

Weitere Tests u.a. bzgl. Formatierung folgen...


melden

SD-Karte Filesystem Block/Cluster-Versuche

04.06.2025 um 22:24
Bei meinem stark fragmentierten Test-Bild-File IMG_2965.JPG oben liegen die letzten ca 1.2 MiB am Ende in einem zusammenhängenden Bereich. Das Preview-Bild nimmt bei diesem Bild die letzten 431310 B ein, liegt also locker in diesem Teil. Warum photorec das Preview-Bild dennoch nicht findet ist unklar (photorec scheint generell die eingebetteten Preview-Bilder nicht zu mögen, selbst wenn das als einzig verwendbarer Teil übrig bleibt).

Noch was anderes: In der Form nur bedingt interessant, aber wenn man ein Fragment mit einem Jpeg-Start erwischt und dann mit irgendwas fortsetzt (wie das DMDE gemacht hat), zeigen übliche Viewer den ersten Teil des Bildes trotzdem korrekt an (hier Gwenview):
56mbmcdiypq1 CorruptJpgWithValidStart


melden

SD-Karte Filesystem Block/Cluster-Versuche

gestern um 18:45
Interessant ist allerdings, dass man den Anfang einer beliebigen Jpeg-Datei und einen zufälligen Teil einer anderen Jpeg-Datei einfach zusammenkopieren kann und dann wird auch der zweite Teil korrekt angezeigt. (gerade getestet).

Voraussetzung beide Teile gehören zur selben Auflösung (z.B. 4000x3000) und haben dasselbe Farbschema etc. Man könnte also Teile eines Bildes retten, wenn man ein komplettes Bild von derselben Kamera hat und auf die Art dann auch mehrere Fragmente zusammenpuzzeln (ggf. wenigstens erkennen, dass sie zum selben Bild gehören).


melden