SD-Karte Filesystem Block/Cluster-Versuche

Hier nochmal ein Bild vom 2.Test:



Die Bilder waren jetzt kleiner, da ich hier Dunkelbilder erzeugt habe. Diesmal habe ich dadurch 2 Fragmente von Dateien in diesem Bereich liegen. Ich habe dann mal nach dem EXIF-Marker ab Kluster 120706 gescannt, der erste Bildanfang (wahrscheinlich vom zusätzlich reingemogelten Bild) beginnt erst ab Kluster 120730, das Fregement beginnt also nicht mit einem Bildanfang.

Mir ist inzwischen auch aufgefallen, dass die Kamera den Bildanfang des zusätzlichen Bildes scheinbar immer an den Anfang eines Sektors legt. Deswegen habe ich mir mal den Sektor davor angeschaut:



Dort endet das normale Bild mit Footer an Offset 390, und bis hierin werden wahrscheinlich auch die Parser die Bilddatei scannen. Ich frage mich, was mit den Daten dazwischen ist. Das sieht schon fast danach aus, als ob selbst innerhalb der Datei RAM-Slack an dieser Stelle entsteht. Zumindest direkt nach dem Footer des normalen Bildes folgt kein gültiger JPG-Marker mehr. Da könnte man auch noch mal genauer drauf eingehen.

Achso, nur zur Info, die Offsetangaben beziehen sich hier auf das letzte Byte der zu suchenden Folge, das werde auch noch ändern, wenn ich Zeit habe.

So, die Bytefolge nach FFD9 kommt leider in den anderen Bilddateien nicht vor, schade.

Das Thumbnail ist ins Hauptbild integriert und hat offenbar einen festen Bereich von 8 KiB. Ist es nur 4 KiB groß, werden 8 Sektoren aufgefüllt. Das Preview-Bild folgt nach dem Hauptbild (inkl. aufgefülltem letzten Sektor), liegt also am Dateiende. Ganz gut zu erkennen mit: ./exiftool -htmldump 0045.jpg > 0045.html

Hab mir nun einige Bilder der SX270 angeschaut und bin der Meinung, dass es nach dem Thumbnail und zwischen Hauptbild und Preview-Bild keinen Embedded Slack gibt, der aus vorherigen Bildern resultiert. Dafür sind mir die Patterns zu gleichmäßig.

Interessant ist das Pattern nach FF D9 des Preview-Bildes am Dateiende. Hier kann man möglicherweise erkennen, ob die Kamera vor diesem Bild ausgeschaltet war. Wenn nicht, beinhaltet der RAM-Slack im letzten Sektor offenbar Reste des oder der vorherigen eingebetteten Preview-Bilder.

@sceptical

Könnte es sein, dass das Preview-Bild 0045 kleiner ist als das Preview-Bild 0044? Und daher die Reste im RAM-Slack übrig bleiben (zB aus einem Preview-Bild-Buffer)? Kannst du leicht prüfen mit: ./exiftool -ThumbnailImage -PreviewImage 0045.jpg (bzw. 0044.jpg)

Offshore7 schrieb:Hab mir nun einige Bilder der SX270 angeschaut und bin der Meinung, dass es nach dem Thumbnail und zwischen Hauptbild und Preview-Bild keinen Embedded Slack gibt, der aus vorherigen Bildern resultiert.

Richtig, Bildreste von vorherigen Dateien scheinen es nicht zu sein, dass hatte ich ja schon geschrieben. Mir ist aufgefallen, dass das Pattern zwischen Hauptbild und Preview-Bild sich zwar ändert, aber manchmal längere Byte-Sequenzen enthält, die trotzdem zu einem anderen Pattern identisch sind. Reste von anderen Bildern kann man aber auch nicht hundertprozentig auschließen, weil die JPG-Komprimierung wohl aus mehreren Schritten besteht. Ich habe irgendwo gelesen, dass die komprimierten Daten zum Schluss nochmal speziell kodiert werden.
Deswegen schließt es der einfache Vergleich nicht hundertprozentig aus, es könnten ja Bilddaten von vor der Kodierung sein, was allerdings schon etwas ungewöhnlich wäre.

Offshore7 schrieb:Interessant ist das Pattern nach FF D9 des Preview-Bildes am Dateiende. Hier kann man möglicherweise erkennen, ob die Kamera vor diesem Bild ausgeschaltet war. Wenn nicht, beinhaltet der RAM-Slack im letzten Sektor offenbar Reste des oder der vorherigen eingebetteten Preview-Bilder.

Das hatten wir ja bereits festgestellt.

