Filesystem wipen

RobJ

Well-Known Member
Hallo,

ich möchte ein paar Festplatten mit ext3 FS wipen. Habe dazu im Netz gelesen, daß das Protokoll des FS eine saubere Lösung verhindert. Was kann ich tun, um die Platten richtig zu säubern? Danke vorab,

Grüße
RobJ
 
Hallo,

ich möchte ein paar Festplatten mit ext3 FS wipen. Habe dazu im Netz gelesen, daß das Protokoll des FS eine saubere Lösung verhindert. Was kann ich tun, um die Platten richtig zu säubern? Danke vorab,

Grüße
RobJ

Moin Rob,

sogenannte journalisierende Dateisysteme, wie ReiserFS oder Ext3, führen jedoch Buch über getätigte Schreiboperationen, um im Fehlerfall ein aufwändiges Suchen von Fehlern im Dateisystem zu unterbinden. In diesem Journal können allerdings Daten zu den zu löschenden Dateien gespeichert sein. Wipe ist jedoch nicht in der Lage, dieses Journal zu verändern. Deshalb ist die Arbeitsweise von Wipe bei journalisierenden Dateisystemen nur durch den Dateisystemtreiber realisierbar.

Soviel dazu als Auszug von wikipedia zudem Tool Wipe:

das hilft Dir aber auch nicht so wirklich !

Mit ist keine Möglichkeit bekannt, in einem Journaling-FS einzelne Dateien zu löschen.
Um alle Daten sicher zu löschen muss die gesamte Partition im ungemounteten Zustand ge-wiped werden.

Oder aber:

Im wesentlichen heisst das,... moderne Dateisysteme machen mit den Daten
noch andere Spielchen, so dass diese uU an anderen Orten auf der Platte
zu finden sind (oder Teile davon, oder Informationen über sie),... ergo
würde ein wipen der "für den User sichtbaren Datei" nicht ausreichen,...
Ob ein patchen des fs-Treibers da hilft ist fraglich,... weil der müsste
dann ja mitloggen was er jemals mit den Daten gemacht hat,.. und
wahrscheinlich noch einiges mehr....
Also sicherste lösung ist die,.. Daten auf ander Platte kopieren
(_NICHT_ per dd) und dann alte Platte komplet wipen.

Einzelne Dateine/Verzeichnisse zu löschen (bei modernen Filesystemen)
ist tatsächlich nicht so sinnvoll... man stelle sich nur folgendes
Beispiel vor,.. man hat nen RSA key,.. den man löschen will, der aber
vorher geswapped wurde... (ok Progs wie gpg sollten ein swappen zwar
verhindern,... aber nur vom Prinzip her)


gruss rudy
 
verstehst du unter "wipen" loeschen so dass man nicht mehr feststellen kann was auf den platten drauf war?
ist doch kein problem!

ich kenn die laufwerksbezeichnungen unter freebsd nicht, aber eigentlich sollte sowas wie das hier funktionieren:
Code:
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% newe2fs ... (oder so)

wenn du das acht mal hintereinander auf die parition machst dann ist die partition ziemlich sicher geloescht.
 
Unter Linux wäre noch Folgendes möglich, um eine ganze Partition oder Platte zu überschreiben:

Code:
badblocks -w -t 0xaa -t 0x55 -t 0xff -t 0x00 -t random /dev/xxx

Je nach Bedarf kann man natürlich auch noch weitere 'test_pattern' nehmen.
 
verstehst du unter "wipen" loeschen so dass man nicht mehr feststellen kann was auf den platten drauf war?
ist doch kein problem!

ich kenn die laufwerksbezeichnungen unter freebsd nicht, aber eigentlich sollte sowas wie das hier funktionieren:
Code:
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% newe2fs ... (oder so)

wenn du das acht mal hintereinander auf die parition machst dann ist die partition ziemlich sicher geloescht.

Frohe Ostern dettus :)

denke er meint das Löschen so das keine Widerherstellung mehr möglich ist, jo und das ist bei jounaled basierten Filesystems nicht so ohne weiteres möglich !
möchte jetzt nicht den Besserwisser raushängen lassen, aber die daten könnten auch nach Deinem Vorschlag wiederherrgestellt werden...

<klugscheissermodus>

Warum das so ist.....
Wie gesagt, dazu sollte man den Aufbau einer Festplatte kennen

