SD-Karte Filesystem Block/Cluster-Versuche

sceptical schrieb:Allerdings glaube ich schon, dass der NFI zumindest nachträglich sich die Sache nochmal genauer angeschaut hat

Da würde ich nicht drauf wetten. Wenn sie in der richtigen Untersuchung solche Sachen "vergessen" haben (und Slack sollte nun das ganz kleine 1x1 eines IT-Forensikers sein), wer sollte da später nochmal nachgehakt haben? Denkst du die haben sich später doch noch eine Vergleichskamera besorgt? Weil ohne die hätten sie ja ganz basale Dinge nie verstanden (wie man im Bericht ja sieht - Stichwort: Thumbnails).

Der Bericht ist ja klar widersprüchlich: Man geht von einer gelöschten Datei #509 aus und behauptet es wäre kein Fitzelchen von #509 auffindbar. Das ist aber sehr unwahrscheinlich (wegen der Kleinheit von #510). Das hätte man mMn unbedingt thematisieren müssen. Hat man aber nicht.

---

@Anthurium
Ich habe jetzt nicht alles gelesen, aber sehe, dass du nach einer Analogie suchst. Ich habe auch lange nach einer brauchbaren Analogie gesucht, aber keine gefunden. Die Übersetzung in Gewichte ist jedenfalls nicht hilfreich. Ganz gut (graphisch) dargestellt ist es im deutschen Wikipedia-Artikel: Slack

Stell dir vielleicht eine sehr lange graue Linie vor: das ist der leere Speicher der SD-Karte. Jetzt kannst du beliebig lange farbige Linien darauf zeichnen. Jede Farbe ist eine Datei und sie darf jede beliebige Länge in mm haben (1mm, 145645mm, whatever). Aber du darfst jeweils nur an bestimmten Punkten anfangen eine Linie zu zeichnen - nämlich nur bei 0, 32cm, 64cm, 96cm, ... also nur alle 32cm ab Start.

Wenn deine erste Linie / Datei (rot) nun z.B. bei 0 beginnt und 731mm lang ist, dann darf die nächste Linie/Datei (blau) erst bei 96cm anfangen. Dazwischen bleibt also eine Lücke (ab 732mm bis 959mm).

Allerdings beschreibt die Kamera immer Blöcke von 5mm Länge. Hier füllt sie also hinter 731 noch bis 734/735mm mit "Datenmüll" (RAM-Slack) der bei der Kamera nicht rein zufällig ist, sondern von der jeweils zuvor geschrieben Datei beeinflusst wird. Am Ende der blauen Linie siehst du also einen winzigen roten Anhang (wenn zwischen rot und blau die Kamera eingeschaltet blieb - und der Teil ist tatsächlich etwas komplizierter)

Im Rest der Lücke (also hinter 735mm bis 959mm) bleibt sichtbar was dort vorher schon stand (Drive-Slack). Wenn du da vorher schon eine (gelbe) Linie/Datei hingzeichnet hattest, die bei 0 begann und länger als 735mm war, dann siehst du noch einen Teil dieser (gelben) Linie (das ist tatsächlich relativ simpel).

Hilft das? Wie gesagt zeichne es mal selbst auf ein Blatt. Ich glaube das hilft beim Verständnis (ich brauche immer Papier zum krakeln, wenn ich über etwas nachdenke).

cyclic schrieb:Weil ohne die hätten sie ja ganz basale Dinge nie verstanden (wie man im Bericht ja sieht - Stichwort: Thumbnails).

Bei den Tumbnails muss man dem NFI zu gute halten, dass diese Annahme durchaus erstmal sinnvoll war, weil die Kamera auch eine Miniaturansicht hat.

cyclic schrieb:Der Bericht ist ja klar widersprüchlich: Man geht von einer gelöschten Datei #509 aus und behauptet es wäre kein Fitzelchen von #509 auffindbar. Das ist aber sehr unwahrscheinlich (wegen der Kleinheit von #510). Das hätte man mMn unbedingt thematisieren müssen. Hat man aber nicht.

Ja, da liegt tatsächlich ein großes Problem im Bericht. Der Bericht beschreibt eigentlich erstmal nur den vorgefundenen Zustand, arbeitet aber keine konkreten Szenarien aus, durch welche das entstanden sein kann.

cyclic schrieb:Die Übersetzung in Gewichte ist jedenfalls nicht hilfreich. Ganz gut (graphisch) dargestellt ist es im deutschen Wikipedia-Artikel:

In diesem Artikel gibt es übrigens über RAM-Slack eine Stelle, die mir etwas aufstößt:

In weiten Teilen der Literatur über Forensik wird angegeben, dass dies auch noch für heutige Betriebssysteme gilt, es wird jedoch sowohl von Brian Carrier, dem Autor des in der Computerforensik häufig genutzten SleuthKits, als auch von Steve Bunting, einem erfahrenen Ermittler, Ausbilder und Autor einiger Bücher über Forensik, ausdrücklich verneint.

Bezogen auf die Kamera ist der Absatz nicht so wichtig, weil sie sich hier hauptsächlich auf die bekannten Betriebssysteme (Windows, Linux usw.) beziehen und nicht direkt auf Firmware irgendwelcher Geräte. Allerdings hinterlässt bei mir Linux sehr wohl zumindest irgendwelche Daten hinter dem Dateiende im Sektor, daher sind diese Aussagen von Carrier und Bunting für micht etwas fraglich. Eventuell meinen sie damit, dass man dort keine wirklich verwertbaren Inhalt findet?

sceptical schrieb:Allerdings hinterlässt bei mir Linux sehr wohl zumindest irgendwelche Daten hinter dem Dateiende im Sektor, daher sind diese Aussagen von Carrier und Bunting für micht etwas fraglich. Eventuell meinen sie damit, dass man dort keine wirklich verwertbaren Inhalt findet?

Solange da nicht wie Windows früher einfach irgendein Teil des RAMs reingeschrieben wird, der potenziell auch z.B. Passwörter (im Klartext) enthält, sondern random Daten oder irgendwie "Daten" die garantiert nicht irgendwie verwendbar sind, ist ja alles in Ordnung. Warum scheinbar auch heute nicht einfach "nichts" geschrieben wird (bei NAND also alles auf 0xFF lassen) erschließt sich mir aber auch nicht wirklich. Ist aber für den Fall alles irrelevant.