HD in Ausgangszustand versetzen mit dd oder s0kill.exe?

[tami]

hi,

da ich hier (und in dem zu Grunde liegenden Thread der dort verlinkt ist) nicht weiterkomme, weil das vermutlich auch zu spezifisch um testdisk/gdisk/GParted geht, möchte ich ganz allgemein fragen, ob jemand weiß, wie eine "normale" HD (in dem Fall SATA 4TB) im Auslieferungszustand ausschaut. Ist eine HD komplett mit "Nullen" beschrieben? Kann ich also dann mit dd oder s0kill.exe (s.a. http://www.ipcop-forum.de/forum/viewtopic.php?f=19&t=17053 oder http://www.bjoern-meissner.de/2007/s0kill.html) die Festplatte wieder komplett in den Ursprungszustand versetzen? Ich gehe mal davon aus, dass "dd if=/dev/zero of=/dev/hdc count=1" im Grunde das selbe macht wie s0kill.exe bzw. den selben Zustand erzeugt.

Oder kann man so eine Platte komplett zerstören, weil dann der MBR (GPT) nicht mehr beschreibbar wäre? [keine Ahnung, wie das erklärliche wäre, aber siehe folgenden Erfahrungsbericht]. Es geht mir hier - neben dem praktischen Nutzen - auch um ein Verständnis der Logik dahinter. Wie hatten nämlich mal in der PC-AG einen Jungen, der hatte irgendwie seinen MBR scheinbar geschrotet (war ein 100GB HD oder so, schon ein paar Jahre her) und  hatte es damals offenbar nicht mehr geschafft, die HD wieder herzustellen. Was ja eigentlich nicht sein kann, wenn man mit dd da Nullen über die ersten Sektoren legen kann und damit die Platte wieder in den Ursprungszustand versetzt.

mfg

tami

[Jörg Reinholz]

Moin!

Ich gehe mal davon aus, dass "dd if=/dev/zero of=/dev/hdc count=1" im Grunde das selbe macht wie s0kill.exe bzw. den selben Zustand erzeugt.

Das ist nicht der Ausgangszustand. Auf der Platte sind noch Daten, weil dd so nur einen Block löscht und zwar den ersten. Diese Daten lassen sich z.B. unter Linux wieder herstellen (man kann es zumindest versuchen).

vor einer Weitergabe Löschen würde ich mit:

# > dd if=/dev/urandom of=dev/hdx

Ist man paranoid, dann macht man das mehrmals. (3 mal sollte aber wirklich reichen)

Die Partitionstabelle und den Bootsektor 'nullt' man danach mit:

# > dd if=/dev/zero of=dev/hdx count=1

freilich geht auch etwas wie:

# > platte='/dev/hdx' && bs=512 dd && if=/dev/urandom of=$platte bs=$bs skip=1 && dd if=/dev/zero of=$platte count=1

Auch eine GPT sollte danach kaputt genug sein, dass ein Partitionierungstool diese nicht mehr erkennen kann, also auch nicht darüber stolpert, weil es darin etwas zu erkennen vermeint.

Jörg Reinholz

[Alexander (HH)]

Moin Moin!

Moin!

Ich gehe mal davon aus, dass "dd if=/dev/zero of=/dev/hdc count=1" im Grunde das selbe macht wie s0kill.exe bzw. den selben Zustand erzeugt.

Das ist nicht der Ausgangszustand. Auf der Platte sind noch Daten, weil dd so nur einen Block löscht und zwar den ersten. Diese Daten lassen sich z.B. unter Linux wieder herstellen (man kann es zumindest versuchen).

Korrekt. parted hat eine Rescue-Funktion für genau den Fall, dass man sich mal eben die Partitionstabelle aus dem ersten Sektor der Platte geblitzdingst hat.

vor einer Weitergabe Löschen würde ich mit:

# > dd if=/dev/urandom of=dev/hdx

Ist man paranoid, dann macht man das mehrmals. (3 mal sollte aber wirklich reichen)

Die Partitionstabelle und den Bootsektor 'nullt' man danach mit:

# > dd if=/dev/zero of=dev/hdx count=1

Overkill.

Eine Runde Nullen schreiben, von vorne bis hinten, reicht auf handelsüblichen Platten vollkommen aus. Es schadet übrigens nicht, die Block Size bei dd höher zu setzen, dann muss das Betriebssystem die Badewanne nicht mit einer Pipette füllen. Ich nehme meistens bs=2M, das paßt auch bei alten Platten noch gut in den Cache. Sprich: "dd if=/dev/zero of=/dev/sdX bs=2M".

Die Idee, Pseudozufallszahlen (also Rauschen) auf die Platte zu schreiben, stammt aus der Zeit, als die Spuren auf den Festplatten noch relativ breit waren und man mit einem leicht verschobenen Lesekopf noch Restmagnetisierungen vom Rand der Spur zurücklesen konnte. Eine Reihe Nullen (oder auch Einsen) hätte nur für einen DC-Offset gesorgt und das Signal geschwächt. Mehrfaches Überschreiben mit Rauschen hätte die Restmagnetisierung für jedes einzelne Bit in einen sehr undefinierten Zustand gebracht und die Daten so beseitigt.

Heute sind die Spuren so schmal, dass die Hersteller schon planen, sie überlappen zu lassen, trotz den damit verbundenen Nachteilen.

Die ernsthaft paranoiden Mitmenschen benutzen übrigens nicht /dev/urandom, sondern einen "richtig guten" Pseudozufallsgenerator (Mersenne-Twister oder besser) und lassen den diverse Runden drehen, mit Verifikation der geschriebenen Daten.

DBAN ist ein Tool für solche paranoiden Leute, kann aber auch ganz einfach eine Runde Nullen schreiben und anschließend prüfen. Anders als bei einem einfachen dd gibt es auch noch eine Fortschrittsanzeige und eine Restzeitschätzung. Ganz nebenbei zeigt dban am Ende auch noch an, ob sich die Platte fehlerfrei befüllen ließ oder nicht. Platten, die dban nicht komplett nullen kann, zerstöre ich, der Rest kommt so in den Elektroschrott (unter 40 GByte) oder in die Bastelkiste (ab 40 GByte). DBAN ist das Interface an der Festplatte übrigens ziemlich egal, DBAN löscht via IDE, SCSI, USB, SATA, Firewire über so ziemlich jeden Controller, für den es Linux-Treiber gibt. Auch parallel, auf max. 100 Platten.

freilich geht auch etwas wie:

# > platte='/dev/hdx' && bs=512 dd && if=/dev/urandom of=$platte bs=$bs skip=1 && dd if=/dev/zero of=$platte count=1

Auch eine GPT sollte danach kaputt genug sein, dass ein Partitionierungstool diese nicht mehr erkennen kann, also auch nicht darüber stolpert, weil es darin etwas zu erkennen vermeint.

Das skip=1 beim ersten dd ist nett, aber der eine Sektor mehr oder weniger ist uninteressant. Das zweite dd putzt zwar den MBR am Anfang der Platte, aber nicht die GPT am Ende. So steht in der GPT Datenmüll statt Nullen wie bei einer fabrikfrischen Platte. Das könnte das eine oder andere Tool verwirren.

Ein kleiner Haken noch: Es gibt Platten-Controller, die nicht mit großen Platten umgehen können, unabhängig vom Betriebssystem. Ergebnis ist meistens, dass die höchsten Bits der LBA nicht bei der Platte ankommen. Das ist auch wohl im Original-Thread beschrieben. Mit anderen Worten: Das Betriebssystem glaubt, am Ende der Platte Daten abzulegen, die landen aber irgendwo mittendrin. Typisches Symptom: mke2fs läuft einwandfrei, e2fsck meldet direkt danach ein völlig demoliertes Dateisystem. Die GPT steht auch am Ende der Platte, wenn der inkompatible Controller die aber in die Mitte packt und anschließend über die gesamte Kapazität eine Partition anlegt und darin ein Dateisystem, kann die GPT mit Teilen des Dateisystems überschrieben werden.

Über so einen Controller bekommt man natürlich nicht die gesamte Platte gelöscht, sondern nur den Anfang.

Was hilft? Tauglichen Controller suchen. Zum Löschen: Modernen Rechner suchen, interne Platte(n) abklemmen, zu löschende Platte an den internen SATA-Controller und an Strom anschließen, DBAN starten und eine Runde Nullen schreiben und prüfen lassen.

Alexander

[tami]

hi Alexander HH,

Was hilft? Tauglichen Controller suchen. Zum Löschen: Modernen Rechner suchen, interne Platte(n) abklemmen, zu löschende Platte an den internen SATA-Controller und an Strom anschließen, DBAN starten und eine Runde Nullen schreiben und prüfen lassen.

Danke auch Dir für die Ausführungen. Dieser Controller bringt es dann hoffentlich. Laut Hermes schon in der Zustellung.

Da die Platte jetzt ja an einem internen SATA-Controller mit GPT/NFTS partitioniert/formatiert wurde (erfolgreich laut GParted, aber kein weiteren check wie e2fsk laufen lassen), hoffe ich jetzt mal, dass die 4TB-Seagate nun mit dem o.g. Controller "funzt". Der Verkäufer bzw. dessen technische Abteilung meinte auf Voranfrage, dass 4TB damit betrieben werden könnten (ich solle halt auf GPT achten, was ich ja getan habe).

mfg

tami

[tami]

hi, Jörg, Martin, Alexander,

mit o.g. USB-SATA-Controller war die mit GParted formatierte Disk jetzt zwar erkennbar und sollte angeblich formatiert werden müssen, das aber ging nicht, weil sie laut Windows schreibgeschützt war. Bin dann hierauf gestoßen:

http://www.espend.de/artikel/schreibgeschuetzte-festplatte-partition-unter-windows-7-und-server-2008-r2.html:

Zitat:

1    Open a command prompt (ie. Start > Run > cmd) with administrative privledges
2    Type in the command: diskpart
3    Run the command: list disk
4    Look for the disk number that’s having the problem.  In my case I have a system drive, a RAID 5 configuration (1 logical drive) and then the new drive, so it was DISK 2.  I will continue to use it in the example but note that yours may differ.
5    Select the disk using the following command: sel disk 2
6    Enter the following command: ATTRIBUTES DISK CLEAR READONLY
7    Exit diskpart with the command: exit

Hat funktioniert ;-).