Egal ob Formatieren, Low-Level Formatieren oder was auch immer für tolle Sachen hier in's Spiel kommen - bei solchen Sachen ist es einfach die Daten wieder herzustellen. Formatieren ist wie löschen.
Technisch KEIN Unteschied, logisch ist der einzige Unterschied, dass nicht nur die Datei als "Gelöscht" gekennzeichnet wird, sonder jeder einzelne Festplattensektor. Hier will ich nicht in's Detail gehen, das is eine langweilige Angelegenheit.

Die Sachen, die einem Daten Forensiker - so nennt man die Leute die das Beruflich machen, Daten wieder herstellen,den Job schwermachen, sind sogenannte ERASER oder wie auch immer diese Löschtools heisen.

Aber wie gesagt, nix ist (fast) unmöglich...

In sogenannten "unallozierten Bereichen" eines Dateisystems befinden sich sogenannte "File Slacks" oder auch Informationen im "Alternate Data Stream" (Linux, Unix, Windows - das Filesystem ist egal).
Unallozierte Bereiche sind Daten in Sektorresten die dann entstehen, wenn der zugewiesene Sektor für die zu speichernde Datei nicht übereinstimmt und es zu seinem sogenannten Sektorverschnitt kommt. Wie das entsteht würde allerdings zu weit führen.

Diese Bereiche bieten etwa Erkenntnisse über gelöschte Originaldateien oder Archive, welche schließlich auf (ehemals) vorhandene Daten schließen lassen.
Fragmente dieser Datei lassen sich oftmals auch teilweise wieder Herstellen, wie z.B. "halbe Bilder" oder "teile von Texten"
Durch eine genormte "Stringanalyse" lassen sich dann entscheidende Hinweise auf Verdächtige Daten oder Dateien entnehmen. Es werden ASCII Zeichen aus der Datei (oder aus dem Teil der Datei - dem SLACK) herausgenommen und entsprechend Analysiert.

Ich selbst arbeite mit EnCASE FORENSIC und was das Produkt bereits in der Grundversion bietet, ist für die meisten Fälle vollkommen ausreichend. Für die etwas schwereren Fälle gibt es dann die Möglichkeit Skripte selbst zu schreiben oder gar eine Auswertung mit ILook zu fahren (beide Produkte werden Hauptsächlich von den Strafverfolgunsbehörden verwendet, wie BKA, FBI, NSA).

So, und ich geb euch jetzt mal ein kleines Beispiel was anhand einer zerstörten und gefundenen Datei aus einem System zu erkennen ist:

Der Unix-Befehl file zeigt, dass es sich bei der "gefischten Datei" (in dem Beispiel in sun1 umbenannt) um eine ausführbare Datei für Solaris handelt:

$file sun1
sun1: ELF 32-bit MSB executable, SPARC, version 1, statically linked, stripped

Die darauf folgende String-Analyse stellt einige Zeichen dar, die einer
weiteren Nachforschung bedürfen:

#strings sun1
[...]
DISPLAY
/usr/lib/libfl.k
pirc
/bin/sh
[...]

Cool - oder??
Der Forensic Spezialist vermutete in diesem Fall, dass zwischen den Zeichen DISPLAY und /bin/sh ein Zusammenhang vorhanden ist, was in diesem Fall sogar ein blinder sieht.
Es wurde weiterhin angenommen, dass es sich um einen trojanisierten Ersatz für das Systemprogramm /bin/login handet und dieses würde Angreifern, die eine bestimmte Display-Variable gesetzt hätten, einen passwortlosen Root-Zugang ermöglichen.
Da wären wir wieder mal bei meinem Lieblingsthema OpenSource und Linux, aber ich will jetzt mal nicht drauf eingehen.
Man braucht also nicht nur technisches Wissen - Erfahrung und auch Bauchgefühl sind da selbstverständlich ebenso Richtungsweisend.

Weiter...

Die originale /bin/login-Datei wurde nach /usr/lib/libfl.k kopiert und wickelt im Anschluss den weiteren normalen Login-Prozess ab.
Als Wert für die besonders zu setzende Display-Variable wurde »pirc« vermutet, da der Wert in der Nähe des String DISPLAY in der Datei auftaucht.

Sollte soweit klar und deutlich für jeden herauszulesen sein.

Als Nächstes überwachte der Ermittler auf einer Solaris-Umgebung mit dem Analysetool "truss" (sollte auch jedem Linux/UNIX User bekannt sein) erneut sämtliche Ressourcenzugriffe der verdächtigen Datei:

