SD-Karte Filesystem Block/Cluster-Versuche

cyclic schrieb am 05.07.2026: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.

Du hast insofern Recht, dass in der Datei selbst nur noch 2 Einträge da sind, aber wenn du dir den Screen-Shot des Sektors von der Katalogdatei nochmal genau anschaust siehst du, dass dort immer noch 4 Einträge im Sektor stehen. Hier tauchen eindeutig Einträge aus vorherigen Versionen der Katalogdatei im RAM-Slack auf.

Der folgende Screen-Shot zeigt den Anfang der 4 Einträge im Sektor, die rote Markierung ist das Dateiende:

@sceptical

Aha, gut dann war mir bisher einfach nicht klar was du meintest. Jetzt habe ich es dann hoffentlich gerafft.

Seltsam ist das weil der Sektor ja immer komplett neu geschrieben werden sollte. Es kann also keine Überbleibsel im letzten Sektor geben nur weil die Datei kürzer geworden ist (auch wenn es logisch klingt).

Wenn das so ist, dann könnte es auch tatsächlich bzgl. #509 relevant sein. Zumindest dann wenn #509 auf der Kamera gelöscht wurde und danach nicht nochmal in den Viewer-Mode gewechselt wurde (was gut möglich ist). In dem Fall wären dann "Reste" der um #509 geschrumpften CTG im RAM-Slack.

Werde ich versuchen nachzumachen...

cyclic schrieb:Seltsam ist das weil der Sektor ja immer komplett neu geschrieben werden sollte. Es kann also keine Überbleibsel im letzten Sektor geben nur weil die Datei kürzer geworden ist (auch wenn es logisch klingt).

Der Sektor wird auch eigentlich komplett neu auf den Datenträger geschrieben. Auch das müssten dann eigentlich Reste der Liste sein, die schon im Speicherpuffer der Software entstehen.

cyclic schrieb:Wenn das so ist, dann könnte es auch tatsächlich bzgl. #509 relevant sein. Zumindest dann wenn #509 auf der Kamera gelöscht wurde und danach nicht nochmal in den Viewer-Mode gewechselt wurde (was gut möglich ist). In dem Fall wären dann "Reste" der um #509 geschrumpften CTG im RAM-Slack.

Da habe ich wenig Hoffnung, wenn man bedenkt, dass die Behörden in Panama die Kamera ja auch nachträglich noch hatten und auch die Finder selbst. Da wird bestimmt jemand die Kamera eingeschaltet und sich die Bilder im Viewer-Modus angeschaut haben.

Ich habe den Test auch nochmal wiederholt, wobei nur die letzte Datei gelöscht wurde. Der letzte Eintrag in der Datei und der darauffolgende einzelne Eintrag im RAM-Slack waren erwartungsgemäß identisch. Es sieht also tatsächlich so aus, als ob die Software sektorweise in den Speicher liest, die Einträge in einer Datenstruktur verwaltet und wenn ein Bild gelöscht wird den Eintrag aus der Liste entfernt und die jetzt kürzere Liste in den Speicher schreibt, wobei der Speicherbereich vorher nicht initalisiert wird. Dann landen die Sektoren mit RAM-Slack wieder auf der Karte.

Sobald ein neues Bild aufgenommen wurde und man in den Viewer-Modus wechselt, ist dieser Resteintrag aber leider wieder weg. Die Sache mit dem Pattern im RAM-Slack der Bilder finde ich tatsächlich vielversprechender. Hast du schonmal nachgeschaut, ob sich dieses Pattern (falls genügend Bytes da sind) irgendwo in den Bilddaten wiederfindet?

sceptical schrieb:Da habe ich wenig Hoffnung, wenn man bedenkt, dass die Behörden in Panama die Kamera ja auch nachträglich noch hatten und auch die Finder selbst. Da wird bestimmt jemand die Kamera eingeschaltet und sich die Bilder im Viewer-Modus angeschaut haben.

