Hallo, ich hätte mal eine Frage zur Datenwiderherstellung von Datenträgern. Ich meine, die Bits und Bytes sind doch generell vorhanden und müssen eigentlich nur in einer definierten Reihenfolge ausgelesen werden... D.h. es müsste doch möglich sein, z.B. nach beliebigen JPEG Files zu suchen, indem man einen kleinen Bildausschnitt von z.B. 100x100 Pixeln als JPEG-Datei annimmt und eben die nachfolgenden Bytes die Man auf der Platte liest in einem entsprechenden Fenster anordnet. So einen Rahmen schiebt man dann über die gesamte Festplatte und irgendwann erkennt man ein Klarbild, welches nicht verwaschen ist. Davon ausgehend könnte man doch dann mehr als nur einen kleinen Schnipsel aufdecken und die wahre Größe des Bildes ermitteln. Sobald dies erfolgreich war und eben eine einzige Datei erkannt ist, müsste doch die Wahrscheinlichkeit relativ hoch sein, die benachbarten Dateien auf der Festplatte ebenfalls zu erkennen, da wohl zum einen Dateien gleichen Typs (Bilder, Musik, Videos,...) vermutlich im gleichen Verzeichnis liegen und mit hoher Wahrscheinlichkeit auch in benachbarten Speicherzellen auf der Festplatte. mehrere mögliche Auflösungen / Höhen und Breiten ausprobiert und dann versucht aus den nachfolgenden Bytes ein Klarbild zu erhalten. Sobald man einen kleinen Schnipsel richtig zugeordnet hat, ergibt sich die richtige Auflösung des Bildes doch von alleine. Eifnacher als ein Bild ist es wohl, nach Textdateien zu suchen, da eigentlich nur reguläre Wörter in der zu erwartenden Sprache gefunden werden müssen. Ich meine, mir ist klar, dass ich mir das alles etwas einfach vorstelle, aber mich würde mal interessieren, ob dies ein prinzipieller Weg ist, Dateien auf Datenträgern wiederzuerkennen.
:
Verschoben durch User
Datus schrieb: > Ich meine, die Bits und Bytes sind doch generell vorhanden und müssen > eigentlich nur in einer definierten Reihenfolge ausgelesen werden... wer sagt das? Jeder Magnet, jeder Kratzer, jedes Feuer kann eine Datenträger so veändern, das die bits nicht mehr erkennbar sind.
das ganze gibt es schon fertig, zwar nicht ganz so wie beschreiben, aber es sucht auf einer Festplatte die Dateien http://www.cgsecurity.org/wiki/PhotoRec
Deine Methode funktioniert vielleicht bei .bmp Files, .jpg sind IMHO komprimiert da geht das nicht so einfach. Wenn die Datei dann auch noch fragmentiert ist wird es auch nicht klappen. Aber im Prinzip(wenn auch ein wenig komplizierter) wir es ja auch so gemacht. EDIT: AchJa, falsches Forum...
:
Bearbeitet durch User
Hei, und dann ist da noch die böse Fragmentierung, die dafür sorgt, dass eine Datei in viele, viele kleine Häppchen zerlegt wird und über die ganze Platte verstreut ist. Die FAT (File allocation table) beschreibt dann, wo diese einzelnen Happen liegen. Soweit zu meinem Halbwissen... ;-) Grüße, Tom
> und mit hoher Wahrscheinlichkeit auch in benachbarten Speicherzellen auf der
Festplatte.
Das kommt drauf an, wie lange die Platte in Betrieb war. Nach relativ
kurzer Zeit ist es nämlich nichts mehr mit "mit hoher Wahrscheinlichkeit
sind die benachbart". Dann heißt es nämlmich "mit hoher
Wahrscheinlichkeit sind die irgendwo auf der Platte, aber sicher nicht
nebeneinander".
Darin liegt der der Clou bei Wiederherstellungsprogrammen für die üblichen Fotos. Mit genug Intelligenz und Zeit sollten die sich recht gut rekonstruieren lasst, selbst wenn fragmentiert (wobei mir nicht klar ist, weshalb Fotos in sich stark fragmentieren sollten). Das Zeug muss konsistent dekomprimierbar sein, Kanten müssen zusammenpassen usw. Wenn dann noch Infodaten der Kamera im Bild drin sind, also von wann und heute nicht selten auch von wo, dann ist auch die ursprüngliche Zuordnung und Zeitachse leicht wiederherstellbar.
:
Bearbeitet durch User
A. K. schrieb: > (wobei mir nicht klar ist, weshalb Fotos in sich stark fragmentieren sollten). Ganz einfach, weil ein Cluster (ein Block an Daten, der nicht weiter zerkleinert wird) bei z.B. NTFS irgendwas zwischen 512Byte und 64KByte hat. Ein normales Digitalfoto hat wohl heutzutage mehr als 3MB. Damit kann dieses Foto z.B. auf 96 Cluster der Größe 32kB aufgeteilt werden und diese können wild verstreut auf der Festplatte sein. Das wäre dann doch eine "starke Fragmentierung"... Grüße, Tom
Hm, da lag ich ja mit meinem Halbwissen schonmal nicht so schlecht. Was ich mir nun aber in Anlehnung an die ursprüngliche Fragestellung ebenfalls Kopfschmerzen bereitet, ist die Frage, inwieweit man einer derartigen Datenwiederherstellung durch eine Verschlüsselung begegnen kann? Arbeitet ein Verschlüsselungsprogramm derart, dass wirklich jedes Bit quasi-zufällig nach einem Algorithmus gekippt wird, oder sind nicht am Ende doch wieder alle benachbarten Speicherzellen in ähnlicher weise gekippt, bzw. nur bestimmte N-Bytes einer Datei verändert? Wenn nämlich jedes Bit gekippt würde, dann würde eine Verschlüsselung nicht nur sehr sehr lange dauern, sondern abhängig von der Art des Schlüssels müsste entweder genauso lang sein, wie die zu verschlüsselnden Daten, oder aber es würden Redundanzen auftreten. Redundanzen treten immer dann auf, wenn man denselben Schlüssel mehrmals auf unterschiedliche Daten anwendet. In einem solchen Fall kann, soweit ich weiß, aus der Häufigkeitsverteilung mit hoher Wahrscheinlichkeit auf die ursprünglichen Daten zurückgeschlossen werden...
>NTFS irgendwas zwischen 512Byte und 64KByte
...aber gerade bei Fotos ergibt sich doch aus Blöcken, die eine Größe
von 64kByte haben eine so große Menge an Daten, dass es speziell bei
Fotos Randbereiche geben muss, die mit > 99,9% Wahrscheinlichkeit genau
benachbart zu einem anderen Fotopuzzle-Stück liegen und demnach einfach
gefunden werden können...
Hei, woran erkennst Du eigentlich, ob ein Block komplett Daten enthält oder evtl. nur die Hälfte davon sinnvoll ist? Naja, bestimmt gibts da ein Steuerzeichen dafür... Andere Frage: Was bringen Dir diese theoretischen Überlegungen für einen Nutzen? Grüße, Tom
Datus schrieb: > aber gerade bei Fotos ergibt sich doch aus Blöcken, die eine Größe > von 64kByte haben eine so große Menge an Daten, dass es speziell bei > Fotos Randbereiche geben muss, die mit > 99,9% Wahrscheinlichkeit genau > benachbart zu einem anderen Fotopuzzle-Stück liegen und demnach einfach > gefunden werden können... so einfach ist das nicht. Es gibt ja noch viel mehr Infos in den Imagedaten. Wenn das Image fragmentiert ist, woher willst du wissen welche Header-Infos( EXIF ) zu welchen bild gehören? Auch sind die Blöcke im Image (wenn es überhaupt welche gibt) nicht die gleichen Blöcke mit den ein Dateisystem arbeitet, sie sind nicht gleich ausgerichtet. Das ein Image überhaupt Fragmentiert ist, kommt recht selten vor. JPEGS haben einen Dateiaufbau, damit finden man auch ohne Bildanalyse die Bilder.
Peter II schrieb: > so einfach ist das nicht. Es gibt ja noch viel mehr Infos in den > Imagedaten. Wenn das Image fragmentiert ist, woher willst du wissen > welche Header-Infos( EXIF ) zu welchen bild gehören? Erst einmal sortiert man mögliche Fragmente der Bilder über Konsistenz des Formats und über inhaltliche Kriterien zusammen. Wie beschrieben hatte ich das für prinzipell möglich, wenn auch vielleicht nicht in jedem Fall. Die EXIF Daten sind dann aufgrund ihres geringen Anteils an der Grösse automatisch ein Teil davon. > Auch sind die Blöcke im Image (wenn es überhaupt welche gibt) nicht die > gleichen Blöcke mit den ein Dateisystem arbeitet, sie sind nicht gleich > ausgerichtet. Richtig. Deshalb die Konsistenzbedingung.
Tom P. schrieb: > Andere Frage: Was bringen Dir diese theoretischen Überlegungen für einen > Nutzen? Manche Leute haben sie ihre Fotomedien zerlegt. Beispielsweise durch defektes NAS.
A. K. schrieb: > Manche Leute haben sie ihre Fotomedien zerlegt. Beispielsweise durch > defektes NAS. ja über dafür gibt es schon ausreichend Programme die die Images wieder finden. Ist ja nicht so das das Thema neu ist.
Datus schrieb: > Arbeitet ein Verschlüsselungsprogramm derart, dass wirklich jedes Bit > quasi-zufällig nach einem Algorithmus gekippt wird, oder sind nicht am > Ende doch wieder alle benachbarten Speicherzellen in ähnlicher weise > gekippt, bzw. nur bestimmte N-Bytes einer Datei verändert? heutige verschlüsselungen kippen bei jedem aufruf rund 50% der Bits undabhängig derer position. Datus schrieb: > Wenn nämlich jedes Bit gekippt würde, dann würde eine Verschlüsselung > nicht nur sehr sehr lange dauern, sondern abhängig von der Art des > Schlüssels müsste entweder genauso lang sein, wie die zu > verschlüsselnden Daten, oder aber es würden Redundanzen auftreten. Jedes bit zu kippen ist die einfachste Verschlüsselung. Rate mal wieso. Ich rate dir die Wikipediaartikel zu AES und RSA zu lesen. Die Länge der Schlüssel ist bei den meisten verfahren Fix. Wenn du also ein Passwort eingibst wird ein passender Hash dazu berechnet. deshalb ist die Lände eines Passworts in sofern nur interessant, als dass der Raum der gültigen Hashes für jede Buchstabenkombination berechnet und beim knacken ausprobiert werden kann. Nennt sich RainbowTable. Redundanz vermeidet man heute weitgehents indem man den Strom betrachtet und nicht jedes Byte, vergleiche ECB und CBC.
Datus schrieb: > Arbeitet ein Verschlüsselungsprogramm derart, dass wirklich jedes Bit > quasi-zufällig nach einem Algorithmus gekippt wird, hast du dir mal überlegt wie man ein quasi zufällig gekipts Bit zurückrechnen soll?
Datus schrieb: > oder sind nicht am > Ende doch wieder alle benachbarten Speicherzellen in ähnlicher weise > gekippt Alle real angewandten Verschlüsselungsprogramme führen eine Anzahl von Vertauschungsoperationen durch, um das zu verhindern und um jeden Rest von statistischen Zusammenhängen zu beseitigen. D.h. es werden nicht Bytes, sondern Blöcke bearbeitet. Gruss Reinhard
kopfkratz Welches Filesystem und wie sind die Daten "verloren" worden ? Un*x und rm = inode weg = absolut gelöscht Un*x Journaling FS und Stromausfall = fsck und es werden nur die Daten die geöffnet waren überprüft Un*x ohne Journaling FS = fsck und vieeeeel Kaffee ... Wenn es dagegen darum geht gezielt bestimmte Daten wieder aufzuspüren macht man normalerweise eine 1:1 Kopie auf einer identischen Platte und läßt nachdem man das Filesystem wieder hergestellt hat Software darüber laufen die auf FS Ebene versuchen die gesamte Datei zu erkennen. Die Idee mit Deinen Bildfragmenten oder Textbaustein funktioniert so nicht wirklich. Kannst ja mal im Windows Suchindex das Wort "Kin" eingeben, wenn dann jemand mal im Netz nach "kin" gesucht hat wird's im Browsercache fündig, wenn jemand eine e-mail für Oma Friede verfaßt hat und da "Kinners" drinsteht wird das auch gefunden usw. usf. Du mußt also unterscheiden zwischen Datenwiederherstellung und Datensuche. Und wenn dann jemand so gemein war TrueCrypt zu installieren oder die Verschlüsselung im Un*x Kernel, tja dann kommst Du auch mit einer 1:1 Kopie ohne das Paßwort nicht weiter. Es reicht sogar meistens ein PW geschütztes ZIP um die Schweizer Kontodaten der Steuer vorzuenthalten :-P
Die besseren Festplattenverschlüssler klinken sich zwischen dem Dateisystem und dem sektorweisen Schreiben auf a) Treiberebene =Softwarebasiert und b) Interfaceebene =Hardwarebasiert ein. Sie nehmen praktisch den zu schreibenden Block vom Betriebssystem entgegen, verschlüsseln ihn komplett und schreiben diesen dann statt des Klartextes auf die Festplatte. Beim Lesen läuft es genau umgekehrt: der zu lesende Bock wird von der Festplatte angefordert, entschlüsselt und an das Betriebssystem weitergreicht. Dazu braucht der Festplattenverschlüssler folgende Parameter: Algorithmus +Modus (AES/DES + CBC/XTS.. Wird bei der Herstellung / Programmierung des Verschlüsslers Fix vorgegeben), Schlüssel, IV und Nebenbeisachen wie Hashes. Die Verschlüssler, die einfach nur Dateien verschlüsseln, sind nur sicher, solange niemand auf die Festplatte schaut. Denn die Daten liegen dort in der Regel auch im Klartext und sind mit den "Datentettungsmaßnahmen" des TO recht zuverlässig wiederherstellbar.
Andy P. schrieb: > Die Verschlüssler, die einfach nur Dateien verschlüsseln, sind nur > sicher, solange niemand auf die Festplatte schaut. Denn die Daten liegen > dort in der Regel auch im Klartext und sind mit den > "Datentettungsmaßnahmen" des TO recht zuverlässig wiederherstellbar. Ist irgendwie nicht ganz logisch oder. Wenn ich dem BS DatenBlöcke zum schreiben auf Festplatte gebe kann es ihm herzlkich egal sein was das für daten sind. Das BS kann nicht entscheiden ob er verschlusselt ist. Wäre ja noch schöner. Es ist eine Frage des Anwendungsfalls wann die Daten verschlüsselt werden. Bei einer Full disk entcryption ist es so wie wie du vorher gesagt hast. Der Vorteil dabei ist, dass ich mir keine gedanken machen muss wenn ich den pc ausmache. Wenn er gestohlen wird kann keiner die daten lesen. Werden nur Anwenderdateien verschlüsselt geht das zum einen auch wie du gesagt hast mit gleichem vorteil oder ich nehm ein Programm. Beim Programm habe ich nur den Nachteil dass ich mich selber darum kümmern muss dass keine Klartextversion noch vorhanden ist beim ausmachen. Verschlüsselt ist verschlüsselt egal auf welcher ebene.
dsd schrieb: > Ist irgendwie nicht ganz logisch oder. Folgende Sequenz: (1) File wird entschlüsselt. (2) File wird bearbeitet. (3) File wird wieder verschlüsselt. Ein sauber arbeitendes Verschlüsselungsprogramm sollte klug genug sein, die entschlüsselte Version zu plätten, bevor es sie löscht. Andernfalls liegt deren Inhalt im Klartext noch auf Disk und kann gefunden werden. Dieses Problem kann aber auch durch das Programm in (2) entstehen, wenn dabei temporäre Versionen, implizite Backups usw. erzeugt werden, die nach Beendigung wieder weggeräumt werden. Um solche Probleme zu vermeiden muss man systematisch dafür sorgen, dass alle gelöschten Files überschrieben werden und erst dann deren Platz vom Filesystem freigegeben wird. Es gibt Tools, die mindestens auf Anfrage den kompletten Freiraum des Filesystems plätten. Evtl. gibts das auch automatisch, als Teil der Löschoperation.
:
Bearbeitet durch User
A. K. schrieb: > Evtl. gibts das > auch automatisch, als Teil der Löschoperation. Das wäre entweder ein Eingriff ins Betriebssystem - nicht so gut - oder die Software selbst sollte immer zuerst Nullen schreiben und dann den Bereich löschen (und möglichst dafür sorgen, dass die Nullen vom BS auch tatsächlich geschrieben werden, sonst wird das möglicherweise wegoptimiert). Schneller wird der Rechner dadurch nicht gerade. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.