Wie einfach ist es, den folgenden Kopierschutz aufzubrechen?

8304
dimovnike

Ich versuche einige Arbeiten zu schützen, eine bootfähige SD-Karte, die einen Linux-Kernel auf einem ARM-Gerät (Raspberry Pi) bootet. Ich verwende diesen Ansatz:

  1. Der Ansatz verwendet eine initrd zum Einhängen eines verschlüsselten Root-Dateisystems.
  2. Die initrd generiert das Kennwort des Dateisystems gemäß der CID der SD-Karte. (eine Hash-Funktion wird verwendet, hat sich noch nicht für md5 oder sha1 entschieden). Initrd versucht, das Dateisystem mit diesem generierten Kennwort einzuhängen.
  3. Hier ist der interessanteste / verdächtigste Teil: Die initrd selbst wird mit einer benutzerdefinierten C-Funktion verschlüsselt. Grundsätzlich wird jedes Byte mit einem benutzerdefinierten Pseudo-Zufallsgenerator XOR-verknüpft. Der Kernel ist so modifiziert, dass er dieselbe Verschlüsselungsfunktion hat, die als Entschlüsseler fungiert.
  4. Das System selbst ist heruntergefahren, so dass keine Tastatur oder externer Speicher verwendet werden kann. Eine einzelne App wird im Vollbildmodus ausgeführt.

Nachdem der Bootloader Kernel und Initrd geladen hat, entschlüsselt der Kernel die Initrd und führt ihr Init-Skript aus, das das Kennwort generiert und das Root-Dateisystem bereitstellt.

Meine Frage ist: Wie einfach wäre es, dieses Setup zu unterbrechen (das Root-Dateisystem zu entschlüsseln und von einer SD-Karte booten zu lassen)? Was sind die schwächsten Teile? Wie einfach ist es, den Kernel zu dekompilieren und die benutzerdefinierten Verschlüsselungsfunktionen zu finden?

BEARBEITEN: Hier sind einige Korrekturen, damit Sie keine Zeit mit den offensichtlichen Dingen verlieren:

  1. Das Root-Gerät wird mit LUKS (aes256) verschlüsselt und der Schlüssel wird von einer HMAC-Funktion mithilfe der CID der SD-Karte und etwas Salt generiert.
  2. Der Pseudo-Random-Algorithmus für die Initramfs-Verschlüsselung wird in der Tat RC4 sein. Der Schlüssel wird nur mit einer benutzerdefinierten Funktion generiert. Wenn ich den Schlüssel nur in einem Byte-Array speichere, ist das Abrufen des Schlüssels sehr einfach aber es scheint keinen anderen Weg zu geben.
  3. Ich verstehe, dass jemand, der einen SD-Karten-Emulator verwendet, eine Kopie dieses Systemstarts erstellen kann, dies ist jedoch in Ordnung für mich, da dies ziemlich schwierig ist und niemand dies tun kann (auch nicht jeder möchte sich mit Emulatoren beschäftigen).
11
Wo sind der Kernel und Initrd gespeichert? grawity vor 10 Jahren 0
Alle sind auf einer einzigen SD-Karte gespeichert. Beides in separaten Dateien. Gespeichert wie üblich in / boot. dimovnike vor 10 Jahren 0

2 Antworten auf die Frage

7
Breakthrough

Wie einfach wäre es, dieses Setup zu unterbrechen (das Root-Dateisystem zu entschlüsseln und von einer SD-Karte booten zu lassen)?

Wie schwer es ist, Ihr Setup zu "brechen", hängt von der Anzahl der Entropiebits in der Methode ab, mit der Sie das Dateisystem selbst signieren / verschlüsseln (da dies die Gesamtzahl der eindeutigen Kombinationen bestimmt, die für das Brute-Force-Verfahren verwendet werden können) das Passwort).

Was sind die schwächsten Teile?

Ohne Zweifel verwenden Sie eine vordefinierte CID als Kennwort sowie eine benutzerdefinierte Pseudozufallszahlen-Generierungsfunktion.

Die CID einer SD - Karte wird nur angenommen, schreibgeschützt werden, aber es ist nicht ungewöhnlich, nicht-konforme Flash - Speichergeräte in der heutigen Zeit zu finden. Einige Leute haben sogar die Fähigkeit demonstriert, das CID mit bestimmten SD-Karten zu überschreiben . Dies würde es einfacher machen, das Passwort brutal zu erzwingen, vor allem, wenn eine SD-Karte nach dem Klonen einer emuliert wird (was Sie vielleicht in Betracht ziehen).

