SD-Karte Filesystem Block/Cluster-Versuche

@Offshore7
Houston - Problem: Ich kann das gerade nicht mehr reproduzieren. Ich bin sicher, dass ich neulich Verzeichniseinträge gelöschter und überschriebener Dateien in ImHex gesehen habe. Aber als ich das gerade nochmal Schritt für Schritt nachvollziehen wollte, sind die Einträge immer sofort verschwunden sobald die Datei überschrieben wurde. Keine Ahnung woher der Unterschied kommt.



Sequenz:
+0064 -> gleich wieder gelöscht
+0065
+0066 -> gleich wieder gelöscht
+0067
+0068
+0069
+0070 -> gleich wieder gelöscht
+0071 (besonders klein, da fast schwarz)
-0068 gelöscht
+0072
-0067 gelöscht
+1165 via PC kopiert

Da ist sogar der Eintrag zu 1165 an die Stelle von 0067 gesetzt worden (zwischen 0065 und 0072)!

Die Speicherbelegung der noch bestehenden Dateien in filefrag sieht so aus (weiß nicht ob das was bringt, aber der Vollständigkeit halber):

@cyclic

Ist die Datei-Nr. 1165 Zufall oder hat das Directory wirklich über 1000 Dateien (inkl. der gelöschten)?

Sobald der letzte Eintrag (1024) geschrieben wurde, werden danach natürlich die vorherigen Lücken gelöschter Dateien gefüllt und die Verzeichniseinträge überschrieben.

Offshore7 schrieb:Ist die Datei-Nr. 1165 Zufall oder hat das Directory wirklich über 1000 Dateien (inkl. der gelöschten)?

Zufall. SD-Karte war frisch formatiert (Low-Level) und nur das letzte Bild habe ich nicht mit der Kamera aufgenommen, sondern einfach eines aus meiner Sammlung vom Rechner draufkopiert. Es gab nie mehr als die 10 genannten Bilder (und die auch nicht gleichzeitig).

Kann es irgendwie an feinen Unterschieden in der Formatierung liegen? Ich habe neulich ein einziges Mal auf meinem alten Win7-Laptop formatiert (sonst immer nur direkt auf der Kamera). Ich bin aber nicht sicher, ob ich auf der so formatierten Karte die Verzeichniseinträge von gelöschten & überschriebenen Dateien gesehen habe. Ansonsten fällt mir gerade nicht viel ein.

@cyclic

Wenn ich mir hier Beitrag von cyclic (Seite 2) den DMDE-Screen anschaue, dann sehe ich 4 gelöschte Einträge 3365, 3366, 3366, 3368 .. wobei 3368 das gelöschte 3365 vollständig überschrieben hat.

Offenbar überlässt es die FAT32-Spezifikation doch dem Betriebssystem, ob und wann gelöschte Einträge recycelt werden. So wie @sceptical sagte, kannst du das dann nur mit der SX270 testen. Am besten erst mal nur 3 Bilder bei Low Level formatierter SD-Karte in der Kamera und gemäß meiner Vorgehensweise hier: Beitrag von Offshore7 (Seite 2)

Ich vermute nach deinen obigen Ergebnissen also, dass es nicht am vollständigen Überschreiben eines Bildes liegt, sondern an der FAT32-Implementierung des OS. Dann sollte es die SX270 aber immer gleich machen und das wäre seltsam:

cyclic schrieb:Ich bin sicher, dass ich neulich Verzeichniseinträge gelöschter und überschriebener Dateien in ImHex gesehen habe.

Obwohl nebensächlich, hier noch, was ChatGPT zum Aufbau des Eintrags ausspuckt:

Spoiler
Hier ist der Aufbau eines Standard- (auch „kurzen“) Verzeichniseintrags (8.3-Dateiname):

---

### 🧱 **Struktur eines 32-Byte-Verzeichniseintrags in FAT32**

| Offset | Größe (Bytes) | Bedeutung |
| ------ | ------------- | ------------------------------------------------------------------- |
| 0x00 | 8 | Dateiname (Name, 8 Zeichen, ASCII, ggf. mit Leerzeichen gepolstert) |
| 0x08 | 3 | Dateierweiterung (Ext, 3 Zeichen, ASCII) |
| 0x0B | 1 | Dateiattribute (z. B. Versteckt, Systemdatei, Verzeichnis, Archiv) |
| 0x0C | 1 | Reserved (für Windows NT, normalerweise 0) |
| 0x0D | 1 | Erstellzeit (Zehntelsekunden, 0–199) |
| 0x0E | 2 | Erstellzeit (in FAT-Zeitformat) |
| 0x10 | 2 | Erstellungsdatum (in FAT-Datumsformat) |
| 0x12 | 2 | Letztes Zugriffsdatum |
| 0x14 | 2 | Höheres Wort (High Word) des Start-Cluster (nur FAT32 relevant) |
| 0x16 | 2 | Letzte Änderungszeit |
| 0x18 | 2 | Letztes Änderungsdatum |
| 0x1A | 2 | Niedriges Wort (Low Word) des Start-Clusters |
| 0x1C | 4 | Dateigröße in Byte (bei Verzeichnissen = 0) |

