SD-Karte Filesystem Block/Cluster-Versuche

cyclic · 2025-03-09T20:11:00Z

SX2070 HS auf 2GB SD-Karte: Original: Formatiert: FILENAME START END M0239.CTG 280.. 280: <- catalog file probably create / updated when switching into the viewer mode IMG_2969.JPG 10.. 111: IMG_2970.JPG 112.. 202: IMG_2971.JPG 203.. 278: <- gap: 2 blocks - probably because the CFG file was created in viewer mode MVI_2972.MP4 281.. 537: 538.. 540: IMG_2973.JPG 541.. 625: IMG_2974.JPG 626.. 723: (IMG_2975.JPG 724.. 817: <- Before changing timestamps with exiftool - size: 94 blocks) IMG_2976.JPG 818.. 908: IMG_2977.JPG 909.. 992: MVI_2978.MP4 993.. 1271: 1272.. 1274: IMG_2979.JPG 1275.. 1355: IMG_2980.JPG 1356.. 1427: IMG_2981.JPG 1428.. 1520: (VIDEO 2982 DELETED BEFORE IMAGE 2983) <- gap: 260 blocks! IMG_2983.JPG 1781.. 1883: IMG_2984.JPG 1521.. 1608: <- filled in gap between 2981 and 2983 (IMAGE 2985 DELETED BEFORE IMAGE 2986) <- gap: 62 blocks (was <- filled in gap between 2981 and 2983) IMG_2986.JPG 1671.. 1772: <- filled in gap between 2981 and 2983 IMG_2987.JPG 1609.. 1670: <- filled in gap between 2981 and 2983 1773.. 1780: <- filled in gap between 2981 and 2983 (+Discontinuity in 1774) 1884.. 1884: <- next free after 2983 IMAGE 2988 DELETED BEFORE IMAGE 2989 (SHUTTING CAM DOWN BEFORE 2989) <- no gap IMG_2989.JPG 1885.. 1953: IMG_2990.JPG 1954.. 2015: IMG_2991.JPG 2016.. 2079: IMAGE 2992 DELETED BEFORE IMAGE 2993 (SHUTTING CAM DOWN BEFORE 2993) <- no gap IMG_2993.JPG 2080.. 2140: IMG_2994.JPG 2141.. 2192: IMG_2995.JPG 2193.. 2301: VIDEO 2996 DELETED BEFORE IMAGE 2997 (SHUTTING CAM DOWN BEFORE 2997) <- no gap IMG_2997.JPG 2302.. 2387: IMG_2998.JPG 2388.. 2494: IMG_2975.JPG 2495.. 2588: <- After changing timestamps with exiftool (still 94 blocks) MVI_2999.MP4 2870.. 2872: 2589.. 2869: <- gap: 3 blocks IMG_3000.JPG 2873.. 2901: <- small 28 blocks image (mostly black) that would easily fit in every gap IMG_3001.JPG 2902.. 3000: IMAGES 3002, 3003, 3004 DELETED BEFORE 3005 (WITHOUT SHUTTING DOWN) <- gap 292 blocks (~3 images) IMG_3005.JPG 3293.. 3390: IMAGES 3006, 3007, 3008 DELETED BEFORE 3009 (SHUTTING CAM DOWN BEFORE 3009) IMG_3009.JPG 3001.. 3094: <- filled in the previous gap between 3001 and 3005 IMG_3010.JPG 3095.. 3188: <- filled in the previous gap between 3001 and 3005 IMG_3011.JPG 3189.. 3282: <- filled in the previous gap between 3001 and 3005 IMG_3012.JPG 3283.. 3292: <- filled in the previous gap between 3001 and 3005 (first part) 3391.. 3474: <- second part starts after 3005 IMG_3013.JPG 3475.. 3567: <- no gap IMAGES 3014, 3015, 3016, 3017 DELETED BEFORE 30018 (WITHOUT SHUTTING DOWN) IMG_3018.JPG 3927.. 4005: <- gap 359 blocks (~4 images) IMG_3019.JPG 4006.. 4083: <- no gap IMG_3020.JPG 4084.. 4163: <- no gap IMG_3021.JPG 4164.. 4238: <- no gap IMAGES 3022, 3023, 3024, 3025 DELETED BEFORE 3026 (SHUTTING CAM DOWN BEFORE 3026) IMG_3026.JPG 3568.. 3667: no gaps IMG_3030.JPG 4279.. 4378: IMG_3033.JPG 4379.. 4485: IMG_3034.JPG 4486.. 4591: IMG_3035.JPG 4592.. 4705: IMG_3039.JPG 4706.. 4815: IMG_3040.JPG 4816.. 4923: IMG_3041.JPG 4924.. 5037: CREATING GAPS (NOT SWITCHING OFF THE CAM), THEN SWITCHING OFF AND TAKE PHOTOS TO SEE IF GAPS ARE FILLED -> yes (but no older gaps) IMG_3042.JPG 5038.. 5144: IMAGE 3044 DELETED (NOT SHUTTING DOWN) <- gap 74 blocks IMG_3044.JPG 5219.. 5324: IMAGES 3045, 3046 DELETED (NOT SHUTTING DOWN) <- gap 142 blocks IMG_3047.JPG 5467.. 5560: IMAGES 3048, 3049, 3050 DELETED (NOT SHUTTING DOWN) <- gap 220 blocks IMG_3051.JPG 5781.. 5876: IMAGES 3052, 3053, 3054, 3055 DELETED (NOT SHUTTING DOWN) <- gap 300 blocks IMG_3056.JPG 6177.. 6275: NEXT IMAGES TAKEN AFTER CAMERA WAS SWITCHED OFF (i.e. gaps can be filled now) IMG_3057.JPG 5145.. 5218: <- filled in the gap between 3042 and 3044 (74 blocks) 5325.. 5375: <- filled in the gap between 3044 and 3047 (51 blocks, second part) IMG_3058.JPG 5376.. 5466: <- filled in the gap between 3044 and 3047 (91 blocks) 5561.. 5577: yes IMG_3063.JPG 6033.. 6131: IMG_3064.JPG 6132.. 6176: 6276.. 6332: <- after 3056 (second part) IMG_3065.JPG 6333.. 6435: IMG_3066.JPG 6436.. 6539: IMG_3067.JPG 6540.. 6642: IMG_3068.JPG 6643.. 6756: IMG_3069.JPG 6757.. 6863: IMG_3070.JPG 6864.. 6978: IMG_3071.JPG 6979.. 7094: IMG_3072.JPG 7095.. 7211: IMG_3073.JPG 5891.. 5998: filefrag_out.txt zu formatieren:File size of ((?:IMG|MVI)_\d{4}\.(?:JPG|MP4)) is \d+ \(\d+ blocks of 32768 bytes\)\n\s*ext: logical_offset: physical_offset: length: expected: flags:\n((?:\s*\d+:\s+\d+\.\.\s+\d+:\s+\d+\.\.\s+\d+:\s+\d+:\s+(?:\d+:\s+)?merged(?:\,eof)?\n)+)(?:IMG|MVI)_\d{4}\.(?:JPG|MP4): \d+ extents? found\n Der Rest geht rel. einfach indem man die wenigen zusätzlichen Zeilen von "fragmentierten" Dateien von Hand einrückt und dann mit einem Editor mit Block-Selektions/Editier-Modus (z.B. Kate) die überflüssigen Spalten löscht. Graph: Matlab/Octave-Skript: Zum Vergleich S120 32GB SD-Karte: Original: Formatiert: IMG_3083.JPG 284437.. 284488: 287151.. 287208: Discontinuity: Block 3328 is at 18377664 (was 18207296) 287340.. 287366: IMG_3084.JPG REMOVED BEFORE 3085 (WITHOUT SHUTTING CAM OFF) gap: 117 blocks IMG_3085.JPG 287474.. 287487: 287367.. 287472: Discontinuity: Block 896 is at 18391488 (was 18399232) 287488.. 287497: IMG_3086.JPG REMOVED BEFORE 3086 (SHUTTING CAM OFF AND ON) no gap IMG_3087.JPG 287498.. 287588: IMG_3088.JPG 287589.. 287628: (black img. 40 blocks - not filling gap) Ergebnisse: Eine Lücke (in der Größe der gelöschten Datei) bleibt wenn man letztes Bild/Video löscht aber Kamera nicht ausschaltetKeine Lücke wenn man letztes Bild löscht und dann Kamera aus und wieder anschaltet (Voriges Bild und nächstes liegen "Sektor an Sektor")Lücken werden nicht gefüllt, obwohl nächstes Bild hineinpasst (selbst die rel. großen Lücken durch gelöschte Videos werden nicht gefüllt). Das muss sich eigentlich spätestens ändern wenn die SD-Karte sonst nicht mehr genug Platz hat, aber noch ausreichend Lücken frei sind. Bestehende Lücken werden gefüllt, selbst wenn kein einziges Bild komplett hineinpasst (Datei "fragmentiert"). Anm.: Erst durch die grafische Ausgabe habe ich bemerkt, dass tatsächlich fast alle Lücken gefüllt wurden, was ich vorher übersehen hatte. Die einzige nicht wieder befüllte Lücke ist interessanter Weise durch die Änderungen der EXIF-Daten mit exiftool entstanden (Bild 2975). exiftool benennt die Original-Datei um (hier in IMG_2975.JPG_original). Diese Datei hatte ich übersehen - sie belegt unverändert den originalen Bereich. Es gibt also keinerlei unbelegte Lücken.Auch bei drei gelöschten Bildern bleibt die Lücke, wenn man direkt das nächste Bild macht ohne die Cam auszuschaltenMit Ausschalten passierte etwas merkwürdiges: das nächste Bild wurde in die zuvor entstandene drei Bild große Lücke gesetzt und liegt jetzt vor dem Bild früheren Bild (andere frühere, zT. deutlich größere Lücken wurden nicht genutz) Anmerkungen: Auch wenn filefrag für SD-Karten wohl nur die logische Struktur wiedergeben kann, so scheint die dann aber doch nicht ganz so weit von der physikalischen Wirklichkeit entfernt zu sein - immerhin werden auch "Discontinuities" ausgegeben (wohl defekte Bereiche) und die entsprechend entstehenden Fragmente (das könnte die "logische Ebene" auch komplett verschleiern).Auch Mini-Lücken von nur einem Block/Cluster Länge werden gefüllt: Unten: vorher letzte Bild-Datei, Mitte: 1-Block-Datei deren 1-Block großer Vergänger gelöscht wurde, Oben neues Bild (1-Block-Lücke wird genutzt) Allerdings bleiben auf der SD-Karte genauso viele 1-Block-Lücken wie es CTG-Katalog-Dateien gibt (die jeweils auch einen Block lang sind). Vermutung: Beim Anlegen der Datei wird diese (bzw. evtl. zunächst eine Temp-Datei) so oft überschrieben/geändert, dass dieser Bereich wegen Wear-Leveling der SD-Karte später ungenutzt bleibt. Mehrfaches Schreiben einer Mini-Datei (1 Block): (Details unten im Thread). Das erklärt warum es pro CTG-Datei genau eine Lücke gibt (die nie gefüllt wird).

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