$ truss ./sun1
execve("./sun1", 0xFFBEFC8C, 0xFFBEFC94) argc = 1
execve("/usr/lib/libfl.k", 0xFFBEFC8C, 0xFFBEFC94) Err#2 ENOENT
_exit(1)

Das ist jetzt schon etwas heftiger. Wer sich aber mal mit W32Dasm oder IDA beschäftigt hat (*gg*) ist hier eigentlich zuhause...

Es sah so aus, als wäre dies das Verhalten der verdächtigen Datei, wenn ein normaler User ohne gesetzte Display-Variable auf das System zugriff.
Es ist gut zu erkennen, wie dann die originale – umkopierte – Login-Datei (/usr/lib/libfl.k) aufgerufen wurde.
Der oben beschriebenen Vermutung folgend, wurde nun die Display-Variable durch die Ermittler auf den Wert »pirc« gesetzt und die verdächtige Datei abermals mit truss analysiert:

# export DISPLAY=pirc
# truss ./sun1
execve("./sun1", 0xFFBEFCA4, 0xFFBEFCAC) argc = 1
sigfillset(0x0002A5E4) = 0
sigprocmask(SIG_BLOCK, 0xFFBEFB0C, 0xFFBEFAFC) = 0
sigaction(SIGCLD, 0xFFBEF9C8, 0xFFBEFABC) = 0
vfork() = 6558
sigaction(SIGINT, 0xFFBEF9C8, 0xFFBEFA7cool = 0
sigaction(SIGQUIT, 0xFFBEF9C8, 0xFFBEFA5cool = 0
#
waitid(P_PID, 6558, 0xFFBEF968, 0403 ) (sleeping...)
# exit
waitid(P_PID, 20903, 0xFFBEF968, 0403 ) = 0
sigaction(SIGINT, 0xFFBEF9C8, 0x00000000) = 0
sigaction(SIGQUIT, 0xFFBEF9C8, 0x00000000) = 0
sigaction(SIGCLD, 0xFFBEF9C8, 0x00000000) = 0
sigprocmask(SIG_SETMASK, 0xFFBEFAFC, 0x00000000) = 0
_exit(1)

Damit Ihr was zum Nachvollziehen habt.
Ihr seht - ein bischen überdurchschnittliche UNIX Kenntnisse reichen aus, um da bereits zu erkennen, was wann wo wie passiert.
Anhand des Root-Prompts »#« ist zu erkennen, dass beim Setzen der »magischen« Display-Variable »pirc« eine passwortlose Root-Shell geöffnet wird. Und - das ganze aus einer halben Datei, wohlgemerkt.

Jetzt wurde bei dieser Analyse noch nicht mal mit den "großen Tools" auf diese Datei geschossen, lediglich mit frei verfügbaren Programmen. Ich denke, dass sollte nun wirklich jedem zu denken geben.

Fazit Unbekannte Binärdateien zu analysieren kann zu einer sehr komplexen Angelegenheit werden.
Wenn man mit den Methoden, der Analyse, dem Vorgehen, dem Betriebssystem und den Werkzeugen vertraut ist, kann man aber unter Unständen interessante Informationen erlangen, die demjenigen das Genick brechen können, dem der Rechner gehört bzw. der der Eigentümer der Datei ist.

Hier kommt es natürlich auch auf eine "Kosten-Nutzen-Rechnung" an. Denn bei einem einfachen "WAREZ Ripper" oder einem "Ab und Zu Crack Runterlader" spielt man nicht das Vollprogramm ab. Klar, so eine Analyse dauert mehrer Tage, manchmal sogar Wochen. Fakt ist aber - nix ist 100%ig.

Also - um es nochmals kurz zu machen, diese ERASER Tools sind ja ganz putzig.
ABER wenn nur EINE EINZIGE FALSCHE DATEI NICHT gelöscht ist, oder ein File Slack übersehen wird oder wie auch immer, tja, dann Pech. Glück für den, der auf dem Rechner Info's sucht...

</klugscheissermodus>

gruss rudy
 
Ist es denn nicht so, dass sowohl Dettus' Variante als auch meine direkt auf dem Blockdevice operieren und sich somit nicht um das Dateisystem scheren?

Ich hab zwar eigentlich keine Ahnung von der Materie, aber meine Variante mit badblocks sollte eigentlich ein Muster darstellen, dass eine Wiederherstellung relativ schwer macht. Ich hab, wie gesagt, eigentlich keine Ahnung, aber das von mir angegebene Muster ist so ausgelegt, dass man die vorherige Magnetisierung nur noch schwer feststellen kann. (kommt nicht von mir)

Natürlich kann man, bei extremem Aufwand, auch eine so gelöschte Partition/Platte wieder herstellen (mit geeigneter Hardware), aber das Ganze sollte doch eigentlich relativ sicher sein. (Kann man ja, wenn man ganz paranoid ist auch zwei mal laufen lassen)

Es kommt ja auch auf die Relationen an; wenn man sich zum Staatsfeind gemacht hat, und die entsprechenden Stellen schwere Geschütze auffahren ist das ja was anderes, als wenn eine 'normale' Privatperson mal eben eine Partition sicher löschen möchte...
 
Ist es denn nicht so, dass sowohl Dettus' Variante als auch meine direkt auf dem Blockdevice operieren und sich somit nicht um das Dateisystem scheren?

Ich hab zwar eigentlich keine Ahnung von der Materie, aber meine Variante mit badblocks sollte eigentlich ein Muster darstellen, dass eine Wiederherstellung relativ schwer macht. Ich hab, wie gesagt, eigentlich keine Ahnung, aber das von mir angegebene Muster ist so ausgelegt, dass man die vorherige Magnetisierung nur noch schwer feststellen kann. (kommt nicht von mir)

Natürlich kann man, bei extremem Aufwand, auch eine so gelöschte Partition/Platte wieder herstellen (mit geeigneter Hardware), aber das Ganze sollte doch eigentlich relativ sicher sein. (Kann man ja, wenn man ganz paranoid ist auch zwei mal laufen lassen)

Es kommt ja auch auf die Relationen an; wenn man sich zum Staatsfeind gemacht hat, und die entsprechenden Stellen schwere Geschütze auffahren ist das ja was anderes, als wenn eine 'normale' Privatperson mal eben eine Partition sicher löschen möchte...

Hallo danlei,

also bitte mich jetzt nicht falsch verstehen, euer Vorschlag ist ein durchaus gangbarer Weg und ich möchte den auch nicht abwerten, nein ganz im Gegenteil..

frohe Ostern gruss rudy
 
Rudy, kannst du mir erklären, wie "Schnipsel" einer Datei auf der Festplatte übrig bleiben sollen, wenn die gesamte Festplatte (formatunabhängig, also auf Blockebene) vollständig überschrieben wird mit zufälligen Mustern?

Was du sagst würde stimmen, wenn nur Teile der Festplatte überschrieben werden, bzw. das ganze auf Dateisystemebene gemacht wird, wenn es aber nicht auf Dateisystemebene gemacht wird, sondern direkt *jeder* einzelne Block der Festplatte überschrieben wird und dies dann auch noch (wegen Restmagnetisierung) mehrfach wiederholt wird, dann sind die Daten sicher weg.

Was du sagst trifft wohl zu wenn man z. B. bei OpenBSD mit rm -P löscht. rm -P überschreibt die Datei dreifach mit Zufallsdaten, tut dies aber auf Dateisystemebene. Wenn ich hingegen mit dd auf der Gerätedatei (statt dem gemounteten Dateisystem) arbeite, wird jeder Block überschrieben. Dann gibt es auch keine überhängenden Teile einer datei, die in einem anderen Block liegen, einfach weil ja jeder Block überschrieben wird.

Für so etwas gibt es doch sogar Spezifikationen wie etwa: http://de.wikipedia.org/wiki/DOD_5220.22-M welches auch von dem von mir erwähnten dban unter anderem benutzt wird.

Gruß
Reks30
 
denke er meint das Löschen so das keine Widerherstellung mehr möglich ist, jo und das ist bei jounaled basierten Filesystems nicht so ohne weiteres möglich !

In sogenannten "unallozierten Bereichen" eines Dateisystems befinden sich sogenannte "File Slacks" oder auch Informationen im "Alternate Data Stream" (Linux, Unix, Windows - das Filesystem ist egal).

Das scheint sich doch Alles auf Methoden zu beziehen, die innerhalb eines Dateisystems arbeiten? Hätte also gar nichts mit Dettus' oder meiner Methode zu tun.

also bitte mich jetzt nicht falsch verstehen, euer Vorschlag ist ein durchaus gangbarer Weg und ich möchte den auch nicht abwerten, nein ganz im Gegenteil..

möchte jetzt nicht den Besserwisser raushängen lassen, aber die daten könnten auch nach Deinem Vorschlag wiederherrgestellt werden...

Ja was denn nun? Ich denke, dass sie zwar wiederhergestellt werden könnten, allerdings nur unter Verwendung spezieller Hardware, welche die vorherige Magnetisierung feststellen kann. (Ist wohl irgendwie so ähnlich, wie bei Audiokassetten, wo man nach mehrfachem Überspielen noch teilweise die alte Musik im Hintergrund hören kann). Dadurch, dass man abwechselnd mit 10101010, 01010101, 11111111, 00000000 und Zufallszahlen überschreibt sollte (aufgrund mir nicht bekannter physikalischer Tatsachen) eine Wiederherstellung relativ schwer sein. Ich denke jedenfalls nicht, dass Deine Software da noch irgendwas ausrichten könnte.

(Ich lass mich aber auch gern korregieren, hab wie gesagt eigentlich keinen Plan davon)
 
Ich würde mal sagen, nach 8-maligem Überschreiben mit Zufallswerten, ist da nichts mehr zu retten.
 
Hallo zusammen,

sorry das ich mich jetzt erst melde also versuche euch das mal näherzubringen:

Auszug aus Diskforensik

Datenanalyse

Gelöschte Daten

Gelöschte Daten können abhängig vom Betriebssystem wiederhergestellt werden. In fast allen Fällen werden sämtliche Daten in Tabellen (FAT oder Inode) gespeichert. Werden Daten gelöscht wird in der Tabelle entweder ein zusätzliches Bit gesetzt oder der Speicherbereich in einer zusätzlichen Tabelle eingetragen so dass dieser Bereich dem Betriebssystem wieder zur Verfügung steht, die Daten physisch aber nicht gelöscht sind.

Unallocated Spaces

Unter nicht zugeordneten Speicherbereichen versteht man Bereiche auf der Festplatte, die nicht mehr dem Betriebssystem zugeordnet sind und somit auch nicht aufscheinen. Diese Bereiche können sich nicht nur am Ende einer Festplatte sondern quer über diese verteilt befinden. Dadurch ist es sehr gut möglich, Daten zu verstecken, die im Dateisystem nicht angezeigt werden. Ein gutes Analysetool ist in der Lage diese Bereiche zu finden, zu analysieren und darzustellen

Slack Bereiche

Die kleinste Speichereinheit (abhängig von Hard- und Software) ist ein Sektor und besteht bei Festplatten üblicherweise aus 512 und bei CD’s 2048 Bytes. Entspricht die Größe einer Datei nicht genau einem Vielfachen der Sektorgröße entsteht im letzten Sektor ein sogenannter Slack Space, in dem keine Daten mehr gespeichert sind, vom Betriebssystem aber keine Daten mehr gespeichert werden können. Diesen Bereich kann man nutzen um Daten zu verstecken (Slack-Space Viren, …). Generell gibt es drei Arten:

File-Slack
RAM-Slack
MFT-Slack

Unter Umständen kann es sogar beim Partitionieren von Festplatten zu Slack Bereichen kommen, wenn nicht ein Vielfaches als Partitionsgröße angegeben wird. Für die Analyse sind diese Bereiche von großer Bedeutung, da sich dort Daten verstecken oder Bruchstücke von gelöschten Dateien enthalten sein können.

Auslagerungsdateien und Swap-Partitionen

Auslagerungsdateien und Swap-Partitionen sind ein Teil des virtuellen Arbeitsspeichers. Wird mehr Arbeitsspeicher benötigt als vorhanden ist, werden Teile (Segmente oder Pages) aus dem Arbeitsspeicher ausgelagert und auf der Festplatte abgelegt. Dies ist performancemäßig ein Nachteil für einen Entwickler bietet dieser Bereich die Möglichkeit, Rückschlüsse auf Aktivitäten der letzten Arbeitssitzung (unter Umständen sogar ältere Sitzungen) vorzufinden und zu analysieren. Es kann sogar vorkommen, dass Applikationen an sich verschlüsselte Text im Klartext ablegen und so angesehen werden können.

komprimierte Daten

Bei der Untersuchung sind komprimierte Daten (.zip – Archive) insofern ein Problem, da die eigentlichen Daten nicht von einer automatisierten Analyse betroffen und ausgewertet werden, da zuerst die Komprimierung rückgängig gemacht werden muss. Dies kann händisch vom Ermittler oder automatisch durch ein Analysetool, sofern es die Funktionalität besitzt, geschehen.

Alternate Data Streams

Alternative Datenstreams sind eine Eigenschaft des NTFS Dateisystems und bieten die Möglichkeit zusätzliche Informationen zu speichern. Dabei können Binärdateien, ausführbare Programme oder auch nur reiner Text angehängt werden. Unerfahrenen Benutzern oder Ermittlern ist es nicht ohne zusätzliche Software oder den genauen Namen möglich solche Datenstreams zu finden. Bei der forensischen Analyse ist es aber wichtig dass ein Analysetool diese ADS automatisiert zur Verfügung stellt und findet.

Falls jemand Interessse an Forensic hat, bitte hier der Link zum WikiBuch der Projekt Gruppe der Datenretter und Gutachter!

http://de.wikibooks.org/wiki/Disk_Forensik

Hoffe ich konnte ein wenig aufklären, prinzipiell lässt sich sagen das es auch immer darauf ankommt was mann noch weiter vorhatt.
Eine Privatperson wird eine andere Methode zum Shreddern wählen als zum Beispiel eine Behörde oder ein Unternehmen..
Allerdings wurden im Falle vom ExBundeskanzler Kohl über 80% der Daten widerhergestellt und zur Beweissfindung vor Gericht genutzt die vorher gewiped wurden..

Noch ein abgedroschener Zusatz man kann fast alles wieder zurückholen...

Denke eure Fragen werden auch weitgehend in dem von mir verlinkten Dokument beantwortet, bitte jetzt nicht falsch verstehen aber derzeit liegt meine Hauptprimässe auf einen ganz anderen Schwerpunkt...

Aber andererseits vielleicht kommt Ihr ja zur Demo und da können wir solche Themen auch direkt diskutieren..

Mann/Frau sieht sich in Frankfurt !

http://www.freiheitstattangst.de
 
@rudy
Wenn man direkt über das Device drüberbügelt ist doch jegliches Wissen über Dateisysteme irrelevant.
 
Hallo zusammen,

sorry das ich mich jetzt erst melde also versuche euch das mal näherzubringen:

Das bezieht sich doch alles was du schreibst auf Dateisystemebene ... Lies dir doch einfach mal genau das durch, was Dettus, danlei, Kamikaze etc. geschrieben haben: Dateisysteme liegen auf Sektoren, es ist dem Betriebssystem frei überlassen, den Datenhaufen auf der Platte als Dateisystem zu verarbeiten oder nicht. Ebenso kannst du auf die Sektoren(!!) schreiben was du willst - wenn du damit dein Dateisystem kaputt machst, ist es deine Schuld.

Oder willst du mir jetzt ernsthaft erzählen, dass meine Festplatte eine FAT oder Inodes hat, in der meine Blöcke verwaltet werden? :ugly:

Allenfalls gäbe es die Möglichkeit, dass ein Block als defekt erkannt wird und SMART(?) einschreitet. Dann könnte womöglich in der Tat auf der Platte ein Block sein, der Daten beinhaltet, die ich nicht mehr löschen kann. Aber der Block ist dann ja sowieso kaputt. ;)

Und wenn du es nicht glaubst, dann schreib doch mal auf deine Festplatte lauter Nullen ... aber beschwer dich nicht, wenn dein tolles Programm dann eben keine Daten mehr wiederherstellen kann ... :rolleyes:
 
rudy schrieb:

oehm... rudy?? auch dir frohe ostern..
deine aussagen sind zwar lang.
aber laufen allesamt in die falsche richtung. ;)

