Zerstörten Luks-Header rekonstruieren

[JohnnyDoe]

Hallo Leute,

ich habe mir beim Herumspielen mit grub-pc den Luks-Header einer Festplatte zerschossen. Wie ich leider feststellen mußte, wird wohl der Header nicht redundant gespeichert, sodaß die Daten erst einmal verloren sind. Damit möchte ich mich aber nicht abfinden.

Da der Header nicht wiederherstellbar ist, möchte ich ihn rekonstruieren und das stelle ich mir so vor.

Zuerst versuche ich herauszufinden, wieviel grub-pc von dem Header zerstört hat und dann versuche ich diesen zerstörten Teil des Headers mittels einer Brute-Force ähnlichen Methode zu erstellen und jedesmal, wenn ein neuer Header erstellt wurde, wird versucht, mittels luksOpen die verschlüsselte Festplatte zu öffnen, bis das erfolgreich ist.

Das ist die Theorie. In der Praxis soll der Großteil natürlich mit Hilfe eines Skriptes passieren. Leider reichen meine Kenntnisse nicht aus, um das alles umzusetzen. Ich ersuche Euch also, mich nicht nur in die richtige Richtung zu schubsen, sondern mich sozusagen bei der Hand zu nehmen.

Allem voran steht natürlich die Frage, ob das überhaupt so machbar ist, wie ich mir das vorstelle.

Danke für Eure Antworten im voraus.

Gruß
JohnnyDoe

[Danielx]

Hallo und willkommen im df.de!

Wenn der verschlüsselte Masterkey überschrieben worden sein sollte, wird eine Rekonstruktion nicht funktionieren.

Hier findest du die LUKS-Spezifikation:
http://code.google.com/p/cryptsetup/wiki/Specification

Gruß,
Daniel

[JohnnyDoe]

Hallo Daniel,

danke für das Willkommen und die Antwort.

Mit dem Link kann ich wenig anfangen.

Ich gehe einfach von folgendem aus:

Der Luks-Header ist größer als die Sequenz, die grub-pc in die Partition geschrieben hat

Der Header (vereinfacht dargestellt) bevor sich grub-pc eingetragen hat:

Das ist ein langer LUKS-Header.
44 61 73 20 69 73 74 20 65 69 6E 20 6C 61 6E 67 65 72 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E

und nachdem sich grub-pc eingetragen hat:

Das grub-pcgrub-pc LUKS-Header.
44 61 73 20 67 72 75 62 2D 70 63 67 72 75 62 2D 70 63 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E

Mein Gedanke ist nun, laienhaft ausgedrückt, die Stelle des grub-pc-Eintrages per Brute-Force zu rekonstruieren.
Es soll also mit Hilfe eines Skriptes der von grub-pc überschriebene Teil wieder überschriebenen werden und zwar so:
44 61 73 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E
44 61 73 20 00 00 00 00 00 00 00 00 00 00 00 00 00 01 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E
44 61 73 20 00 00 00 00 00 00 00 00 00 00 00 00 00 02 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E
...

Nach jeden Überschreiben soll dann getestet werden, ob man die Festplatte öffnen kann, was genau dann der Fall sein sollte, wenn der ursprüngliche Header wieder hergestellt ist:

44 61 73 20 69 73 74 20 65 69 6E 20 6C 61 6E 67 65 72 20 4C 55 4B 53 2D 48 65 61 64 65 72 2E

Dabei müßte es doch eigentlich egal sein, ob der verschlüsselte Masterkey überschrieben wurde, oder?

Das ist die Theorie. Die Praxis hapert an meinen mangelhaften Kenntnissen.

Gruß
JohnnyDoe

[Danielx]

Der Luks-Header ist größer als die Sequenz, die grub-pc in die Partition geschrieben hat

Wahrscheinlich ist das so, falls allerdings die ersten 168 Byte überschrieben wurden, wird es schon schwer (aber noch möglich), die Partition zu entschlüsseln, denn in den ersten 168 Bytes sind u.a. der Salt und die Anzahl der nötigen Iterationen enthalten und schon das alleine ergibt ziemlich viele mögliche Kombinationen.

Als erstes musst du also unbedingt herausfinden, welche Bytes du überschrieben hast und welche Funktion diese bei LUKS haben.

Dabei müßte es doch eigentlich egal sein, ob der verschlüsselte Masterkey überschrieben wurde, oder?

Warum sollte das egal sein?
In diesem Fall müsstest du mal eben alle möglichen Kombinationen für den Master-Key durchprobieren, das sind z.B. bei einer Schlüssellänge von 256 Bit mal eben 2^256 Kombinationen.

Achja und 2^256 sind ausgeschrieben:

Code: Alles auswählen

115.792.089.237.316.195.423.570.985.008.687.907.853.269.984.665.640.564.039.457.584.007.913.129.639.936

Gruß,
Daniel

[bse]

... da kommt noch dazu, dass LUKS ähnlich wie WPA mehrfach hasht, um das ganze künstlich zu verlängern (siehe hier).

Das heißt, pro Versuch auch noch mindestens 1 Sekunde Rechenzeit.

[Danielx]

... da kommt noch dazu, dass LUKS ähnlich wie WPA mehrfach hasht, um das ganze künstlich zu verlängern (siehe hier).

Das heißt, pro Versuch auch noch mindestens 1 Sekunde Rechenzeit.

Das bezieht sich auf das Durchprobieren des Passwortes um an den Schlüssel zu gelangen und nicht auf das direkte Durchprobieren des Schlüssels.

Gruß,
Daniel

[bse]

Ach ja, stimmt natürlich. Aber ist auch so wohl schon mehr Rechenzeit als realistisch.