Schließlich hat die Verwendung eines beliebigen Pseudozufallszahlengenerators bereits einige intrinsische Fehler, weil es nicht zufällig ist - es gibt einen Grund, warum es Pseudozufallszahlen genannt wird . Es ist möglicherweise besser, einen vorgefertigten, verschlüsselten Bootloader (wie TrueCrypt oder LUKS, die beide auf dem Raspberry Pi funktionieren) zu verwenden, und keine manuellen Kernel-Änderungen vornehmen zu müssen.

Wie einfach ist es, den Kernel zu dekompilieren und die benutzerdefinierten Verschlüsselungsfunktionen zu finden?

Es ist sehr schwierig, etwas zu dekompilieren. Umgekehrt ist die Demontage einer kompilierten Anwendung oftmals trivial, und es gibt viele Werkzeuge, die dazu verwendet werden können, um die umgekehrte Konstruktion wieder in eine andere übergeordnete Sprache umzuwandeln. Wenn ein Angreifer sogar Zugriff auf einen kompilierten Kernel hat, ist die Analyse eines Pseudo-Zufallszahlengenerators wahrscheinlich trivial, wenn der Code nicht absichtlich verschleiert wird.

TL, DR : Das Rad muss nicht neu erfunden werden, wenn es um Verschlüsselung und Sicherheit geht. Bleiben Sie beim Bewährten. Es gibt verschiedene Verschlüsselungsoptionen für Festplatten, die bereits auf dem Raspberry Pi einwandfrei funktionieren. Ich würde vermeiden, die CID der SD-Karte als eine Art "Passwort" zu verwenden - selbst wenn es nicht geändert werden kann, gibt es Möglichkeiten, diesen Wert zu fälschen.

Der Kopierschutz ist in der SD-Kartenspezifikation bereits als CPRM enthalten .

Danke für die Antwort. Ich kenne CPRM, aber seine Spezifikationen sind mit NDA abgeschlossen und kosten viel Geld (von dem, was ich gegoogelt habe). Für LUKS und Truecrypt müssen diese beim Booten manuell eingegeben werden. Wenn ich den TrueCrypt-Bootloader modifiziere, um den Schlüssel aus dem CID mit einer hmac-Funktion zu generieren, wird es dann besser sein? Ich verstehe auch, dass dies mit dem SD-Kartenemulator möglich ist, aber das ist gut für mich, das ist der für Piraten bequeme Schwierigkeitsgrad. (Ich verstehe hier keinen 100% igen Schutz, solange der Schlüssel im Gerät enthalten ist) dimovnike vor 10 Jahren 0
@ user2021201 In der Tat wollte ich Sie dazu bringen. Es wäre * wahrscheinlich * ziemlich einfach, den Truecrypt-Bootloader von der Quelle aus zu ändern, obwohl ich nicht sicher bin, wie schwierig es wäre, das CID von einem Bootloader zu erhalten (da Sie kein geladenes Betriebssystem haben, um die SD-Karte abzufragen) Spezifikationen von). Wenn Sie es dennoch geschafft haben, wäre dies wahrscheinlich eine akzeptable und ausreichende Lösung für Ihre Bedürfnisse. Breakthrough vor 10 Jahren 0
1
derobert

Someone skilled wouldn't have much trouble cracking this. It'd be relatively easy to boot the SD card under an emulator, and then just read the keys out of RAM. Then they post a version without the copy protection to the Pirate Bay (etc.), and that's that.

Alternatively, use the emulator to inject shellcode into the running emulated system. Then use the running system to copy the decrypted rootfs off (or read the keys using dmsetup table --showkeys, etc.)

A quick search turns up the existence of Raspberry Pi emulators, so part of the work has already been done.

You've got another problem, in particular this:

Kernel is modified to have the same encrypting function, which works as decryptor.

Anyone you distribute this to is entitled to the kernel source code, under the terms of the GPL. So you wouldn't need to disassemble it, you could just use diff to find the extra function.

(Not that finding it through disassembly would be that hard, as you can e.g., check vs. a stock kernel)

I'm not completely familiar with the Raspberry Pi boot code, but if you can reflash the bootloader with an embedded crypto key (that is then passed to the kernel), that'd at least not be on the SD card, so it'd foil an attempt to get it to boot in an emulator.

Ja, ich bin mir über Lizenzierungsprobleme bewusst. Ich suche immer noch nach Möglichkeiten, den Kernel intakt zu lassen und sogar zum FreeBSD-Kernel zu wechseln, aber jetzt können wir nur die technischen Probleme besprechen. Die Bootloader-Idee ist sehr interessant, aber ich konnte keinen Weg finden, dies zu implementieren, anscheinend gibt es keinen solchen Weg. dimovnike vor 10 Jahren 0

Verwandte Probleme