mit meinem vorschlag kriegst du GAR KEINE daten mehr von der platte runter. egal ob auf den dingern ein journaling, relationales oder tar-basiertes filesystem drauf war.

ausserdem fehlt mir der kontext was ein deassembler fuer windows mit einem executable fuer sparc-prozessoren zu tun hat.... und was das fuer ein beispiel ist... oder was du geraucht hast...
oder welche kraeuter du auf deine ostereier gestreut hast...

also, um zurueck zum thread zu kommen....
wer kann bei meinem beispiel die korrekten device-namen ergaenzen?
 
Zuletzt bearbeitet:
dettus schrieb:
wer kann bei meinem beispiel die korrekten device-namen ergaenzen?
Aus 'man 4 ata':
Code:
     /dev/ad*                ATA disk device nodes
     /dev/ar*                ATA RAID device nodes
     /dev/acd*               ATAPI CD-ROM device nodes
     /dev/afd*               ATAPI floppy drive device nodes
     /dev/ast*               ATAPI tape drive device nodes

Aus 'man 4 da':
Code:
/dev/dausn     raw mode SCSI disk unit u, slice n, accessed as an 
               unpartitioned device
/dev/daup      raw mode SCSI disk unit u, first FreeBSD slice, partition p
/dev/dausnp    raw mode SCSI disk unit u, nth slice, partition p