Offshore7 schrieb:Könnte es sein, dass das Preview-Bild 0045 kleiner ist als das Preview-Bild 0044? Und daher die Reste im RAM-Slack übrig bleiben (zB aus einem Preview-Bild-Buffer)? Kannst du leicht prüfen mit: ./exiftool -ThumbnailImage -PreviewImage 0045.jpg (bzw. 0044.jpg)

Könnte ich, wenn ich die Daten noch hätte. Die sind aber durch die Formatierung des 2.Tests überschrieben worden.

Offshore7 schrieb:Hab mir nun einige Bilder der SX270 angeschaut und bin der Meinung, dass es nach dem Thumbnail und zwischen Hauptbild und Preview-Bild keinen Embedded Slack gibt, der aus vorherigen Bildern resultiert. Dafür sind mir die Patterns zu gleichmäßig

Habe ich mir auch gerade angeschaut, weil es ein kleines Mysterium lüftet, um das ich damals in einem Programm zum Auslesen der drei Auflösungen trickreich drumrumgewerkelt hatte. Es kommt nämlich mind. sehr sehr oft (in meinen Testbildern immer) ein FFD8 (JPEG-Start-Tag) in diesen Daten vor. Seltener auch ein oder sogar mehrere FFD9 (JPEG-End-Tags). Wenn dann scheinbar vor dem FFD8. So ganz zufällig scheint das nicht zu sein.
Oft, aber auch nicht immer, gibt es entweder sehr viele "A" oder "5" in der Hex-Darstellung.

Aber es scheint kein sich über mehrere Bilder wiederholendes Pattern zu geben. Womit diese Daten zumindest nicht denselben Zweck wie die im RAM-Slack erfüllen können. Schade eigentlich, denn an die Orignal-Bild-Dateien zu kommen wäre noch einen winzigen Ticken weniger unrealistisch als an ein SD-Karten-Image.

cyclic schrieb:aber auch nicht immer

Ja, leider nicht immer, jetzt auch gemerkt. Ich nutze ja diese Original-Bilder da ich keine SX270 habe.

Offshore7 schrieb am 16.07.2026:Ja, leider nicht immer, jetzt auch gemerkt. Ich nutze ja diese Original-Bilder da ich keine SX270 habe.

Wenn du bestimmte Bilder einer bestimmten Bediensequenz brauchst, sag bescheid...

cyclic schrieb am 12.07.2026:BTW: Was man auch noch testen müsste ist, ob ein aufgrund Fehler nicht geschriebenes Bild trotzdem das End-Sektor-Pattern verändert (das muss nicht, aber könnte durchaus sein).

Denkfehler meinerseits: nach Auftreten des Fehlers (Bild konnte nicht gespeichert werden), muss man die Kamera eh aus und wieder einschalten. Damit können in dem Fall keine Überbleibsel von #509 im RAM-Slack von #510 stehen. Wenn man also etwas dort findet, was nur das Ende von #509 sein kann, dann muss #509 gelöscht worden sein.

cyclic schrieb:Wenn du bestimmte Bilder einer bestimmten Bediensequenz brauchst, sag bescheid...

Wenn, dann würde mich ein komprimiertes Image einer Low Level formatierten SD interessieren mit folgendem Inhalt:

1. Einfarbiges Foto
2. Strukturfoto (Tapete, Teppich, Rasen oder so)
-> Kamera aus/an
3. Einfarbiges Foto
4. Einfarbiges Foto

Das Ganze zweimal. Sollten eigentlich keine 10 MB sein pro Image. Kein Plan, ob man daraus was ableiten könnte und eilt natürlich auch nicht.

Offshore7 schrieb:1. Einfarbiges Foto
2. Strukturfoto (Tapete, Teppich, Rasen oder so)
-> Kamera aus/an
3. Einfarbiges Foto
4. Einfarbiges Foto

Kann ich machen. Das einfarbigste Foto, das ich erzeugen kann, ist ein komplett schwarzes.

Dass man auf keinen Fall beeinflussen kann wie viel des letzten Sektors eine Datei belegt, ist klar oder? Nur weil ich hatte kurz gedacht man könnte, mit einer ähnlichen Sequenz ;-)

cyclic schrieb am 15.07.2026:Oft, aber auch nicht immer, gibt es entweder sehr viele "A" oder "5" in der Hex-Darstellung.