Blog von cyclic Beobachten Kommentieren

Seite 12 von 13vorherige 1 ... 2 10 11 12 13 nächste

Direkt zur Seite:

zum ersten Beitrag zum letzten Beitrag

Offshore7

dabei seit 2022

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

28.07.2026 um 23:09

cyclic schrieb:wonach #510 ohne Blitz aufgenommen worden sein soll.

Ohne Blitz wäre ne plausible Erklärung, kA welchen Einfluss Halbmond hätte.

Bei deinen Bildern findet man in den EXIF-Daten: Flash: Off, Did not fire
Das findet man auch bei den Tagfotos, während bei den Nachtfotos das steht: Flash: Auto, Fired

Passiert das automatisch (von Off auf Auto) beim (manuellen) Ausfahren des Blitzes?

cyclic schrieb:Aber so sehr interessiert mich dieses Detail jetzt eigentlich auch nicht.

Nee, null. Wir graben ja jetzt schon tiefer, als es für die zur Verfügung stehenden Daten Sinn macht. :D

1x zitiert melden

cyclic Diskussionsleiter

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

29.07.2026 um 07:03

Offshore7 schrieb:Passiert das automatisch (von Off auf Auto) beim (manuellen) Ausfahren des Blitzes?

Im AUTO-Modus kann man den Blitz gar nicht manuell zwangsweise aktivieren. Man kann ihn deaktivieren oder ebenfalls auf Auto stellen (zwangsweise aktivieren kann bzw. muss man ihn in anderen Programmen z.B. Zeitautomatik)