mfg Robert aka tami

[Der Martin]

Hallo,

[...] ob jemand weiß, wie eine "normale" HD (in dem Fall SATA 4TB) im Auslieferungszustand ausschaut. Ist eine HD komplett mit "Nullen" beschrieben?

nein, nicht zwingend. Genau wie früher eine Diskette vor dem Gebrauch formatiert werden musste, müssen auch Harddisks formatiert werden, bevor sie überhaupt benutzt werden können. Damit meine ich nicht das, was DOS/Windows mit dem format-Kommando tut - das ist nur das Erstellen eines neuen, leeren Filesystems. Nein, Formatieren ist das Einteilen des Datenträgers in Tracks und Sektoren, und das Markieren derselben (auch als Low-Level-Format bekannt).
Bei diesem Prozess, der in der Regel vom Festplattenhersteller durchgeführt wird, werden auch alle Sektoren mit einem bestimmten Datenmuster gefüllt. Möglicherweise sind das alles Null-Bytes, aber es könnte auch jedes andere Bitmuster sein. Aus der Sicht des Anwenders enthalten also alle Sektoren einen zufälligen Inhalt.

Wichtig ist nur, dass nicht "zufällig" die Bitmuster entstehen, an denen das System eine gültige Formatierung erkennt. Bei der traditionellen MBR-Partitionierung sind das beispielsweise die Bytes 0x55, 0xAA am Ende des ersten Sektors, der dann auch die Partitionstabelle enthält, beim GPT-Schema gibt es vermutlich ähnliche Markierungen.