HTH
 
@dettus (oder alle Anderen, die es wissen):
Ist es nun besser, direkt mit Zufallszahlen drüberzuschrubben, oder doch nach meinem Muster vorzugehen? Ich hatte das mal irgendwo gelesen, find aber gerade den Thread in meinem Bookmark-Nirvana nicht mehr. ;)
 
Code:
% dd if=/dev/urandom of=PARTITION bs=1m count=GROESSE
% dd if=/dev/null of=PARTITION bs=1m count=GROESSE
% newe2fs ... (oder so)
Prinzipiell stimme ich dir, Kamikaze usw. zu. Wenn direkt auf das raw-Device der HD schreibend zugegriffen wird, geht das FS garantiert kaputt. Wenn das mit Zufallszahlen oft genug gemacht wird, wobei 8-mal nicht reichen soll, dann ist da auch nix mehr zu holen.

Aber eine kleine Korrektur muss ich doch anbringen:
Statt /dev/null muss /dev/zero verwendet werden, um die Platte zu nullen.

Gruß c.
 
Ich glaube, dass weit weniger als 8 Mal nötig sind um die Daten unwiederbringlich zu vernichten. Ich denke, das Märchen, dass spezielle Einrichtungen zu so etwas in der Lage sind, gehört eher ins Reich der Mythen.
 