---

### 🔎 **Erklärung ausgewählter Felder:**

* **Dateiattribute (Offset 0x0B)**: Bitmaske:

* 0x01: Read Only
* 0x02: Hidden
* 0x04: System
* 0x08: Volume Label
* 0x10: Directory
* 0x20: Archive

* **Start-Cluster**:

* FAT32 verwendet 32 Bit für den Startcluster (verteilt über 0x14 + 0x1A). Um den tatsächlichen Startcluster zu berechnen:

```c
startCluster = (high << 16) | low;
```

* **FAT-Zeit-/Datumsformat**:

* FAT speichert Zeit und Datum als Bitfelder:

* **Zeit (2 Byte):**

* Bits 15–11: Stunden (0–23)
* Bits 10–5: Minuten (0–59)
* Bits 4–0: Sekunden/2 (0–29, also Sekunden 0–58)
* **Datum (2 Byte):**

* Bits 15–9: Jahr seit 1980
* Bits 8–5: Monat (1–12)
* Bits 4–0: Tag (1–31)

---

### 📂 Sonderfälle:

* **Gelöschte Dateien**: Wenn das erste Byte auf `0xE5` gesetzt ist, gilt der Eintrag als gelöscht.
* **Freier Eintrag**: Ein Eintrag beginnt mit `0x00`, was das Ende der belegten Verzeichniseinträge signalisiert.
* **LFN-Einträge**: Lange Dateinamen (Long File Names) werden durch spezielle zusätzliche Einträge davor realisiert (Attribut = `0x0F`).

---

Offshore7 schrieb:Wenn ich mir hier Beitrag von cyclic (Seite 2) den DMDE-Screen anschaue, dann sehe ich 4 gelöschte Einträge 3365, 3366, 3366, 3368 .. wobei 3368 das gelöschte 3365 vollständig überschrieben hat.

In dem Versuch wurde gar nichts überschrieben, weil ich da in einer Session (ohne die Karte/den Reader zwischendurch abzustöpseln) mehrere Bilder mehrfach gedreht habe und dabei wird ja freier Speicher nicht neu belegt.

Offshore7 schrieb:Offenbar überlässt es die FAT32-Spezifikation doch dem Betriebssystem, ob und wann gelöschte Einträge recycelt werden. So wie @sceptical sagte, kannst du das dann nur mit der SX270 testen. Am besten erst mal nur 3 Bilder bei Low Level formatierter SD-Karte in der Kamera und gemäß meiner Vorgehensweise hier: Beitrag von Offshore7 (Seite 2)

Das habe ich ja quasi gemacht. Erst ganz am Ende habe ich versuchsweise auch eine Datei vom Rechner draufgeschoben (1165). Alles andere (Formatieren, Fotos machen, Fotos löschen) war auf der Kamera. Und zwischendurch jedesmal mit ImHex gecheckt. Verzeichniseintrag gelöschter Dateien (mit 0xE5 am Anfang) zunächst vorhanden. Dann aber sofort weg wenn Datei überschrieben (teilweise überschrieben reicht, habe extra ein sehr kleines Foto gemacht durch Zuhalten des Objektivs).

Was ich nochmal testen werde ist das Formatieren unter Win7.

cyclic schrieb:In dem Versuch wurde gar nichts überschrieben, weil ich da in einer Session (ohne die Karte/den Reader zwischendurch abzustöpseln) mehrere Bilder mehrfach gedreht habe und dabei wird ja freier Speicher nicht neu belegt.

Aber 3368 beginnt im selben Cluster 4 wie das durch Drehen gelöschte 3365.

Offshore7 schrieb:Aber 3368 beginnt im selben Cluster 4 wie das durch Drehen gelöschte 3365.

Bin ich blind? Wo sind da Cluster ablesbar? Name, ID und Dateigröße sehe ich.

cyclic schrieb:Wo sind da Cluster ablesbar? Name, ID und Dateigröße sehe ich.

Die ID ist der Startcluster. :'D