Wenn das noch ging. Bei der Kamera soll immerhin Wasser im SD-Karten-/Batteriefach gewesen sein (und damit wahrscheinlich auch überall sonst, denn das ist gegen den Rest der Innereien nicht abgedichtet, soweit ich das erkennen konnte).

Auch ist auf den Fotos, die den ganzen Rucksackinhalt zeigen, die SD-Karte zu sehen, also nicht in der Kamera (es ist glaube ich nicht mal wirklich klar, ob sie in oder außerhalb der Kamera gefunden wurde). Anders als bei den Handys glaube ich dass die Kamera eher nicht nochmal eingeschaltet wurde.

sceptical schrieb:Hast du schonmal nachgeschaut, ob sich dieses Pattern (falls genügend Bytes da sind) irgendwo in den Bilddaten wiederfindet?

Ja, aber das war nicht der Fall. Der Teil der bei mir mehrfach ganz am Ende auftauchte (hinter einem FF D9) kommt so auch irgendwo im EXIF-Teil einer Bilddatei vor. Ich vermute dass die Kamera evtl. beim Einschalten ein Bild in ihrem Speicher generiert. Was ich noch testen wollte ist, ob das RAM-Slack-Pattern irgendwie speziell aussieht, wenn man die Kamera z.B. im Stockdunklen einschaltet.

cyclic schrieb:Ja, aber das war nicht der Fall. Der Teil der bei mir mehrfach ganz am Ende auftauchte (hinter einem FF D9) kommt so auch irgendwo im EXIF-Teil einer Bilddatei vor. Ich vermute dass die Kamera evtl. beim Einschalten ein Bild in ihrem Speicher generiert. Was ich noch testen wollte ist, ob das RAM-Slack-Pattern irgendwie speziell aussieht, wenn man die Kamera z.B. im Stockdunklen einschaltet.

So, jetzt wird es richtig interessant. Bei mir verhält sich die Kamera scheinbar etwas anders. Habe heute den Slack-Befehl mal etwas modifiziert. Er zeigt jetzt als ersten Sektor den mit Dateiende (RAM-Slack) an, wobei das letzte Byte der Datei anhand der Größenangabe speziell mit # markiert wird. Nach Formatierung und Aufnahme mehrere Bilder sieht der RAM-Slack der ersten 3 Bilder wie folgt aus:







Bei mir bleiben eindeutig Inhalte der vorherigen Dateien übrig. Bei Bild img_0045.jpg folgen hinter dem Dateieende (Offset 105) das Dateiende von img_0044.jpg bis Offset 478 und danach noch ein paar Bytes bis Offset 482 des Dateiendes von img_0043.jpg.

Geprüft mit ADE, hier der Beweis:

Original anzeigen (0,6 MB)

Die Sektoren stimmen überein.

@sceptical

Wenn ich das nicht wieder falsch verstehe entspricht das dem was ich auch beobachtet habe. Vielleicht ist es in meiner Beschreibung nicht klar genug geworden. Der letzte Sektor der letzten Aufnahme überschreibt das Pattern eben bis zu dem Byte an dem die vorige Datei endete. Wenn eine Datei zufällig alle 512 B des letzten Sektors füllt bleibt von dem ursprünglichen Pattern nichts übrig. Die Frage ist woher kommt das ursprüngliche Pattern von dem man im allergünstigsten Fall 511 B bei der ersten Aufnahme sehen kann? Aber ich bin mir sicher dass das von der Kamera generierte Daten sind und keine Dateireste von vor der Formatierung.

Das mit den CTGs habe ich mir noch nicht angeschaut (es ist schon wieder brütend heiß hier).

