SD-Karte Filesystem Block/Cluster-Versuche

Könnte es eventuell sein, dass du bislang dir nur Sektorinhalte von Dateien angesehen hast, bei denen Windows oder Linux die Datei auf den Datenträger geschrieben hat?

So, habe das ganze nochmal in der Einstellung Large und 4:3 getestet. Ändert sich nix.

Übrigens: Es werden nicht alle Überhangsektoren überschrieben, sondern nur 32 Stück, sofern mehr übrig bleiben. Die restlichen 32 Sektoren sind immer noch mit 0xFF initalisiert.

Hier mal ein vollständiger dieser Überhangsektoren:

Bezüglich der Katalogdateien. Wenn man mit der Kamera Bilder löscht, werden die Einträge bei mir nicht aus der Katalogdatei entfernt? Auch, wenn ich danach in den Viewer-Modus wechsele.

Ich habe 4 Bilder aufgenommen und danach 2 wieder gelöscht:



Die aktuelle Katalogdatei enthält trotzdem noch 4 Einträge



BTW: Bei dem Problem mit den Resten in den Sektoren hatte ich eine MicroSD-Karte mit 16GB getestet, die in einem Adapter (microSD->SD) steckt. Die o.g. Bilder stammen von einer echten SD-Karte mit 4GB. Da taucht nur noch die Boot-Sektor-Kennung im letzten Sektor auf und die formatierten Sektoren sind jetzt mit 0x00 beschrieben.

Habe es jetzt mit der Situation wie bei 509 getestet, da ist der Eintrag nicht mehr vorhanden. Der Eintrag einer gelöschten Dateien bleibt also scheinbar auch in der Katalogdatei solange erhalten, bis der Gelöschteintrag überschrieben wird.

@sceptical
Da kommen mir mehrere Sachen komisch vor und ich bin eigentlich relativ sicher, dass ich z.B. bzgl. CTG anderes gesehen habe. Aber ich werde das nochmal gezielt nachstellen. Bin noch nicht dazu gekommen und teilweise war es mir auch einfach zu warm um mich noch von meinem Rechenknecht warm anblasen zu lassen.

sceptical schrieb:Bezüglich der Katalogdateien. Wenn man mit der Kamera Bilder löscht, werden die Einträge bei mir nicht aus der Katalogdatei entfernt? Auch, wenn ich danach in den Viewer-Modus wechsele.

Ich verstehe nicht was du da schreibst. Auf der Kamera kannst du Bilder ausschließlich im Viewer-Modus löschen. Du musst also nicht noch in den Viewer-Modus wechseln um irgendetwas upzudaten. Das ist nur nach Aufnahme von neuen Bildern teilw. nötig (wenn es um die CTG-Dateien geht).

Wenn ich von Katalog-Dateien schreibe meine ich immer die Canon-Catalog-Dateien (*.CTG) die im Ordner /DCIM/CANONMSC/ liegen (eine je Monat).

Gerade nochmal folgendes getestet:

1. 4 Bilder aufgenommen: entsprechende CTG ist 948 B groß (868 B + 20 B je Bild)
2. 1 Bild auf der Kamera gelöscht (wiederherstellbar z.B. mit PhotoRec): CTG ist 928 B groß
3. 1 weiteres Bild auf PC gelöscht (wiederherstellbar z.B. mit PhotoRec), danach in der Kamera den Viewer-Mode aktiviert: CTG ist 908 B groß

=> Die CTG enthält keine Sektionen zu gelöschten Dateien, weder wiederherstellbare noch endgültig überschriebene.

