Wie einfach ist es, den folgenden Kopierschutz zu knacken? [geschlossen]

Ich versuche, einige Arbeiten kopiergeschützt zu machen, bei denen es sich um eine bootfähige SD-Karte handelt, die einen Linux-Kernel auf einem ARM-Gerät (Raspberry Pi) bootet. Ich benutze diesen Ansatz:

1. Der Ansatz verwendet eine initrd, um ein verschlüsseltes Root-Dateisystem bereitzustellen.
2. Der 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 bereitzustellen.
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 Pseudozufallsgenerator XOR-verknüpft. Der Kernel wurde so geändert, dass er dieselbe Verschlüsselungsfunktion hat, die auch als Entschlüsseler fungiert.
4. Das System selbst ist reduziert, sodass keine Tastatur oder kein 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 den initrd und führt sein Init-Skript aus, das das Kennwort generiert und das Root-Dateisystem bereitstellt.

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

EDIT: Hier sind einige Korrekturen, damit Sie keine Zeit mit den offensichtlichen Dingen verschwenden:

1. Das Root-Gerät wird mit LUKS (aes256) verschlüsselt und der Schlüssel wird von einer HMAC-Funktion unter Verwendung der CID der SD-Karte und etwas Salz generiert.
2. Der Pseudozufallsalgorithmus für die Initramfs-Verschlüsselung ist in der Tat RC4, nur der Schlüssel wird mit einer benutzerdefinierten Funktion generiert, denn wenn ich den Schlüssel nur in einem Byte-Array speichere, ist es absolut einfach, ihn abzurufen (ja, das ist Sicherheit durch Dunkelheit aber es scheint keinen anderen Weg zu geben).
3. Ich verstehe, dass bei Verwendung eines SD-Kartenemulators jemand eine Kopie dieses Systems starten kann, aber das ist für mich in Ordnung, da es ziemlich schwierig ist und niemand dies tun kann (auch wird niemand mit Emulatoren umgehen wollen).

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

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

Was sind die schwächsten Teile?

Ohne Zweifel die Verwendung einer vordefinierten CID als Kennwort sowie eine benutzerdefinierte Funktion zur Erzeugung von Pseudozufallszahlen.

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

Schließlich weist die Verwendung eines Pseudozufallszahlengenerators bereits einige intrinsische Mängel auf, gerade weil er nicht zufällig ist - es gibt einen Grund, warum er als Pseudozufallszahlengenerator bezeichnet 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 vorzunehmen.

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

Es ist sehr schwierig, etwas zu dekompilieren. Umgekehrt ist die De-Assemblierung einer kompilierten Anwendung oft trivial, und es gibt viele Tools, mit denen das Reverse Engineering der Assemblierung in eine andere übergeordnete Sprache unterstützt werden kann. Wenn ein Angreifer sogar Zugriff auf einen kompilierten Kernel hat, ist die Analyse eines Pseudozufallszahlengenerators wahrscheinlich trivial, es sei denn, der Code ist absichtlich verschleiert.

TL, DR : Erfinden Sie das Rad nicht neu, wenn es um Verschlüsselung und Sicherheit geht. Halten Sie sich an das Bewährte. Es gibt mehrere Verschlüsselungsoptionen für die gesamte Festplatte, die bereits verfügbar sind und auf dem Raspberry Pi nachweislich einwandfrei funktionieren. Ich würde es vermeiden, die CID der SD-Karte als eine Art "Passwort" zu verwenden - auch wenn sie 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 .

Jemand Fachmann würde nicht viel Mühe haben, dies zu knacken. Es wäre relativ einfach, die SD-Karte unter einem Emulator zu starten und dann einfach die Schlüssel aus dem RAM zu lesen. Dann veröffentlichen sie eine Version ohne Kopierschutz in der Piratenbucht (usw.), und das war's.

Verwenden Sie alternativ den Emulator, um Shellcode in das laufende emulierte System einzufügen. Verwenden Sie dann das laufende System, um die entschlüsselten Rootfs zu kopieren (oder lesen Sie die Schlüssel mit dmsetup table --showkeysusw.).

Eine schnelle Suche zeigt die Existenz von Raspberry Pi-Emulatoren an , sodass ein Teil der Arbeit bereits erledigt ist.

Sie haben ein weiteres Problem, insbesondere das folgende:

Der Kernel wurde so geändert, dass er dieselbe Verschlüsselungsfunktion hat, die auch als Entschlüsseler fungiert.

Jeder, an den Sie dies verteilen, hat gemäß den Bestimmungen der GPL Anspruch auf den Kernel-Quellcode. Sie müssten es also nicht zerlegen, sondern könnten nur diffdie zusätzliche Funktion finden.

(Nicht, dass es so schwierig wäre, es durch Demontage zu finden, wie Sie z. B. im Vergleich zu einem Standardkern überprüfen können.)

Ich bin mit dem Raspberry Pi-Bootcode nicht vollständig vertraut, aber wenn Sie den Bootloader mit einem eingebetteten Kryptoschlüssel (der dann an den Kernel übergeben wird) erneut flashen können, befindet sich dieser zumindest nicht auf der SD-Karte. d einen Versuch vereiteln, ihn in einem Emulator zum Booten zu bringen.