Genau das habe ich auch bemerkt, 0x55 oder 0xaa tauchen bei mir sehr häufig bei Tagbildern auf. Bei Nachtaufnahmen aber komischerweise nicht. Es scheint hier einen Unterschied zwischen Tag- und Nachtafnahmen bezüglich des Inhaltes zu geben. Allerdings kommt immer nur eines der beiden Werte bei mir auffällig häufig vor und es scheint hier zumindest bei mehreren Bildern ohne Ausschalten der Kamera dazwischen ein Abwechseln zwischen diesen zwei Werte zu geben, welches eine gewisse Regelmäßigkeit besitzt. Zuerst enthielten die Bilder bei einem Test für ca. 256 Kluster den Wert 0xaa sehr häufig, danach wechselte es für ca. 480 Kluster zu 0x55 und danach wieder für ca. 256 Kluster zu 0xaa. Man müsste hier wirklich mal eine ganze Reihe von 300 Bildern machen und das genauer auswerten.

cyclic schrieb:Denkfehler meinerseits: nach Auftreten des Fehlers (Bild konnte nicht gespeichert werden), muss man die Kamera eh aus und wieder einschalten. Damit können in dem Fall keine Überbleibsel von #509 im RAM-Slack von #510 stehen. Wenn man also etwas dort findet, was nur das Ende von #509 sein kann, dann muss #509 gelöscht worden sein.

Wofür man den Slack noch nutzen könnte ist die Beurteilung, ob ein Bild überhaupt von der Kamera oder von einem anderen Gerät (PC, andere Kamera) auf den Datenträger geschrieben wurde.

@sceptical
@cyclic

Es hat zwar konkret mit dem Fall hier nix zu tun bzw. wird hier keine Rolle spielen, aber bei der Entwicklung eines solchen Programms kann man tatsächlich viel dazulernen. Zum Beispiel wusste ich vorher nicht, dass es zwischen Linux und FAT tatsächlich ein Problem mit den Zeitstempeln gibt. Linux trägt die Zeitstempel wohl um genau 2 Stunden versetzt in den Dateieintrag ein. Erst hatte ich wie ein Blöder nach einem BUG im Programm gesucht, bis die KI von Google mich freundlicherweise darauf hingewiesen hat.

cyclic schrieb:Dass man auf keinen Fall beeinflussen kann wie viel des letzten Sektors eine Datei belegt, ist klar oder? Nur weil ich hatte kurz gedacht man könnte, mit einer ähnlichen Sequenz ;-)

Ja klar, ich hoffe einfach, dass der statistische Zufall nicht zu launisch ist. :D

cyclic schrieb am 15.07.2026:Es kommt nämlich mind. sehr sehr oft (in meinen Testbildern immer) ein FFD8 (JPEG-Start-Tag) in diesen Daten vor.

Das ist tatsächlich seltsam, bei mir kommt zumindest in den Slacks nicht einmal FFD8 vor. Der Aufbau ist wohl tatsächlich relativ verschachtelt.

Hier ein detaillierterer Dateiaufbau anhand eines Testbildes von der Kamera:

Kluster Sektor Bezeichnung ------------------------------------------------------- 5 0 FFD8 CANON-Dateianfang 5 11 FFD8 Dateianfang Tumbnail 5 12 FFDA Bilddaten Tumbnail Anfang 5 16 FFD9 Bilddaten Tumbnail Ende 5 16-26 RAM-Slack Tumbnail 5 27-34 FFD8 Exif-Daten + APP2-Marker 5 35 FFD8 Dateianfang Hauptbild 5 36 FFDA Bilddaten Hauptbild Anfang 82 27 FFD9 Bilddaten Hauptbild Ende (inkl. Slack) 82 28 FFD8 Exif-Daten 82 29 FFD8 Dateianfang Preview 82 30 FFDA Bilddaten Preview Anfang 91 3 FFD9 Bilddaten Preview Ende (inkl. Slack)

Es kommen bei mir bei mehreren getesteten Bildern immer genau 6x FFD8 vor und zwar immer nur am Sektoranfang. Zwischen Bildern stehen noch EXIF-Daten dazwischen, vielleicht hast du die mit zum Slack gezählt?

cyclic schrieb:Dass man auf keinen Fall beeinflussen kann wie viel des letzten Sektors eine Datei belegt, ist klar oder? Nur weil ich hatte kurz gedacht man könnte, mit einer ähnlichen Sequenz ;-)

Schön wärs, darüber hatte ich auch schon nachgedacht.

sceptical schrieb:Es kommen bei mir bei mehreren getesteten Bildern immer genau 6x FFD8 vor und zwar immer nur am Sektoranfang. Zwischen Bildern stehen noch EXIF-Daten dazwischen, vielleicht hast du die mit zum Slack gezählt?

Du hast recht. Ich hatte einen Fehler und habe deutlich zu weit gelesen (weiter als 16 Sektoren ab Thumbnail-Start). Dann bleiben nur noch ein paar FFD9 die manchmal in den Daten auftauchen (bei mir gerade 7x in 74 Dateien).