Weiß jetzt nicht 1000% was die Werkseinstellung ist, aber doch ziemlich wahrscheinlich ist sie dass der Blitz automatisch aktiviert wird, wenn es halt zu dunkel ist.

Für diese Fotos habe ich den Blitz aber deaktiviert. Das müsste demnach jemand auch bei der Originalkamera gemacht haben. Denn so dunkel kann es sonst nur unter sehr speziellen Umständen sein. Da vor dem 8.4. keine Blitzbilder bekannt sind, kann das irgendwann umgestellt worden sein. Naheliegend wäre in einem Museum oder einer Kirche (aber auch solche Bilder sind ja nicht bekannt).

melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

19.08.2026 um 14:08

cyclic schrieb am 11.07.2026:Ach du meine Güte, jetzt erst begreife ich worauf du die ganze Zeit hinaus willst! Und du hast völlig Recht

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

Hast du eine Ahnung, welche Datenfelder Reste von 509 enthalten könnten?
Wie laßen sich diese als Überreste identifizieren?
Könnten diese Überreste Aufschluss über Zeitpunkt, Ort, oder die Möglichkeit der Bildrekonstruktion geben?

Könntest du ein solches „Überrestexperiment“ mit deiner eigenen Kamera durchführen?
510 war komplett dunkel, also vielleicht war die Foto mit aufgesetztem Objektivdeckel gemacht.

2x zitiert melden

cyclic Diskussionsleiter

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

19.08.2026 um 18:07

Anthurium schrieb:Hast du eine Ahnung, welche Datenfelder Reste von 509 enthalten könnten?

Es gibt zwei Möglichkeiten: die eine kennen wir schon lange: zwischen zwei Dateien bleibt normalerweise ein Bereich der nicht beschrieben wird. Wenn #509 gelöscht wurde bevor #510 aufgenommen wurde, dann überschreibt #510 den alten Bereich von #509. Wenn aber #509 länger war als #510 können Reste hinter #510 und vor #511 übrig bleiben. Da #510 extrem klein ist, wäre das sogar sehr wahrscheinlich. Maximal können da 32768-512 Byte erhalten bleiben (wenn #509 relativ groß war, könnte auch noch zwischen #511 und #512 ein solcher Rest erhalten geblieben sein). Mit etwas Glück sogar ein Teil der Preview-Auflösung. Da könnte man mit knapp 32 kiB schon einen kleinen Bildausschnitt rekonstruieren.

