SD-Karte Filesystem Block/Cluster-Versuche

sceptical schrieb:Unter welchen Bedingungen eine Lücke geschlossen wird, kann von ganz vielen Faktoren abhängig sein.

Ich habe da inzwischen umfangreiche Tests gemacht und es ist tatsächlich überhaupt nicht komplex: es wird immer mit dem ersten freien Cluster (kleinste Adresse) begonnen und dann aufsteigend gefüllt. Auch wenn eine Lücke nur 1 Cluster groß ist wird sie genutzt und auch habe ich normalgroße JPGs über 10 Lücken fragemtieren lassen. (wir reden hier inmer nur von der logischen FAT-Ebene nicht von NAND-Pages / -Blöcken / etc. an die man eh nicht rankommt).

Probier es selbst mal aus (geht prima auch ohne Kamera).

Warum das mit der gleichen Clusteranzahl dann stimmt merkst du dann selber.

sceptical schrieb:Steht irgendwo im Bericht, wie viele wiederhergestellte Bilder überhaupt noch einen Gelöscht-Eintrag hatten ?

Ich weiß da auch nicht mehr. Nichtmal dass es bei den 64+4 oder 24+4 um 0xE5-Verzeichniseibträge geht steht irgendwo. Es ist nur bisher die einzig sinnvolle Annahme, die ich kenne. Aber die Erkenntnis, dass diese erhalten bleiben, wenn das Verzeichnis(Cluster) nicht mehr angefasst wird, dürfte der Schlüssel zum Verständnis sein (immerhin gibt es noch 63 oder 103 weitere fehlende Dateien, die wahrscheinlich nur durch die fehlenden Nummern belegbar sind.

Dateien ohne diese Einträge bezeichnet man als verlorene Dateien. Das könnten dann Dateien von vor einer Formatierung sein. Sowas würde ich hier dann eher weiter hinten im Datenbereich erwarten.

Hast du dir das mit den TMP-Dateien schon angeschaut. Erzeugt die Kamera solche Dateien - die übrigens insofern interessant sind, weil sie eigentlich noch einen zusätzlichen VFAT-Eintrag brauchen. Es ist auch nicht klar, wo die Einträge der neuen Bilder sind oder wo die neuen Bilder abgespeichert sind.

sceptical schrieb:Hast du dir das mit den TMP-Dateien schon angeschaut. Erzeugt die Kamera solche Dateien

Beitrag von cyclic (Seite 2)

Ja sowohl ich und vorher schon @Offshore7 haben experimentiert. Nein die Kamera erzeugt solche Dateinamen nicht. Wohl aber mind. 2 Windows-Standard-Bildbetrachter u.a. der Viewer, der auch in den EXIF-Daten div. Bilder auftaucht. Und zwar z.B. beim Drehen. Das waren höchstwahrscheinlich die Ermittler in Panama.

Unklar ist wie viele Bilder gedreht wurden (wie viele TMP-Dateien es gibt) und ob diese zu den gelöschten gehören. Mir schien, dass die unter bestimmten, aber unklaren, Umständen erst beim Schließen des Viewers gelöscht werden, so dass sie evtl. erhalten bleiben, wenn man vorher die SD-Karte aus dem Reader reißt - z.B. weil man merkt, dass man gerade großen Mist baut (reproduzieren könnte ich das aber nicht mehr).

Jedenfalls benennen beide Viewer die Datei in eine TMP um und dann direkt vor dem Löschen scheinbar nochmal in eine tmp (kleines tmp). Merkwürdig ist, dass man bei IP nur die TMP-Form sieht. Spricht für mich dafür, dass die TMP nicht gelöscht wurden.

Irgendeine Idee, welches Tool in einem Schwung 40 Thumbnails erzeugt, aber nicht mehr? Linux Gnome Nautilus File-Explorer (ggf. entspr. alte Version) könnte ein Kandidat sein, konnte ich aber noch nicht testen

Gibt es irgendwo informationen über die Bilder vor April, z.B. Aufnahmen mit konkreter Bildnummer? Weiss man, welche Bildnummer das erste Bild trägt?

sceptical schrieb:Gibt es irgendwo informationen über die Bilder vor April, z.B. Aufnahmen mit konkreter Bildnummer? Weiss man, welche Bildnummer das erste Bild trägt?

Die Bilder (in schlechter Auflösung), die es halt gibt sind alle auf Koudekaas (wie immer). Wobei Christian (Doctective) neulich Zweifel angemeldet hat, ob das wirklich Bilder der SX270 sind.

Das erste Bild der Reise soll lt. Scarlet (Koudekaas) #167 sein. Welche Nummer das erste überhaupt erhaltene Bild hat ist unbekannt. Auch ob es vor #167 überhaupt Bilder auf der SD-Karte gibt. Der Januar-Ordner 100___01 kann theoretisch leer sein, wenn man alle Dateien darin von einem Rechner gelöscht (wegge-moved) hat.

Es gibt ganz wenige April-Bilder mit weitgehend vollständigen EXIFs (ich kenne genau zwei), aber ich kenne keine vom März mit Canon-spezifischen EXIF-Daten. IP hat offenbar Original-EXIFs aller Nachtbilder erhalten (so konnten sie die Temperatur auslesen).

Etc:

• CTG-Dateien "faken":
  Wenn man die SD-Karte formatiert und vom PC die Ordnerstruktur DCIM/<FolderNr>___<Monat>/ erzeugt und Bilder in die Ordner kopiert und dann die SD-Karte in die Kamera einlegt und einmal einschaltet (zumindest via View-Mode), dann wird der Unterordner DCIM/CANONMSC/ angelegt und für alle Monatsordner werden CTG-Catalog-Dateien erzeugt (M<OrdnerNumer4Stellig>.CTG z.B. M0124.CTG) - d.h. auch wenn man kein einziges Bild aus einem bestimmten Monatsordner betrachtet hat.
  ==> Man muss also keine CTG-Dateien faken, man muss nur einmal die SD-Karte in die Kamera einlegen.
  
  
• Video-Größen / Belegungs-Plausibilitäts-Check:
  Bis einschließlich #508 existieren lt. IP 370 Bilder und 7 Videos. #508 endet in Sektor 336859 (Clusterende), d.h. bei Byte 1724907519. Das sind 1645 MiB. Bei durchschnittlich 3.7 MiB / Bild bleiben 276 MiB für die 7 Videos, also 40 MiB / Video. Das dürften etwa 13s Länge je Video sein (10s => 31 MiB)
  
  
• Löschen ganzer Ordner am PC:
  
  • Nach Löschung des Ordners 124___06 sind Verzeichniseinträge noch als [0xE5]24___06 und alle enthaltenen Dateien noch als [0xE5]MG_<Nr>.JPG erhalten (Bilder sind wiederherstellbar)
  • Nach einer weiteren Aufnahme mit der Kamera, sind die Verzeichniseinträge des Ordners und der enthaltenen Bilder nicht mehr auffindbar (ImHex Search). Bilder sind noch widerherstellbar soweit Content noch nicht überschrieben (DMDE) - in dem Fall ist eines bereits überschrieben.
  
  
• Datei- und Ordner-Nummerierung:
  Es existierte ein einziger Ordner 125___07 mit einem Bild IMG_3125.JPG, obwohl das Kameradatum korrekt auf Juli eingestellt ist, landete das nächste Bild in 128___07 und das Bild heißt IMG_0143.JPG.
  ==> Es wurde weder die Ordnernummer zurückgesetzt, noch der existierende Juli-Ordner genutzt (obwohl letzter / einziger Ordner) und auch der Bildzähler wurde nicht an die größte existierende Bildnummer angepasst (vermutlich weil in anderem Ordner). Das muss von früheren Ergebnissen abgegrenzt werden, wo ein Ordner weiterbenutzt wurde wenn man das Jahr ändert (aber gleicher Monat) und die Bildnummer entspr. dem existierenden Bild mit der größten Nummer erhöht wird (aber das Bild im gleichen Ordner liegt).
  

Ich habe jetzt versucht alles was hier geschrieben wurde zu verstehen. So wir ich es verstehe weißt die Dateisystemstruktur Merkmale auf, die ein rein kamerabasiertes Nutzungsszenario als weiger wahrscheinlich erscheinen lassen. Ein Eingriff über ein externes System zum Beispiel einen PC ist deutlich plausibler, insbesondere zur Erklärung der Clusterverteilung und Dateireihenfolge. Oder wie seht ihr die Sache?

@InspektorLemon

Ich weiß jetzt nicht wirklich woraus du das ableitest.

Die Ultrakurzfassung aus meiner Sicht ist: wir haben verstanden wie bestimmte Angaben aus den Akten zu verstehen sind. Wir haben einige Hypothesen bzgl. anderer Angaben, die aber zu ungenau und teilweise sogar widersprüchlich sind. Und wir wüssten worauf man achten müsste, wenn man die Originaldaten, oder wenigstens deutlich mehr Informationen hätte.

Aber wirklich etwas handfestes haben wir bisher nicht. Gerade die Interpretation bzgl. #509 macht ja für mich in der Form, wie sie in den Akten steht, eigentlich keinen Sinn. Entweder sie haben einen wesentlichen Standardschritt überhaupt nicht gemacht (Schlupfspeicher-Auswertung) oder ihre Schlussfolgerungen, dass Löschen plausibel sei ist schwer nachvollziehbar.

Es gibt noch ein paar Tests, die ich bei Gelegenheit noch machen möchte, die sich insbesondere auf die sog. Catalog-Dateien (*.CTG) beziehen und wie oft die upgedatet werden und ob das ein nachvollziehbares Muster im Speicher ergibt. Ich bin mir aber fast sicher, dass das NFI soetwas überhaupt nicht ausgewertet hat (wenn sie schon die Thumbnails/Previews nicht verstanden haben) und insofern ist das erstmal rein akademisches Interesse, das nur für den extrem unwahrscheinlichen Fall relevant würde, dass ich einen Abzug der SD-Karte in die Finger bekäme.

Meine Einschätzung war eine eigene Wahrscheinlichkeitsbewertung, keine Feststellung. Für mich sind die vorliegenden Auffälligkeiten technisch eher durch externe Eingriffe als durch reines Kameraverhalten erklärbar. Die Clusteranalysen und Zeitstempel-Reihen bieten Hinweise, aber mehr nicht. Ohne die SD-Karte bzw. deren Clone-Kopie ist es aber natürlich in weiten Teilen auch nur raten ins Blaue hinein. Also bleibt es natürlich bisher Spekulation ob ein PC im Spiel war, da gebe ich dir absolut Recht.

Ich habe noch Fragen, habe ich es richtig verstanden, dass es zeitlich zusammengehörige Bilder in nicht zusammenhängenden Clustern und Dateien mit exakt gleichem Erstellungs- und Änderungszeitpunkt, aber nicht benachbarter Speicherposition haben?

InspektorLemon schrieb:Ich habe noch Fragen, habe ich es richtig verstanden, dass es zeitlich zusammengehörige Bilder in nicht zusammenhängenden Clustern und Dateien mit exakt gleichem Erstellungs- und Änderungszeitpunkt, aber nicht benachbarter Speicherposition haben?

Es ist einfach eine Situation herbeizuführen in der die Abfolge der Dateien gemäß Speicheradressen nicht mehr der Aufnahmereihenfolge entspricht. Das ist immer dann der Fall wenn vorher Bilder gelöscht wurden. Insbesondere wenn einzelne Bilder (keine zusammenhängenden Blöcke aufeinanderfolgender Aufnahmen) gelöscht werden. Die folgenden Aufnahmen springen dann in die Lücken. Das führt zwangsläufig auch zum Fragmentieren (einzelne Dateien liegen nicht in einem einzigen zusammenhängenden Speicherabschnitt sondern sind über mehrere verteilt).

Da wir wissen, dass Dateien gelöscht wurden (die 64+4 sowie sehr wahrscheinlich 63 weitere) muss es solche "Brüche" in der Abfolge und fragmentierte Dateien gegeben haben. Aber das ist nur indirekt ableitbar.

Direkt wissen wir aus dem NFI-Bericht (IP + Koudekaas/ViP) nur, dass dies im April nicht aufgetreten ist. Alle Bilder lagen im Speicher "neatly" hintereinanderweg - mit der Besonderheit dass es #509 nicht gibt und also #510 direkt ohne Lücke auf #508 folgt.

(daraus kann man jetzt noch mehr bzgl. der gelöschten Bilder und wann sie überschrieben wurden ableiten - habe ich oben gemacht und lasse ich hier weg - zu kompliziert)

Verschiedene Dateien mit exakt gleichem Erstellungs- und Änderungsdatum kann es nie geben (bzw. das wäre sicher auch dem NFI aufgefallen), weil man nicht gleichzeitig mehrere Aufnahmen machen kann.

Solange Dateien nicht am Rechner verändert werden ist in jeder einzelnen Bilddatei das Erstellungsdatum identisch zum Änderungsdatum. Erst wenn man mit einem Bildbearbeitungsprogramm am PC Dateien ändert (dreht, beschneidet, skaliert, aufhellt, ...) ändert sich das Änderungsdatum während das Erstellungsdatum immer den Originalwert beibehalten sollte. Beide, sowie überhaupt alle Metadaten lassen sich aber z.B. mit exiftool beliebig verändern.

cyclic schrieb:Solange Dateien nicht am Rechner verändert werden ist in jeder einzelnen Bilddatei das Erstellungsdatum identisch zum Änderungsdatum. Erst wenn man mit einem Bildbearbeitungsprogramm am PC Dateien ändert (dreht, beschneidet, skaliert, aufhellt, ...) ändert sich das Änderungsdatum während das Erstellungsdatum immer den Originalwert beibehalten sollte. Beide, sowie überhaupt alle Metadaten lassen sich aber z.B. mit exiftool beliebig verändern.

Hey vielen Dank für die Infos. Es ist leider etwas schwer das alles richtig zu erfassen. Aber ich bin bemüht.:) Bei den Telefondaren von @Offshore7 habe ich es auch irgendwann begriffen. ;) Ich nehme also gerne meine Einschätzung nach deinen Infos zurück und sehe es jetzt so, dass die bisher beschriebenen Auffälligkeiten mit normaler Nutzung vereinbar sind. Dafür braucht man nicht unbedingt einen PC nach allem was wir wissen.