Du redest aber offenbar von FAT32-Verzeichniseinträgen. Bitte nenne das nicht "Katalogdateien", da das extrem missverständlich ist. Das Thema "Verzeichniseinträge" haben wir lang und breit erörtert. Ja die bleiben erhalten auch wenn man die Datei löscht (mit einem Marker, dass die Datei gelöscht ist). Das Verhalten ist etwas unterschiedlich zw. Canon/Linux auf der einen und Windows auf der anderen Seite. Bei Canon/Linux ist es so, dass der Verzeichniseintrag verschwindet sobald der Speicherbereich durch eine neue Datei überschrieben wird, WENN dabei das Verzeichnis angefasst wird (d.h. hier i.d.R. nur wenn die neue Datei im selben Monats-Ordner liegt). Unter Windows bleibt der Verzeichniseintrag selbst dann erhalten, wenn deren Speicherbereich von einer neuen Datei überschrieben wird (wäre das Verhalten auf der Kamera so wie unter Windows, dann könnte man ein Löschen von #509 auf der Kamera komplett ausschließen, weil man dann den Verzeichniseintrag hätte finden müssen). S.a.: Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon (Seite 1172) (Beitrag von cyclic)

---

sceptical schrieb am 28.06.2026:Könnte es eventuell sein, dass du bislang dir nur Sektorinhalte von Dateien angesehen hast, bei denen Windows oder Linux die Datei auf den Datenträger geschrieben hat?

Nein, das habe ich zwar auch getestet (@Offshore hat ja die o.g. lustige Eigenart entdeckt, dass das mit dem Löschen unter Windows anders als unter Linux und auf der Kamera funktioniert), aber hauptsächlich habe ich das Verhalten der Kamera getestet (Schreiben/Aufnehmen und Löschen mit der Kamera).

---

sceptical schrieb am 28.06.2026:Übrigens: Es werden nicht alle Überhangsektoren überschrieben, sondern nur 32 Stück, sofern mehr übrig bleiben. Die restlichen 32 Sektoren sind immer noch mit 0xFF initalisiert.

Den Satz verstehe ich auch noch nicht. Wer überschreibt wann nicht alle Überhangssektoren? Ein Cluster (32768 B) besteht aus 64 Sektoren (a 512 Byte). Je nach Dateigröße der Datei wird sie in ihrem letzten Sektor 1 bis alle 64 Sektoren nutzen. Ein genutzter (angekratzter) Sektor wird vollständig "überschrieben" (technisch ist das entweder re-initialisierter Speicher, oder welcher der durch das Wear-Leveling ohnehin physikalisch ganz neu zugeordnet wurde). Die übrigen 0-63 Überhangssektoren bleiben erhalten. Wann werden davon jetzt (nur) die ersten 32 überschrieben (bzw. wann werden die denn überhaupt überschrieben)? Doch nur wenn auch die überschreibende Datei wiederum gelöscht und überschrieben wird und da hängt es einfach von der Größe der überschreibenden Datei ab, wieviele Sektoren sie überschreibt.

---

Die Bytefolge AA 55 kommt auf meiner derzeitigen Test-SD-Karte mit 62 Bildern 2390 mal vor. Bis auf das erste scheinen das alles normale Daten mitten in Bildern zu sein. Nur ganz am Anfang im ersten Sektor (definiert das FAT-Filesystem) kommt er tatsächlich am Ende des Sektors vor. Aber das hat ja mit den Bildern nichts zu tun und der Sektor ist bei einem entspr. FAT-Formatierten Datenträger natürlich immer da (auch wenn ganz frisch formatiert). Das hier hilft vielleicht weiter:
https://stackoverflow.com/questions/79324973/reading-boot-sector-and-bpb-structure-of-fat32-sd-card

cyclic schrieb:Wenn ich von Katalog-Dateien schreibe meine ich immer die Canon-Catalog-Dateien (*.CTG) die im Ordner /DCIM/CANONMSC/ liegen (eine je Monat).

Gerade nochmal folgendes getestet:

Ne, ich rede auch von den Katalogdateien. Wenn du es nicht verstehst, werde ich es später nochmal näher ausführen, wenn ich Zeit dazu habe.

cyclic schrieb:Den Satz verstehe ich auch noch nicht.

Es ging um die ominösen Inhalte in den Überhangsektoren, die eigentlich nach der Formatierung nicht da sein sollten. Diese befinden sich nicht immer in allen Überhangsektoren. Wenn mehr als 32 Überhangsektoren übrig bleiben, finden sich diese nur bis zum Sektor 31, Sektor 32-63 sind immer noch initalisiert. Das tritt aber auch nur bei meiner microSD-Karte auf, bei der normalen SD-Karte finde ich tatsächlich keine Datenreste nach Formatierung in den Überhangsektoren mehr. Allerdings gibt es auch da die Boot-Sektor-Kennung im letzten Dateisektor. Woher diese Reste kommen, weiß ich auch nicht, darum geht es ja. Es scheint übrigens nicht an der Kamera zu liegen, wenn ich Dateien mit Linux auf den Datenträger kopiere, passiert es da auch. Da die Inhalte von anderen Programmen ebenso angezeigt werden, scheint es auch kein BUG in Forex zu sein.

cyclic schrieb:Die Bytefolge AA 55 kommt auf meiner derzeitigen Test-SD-Karte mit 62 Bildern 2390 mal vor. Bis auf das erste scheinen das alles normale Daten mitten in Bildern zu sein.

Naja, du hättest dir ja einfach nur ein paar letzte Sektoren von mit der Kamera aufgenommenen Bilddateien anschauen brauchen. Also, bei dir passiert das nicht und du hast auch keine Reste in den Überhangsektoren, richtig? Dann frage ich mich, wo die bei mir herkommen.

cyclic schrieb:Nur ganz am Anfang im ersten Sektor (definiert das FAT-Filesystem) kommt er tatsächlich am Ende des Sektors vor.

Das ist völlig normal, diese Kennung findet man in alle gängigen Boot-Sektoren (ist auch nicht direkt von FAT vorgegeben) und auch im MBR. In diesem Sektor sind grundsätzliche Kennwerte des Dateisystems (Klustergröße etc.) hinterlegt und je nach Formatierung eventuell auch sogenannten Loader-Code, der dazu gedacht ist, ein auf diesem Volume installiertes System zu booten (deswegen auch Boot-Sektor).

@cyclic

Übrigens, von welchem Programm stammt eigentlich dein Screen-Shot? Forex hattest du auch noch nicht getestet, oder?

sceptical schrieb:Ne, ich rede auch von den Katalogdateien

Aber dein Screenshot zeigt Verzeichniseinträge wo das erste Byte anzeigt dass du Bild 24 und 27 gelöscht hast (während 25 und 26 noch da sind).
Den Inhalt der CTG-Katalogdateien kann man nicht lesen. Es scheint nirgends einen freien Parser dafür zu geben (es scheint mehrfach die Bildnummer darin aufzutauchen aber das war's dann auch). D.h. du kannst nur anhand der Dateigröße der CTG erkennen wieviele Bilder sie umfasst.

Drive-Slack habe ich gerade nochmal mit frisch formatierter SD-Karte getestet. Du hast wohl Recht, dass die letzten 2 Bytes des letzten tatsächlich genutzten Sektors jedes Bilds mit 0x55 0xAA beschrieben werden (die ungenutzten Bytes davor mit 0x00). Das ist mir in dem Wust sonst. 55AAs vorher nicht aufgefallen.

Aber dass bei mehr als 32 Sektoren im Drive-Slack trotz vollständiger Formatierung noch Daten wären ist bei mir nicht so.
Hier ein Bsp. Drive Slack ist mehr als 40 Sektoren groß, aber bis zum Anfang der nächsten Datei (bei 0x5A0600) ist alles ordentlich mit 0xFF initialisiert.



Nun könnte es theoretisch noch ein Zufallselement geben, evtl. auch abhängig davon wie voll die SD-Karte vorher mal war. Allerdings glaube ich das nicht und meine SD-Karte war schon gut gefüllt.

sceptical schrieb:Übrigens, von welchem Programm stammt eigentlich dein Screen-Shot?

ImHex (wie eigentlich immer wenn ich einen Hex-Editor brauche).

@sceptical

Ich habe mal noch mit einigen Dateien mehr getestet. 23 Bilder auf frisch formatierter SD-Karte. Ich sehe teilweise "Daten" im letzten benutzten Sektor (also der Sektor in dem die Datei tatsächlich endet), direkt nach dem Dateiende (JPEGs enden immer mit FF D9). Sieht so aus:


Die Datei endet direkt vor dem selektierten Bereich, der Rest des Sektors ist selektiert.

Das sind aber wahrscheinlich keine Überreste alter Daten. Bei mir steht da immer exakt dasselbe Pattern drin. Es endet mit:

EC 22 83 C0 1E B4 D0 C0 31 6D A8 4E 07 AF A5 44 D9 56 19 38 14 D0 86 E1 8E 40 E5 40 E4 D3 99 B0 09 03 00 F4 CF A5 30 67 FF D9 2A 8A A2 AA 2A AA

• 9x sehe ich nach FF D9 dann 00 bis zum Sektor-Ende, wobei die letzten beiden Bytes dann 55 AA sind
• 14x sehe das obige Pattern (und das sind glaube ich die Bilder die ich erst in einem zweiten Schwung geknipst habe, nachdem ich zwischendurch am Rechner gecheckt habe)

Und diese scheinbaren "Daten" sind wahrscheinlich eher Zufall. Jedenfalls sind es keine Left-Overs alter Dateien, sondern wurden neu geschrieben (Sektoren werden komplett erased). Dieses Vollschrieben mit mehr oder weniger Random-Datensalat ist normal, ich habe da mal irgendetwas gelesen. Müsste ich aber erst wieder suchen.

Selbst wenn das aus irgendeinem irren Grund Reste einer alten Datei wären kann man mit max 511 B Jpeg-Daten ohnehin nichts anfangen (echter Drive-Slack kann ja immerhin bis zu 32256 B lang sein, wenn man ganz viel Glück hat).

In den Bereichen in denen sonst tatsächlich Dateireste übrig bleiben können, nämlich in den komplett ungenutzten Sektoren die den letzten Cluster auffüllen, sehe ich weiterhin keinerlei Daten nach einer Low-Level-Formatierung (da ist alles 0xFF).

PS: Das entspricht dem was du hier beschrieben hast: Beitrag von sceptical (Seite 7)
Was du vorher hier Beitrag von sceptical (Seite 7) im letzten Screenshot zeigst sieht anders aus, weil da erst nach der Sektor-Grenze noch Daten zu stehen scheinen, aber ich weiß nicht wirklich was ich da sehe. Das kann ich jedenfalls so nicht reproduzieren.

cyclic schrieb:9x sehe ich nach FF D9 dann 00 bis zum Sektor-Ende, wobei die letzten beiden Bytes dann 55 AA sind

Danke für die Bestätigung.

cyclic schrieb:PS: Das entspricht dem was du hier beschrieben hast: Beitrag von sceptical (Seite 7)
Was du vorher hier Beitrag von sceptical (Seite 7) im letzten Screenshot zeigst sieht anders aus, weil da erst nach der Sektor-Grenze noch Daten zu stehen scheinen, aber ich weiß nicht wirklich was ich da sehe. Das kann ich jedenfalls so nicht reproduzieren.

Wie ich eigentlich schon erwähnt hatte, stammt ein Screen-Shot von einer microSD-Karte. Nur dort tauchen in den Überhangsektoren Daten auf. Bei meiner normalen SD-Karte (4GB) sind die wie bei dir alle initalisiert (allerdings mit 0x00), nur die Daten im letzten Sektor finden sich auch dort. Ich verstehe aber immer noch nicht wo diese Daten herkommen. Ich habe Forex jetzt mit 3 verschiedenen USB-Sticks und einer GPT-Partition auf meiner Festplatte getestet. Dort finde ich weder Daten im letzten Sektor noch in den Überhangsektoren. Das passiert scheinbar nur bei der (micro)SD-Karte. Mich würde interesssieren, ob diese Reste durch die auf die Karte schreibende Software oder die Hardware entstehen.

cyclic schrieb:Und diese scheinbaren "Daten" sind wahrscheinlich eher Zufall.

Naja, die in 0x55AA endenden Daten sind zumindest keine "Zufallsdaten".

Grundsätzlich könnte es z.B. daran liegen, dass schlichtweg die Software den Sektor vor dem Schreiben auf die Karte im Speicher nicht initalisiert. Die Daten werden in der Regel nicht direkt auf die Karte geschrieben. Da gibt es irgendwo im Speicher 512Byte, in denen der
Sektorinhalt gespeichert ist. Wenn dann der Sektor nur bis zum Dateiende geschrieben wird und dieser Speicher vorher nicht neu initalisiert wurde, dann liegen da nach dem Dateiende noch Restdaten rum, die dann auf Karte landen könnten. Sowas glaube ich hier aber nicht, weil ich das selbe auch habe, wenn ich Dateien mit Linux auf den Datenträger schreibe. Auch hierbei kommt es nur bei der (micro)SD-Karte vor (mit gleichem Resultat). Daher glaube ich eher, dass es an der Hardware (den Karten) liegt.

Vielleicht könnte @Offshore7 uns hierrüber aufklären?

sceptical schrieb:Vielleicht könnte @Offshore7 uns hierrüber aufklären?

Leider nein. Wenn es immer dasselbe Pattern ist, scheiden Wear Leveling und Slack Space aus. Slack Space würde auch niemals immer genau im letzten Sektor der Datei enden. Außer es wäre RAM Slack, also dass der Sektor mit Zufallsinhalten aus dem RAM aufgefüllt würde.

Theoretisch könnten es auch nicht initialisierte Pufferdaten zB des JPG-Encoders der Kamera sein. Aber warum der letzte Sektor mal mit Nullbytes (0x00) und mal anscheinend mit undefinierten Daten gefüllt wird, erschließt sich mir nicht. Slack Space im Sinne von alten Dateien (bis zu 32 KiB -1) ist es aber eher nicht und wäre mit max. 511 Bytes forensisch sowieso unbrauchbar.

Möglicherweise zeigen bestimmte Tools nach Dateiende auch nicht die physischen Daten an oder der Controller spinnt sich was zusammen. Kein Plan.

@Offshore7
@sceptical

An den Tools liegt es nicht, denke ich. Auffällig ist ja dass man direkt nach der Formatierung hinter allen direkt im selben Zug geschossenen Bildern alles 00 und dann 55 AA sieht - genau wie im ersten Sektor (FAT-Sektor). Das wird kein Zufall sein. Und dann nach Aus- und wieder Einschalten ein anderes Pattern sieht, dass wieder für alle dann geschossenen Bilder gleich ist (bei mir kam gestern der JPEG-End-Tag FF D9 drin vor, aber das kann Zufall sein). Merkwürdig ist nur, dass das ein Buffer zu sein scheint, der sonst gar nicht benutzt wird, denn das Pattern bleibt ja immer gleich innerhalb einer Session.

Aber ich glaube auch dass das zu nichts führt. Sehr sicher sind das von der Kamera generierte Daten und keine Reste gelöschter Daten auf dem Datenträger und zu klein um damit was anfangen zu können sind sie eben auch noch.

@Offshore7
@sceptical

Müsste man noch ausgiebiger testen, ob das Auffüll-Pattern im letzten genutzten Sektor während einer Session wirklich immer gleich bleibt - aber wenn das so ist, dann wäre es die einzige mir bekannte Möglichkeit festzustellen, ob die Kamera zwischen zwei Aufnahmen ausgeschaltet wurde. Bei den Nachtaufnahmen könnte das evtl. nicht ganz uninteressant sein (auch wenn ich jetzt nicht genau wüsste was man daraus in jedem möglichen Fall dann ableiten könnte).

Nur bräuchte man dafür nicht nur die Originaldateien, sondern einen echten forensischen Abzug der SD-Karte. Also extremst unwahrscheinlich.

Ach ich habe mich erinnert wo ich das mit den Zufallsspeicherwerten im "RAM-Slack" gelesen habe (der wohl auch deshalb so genannt wird):
https://de.wikipedia.org/wiki/Slack_(Dateisystem)

@Offshore7
@sceptical

Aus rein akademischen Interesse habe ich noch einen Versuch gemacht und dabei jeweils um die 10 Bilder gemacht, die Kamera aus- und wieder eingeschaltet und weitere ~10 Bilder gemacht. Ergebnis ist, wie fast schon erwartet:

Die Bilder einer Session haben jeweils alle dasselbe RAM-Slack-Pattern.

Allerdings wird das im vorderen Bereich durch neue Dateien überschrieben. Wenn ein geschossenes Bild z.B. nur 6 B in RAM-Slack übrig lässt, dann ändert sich das Pattern für die übrigen Bilder bis Byte 512-6 und nur die letzten 6 bleiben wie vorher. Es sieht so aus als habe die Kamera einen Buffer der nur genau den jeweils letzten Sektor umfasst (egal wie groß die jeweils nächste zu schreibende Datei ist).

Die offensichtliche Frage ist nun: wo kommt das initiale Pattern her? Nach dem Formatieren ist es ziemlich klar, da wurde dieser Buffer mit dem FAT-Sektor gefüllt und entsprechend ist das Pattern 00 ... 00 55 AA. Vor dem Formatieren war der Buffer schon mit einer anderen Bytefolge gefüllt, die nur durch das Formatieren überschrieben wurde.

Das eigentliche initiale Pattern scheint immer zu enden mit 2E DA 32 AA 2E CE. Davor meist (aber nicht immer) der JPEG End-Tag FF D9. Ich vermute die Kamera erzeugt irgendwie ein Zufallsbild, was entweder immer dieselbe Größe hat oder sie füllt den Buffer von hinten auf - richtet ihn also am JPEG-Ende aus. Ein bisschen merkwürdig ist das schon.

Die Vermutung auf die ich hinauswollte hat sich aber soweit bestätigt: Man kann damit recht gut (von Ausnahmen wo kein RAM-Slack übrig bleibt abgesehen) nachvollziehen, ob die Kamera zwischen zwei Aufnahmen ausgeschaltet wurde oder nicht. Helfen wird es nix, aber irgendwie lustig was man noch so alles herausfinden kann...

PS: Lässt man die Kamera zwischendurch in den Stand-By gehen (1 Minute keinerlei Bedienung), bleibt das Füll-Pattern unverändert.

PPS: Und diesmal endet das Pattern nicht mit 2E DA 32 AA 2E CE und davor steht auch kein FF D9 (JPEG End). Die Regel kann man also gleich wieder vergessen.

@cyclic

Wenn ich das richtig verstehe, könnte man mittels RAM Slack also evtl. feststellen, ob zB das Haarfoto später den Nachtfotos hinzugefügt wurde oder realer Teil der Nacht-Session war? Standby vorher UND nachher kann man bei den 3 Hauptverdächtigen #550, #576 und #580 ja ausschließen.

Oder ob alle Nachtfotos erst später der SD hinzugefügt wurden, insofern die alle keinen RAM-Slack hätten. Oder dass die Mirador-Bilder #496 bis #502 einer Session ohne Standby entstammen und nicht manipuliert wurden. Es wäre ja schon so eine Art Signatur, wenn das Pattern zwischen Ein-/Ausschaltvorgängen oder innerhalb einer Session ohne Standby konsistent bliebe.

Letztlich bräuchte man nicht nur ein Image der SD, sondern müsste auch wissen, was die Kamera (oder der SD-Controller) da überhaupt im letzten Sektor macht bzw. wie zufällig das Pattern ist. Aber witzig, dass Win 95A da im Worst Case einfach Passwörter etc. ausgeplaudert hat. :D

Offshore7 schrieb:Wenn ich das richtig verstehe, könnte man mittels RAM Slack also evtl. feststellen, ob zB das Haarfoto später den Nachtfotos hinzugefügt wurde oder realer Teil der Nacht-Session war?

Interessanter Gedanke. Wenn das RAM-Slack-Pattern zeigt dass die Kamera vor und nach #580 ausgeschaltet wurde, sonst aber nicht, dann wäre das ein klarer Hinweis. Wobei das nächste Bild nur 9s später gemacht wurde - ein Ausschalten wäre da in jedem Fall auffällig.
(Auch für andere die evtl. hier reinstolpern: würde man solche Anhaltspunkte finden, wäre die Erklärung eher, dass #580 überhaupt nicht chronologisch zw. #579 und #581 aufgenommen wurde sondern die Bilder insgesamt manipuliert sind).

Sollten Bilder überhaupt keine/andere Patterns zeigen wäre es der direkte Beweis einer Manipulation, wobei man dafür genauer herausfinden müsste, wie die Kamera das Pattern generiert. Aber rein zufällig ist es sicher nicht.

Offshore7 schrieb:Standby vorher UND nachher kann man bei den 3 Hauptverdächtigen #550, #576 und #580 ja ausschließen.

Standby kann man halt nicht erkennen es unterscheidet sich nicht zu Kamera angelassen. Standby bedeutet übrigens, dass das Objektiv ausgefahren bleibt. Es wird wohl nur das Display schwarz.