Die zweite Möglichkeit ist neu und wurde von @sceptical entdeckt (an einer Stelle wo ich absolut keine sinnvollen Daten erwartet hätte). Es gibt direkt hinter dem Dateiende einen noch viel kleineren Bereich von max. 511 Byte. Aus irgendeinem Grund schreibt die Kamera dort (unter bestimmten Voraussetzungen) das Ende der jeweils vorigen Datei hinein. Aber nur wenn zwischen den beiden Fotos die Kamera eingeschaltet blieb und nicht in den Viewer-Modus gewechselt wurde. In den Viewer-Modus müsste man aber wechseln um #509 zu löschen.

Sollte sich ein kleiner Rest von #509 in diesem Bereich finden könnte man ihn mit rel. hoher Wahrscheinlichkeit auch als solchen erkennen. Es gibt eine kleines Risiko, dass man es nicht von einem Wechsel in den Viewer Modus unterscheiden kann. Auch müsste zur Abgrenzung auch #511 ohne zwischenzeitliches Ausschalten aufgenommen worden sein.

Allerdings ist das wie gesagt eigentlich nicht möglich, da man #509 auf der Kamera nur vom Viewer-Modus aus löschen konnte. Das wäre also höchst merkwürdig und würde stark auf nachträgliche Manipulation hindeuten.

Es gibt aber noch eine Stelle die hier interessant sein könnte und das ist die CTG-Datei (mal wieder). Auch da enthält dieser kleine Bereich Reste und zwar von ihrem eigenen alten Zustand bevor sie upgedatet wurde. Und da könnten, mit etwas Glück, eben genau die 20 Byte der CTG übrig geblieben sein, die Metadaten von #509 enthalten. Das passiert genau dann, wenn man in den Viewer-Modus geht und z.B. ein Bild löscht. In diesen 20 Byte steht vermutlich auch das Aufnahmedatum+Zeit, allerdings verstehe ich bisher das Format nicht wirklich.
Und diese Datenreste bleiben nur erhalten, wenn man danach nie wieder in den Viewer-Modus wechselt. Das ist gar nicht so unwahrscheinlich, denn warum hätte man während der Nachtbilder noch jemals in den Viewer-Modus wechseln sollen?

Das Erkennen ob die Kamera angeschaltet blieb kann noch an anderen Stellen interessant sein. Insbesondere rund um #550 (Tütenfels), #576 ("SOS") und #580 (Haare).

Außerdem könnten im Falle einer Manipulation hier Auffälligkeiten bestehen an die mit ziemlicher Sicherheit kein Manipulator gedacht hätte.

Aber für all das bräuchte man nicht nur eine Kopie der Originaldateien, sondern einen echten "forensischen" 1:1-Abzug der SD-Karte. Chancen also minimal.

Anthurium schrieb:Könntest du ein solches „Überrestexperiment“ mit deiner eigenen Kamera durchführen?

Ja das könnte ich mit meiner eigenen Kamera bestätigen. Ein bestimmtes Experiment von @sceptical habe ich selbst noch nicht nachgemacht, bin aber sicher dass das so stimmt, weil es derselben Systematik folgt.

Anthurium schrieb:510 war komplett dunkel, also vielleicht war die Foto mit aufgesetztem Objektivdeckel gemacht.

Die Kamera hat keinen Objektivdeckel. Sie hat einen Schutz der automatisch wegklappt sobald man die Kamera einschaltet und das Objektiv ausgefahren wird.

2x zitiert melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

19.08.2026 um 19:26

cyclic schrieb:Die Kamera hat keinen Objektivdeckel. Sie hat einen Schutz der automatisch wegklappt sobald man die Kamera einschaltet und das Objektiv ausgefahren wird.

Weisst du dann wie man ein komplett schwarzes Foto aufnehmen kann? Ein Foto, das absolut keinerlei Bildinhalt aufweist?

1x zitiert melden

cyclic Diskussionsleiter

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

19.08.2026 um 19:52

Anthurium schrieb:Weisst du dann wie man ein komplett schwarzes Foto aufnehmen kann? Ein Foto, das absolut keinerlei Bildinhalt aufweist?

#510 kann nicht wirklich komplett schwarz sein. Ein wirklich schwarzes Foto (alle Pixel Farbwert #000000) ist nochmal deutlich kleiner (genau 282876 B). Ich habe das mehrfach geschafft indem ich in einem sehr dunklen Raum (keine Fenster, kein Licht) die Hand auf das Objektiv gelegt habe und im Manuell-Modus die kleinste mögliche Blendenöffnung und kürzeste mögliche Belichtungszeit eingestellt habe. Lässt man die letzten beiden Sachen weg und bleibt im AUTO-Modus, dann kommen Bilder raus die etwa dieselbe Größe wie #510 haben (so knapp 1MB). Es ist also plausibel, dass #510 ohne Blitz und Fremdlicht im stockdunklen Wald aufgenommen wurde.