Fortsetzung CTG-Dateien (Canon-Catalog-Dateien - s. Beitrag von cyclic (Seite 4)):

Eine CTG-Datei wird für einen Monatsordner (erst) angelegt sobald man erstmalig in den Viewer-Modus wechselt. Wechselt man nie in den Viewer-Modus weden weder CTG-Dateien noch der Ordner DCIM/CANONMSC angelegt.

Obwohl die Datei danach, wenn neue Aufnahmen gemacht wurden und man erneut in den Viewer-Modus geht, geändert wird, bleibt last-modified unverändert und die Datei bleibt auch unverändert im passenden Cluster, dort wo sie zuerst angelegt wurde (also nach dem letzten Bild bevor man in den Viewer-Mode gewechselt hat). So hat man üblicherweise in einem Monatsordner Bilder deren Erstellungsdatum vor dem der CTG-Datei liegt und Bilder deren Erstellungsdatum nach dem der CTG-Datei liegt und die auch im Speicher logisch entsprechend vor und hinter der CTG-Datei liegen.

Will man das plausibel faken muss man also beim Füllen jeden Ordners via PC, irgendwann am Anfang jedes Monatsordners, nach dem Reinkopieren der ersten paar Bilder, die SD-Karte einmal in die Kamera stecken und in den Viewer-Modus gehen, bevor man am Rechner den Ordner weiterbefüllt und dann mind. noch einmal am Ende, wenn alle Dateien kopiert wurden. (ich bin aber fast sicher, dass das NFI das nicht geprüft hat, insofern muss man nicht davon ausgehen, dass ein möglicher Manipulator das gewusst und den Aufwand betrieben hat).

