Hallo Robert, Robert Michel <[EMAIL PROTECTED]> wrote: > Ok jetzt zu fsck.vfat: > # fsck.vfat /dev/loop1 > dosfsck 2.10, 22 Sep 2003, FAT32, LFN > Logical sector size is zero. > > Ein frisch formatierte Karte liefert �brings die > gleiche Angabe.
Bei einer formatierten Karte mu� eigentlich die Anzahl der Cluster angezeigt werden. So in der Art etwa: dosfsck 2.11, 12 Mar 2005, FAT32, LFN 32mb.img: 0 files, 0/15640 clusters Oder meinst Du mit formatiert 'dd if=/dev/ zero of=/dev/hdX bs=512'? Wenn nur der erste Sektor besch�digt/gel�scht wurde, dann k�nntest Du diesen mit dd von einer anderen Karte mit gleicher Kapazit�t und gleicher Formatierung kopieren. Das w�rde Dir etwas nutzen, wenn nicht noch weitere Sektoren besch�digt sind. > Was mu� ich lesen um zu wissen, was da nicht stimmt? > Google hat mir nicht helfen k�nnen. Wenn der erste Sektor z.B. gel�scht wurde, dann fehlen alle logischen Informationen dar�ber wie der Platz auf der Karte organisiert wird. Informationen wie das FAT Dateisystem aufgebaut ist findest Du z.B. hier: http://en.wikipedia.org/wiki/File_Allocation_Table http://www.inf.hs-zigr.de/~maetti01/?page=Studium/FAT32 sehr ausf�hrlich auch hier: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx > autopsy hatte ich schon probiert - ohne das ich etwas damit gefunden > habe. Das h�ngt damit zusammen das es keine Informationen �ber das verwendete Filesystem gefunden hat. > Bei foremost hatte ich erst bef�rchtet, es w�re nur f�r > Bilder, Audio und Video - aber man kann die Header frei w�hlen. > Wobei ich nicht verstehe warum es keine eindeutigen Deiteianfangs > und Endeformatierungen gibt. Bei bin�ren Formaten gibt es fast immer einen Header in dem weitere Informationen zum Inhalt stehen. Dieser setzt sich meistens aus einer eindeutigen Kennung (z.B. %PDF bei Dateien im PDF-Format) und weiteren Informationen �ber den Dateiinhalt zusammen (z.B. die Gr��e und Farbtiefe bei Bildformaten). Die Kennung wird von den Programmen auch verwendet um zu erkennen ob sie den Inhalt der Datei auch interpretieren k�nnen. W�rdest Du beispielsweise in einer PDF-Datei %PDF durch %XYZ ersetzen, dann k�nntest Du Dir das PDF-Dokument nicht mehr anzeigen lassen. Da ein Anzeigeprogramm die Datei dann nicht mehr als PDF erkennen w�rde und somit auch garnicht erst versucht den Inhalt der Datei zu interpretieren. Weil es Datenformate gibt in denen Informationen in verschiedenen Bl�cken abgelegt sind (z.B. JPEG) wird das Ende eines Blocks mit einem Footer gekennzeichnet (z.B. bei JPEG sind das die Bytes FFh, F9h). > OK fat ist von M$ verbreitet worden - ich sollte mich nicht wundern. Der Dateiaufbau hat aber nichts mit dem Filsystem zu tun. > Gibt es keine Tools, die alle Dateien, auch Exotische Formate > wiederherstellen k�nnen? Es kommt immer darauf an welche Informationen noch da sind. Ist das Inhaltsverzeichnis auf einer FAT Partition gel�scht, z.B. durch 'mkfs.vfat /dev/hdX', dann sind die Daten der Dateien immer noch auf der Partion vorhanden. Es fehlt aber der Hinweis wie eine Datei gehie�en und in welchem Sektor sie begonnen hat. Ohne diese Informationen kann z.B. autopsy eine gel�schte Datei nicht wieder herstellen. Foremost k�nnte es aber trotzdem noch. Und zwar macht es sich eben Header und Footer einer Datei zu nutze. Es liest einen Sektor ein und �berpr�ft ob dieser mit einem zu pr�fenden Header beginnt. Ist das nicht der Fall liest es den n�chsten und so fort. Wird ein passender Sektor gefunden, dann liest es solange weitere Sektoren ein bis es auf den Footer trifft oder die angegebene maximale L�nge erreicht wurde. Daran ist aber schon zu erkennen, das es nur dann wirklich erfolgreich ist, wenn: - alle zur Datei geh�renden Sektoren hintereinander liegen - das Dateiformat sich mindestens durch einen Header festlegen l�sst > F�r Palm Programme *.prc und Datenbanken *.pdb mu� ich also > passende Werte f�r die foremost.conf finden Du l�sst Dir einfach von einigen Dateien des gleichen Typs die ersten und letzten Bytes anzeigen und schaust ob da konstante Bytefolgen zu erkennen sind. Die kannst Du dann in der foremost.conf eintragen. f�r Header: hexdump - Cn 15 dein.prc f�r Footer: tail --bytes 15 dein.prc | hexdump -C > Ich glaube das Forensische Datenwiederherstellen erschlie�t sich > nicht an einem Abend - daher werde mein image beiseite legen und > versuchen schrittweise verschiedene Dateitypen wiederherzustellen, > bevor ich es mit dem 128 MB Image probiere. Zuerst musst Du Dir theoretisches Wissen �ber den Aufbau des Filesystems aneignen. Ansonsten suchst Du die Nadel im Heuhaufen. Mit den theoretischen Grundlagen ist es dann vielleicht nur der Nagel im Strohballen. ;-) Wenn auf der Karte zuvor h�ufig Dateien gel�scht, �berschrieben, neu angelegt wurden, dann sind die Erfolgschancen wegen der dadurch entstandenen Fragementierung eher gering. Die Erfolgschancen w�rde ich in so einem Fall als umgekehrt proportional zu Fragmentierung und Dateigr��e ansehen. nette Gr��e Frank