1x zitiert melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

20.08.2026 um 07:53

cyclic schrieb:Lässt man die letzten beiden Sachen weg und bleibt im AUTO-Modus, dann kommen Bilder raus die etwa dieselbe Größe wie #510 haben (so knapp 1MB). Es ist also plausibel, dass #510 ohne Blitz und Fremdlicht im stockdunklen Wald aufgenommen wurde.

Foto 510 wurde 25 Sekunden vor Foto 511 aufgenommen. Die Zeitstempel und Temperaturen der einzelnen Fotos sind bekannt, aber wo in Allmy finde ich eine Übersicht der Dateigrößen (in MB)?

Referenz für komplett schwarz:

cyclic schrieb:Ein wirklich schwarzes Foto (alle Pixel Farbwert #000000) ist nochmal deutlich kleiner (genau 282876 B).

1x zitiert melden

Offshore7

dabei seit 2022

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

21.08.2026 um 20:15

Anthurium schrieb:wo in Allmy finde ich eine Übersicht der Dateigrößen (in MB)?

Hier im zweiten Spoiler: Beitrag von Offshore7 (Seite 1)

Quasi simpel die Sektor-Angaben von Matt ausgerechnet: IP - Picture 4

1x zitiert melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

23.08.2026 um 23:50

Anthurium schrieb am 19.08.2026:Könntest du ein solches „Überrestexperiment“ mit deiner eigenen Kamera durchführen?

cyclic schrieb am 19.08.2026:
Anthurium schrieb am 19.08.2026:Könntest du ein solches „Überrestexperiment“ mit deiner eigenen Kamera durchführen?
Ja das könnte ich mit meiner eigenen Kamera bestätigen. Ein bestimmtes Experiment von @sceptical habe ich selbst noch nicht nachgemacht, bin aber sicher dass das so stimmt, weil es derselben Systematik folgt.

Hier nochmal ein entsprechender Test mit der Kamera mit forensischer Auswertung, wo man zum Beispiel Reste einer von der Kamera gelöschten Datei bzw. Metadaten der Datei finden kann. Vorraussetzung ist, dass das Bild direkt hinter dem vorherigen Bild lückenlos abgespeichert wurde. Der Test wurde in der Einstellung "fortlaufende Nummerrierung" durchgeführt.

Testablauf
1. Aufname von 3 Bildern (img_0001 - img_0003)
2. Erzeugung des Ordners CANONMSC sowie der Katalogdatei durch Wechsel in den Viewer-Modus
3. Aufname weiterer 6 Bilder (img_0004 - img_0009)
4. Erneuter Wechsel in den Viewer-Modus, um eine Aktualisierung der Liste in der Katalogdatei zu errreichen
5. Löschen von Bild img_0009
6. Aus- und Einschalten der Kamera
7. Aufnahme eines weiteren Bildes, ohne dabei nochmal in den Viewer-Modus zu wechseln. Durch Zuhalten der Linse wurde ein Dunkelbild erzeugt, damit dieses auf jeden Fall kleiner ist als das vorherige Bild.

Forensische Auswertung Bilddateien:

Dateieinträge der Bilder im Ordner und letzter Sektor der Datei img_0009 nach Schritt 4:

Original anzeigen (0,6 MB)

Dateieinträge der Bilder im Ordner und letzter Sektor der gelöschten Datei img_0009 nach Schritt 7:
Bilder2

- Die Bildnummer 0009 fehlt
- Das neue Bild hat die Nummer 0010 bekommen (auf Grund der Einstellung "fortlaufende Nummerierung")
- Das neue Bild beginnt im gleichen Kluster (816) wie das gelöschte Bild 0009 und hat dieses somit überschrieben
- Da das neue Bild 0010 kleiner ist als das gelöschte Bild 0009, wurde der letzte Sektor des gelöschten Bildes nicht überschrieben. Wenn Bild 0010 größer gewesen wäre als Bild 0009, dann wären hier keine Reste übrig geblieben.

Forensische Auswertung Katalogdatei:

Dateieintrag und letzter Sektor der Katalogdatei nach Schritt 4:

Original anzeigen (0,5 MB)

Dateieintrag und letzter Sektor der Katalogdatei nach Schritt 7:

Original anzeigen (0,5 MB)

Die Datei selbst hat sich um 20 Byte (1 Eintrag) verkürzt, was man sowohl an der Größenangabe im Ordner als auch am Dateiende (weißer Block) im Sektor sehen kann. Trotzdem hat sich der Sektor nicht verändert, der letzte Eintrag ist dort als RAM-Slack außerhalb der Datei erhalten geblieben.

Sobald man aber nachträglich nochmal in den Viewer-Modus wechselt, wird der Eintrag wieder überschrieben, weil dann die aktualisierte Liste mit img_0010 in den Sektor geschrieben wird.

1x zitiert melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

25.08.2026 um 11:45

Offshore7 schrieb am 21.08.2026:Hier im zweiten Spoiler:

sceptical schrieb:Hier nochmal ein entsprechender Test mit der Kamera mit forensischer Auswertung

Danke, ich werde es mir in aller Ruhe ansehen ...

melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

30.08.2026 um 15:40

@sceptical
Ich habe versucht, dieser technischen Erklärung zu folgen und sie zu verstehen. Dennoch komme ich immer wieder auf dieselbe Frage zurück: Was geschieht mit jenem spezifischen Teil der Daten des ursprünglichen Fotos 0009?

Um zu verdeutlichen, was ich meine, ersetze ich – der Einfachheit halber – die Bytes (MB) durch Milligramm (mg).

Die Schritte 1 bis 4 werden ausgeführt. Alle Fotos haben ein bestimmtes Gewicht in mg. Weisen wir Foto 0009 ein hypothetisches Gewicht von 10 mg zu.

Die Schritte 5 und 6 werden ausgeführt; Foto 0009 wird gelöscht und die Kamera ausgeschaltet, ohne die Katalogdaten zu aktualisieren. Folglich werden die 10 mg Daten entfernt, aber die Katalogdaten bleiben unverändert.

Schritt 7 wird ausgeführt; ein neues Foto wird in einer dunklen Umgebung aufgenommen. Infolgedessen hat dieses Foto ein geringeres Gewicht als das gelöschte Foto 0009. Das Nummer 0009 fehlt und das neue Foto bekommt Nummer 0010. Weisen wir diesem Foto, 0010, ein hypothetisches Gewicht von 6 mg zu.

Da 6 mg weniger sind als 10 mg, werden nur 6 mg der gelöschten Datei 0009 überschrieben – schließlich können 6 mg keine 10 mg überschreiben. Die Konsequenz ist, dass 4 mg nicht überschrieben werden.

Wo bleiben die verbleibenden 4 mg? Was geschieht mit diesen Überresten?
Wenn sich die Reste im neuen Foto 0010 befänden, warum hat 0010 dann nicht dasselbe Gewicht wie das gelöschte Foto 0009?

1x zitiert melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

30.08.2026 um 19:38

Anthurium schrieb:Die Schritte 5 und 6 werden ausgeführt; Foto 0009 wird gelöscht und die Kamera ausgeschaltet, ohne die Katalogdaten zu aktualisieren. Folglich werden die 10 mg Daten entfernt, aber die Katalogdaten bleiben unverändert.

Die Katalogdatei wird durch das Löschen des Bildes auch schon aktualisiert, weil das eben auch nur im Viewer-Modus geht. Ich hätte hier eventuell den Sektorinhalt der Katalogdatei nach Löschen von 0009 und dem Ausschalten zeigen sollen. Das erneute Einschalten und Aufnahme eines neuen Bildes verändert die Katalogdatei aber nicht, sofern man nicht mehr in den Viewer-Modus wechselt. Daher würde hier das gleiche Ergebnis zu sehen sein. Kann ich aber gerne nochmal wiederholen. Man sieht hier nach Schritt 7 an der Dateigröße, dass 1 Eintrag entfernt wurde, aber der Sektorvergleich zum Sektor nach Schritt 4 zeigt, dass der entfernte letzte Eintrag trotzdem hinter dem Dateiende erhalten geblieben ist. Das ist hier erstmal das wesentlich, egal, nach welchem Schritt die Entfernung aus der Datei passiert.

Anthurium schrieb:Schritt 7 wird ausgeführt; ein neues Foto wird in einer dunklen Umgebung aufgenommen. Infolgedessen hat dieses Foto ein geringeres Gewicht als das gelöschte Foto 0009. Das Nummer 0009 fehlt und das neue Foto bekommt Nummer 0010.

Richtig, der Eintrag fehlt im Ordner. Nach dem Löschen von 0009 wurde der Eintrag zunächst als gelöscht markiert (das ist beim normalen Löschen immer so) und muss danach bei Aufnahme von 0010 von diesem Eintrag überschrieben worden sein. Da solche Einträge im Ordner immer die gleiche Größe haben (32 Byte), wird hier immer vollständig überschrieben. Solche Ordnerinhalte muss man unabhängig von den eigentlichen Dateien betrachten. Diese Ordnerlisten liegen sozusagen getrennt von den eigentlichen Dateien in eigenen Klustern. Die Größenunterschiede der Dateien spielen für die Größe der Einträge im Ordner und übrigens auch der Einträge in der Katalogdatei keine Rolle.
Auch in der Katalogdatei, die ebenfalls unabhängig von den eigentlichen Dateien separat abgespeichert wird, haben die Einträge alle die gleiche Größe.

Anthurium schrieb:Da 6 mg weniger sind als 10 mg, werden nur 6 mg der gelöschten Datei 0009 überschrieben – schließlich können 6 mg keine 10 mg überschreiben. Die Konsequenz ist, dass 4 mg nicht überschrieben werden.

Richtig, ich konnte hier nur nicht alle "4 mg" an übrig gebliebenen Sektoren darstellen, deswegen habe exemplarisch den letzten Sektorinhalt gezeigt, Wenn die Größenverhältnisse umgekehrt gewesen wären, dann wäre nichts übrig geblieben.

Anthurium schrieb:Wo bleiben die verbleibenden 4 mg? Was geschieht mit diesen Überresten?

Nix, die bleiben erstmal da, wo sie vorher waren. Der Sektor 66912 enthält sozusagen den Rest dieser 4 mg. Nach Löschung und Neuaufnahme (Schritt 7) hat sich der Sektorinhalt nicht verändert, der Sektor wurde also nicht überschrieben.

Um das nochmal zu erläutern, was hier beim Überschreiben der Bilddateien selbst passiert, ist erstmal unabhängig davon, was in den Dateilisten im Ordner und der Katalogdatei passiert.

melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

30.08.2026 um 20:10

Nachtrag:

Die restlichen 4mg bleiben so lange da, bis der Sektor von neuen Daten überschrieben wird, weil dieser nach dem Löschen vom Dateisystem als freier Speicher angesehen wird, der jederzeit wieder neu benutzt werden kann.

Wenn ich also noch ein weiteres großes Bild machen würde (0011), dann wird der Rest (fast) auch noch überschrieben. Allerdings gibt es da noch den Schlupfspeicher (engl.: Slack). Das sind im Grunde genommen in der Regel ein paar Sektoren zwischen dem Ende von 0010 und dem Anfang von 0011, die dabei nicht überschrieben werden. Hier würde man dann noch minimale Reste von 0009 finden können.

2x zitiert melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

31.08.2026 um 14:37

sceptical schrieb:Wenn ich also noch ein weiteres großes Bild machen würde (0011), dann wird der Rest (fast) auch noch überschrieben.

Können wir also nicht einfach davon ausgehen, dass gar keine Spuren von 509 mehr vorhanden sind, weil sie von 511, 512 usw. überschrieben wurden?

1x zitiert melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

31.08.2026 um 15:34

Anthurium schrieb:Können wir also nicht einfach davon ausgehen, dass gar keine Spuren von 509 mehr vorhanden sind, weil sie von 511, 512 usw. überschrieben wurden?

sceptical schrieb:Allerdings gibt es da noch den Schlupfspeicher (engl.: Slack). Das sind im Grunde genommen in der Regel ein paar Sektoren zwischen dem Ende von 0010 und dem Anfang von 0011, die dabei nicht überschrieben werden. Hier würde man dann noch minimale Reste von 0009 finden können.

melden

Anthurium

dabei seit 2024

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

01.09.2026 um 15:49

@sceptical

Ah, ich musste tatsächlich einige Informationen zum Thema „Slack RAM“ nachschlagen, um besser zu verstehen, was du hier meinst.

Es sollten also Spuren im Slack vorhanden können sein. Voraussetzungen:
1. #510 ist/war kleiner als #509
2. bestimmte Handlungen wurden an der Kamera durchgeführt – oder eben nicht

Laut beiden Büchern (LitJ und ViP) stellte der Analyst fest, dass „nicht die geringste Spur von 509“ zu finden war. Wir wissen nicht genau, was der Analyst sich angesehen hat, aber, wenn man davon ausgeht, dass nicht einmal die kleinste Spur von 509 im Slack RAM zurückblieb: Worauf könnte das hindeuten? Der Ausgangspunkt bleibt (siehe Punkt 1 oben), dass #510 kleiner ist/war als #509.

Könnte dies auf eine andere Abfolge von Handlungen an der Kamera hinweisen (Punkt 2 oben)? Oder könnte es womöglich auf den Eingriff eines anderen Geräts hindeuten?

3x zitiert melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

01.09.2026 um 16:32

Anthurium schrieb:Es sollten also Spuren im Slack vorhanden können sein. Voraussetzungen:
1. #510 ist/war kleiner als #509
2. bestimmte Handlungen wurden an der Kamera durchgeführt – oder eben nicht

Die Sache ist etwas schwieriger. Es gibt 2 verschiedene Arten von slack:

1. RAM-Slack
Das ist der Bereich vom Dateiende bis zum Sektorende, in dem die Datei endet. Wenn hier hinter der Datei Daten stehen, dann sind das Datenreste, die bereits im Speicher der Kamera durch die Firmware entstehen und nicht dadurch, dass bereits auf dem Datenträger vorhandene Daten nicht überschrieben wurden. Der Inhalt ist hier also von der Software abhängig, welche die Datei auf den Datenträger geschrieben hat. Die Kamera erzeugt einen eher ungewöhnlichen RAM-Slack, der unter gewissen Umständen Dateienden von vorherigen Dateien enthalten kann. Das Dateiende von 509 wird aber wahrscheinlich nicht im RAM-Slack von 510 zu finden sein, allerding gibt es andere Möglichkeiten, diesen zu nutzen. Zum Beispiel kann man hieran eventuell erkennen, wann die Kamera aus-/eingeschaltet wurde. Weiterhin kann man eventuell erkennen, wenn ein Bild von einem anderen Gerät auf der Karte abgelegt wurde, weil dieses Gerät eventuell anderen RAM-Slack erzeugt. Auch der gezeigte Eintrag in der Katalogdatei befindet sich im RAM-Slack. Der Inhalt wird bei der Kamera stark durch das Aus-/Einschalten und die Nutzung des Viewer-Modus beeinflusst.

Dies hat aber erstmal nicht direkt etwas mit den Größenverhältnissen der Gesamtgrößen zwischen 509 und 510 zu tun, da geht es um die zweite Slack-Variante:

2. Drive-Slack
Das sind eventuell noch folgende Sektoren bis zum Klusterende. Datenreste hier sind tatsächlich dadurch entstanden, dass schon vorher auf dem Datenträger vorhandene Daten (z.B. von 509) in diesen Sektoren einfach nicht überschrieben wurden. Im Hinblick auf Datenreste von 509 hierin kommt es dann auf die Größendifferenz der Gesamtgrößen an.

Anthurium schrieb:Laut beiden Büchern (LitJ und ViP) stellte der Analyst fest, dass „nicht die geringste Spur von 509“ zu finden war. Wir wissen nicht genau, was der Analyst sich angesehen hat, aber, wenn man davon ausgeht, dass nicht einmal die kleinste Spur von 509 im Slack RAM zurückblieb: Worauf könnte das hindeuten? Der Ausgangspunkt bleibt (siehe Punkt 1 oben), dass #510 kleiner ist/war als #509.

Im RM-Slack sind erstmal keine Spuren der Datei 509 zu erwarten, da geht es nur um den gelöschten Eintrag von 509 in der Katalogdatei, also reine Meta-Daten. Wenn 509 größer war als 510 und keine Daten im Drive-Slack davon übrig geblieben wären, dann könnte das auf Folgendes hindeuten:

1. Das Bild war auf der Karte nicht abespeichert (technischer Fehler oder Kartentausch)
2. Das Bild wurde beim Löschen gleich auch vollständig überschrieben (geht nur mit PC)

Allerdings wissen wir ja nicht, welches Bild größer war.

melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

01.09.2026 um 17:24

Nochmal kurz zur Erklärung, wodurch dieser Slack überhaupt entsteht.

Der Speicher auf der Karte wird zur Adressierung der Daten im Allgemeinen erstmal in gleichgroße Blöcke zu je 512 Byte aufgeteilt (das sind die Sektoren). Dann gibt es noch das Dateisystem (in diesem Fall FAT32).
Das sind zusätzlich auf der Karte abgespeicherte Meta-Daten (Ordner und weitere Dinge), die zur Verwaltung der abgespeicherten Dateien dienen. Dieses Dateisystem teilt den Speicher ebenfalls in gleich große Datenblöcke auf, allerdings werden hier mehrere Sektoren zu einem größeren logischen Block zusammengefasst (das ist ein Kluster). Auf der SD-Karte im Fall bestand ein Kluster z.B. aus 63 Sektoren.

Dieser Kluster ist sozusagen die kleinste Verwaltungseinheit des Dateisystems und kann verwaltungstechnisch immer nur einer einzigen Datei zugeordnet sein, auch wenn diese z.B. nur 1 einzelnes Byte darin belegen würde. Der übrig gebliebene Speicher kann daher zur Abspeicherung weiterer Dateien logisch nicht mehr verwendet werden, weil das Dateisystem nicht 2 Dateien in einem Kluster verwalten kann. Die Sektoren hinter dem Dateiende bis zum Klusterende (falls vorhanden) werden dabei auch nicht überschrieben. So entsteht zumindest der Drive-Slack.

1x zitiert melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

01.09.2026 um 17:43

Anthurium schrieb:ch musste tatsächlich einige Informationen zum Thema „Slack RAM“ nachschlagen, um besser zu verstehen, was du hier meinst.

sceptical schrieb:Auf der SD-Karte im Fall bestand ein Kluster z.B. aus 63 Sektoren.

64 natürlich, Tippfehler.

melden

sceptical

dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

01.09.2026 um 21:51

Anthurium schrieb:Wir wissen nicht genau, was der Analyst sich angesehen hat, aber, wenn man davon ausgeht, dass nicht einmal die kleinste Spur von 509 im Slack RAM zurückblieb:

Theoretisch könnte der NFI bei der damaligen Untersuchung sowas wie den übrig gebliebenen Eintrag im RAM-Slack der Katalog-Datei übersehen habe, zumal weder das Thema Katalogdateien noch Slack im Bericht überhaupt nur thematisiert wird. Allerdings glaube ich schon, dass der NFI zumindest nachträglich sich die Sache nochmal genauer angeschaut hat und davon trotzdem wüsste. Die Frage ist nur, ob der NFI einen solchen nachträglich gemachten Fund veröffentlicht hätte.

1x zitiert melden

Seite 12 von 13vorherige 1 ... 2 10 11 12 13 nächste