Beim Anlegen der allerersten CTG-Datei wird gleichzeitig auch der Ordner DCIM/CANONMSC/ angelegt und liegt enstpr. im Cluster direkt vor der ersten CTG-Datei.

Hier eine Hex-Ausgabe von einer CTG, nach dem erstmaligen Anlegen, als 6 Bilder im einzigen Monatsordner lagen (IMG_0148.JPG ... IMG_0153.JPG) und nachdem weitere 3 Bilder gemacht wurden (IMG_0154.JPG ... IMG_0156.JPG):

Dateianhang: M0128_Old.hex (4 KB)

Dateianhang: M0128_New.hex (4 KB)

...um Aufnahmen zu löschen muss man in den Bildbetrachtungsmodus, was die CTG-Datei anlegt, fall sie noch nicht existiert. Es muss also eine CTG-Datei geben die sowohl lt. Filesystem-Zeitstempel (last modified) als auch nach Cluster-Adresse irgendwo zwischen #476 (erstes April-Bild) und vor #510 liegt.

Dann liegen aber die April-Bilder im Ordner DCIM/102___04 nicht alle "neatly" aneinandergrenzend hintereinanderweg, weil irgendwo dazwischen die Datei DCIM/CANONMSC/M0102.GTG liegen muss. Da ich nicht glaube, dass man die CTG-Dateien und den Ordner in dem sie liegen überhaupt angesehen hat (sonst hätte man dazu wenigstens einen Satz schreiben müssen), spricht das gegen ein Löschen von #509 auf der Kamera.