Verstehe. Ich habe wohl leider bei dem Versuch keine filefrag-Anlyse gemacht und DMDE ist leider voller Bugs (zeigt z.B. manchmal 2GB große Bilder an und andere Scherze).

Ich habe jetzt nochmal getestet: Formatiert unter Win7, formatiert unter Linux. Keine Änderung. Dann habe ich noch die 32GB-Karte aus meiner S120 getestet indem ich auch da ein Bild (das vorletzte) gelöscht und ein neues Bild kopiert habe. Immer sind die Verzeichnis-Einträge gelöschter Bilder verschwunden, sobald der Content (mind. teilw.) überschrieben wurde.

Ich weiß gerade nicht weiter.

Es gibt aber einen blöden Effekt. Bin nicht sicher was davon auf das Konto des Readers, des Rechners und des Tools (ImHex) geht. Jedenfalls muss man aufpassen, dass man wirklich den aktuellen Zustand und nicht irgendwas gecachtes sieht.

Versuch alles auf der Kamera:

1. Low-Level-Formatierung (mal wieder)
2. 3 Bilder: 73, 74, 75
3. Monat auf Juli vorgestellt
4. 1 Bild: 76
5. Bild 74 wieder gelöscht
6. Kamera aus/an
7. Noch 1 Bild: 77

Ergebnis: der Verzeichniseintrag von Bild 74 ist noch da, obwohl Bild 77 den gleichen Speicherbereich belegt.

166 Bilder/Vidos vor der Reise aufgenommen (#167 ist erstes Reisebild) 470 + 7 = 477 Images/Videos auf SD 33 + 0 Pianista/Mirador/Q1 (01.04) 100 + 0 Nacht (08.04) 337 + 7 = 344 < 01.04. existierende Bilder gefunden 475 < 01.04. mit der Camera aufgenommen (Januar - 31.03.) 131 gelöscht ENTWEDER: 64 + 4 = 68 gelöscht mit Spuren (FAT-Verzeichniseinträge) 63 gelöscht ohne Spuren (nur fehlende Bild/Video-Nummern) ODER: 24 + 4 = 28 gelöscht mit Spuren (FAT-Verzeichniseinträge) 103 gelöscht ohne Spuren (nur fehlende Bild/Video-Nummern)

Es wurde nie eine Datei sofort gelöscht - d.h. vor der nächsten Aufnahme (abgesehen evtl. von #509)

Zeiträume möglicher Löschungen der 68 / 28:
- Januar-Dateien nach letzter Januar-Aufnahme
- alle Februar-Dateien (falls es welche gab) vor erster März-Aufnahme
- März-Dateien nach letzter März-Aufnahme
- alle so dass sie noch überschrieben wurden (spätestens von gedrehten Bildern und 40 Miniaturansichten)
- April keine
- theoretisch nur nach #609 aber
- dann wären spätere gedrehte Bilder (und ggf. Miniaturansichten) in diese Lücken gewandert
- (bedingt auch dass Drehungen und Erzeugung Miniaturansichten unter Windows erfolgte, da sonst FAT-Verzeichniseinträge verschwunden wären)

@cyclic

Ich würde noch ein beispielhaftes Szenario hinzufügen:

28. März: 54+4 "März-Dateien" gelöscht, zB u.a. von einem Ausflug am 20.3. :-)
31. März: 30 neue Fotos bis 31.3. überschreiben die ersten 30 0xE5-Einträge und natürlich die Cluster der ersten gelöschten Dateien
01. April: 24+4 0xE5 Einträge verbleiben, da Wechsel Directory-Cluster 03->04
08. April: Alle Cluster der 54+4 (54*4 + 4*30 = 336 MB) überschrieben ==> 30x4 + 33x4 + 100x1 = 352 MB

@Offshore7
Das ist ein sehr guter Einwand: Dateien können doch schon vorher gelöscht worden sein solange sie im selben Monat noch nicht überschrieben wurden.
(ich glaube zwar dass das stimmt / stimmen muss, aber würde auch das sicherheitshalber auch nochmal testen wollen)

Ganz theoretisch könnten sogar alle nicht vorhandenen Dateien gleichzeitig im März gelöscht worden sein.

Bzgl. 64+4 oder auch nur 24+4 bedeutet das aber weiterhin dass die erst im April überschrieben wurden - wenn alle gelöschten Dateien vom März (101___03) sind.

Bist du jetzt eher bei 24 als 64? Ich bin da weiterhin unschlüssig (24 wären wohl leichter erklärbar).

Es gibt ohnehin wieder zu viele Unsicherheitsfaktoren. Gelöschte Aufnahmen können schon im Januar und sogar Februar gemacht worden sein. Wenn ich nur die Ordner ansehe, würde ich aber eher darauf tippen, dass im Januar nur eine handvoll Testfotos gemacht wurden, die Kamera im Februar in der Ecke lag und erst im März wieder benutzt wurde. Hätten sie z.B. jemals Bilder auf einen Rechner transferiert, hätte das die Chancen deutlich erhöht, dass mal das falsche Jahr aufgefallen wäre. Wenn alle gelöschten Files aus dem März wären, wäre die Anzahl gelöschter Dateien und der offenbar späte Löschzeitpunkt schon extrem auffällig. Aber beweisen kann man wieder nix...

Offshore7 schrieb:28. März: 54+4 "März-Dateien" gelöscht, zB u.a. von einem Ausflug am 20.3. :-)