Kann ich also dann mit dd oder s0kill.exe (s.a. http://www.ipcop-forum.de/forum/viewtopic.php?f=19&t=17053 oder http://www.bjoern-meissner.de/2007/s0kill.html) die Festplatte wieder komplett in den Ursprungszustand versetzen?

De facto ja. Damit überschreibst du auf jeden Fall die "magische" Markierung einer gültigen Partitionstabelle, so dass die einschlägigen Tools die Platte als "noch nicht partitioniert" erkennen müssen.

Oder kann man so eine Platte komplett zerstören, weil dann der MBR (GPT) nicht mehr beschreibbar wäre?

Nein. Auf unterster Ebene gibt es nur Kommandos an die Platte, die etwa besagen: "Schreibe die folgende Sequenz von 512 Bytes in Sektor X." Eine nachhaltige Beschädigung der Platte ist damit nicht möglich. Es kann höchstens sein, dass man damit eine Datenstruktur erzeugt, die das eine oder andere OS dazu bewegt, "sicherheitshalber" die Finger davon zu lassen.
Wobei Linux da eigentlich recht unerschrocken ist und sich durch irgendwelche seltsamen Bitmuster nicht wirklich aus der Ruhe bringen lässt. Warum auch?

Wie hatten nämlich mal in der PC-AG einen Jungen, der hatte irgendwie seinen MBR scheinbar geschrotet (war ein 100GB HD oder so, schon ein paar Jahre her) und  hatte es damals offenbar nicht mehr geschafft, die HD wieder herzustellen.

Dann hat er es wohl geschafft, eine Datenstruktur zu erstellen, die DOS/Windows (Mutmaßung) so beeindruckt hat, dass das System einen weiteren Zugriff auf das Medium verweigert.

So long,
 Martin

[tami]

hi Jörg und Martin,

danke für die Antworten, die hoffentlich zu meinem Verständnis der zu Grunde liegenden Techniken beigetragen haben.

Bei meinem konkreten Ausgangspunkt, dem externen Laufwerk von Fantec und meiner Seagate 4TB HD habe ich gestern in der schulischen PC-AG die Platte an einem Rechner gehabt, der SATA-tauglich war und die Platte mit Linux-Live-Stick (Ubuntu 13) problemlos erkannt und auch in Sekundenschnelle "formatiert" (GPT/NTFS) und mit einem Testfile beschrieben.

Da eine 1,5-TB-Platte in dem Fantec-Gehäuse normal erkannt wird, "muss" das Problem ja wohl am Zusammenspiel von Fantec und 4TB liegen oder dieser SATA-USB-Controller war grade irgendwie defekt?

Dank nochmal für die hilfreichen Postings verteilt auf mehrere Threads (auch an Felix) und Gruß, Robert aka

tami