Bleibt Manipulation am PC oder Kamerafehlfunktion (Zähler hochgezählt aber keine Datei auf der SD-Karte abgelegt).

Teilw. konnte ich den Inhalt von CTG-Dateien entschlüsseln:

Die Größe von CTG-Dateien ist exakt berechenbar durch:
868 + #Files x 20 [Byte]

d.h. mit nur einer einzigen Datei im Ordner ist die CTG genau 888 Bytes lang, mit 236 Dateien ist sie 5588 Bytes lang.

In einen Cluster passt damit eine CTG für max. 1595 Dateien = (32768 - 868) / 20.

• Byte 0x12 ist die Ordnernummer.
• Byte 0x24, 0x28, 0x52, 0x54 und 0x58 enthalten alle die Anzahl Dateien
• Rest unklar
• Jeder 20 Byte-Block besteht aus:
  
  • Die ersten 4 Byte scheinen das Datum anzugeben, aber das genaue Format ist unklar (Anzeige als DOS-Datum scheint jedenfalls korreliert). Vermutlich kommt danach die Zeit, aber das Format ist noch unklarer. Rest ist ebenfalls unklar (Dateigröße?, ...)
  
  

• Alle Daten die sonst auffindbar bleiben könnten (Drive-Slack) löschen, indem man ein große Leerdatei (komplett 0xFF) schreibt, diese löscht und dann noch mind. eine Datei schreibt, funktioniert prima.
• Der Dateizähler der Kamera lässt sich auch durch Dateien manipulieren die keine Canon-Jpegs oder -Videodateien sind, wie z.B. Leerdateien (s.o.), solange sie dem Dateinamensschema entsprechen
• Rücksetzen des Dateizählers geht auch, wenn man auf "autom. Rücksetzen" und dann direkt wieder auf "Fortlaufend" umstellt. Die nächste Datei-Nummer entspricht der höchsten auf der SD-Karte (im akt. Monat) + 1 (auch wenn das keine Canon-Datei ist, s.o.)