64 Bilder passen bei ihrer durchschnittlichen Fotoquote halt schon zu 2 Tagen, die da fehlen.

cyclic schrieb:Bist du jetzt eher bei 24 als 64? Ich bin da weiterhin unschlüssig (24 wären wohl leichter erklärbar).

Matt "interpretiert" 24+4, obwohl es nicht klar ist, dem würde ich mich erst mal anschließen.

cyclic schrieb:Es gibt ohnehin wieder zu viele Unsicherheitsfaktoren.

Leider. :|

cyclic schrieb:64 Bilder passen bei ihrer durchschnittlichen Fotoquote halt schon zu 2 Tagen, die da fehlen.

Ah stimmt .. meinte ich ja .. Ausflug mit Übernachtung. :-)

#

Noch eine Sache zum mutmaßlichen Funktionsumfang von Encase, das das sicher auch konnte. WinHex hat eine Funktion, womit man den Schlupfspeicher easy extrahieren und in einer neuen Datei speichern kann:

Im selben Monat löschen, nur teilweise überschreiben und erst im nächsten Monat die restlichen überschreiben funktioniert: Verzeichnis-Einträge im neuen Monat überschriebener Dateien bleiben sichtbar.
Hatte kurz befürchtet, dass der alte Ordner evtl. "aufgeräumt" wird wenn ein neuer angelegt wird, aber das ist nicht der Fall.

Offshore7 schrieb:Noch eine Sache zum mutmaßlichen Funktionsumfang von Encase, das das sicher auch konnte. WinHex hat eine Funktion, womit man den Schlupfspeicher easy extrahieren und in einer neuen Datei speichern kann:

Ah, cool. Wäre auch merkwürdig wenn EnCase das nicht könnte. Nur ob man das auch tatsächlich gemacht hat, ohne es explizit zu erwähnen ist fraglich. Bis in die Haarspitzen motiviert war man beim NFI bzgl. Kamera scheinbar auch nicht, oder man hat vieles nicht dokumentiert.

Offshore7 schrieb:Matt "interpretiert" 24+4, obwohl es nicht klar ist, dem würde ich mich erst mal anschließen.

24 sind weniger als die 33 vom 1.4. :-/ Ist ansonsten natürlich einfacher (eher alle überschrieben). Dann fehlen noch 103 andere Bilder/Videos (ohne Verzeichnis-Einträge / Reste).

PS: Diese Ordnernummernlogik ist schon skurril, bei neuer / neu formatierter Karte zählt das Ding stumpf weiter hoch. Aber wenn ich den letzten Ordner lösche, dann wird dessen Nummer neu vergeben.

Morgen, werde meine Beiträge zukünftig hier verfassen. Wo bekommt man die Kamera für nur 40-80 EUR, auf eBay zahle ich dafür locker über 100 EUR. Das ist mir wirklich zu teuer. EnCase gibt es wohl nicht als Freeware, wie es aussieht.

Also, der Test zeigt zumindest, dass man sich hier nicht sicher sein kann, ob 509 tatsächlich im Datenbereich direkt hinter 508 abgelegt war. Damit wird die Sache noch schwieriger, aber von irgendwas muss 509 trotzdem überschrieben worden sein. Wenn nicht von den Nachtaufnahmen, dann kommen nur noch temporäre Daten oder eventuell doch ein Löschprogramm in Frage.

sceptical schrieb:Wo bekommt man die Kamera für nur 40-80 EUR, auf eBay zahle ich dafür locker über 100 EUR. Das ist mir wirklich zu teuer.

Man braucht etwas Geduld. Meine habe ich in der Bucht geschossen. Kleinanzeigen hat sonst auch noch gute Chancen.