cyclic schrieb:Wenn ich das nicht wieder falsch verstehe entspricht das dem was ich auch beobachtet habe. Vielleicht ist es in meiner Beschreibung nicht klar genug geworden. Der letzte Sektor der letzten Aufnahme überschreibt das Pattern eben bis zu dem Byte an dem die vorige Datei endete. Wenn eine Datei zufällig alle 512 B des letzten Sektors füllt bleibt von dem ursprünglichen Pattern nichts übrig. Die Frage ist woher kommt das ursprüngliche Pattern von dem man im allergünstigsten Fall 511 B bei der ersten Aufnahme sehen kann? Aber ich bin mir sicher dass das von der Kamera generierte Daten sind und keine Dateireste von vor der Formatierung.

Das Pattern ist die eine Sache, aber die Bildreste könnten tatsächlich auch weiterhelfen. Ich hatte dich da wahrscheinlich falsch verstanden.

Ach du meine Güte, jetzt erst begreife ich worauf du die ganze Zeit hinaus willst! Und du hast völlig Recht - ich habe nur die ganze Zeit an was anderes gedacht.

Im letzten Sektor von #510 (und folgenden) könnte, mit etwas Glück, ein Rest von #509 stehen. Und da man alle anderen Dateien ja hat (wenn man einen Abzug der SD-Karte hat) könnte man das sogar ziemlich sicher feststellen, ob es ein Rest von #509 sein muss.

Voraussetzungen:
1) Nur wenn die Kamera zw. #509 und #510 nicht ausgeschaltet wurde
2) Nur wenn #510 RAM-Slack hat der lang genug ist
3) Und wenn #509 mehr von seinem letzten Sektor gefüllt hat als #510

Aber die Chance wäre schon absolut gegeben. Schade dass wir die Dateigröße von #510 nur auf ganze Cluster aufgerundet kennen.

Umgekehrt, wenn man im RAM-Slack von #510 jetzt das Ende einer früheren Datei wie z.B. #508 oder früher fände, aber keine unbekannte Datei (#509) dann kann das auch daran liegen, dass #509 einfach weniger vom letzten Sektor als #510 gefüllt hat. Die Wahrscheinlichkeit dafür hängt davon ab wie groß #510 exakt ist (was wir halt auch schon nicht wissen).

Sollten wir widererwarten einen Abzug der SD-Karte in die Finger bekommen, absolut ein Prüfpunkt.

Ich habe noch etwas sehr merkwürdiges gefunden, von dem bislang noch nicht die Rede war. Deswegen hatte ich auch hier erst an einen Fehler im Programm gedacht. Inzwischen habe ich es aber ebenfalls mit ADE positiv nachgeprüft.

Bei einzelnen Dateien zerlegt meine Kamera die Datei völlig ohne Grund in 3 Fragmente, wobei das mittlere Fragment plötzlich ganz am Ende des Datenbereichs gespeichert wird:



120753 ist hier tatsächlich der letzte Kluster im Volume. Ich habe jeweils die Inhalte der 3 Fragmente (erster Sektor) mit ADE gegengeprüft, es stimmt. Danach habe ich immer noch aus Unglauben die 3 Fragmente mit ADE in 3 Datein extrahiert und mit ImHex in eine Datei zusammengefügt, sodass am Ende gleich 2 andere Tools beteiligt waren. Tatsächlich kommt das richtige Bild dabei raus.

Hattest du das schonmal bei deinen Tests? Es wäre hier tatsächlich ebenfalls wichtig. Wenn sowas bei 509 passiert ist, dann war 509 von vornherein schon kleiner und es könnte doch noch ein Fragment irgendwo am Ende des Datenbereichs liegen. Ich weiß nicht, ob dieses Mittelfragment von PR gefunden würde, wenn die beiden anderen Fragmente (Anfang und Ende) überschrieben wurden.

@sceptical
Ähm, können das die drei eingebetteten Auflösungen sein (die jeweils in sich vollständige JPEGs darstellen)?
- Volle Auflösung 4000x3000
- Preview 1440x1080
- Thumbnail 600x400