full ack.

diese "einrichtungen" sind vielleicht gerade mal imstande eine einfach mit /dev/zero ueberschriebene platte mit SEHR VIEL AUFWAND wieder herzustellen. (sorry fuer den tippfehler vorhin ;) )
das wars dann aber auch schon.
 
Irgendwann mal wurde von einem gewissen Gutenberg empfohlen insgesamt über 30 Mal zu überschreiben. Diese Anzahl, zusammen mit der Quelle der Daten, mit denen überschrieben werden sollte (/dev/urandom, /dev/zero, kA.) wird auch als "Gutenberg-Methode" bezeichnet. Derzeit gibt es die Aussage, ebenfalls von diesem Gutenberg, dass das vollkommener Overkill ist. Bei der aktuellen Strukturgröße auf einem magnetischen Datenträger reichen wesentlich weniger Zyklen aus. Ich bin zu faul da jetzt eine Quelle zu suchen.

Der Grund, warum alternierend mit Mustern überschrieben wird anstatt mit Zufallszahlen, ist unter anderem, dass das Erzeugen von Zufallszahlen in der benötigten Menge durchaus mehrere Tage dauern kann.

Alles AFAIK.
 
Es gibt einen Standard von der amerikanischen Regierung, wie diese (ordentlicher weise) ihre Festplatten löschen sollten. Und ich glaube NSA und NCSA haben ein bisschen mehr Ahnung, und können das besser beurteilen als ihr. Oder ist einer von euch Forensiker, Elektrotechniker und Mikromechaniker?
In dem Standard läuft es auf jeden Fall danach ab, dass man vielfach einen Zyklus ablaufen lässt, der die Einheiten "Alles auf Null" , "Zufallszahlen", "bestimmtes Muster" enthält. Das soll auf physikalischer Ebene auch verhindern, dass die geschriebenen Bits in der Nachbarschaft der "Bitposition" keine Spuren hinterlassen, was landläufig auch verwendet wird, um in einfacheren Fällen Daten zu rekonstruieren.
Ich bin auch kein Experte, aber eure Aussagen sind doch ziemlich gewagt, denn jetzt schon sind verschieden theoretische Methoden öffentlich bekannt, mit denen sich sowas realisieren lässt.
 
Ich denke du überschätzt da die Behörden. Ich denke nach einem mal alles einsen, danach noch Zufallszahlen drüber (von mir aus auch zwei oder drei mal) und am Schluß noch alles Nullen, ist da für niemanden mehr was zu holen.
 
Zurück
Oben