sceptical schrieb:Also, der Test zeigt zumindest, dass man sich hier nicht sicher sein kann, ob 509 tatsächlich im Datenbereich direkt hinter 508 abgelegt war.

Welcher Test zeigt das warum? Es kann im Endergebnis keine andere Datei zwischen #508 und #510 gelegen haben, das geht eindeutig aus dem Bericht hervor. Es kann zwischendurch eine Datei #509 gegeben haben, die vor #510 gelöscht und durch #510 überschrieben wurde (ggf. #510 und folgende, aber #510 hätte bereits dafür gesorgt, dass der Verzeichniseintrag verschwindet).

Dein Test zeigt dass, 0077 liegt ja auch nicht mehr hinter 0076. Somit kann es also auch sein, dass 509 nicht hinter 508 abgelegt war, sondern woanders und 510 gar nichts Überschreiben hat.

sceptical schrieb:Somit kann es also auch sein, dass 509 nicht hinter 508 abgelegt war, sondern woanders und 510 gar nichts Überschreiben hat.

Weiß nicht genau, ob ich verstehe was du meinst, aber folgendes wäre denkbar:

Es könnte nach #508 / vor #509 eine frühere Datei X gelöscht worden sein, dann wäre #509 statt hinter #508 in den Bereich von X geschrieben worden, ja.

Falls und nur falls #509 und X ungefähr gleich groß waren (exakt gleiche Anzahl Cluster), dann wäre #510 direkt hinter #508 geschrieben worden (wie lt. Akten der Fall). In dem Fall hätte dann #509 später gelöscht worden und durch ein anderes der 100 Nachtbilder überschrieben worden sein können (Content und Verzeichniseintrag von #509 damit dann verschwunden).

Soweit so gut, aber ein paar Probleme gibt es:

- eine so ähnliche Dateigröße ist unwahrscheinlich - die Größe von Bildern (und erst recht von Videos) variiert erheblich.

- mind. eines der Bilder #512 - #609 wäre aus der Reihe gewesen - nämlich da wo zunächst X und dann #509 war. Ob man das allerdings untersucht hat ist unklar.

- dass man nach #508 genau ein einziges früheres Bild gelöscht hat ist auch wahnsinnig unwahrscheinlich (mind. für K & L, aber auch sonst wüsste ich keinen plausiblen Grund)

Insofern, interessante theoretische Variante, allerdings nicht wirklich von Bedeutung, soweit ich sehe. Oder welche anderen Varianten siehst du noch?

PS: Man könne aus X noch mehrere Dateien machen, die zusammen exakt dieselbe Clusteranzahl wie #509 belegt haben, aber das macht es nicht wahrscheinlicher.

Nein, ich meine, dass 509 genutzt wurde, um eine Lücke irgendwo davor zu schließen, so, wie es 077 in deinem Test auch gemacht hat, und danach 510 wieder normal hinter 508 abgespeichert wurde, ohne eine gelöschte Datei zu überschreiben. In diesem Fall ist nur die Frage, was dann 509 überschrieben hat. Ich habe hier den Verdacht, dass die TMP-Dateien etwas damit zu tun haben könnten. Ist hier geklärt, wer hier die Bilder 505 bis 507 bearbeitet hat?

Gibt es eigentlich den NFI-Bericht irgendwo offiziell zu lesen? Im Testbericht von IP finde ich nur kurze Auszüge. Und woher hat IP diese ganzen Informationen, sind das nicht einfach nur normale Reise-Blogger?

OK, ich sehe gerade, dass du mich doch richtig verstanden hast.

Ich spreche aber von einer Lücke davor, wo soll danach auch bitte eine Lücke sein, wenn noch nichts abgespeichert war.

Wie kommst du darauf, dass die gleiche Anzahl von Clustern vorliegen muss. Unter welchen Bedingungen eine Lücke geschlossen wird, kann von ganz vielen Faktoren abhängig sein. Da kann trotzdem noch etwas übrig bleiben oder eine größere Datei kann über mehrere Lücken fragmentiert abgespeichert werden.

Ich vermute, dass 507 und 508 Testbilder sind. Daher würde das Löschen von Bildern generell in diesem Moment reinpassen. Auch irgendein Bild vorher. Es steht hier generell die Frage im Raum, warum überhaupt gelöschte Einträge noch da waren. Im April scheint sonst kein einziges Bild eine gelöschte Datei davor gelöscht zu haben. Das schon finde ich etwas merkwürdig. Steht irgendwo im Bericht, wie viele wiederhergestellte Bilder überhaupt noch einen Gelöscht-Eintrag hatten ?