Wenn nur die letzten N Aufnahmen gelöscht wurden, dann eine Leerdatei mit dem Namen IMG_0509.JPG auf die SD-Karte kopiert wurde, dann von "Fortlaufend" auf "autom. Rücksetzen" und sofort wieder zurückgestellt wurde, aber erst danach das erste Nachtbild gemacht worden wäre, dann hieße das nächste Bild IMG_0510.JPG (angrenzend an #508 und Drive-Slack vor #511 wäre leer).

Beim Löschen auf der Kamera müsste es aber eine CTG irgendwo zw. #476 und #510 geben!

Dass das Kopieren vom PC den last-modified-Zeitstempel des Monatsordners 102___04 verändert hätte, wäre nicht nachweisbar (falls Täter den vergessen hätten zurückzusetzen), weil die pan. Ermittler ihn später selbst nochmal verändert haben (durch Bilderdrehen, 40 Thumbails anlegen und nochmal beim Löschen).

Das Setzen der Filesystem-Timestamps unter Linux hat sich als erstaunlich schwierig herausgestellt. Bei creationDate stimmt das Datum, aber die Zeit nicht, bei lastModified stimmt eigentlich nur das Jahr.

Unter Windows (Win-7) funktioniert derselbe Code problemlos (führt zum gewünschten Datum/Uhrzeit).

Soetwas ähnliches was Agno sich gebastelt hat gibt es zu kaufen: SD-Karten-Verlängerungskabel. Das habe ich mir mal gegönnt:

Original anzeigen (0,4 MB)

Original anzeigen (0,4 MB)

und zwar für einen ganz bestimmten Test...