Wie nennen wir das Dingens? Oder gibt es einen offiziellen Namen? Thumb-(Pseudo-)Slack?

sceptical schrieb:Zum Beispiel wusste ich vorher nicht, dass es zwischen Linux und FAT tatsächlich ein Problem mit den Zeitstempeln gibt. Linux trägt die Zeitstempel wohl um genau 2 Stunden versetzt in den Dateieintrag ein. Erst hatte ich wie ein Blöder nach einem BUG im Programm gesucht, bis die KI von Google mich freundlicherweise darauf hingewiesen hat.

Darüber bin ich auch mal gestolpert. So ganz geklärt hat sich das für mich nicht. Die haben da für alle Ewigkeit einen ziemlich offensichtlichen Bug dringelassen?

sceptical schrieb:Wofür man den Slack noch nutzen könnte ist die Beurteilung, ob ein Bild überhaupt von der Kamera oder von einem anderen Gerät (PC, andere Kamera) auf den Datenträger geschrieben wurde.

Absolut. Für mich ein wesentlicher Punkt an der Sache. Bin mir auch quasi 1000%ig sicher dass all das vom NFI nicht geprüft wurde.

cyclic schrieb:Wie nennen wir das Dingens? Oder gibt es einen offiziellen Namen? Thumb-(Pseudo-)Slack?

Ja, kann man so nennen. Was mich hieran noch ganz besonders interessiert ist, ob normale Bildbetrachter alle EXIF-Daten auswerten oder es EXIF-Daten gibt, die nur die Kamera für sich selbst abspeichert.

cyclic schrieb:Dann bleiben nur noch ein paar FFD9 die manchmal in den Daten auftauchen

So ist es bei mir auch, zumindest hatte ich bis jetzt einmal ein zusätzliches FFD9 bei einem Test dabei, ein zusätzliches FFD8 ist mir bis jetzt noch nicht untergekommen.

Nur so am Rande, die Tests von dir bezüglich des Löschens eines letzten Bildes im Hinblick auf 509 und auch der ungeklärten Tumbnails auf dem Datenträger kann ich mit meiner Kamera hinsichtlich der Ergebnisse alle bestätigen.

Wo wir gerade bei den Tumbnails sind.

Die drei Bilder lassen sich tatsächlich einzeln extrahieren und werden dann separat ohne Probleme im Bildbetrachter als einzelne Bilder angezeigt. Da der Anfang jeweils an einem Sektoranfang liegt, könnte es durchaus theoretisch passieren, dass der erste Kluster eine gelöschten CANON-JPG vom Ende einer anderen Datei überschrieben wird, wobei das Tumbnail im Drive-Slack übrig bleibt, wodurch ein Datenrettungsprogramm es als eigenständiges Bild finden könnte, sofern dieses sektorweise sucht oder der Sektoranfang rein zufällig auch auf einen Klusteranfang fällt, was aber hier nicht sein kann, weil das Tumbnail bei 64 Sektoren pro Kluster immer komplett im ersten Kluster liegt.

Ich habe mir mal eine Beschreibung des PR-Algos durchgelesen. Da steht, dass PR das daran festmacht, ob es einen gültigen Boot-Sektor findet. Wenn ja, wird klusterweise gescannt, ansonsten sektorweise. Du hast PR schonmal getestet, kann man das eventuell doch als Benutzer irgendwo umstellen?

sceptical schrieb:Ja, kann man so nennen. Was mich hieran noch ganz besonders interessiert ist, ob normale Bildbetrachter alle EXIF-Daten auswerten oder es EXIF-Daten gibt, die nur die Kamera für sich selbst abspeichert.

Ich glaube die vollständigsten EXIF-Daten bekommt man mit exiftool und ich glaube die sind auch wirklich vollständig. Ich weiß nicht ob da manchmal mit neuen Kameramodellen noch neue Metadaten dazuerfunden werden, aber exiftool sollte alles was es schon seit Jahren gibt kennen.

sceptical schrieb:Du hast PR schonmal getestet, kann man das eventuell doch als Benutzer irgendwo umstellen?

Soweit ich mich erinnere habe ich da nichts spezifisch eingestellt. Hauptsächlich hatte ich das hier getestet:
Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon (Seite 1154) (Beitrag von cyclic)
Interessant und für mich nicht wirklich erklärbar ist, dass PhotoRec nur Thumbnail und Vollauflösung, nicht aber die mittlere Previewauflösung rekonstruiert (die in der Datei am Ende liegt).

PS: übrigens hatte ich neulich mal Unsinn bzgl. der Thumbnail-Auflösung geschrieben. Die sind 160x120.