Verschlüsselte USB-Laufwerke sind oft weniger sicher, als die Werbung suggeriert. Ein Sicherheitsforscher hat mehrere Produkte untersucht, die verschlüsselte oder kopiergeschützte USB-Laufwerke anbieten. AES und Blowfish wurden dabei nicht gebrochen. Das Muster ist ein anderes: Die Verschlüsselung wirkt solide, aber die Schlüsselverwaltung liegt offen. Der Zweitschlüssel hängt neben dem Tresor.
YutianDun: versteckte Konten in verschlüsselten USB-Laufwerken
Das erste Laufwerk kommt von YutianDun und wird von SecZure vertrieben. Es blendet verschlüsselte Dateien aus dem Windows-Explorer aus und öffnet sie nur über mitgelieferte Reader. Diese sollen Kopieren, Screenshots und Drucken verhindern. Der Autor hatte das Produkt schon früher geprüft und gezeigt, dass eine in den PDF-Reader injizierte DLL geschützte Dateien lesen konnte. Diesmal ging es nicht um Kopierschutz, sondern um die Frage, ob das Kryptosystem hält. Mit Time-Travel-Debugging zeichnete er die Abläufe auf und stieß auf versteckte Konten.
In den Aufzeichnungen fand er eine Anmeldung als Buffer mit dem Passwort 123456, bevor er selbst das Administratorkennwort eintippte. Das Konto erscheint nicht in der Benutzerverwaltung. Sein Datensatz enthält eine weitere eingewickelte Kopie derselben Kennung. Daraus lässt sich der AES-Schlüssel für die Dateien ableiten. Zusätzlich fand er ein System-Konto mit dem festen Passwort SECZURE.COM. Auf zwei getesteten Laufwerken öffneten beide Konten die Kennung und damit die Dateien. Der Autor nennt das eine Backdoor im technischen Sinn: Feste Passwörter entschlüsseln Dateien ohne das Nutzerpasswort.
Das belegt keine böse Absicht. Es zeigt aber ein Problem opaker Kryptoprodukte. Eine Hintertür kann selbst dann schwer zu erkennen sein, wenn der Verschlüsselungsalgorithmus ordentlich aussieht. Anwender sehen nicht, welche Konten, festen Kennwörter und alternativen Schlüsselpfade im Hintergrund existieren. Das Problem ist nicht die Stärke von AES, sondern die Frage, wer sonst noch einen Schlüssel bekommt.
Warum die Verschlüsselung von YutianDun fast solide wirkt
Im vereinfachten Ablauf wird das Administratorpasswort gehasht, und der Hash entpackt eine Kennung. Aus dieser Kennung entsteht der AES-Schlüssel für die Dateibytes. Der Autor nennt zwei Schwächen: schnelles MD5 beziehungsweise HMAC-MD5 statt PBKDF2 und 16 Hexzeichen pro AES-Schlüssel, also höchstens 64 Bit Entropie. Ein Brute-Force-Angriff über 2^64 Möglichkeiten ist theoretisch denkbar, praktisch ging er diesen Weg nicht. Die eigentliche Verschlüsselung wirkte zunächst sicher genug, um nicht direkt angegriffen zu werden.
Die Tresor-Analogie passt: Die Tür kann aus dickem Stahl sein. Wenn daneben ein Zweitschlüssel für ein verstecktes Dienstkonto hängt, hilft sie wenig. Für den Nutzer ist das schwer zu erkennen, weil das Produkt nach außen nur Passwortabfrage und verschlüsselte Dateien zeigt. Eine Prüfung der Verschlüsselungsalgorithmen allein reicht nicht. Man muss auch prüfen, welche Konten, festen Kennwörter und Schlüsselpfade im Code stecken.
NetacFileLock: fester AES-Schlüssel statt Nutzerpasswort
Beim zweiten Produkt, NetacFileLock, setzte der Autor Reverse Engineering mit Binary Ninja und einem MCP-Werkzeug ein. Er gab im Wesentlichen einen Prompt: Die KI sollte das Kryptosystem analysieren und prüfen, ob es sicher ist. Nach sieben Minuten erreichte das Modell den Kern des Problems. Das Programm initialisiert AES-256 mit einem festen 32-Byte-Schlüssel, der in der ausführbaren Datei eingebettet ist. Das Nutzerpasswort wird separat geprüft und bestimmt nicht den Dateischlüssel.
Wer die AES-Verschlüsselung von USB-Laufwerken in diesem Produkt knacken will, muss AES nicht selbst angreifen. Es genügt, die ausführbare Datei und den festen Schlüssel zu kennen, um die Dateien ohne Passwort zu entschlüsseln. Die KI fand in denselben Minuten weitere Auffälligkeiten: Das Programm schrieb das Nutzerpasswort in Diagnoseprotokolle, verschlüsselte unabhängige 16-Byte-Blöcke ohne IV oder Verkettung, nutzte MD5 zur Passwortprüfung und einen ungesalzenen MD5-Digest als Dateisignatur. Auch die SM4-Option arbeitete mit einem weiteren festen Schlüssel.
Eine offene Frage aus früherer Forschung war, warum nur etwa ein Drittel einer Testdatei verschlüsselt wurde. Der Bericht löst sie: Das Verhalten ist nicht auf PDFs beschränkt. Es tritt bei jeder Datei über 1.024 Bytes auf, wenn der schnelle Modus aktiv ist. Ein erheblicher Teil der Datei kann im Klartext bleiben. Für Anwender sieht die Datei trotzdem geschützt aus, weil der offizielle Viewer den Rest passend behandelt.
KakaSoft: Kopierschutz mit verstecktem Verzeichnis und manipuliertem MD5
KakaSoft USB Copy Protection 5.6.0.299 bot drei Stufen. Normal blendet Dateien aus und sperrt sie, ohne sie zu verschlüsseln. High XORt höchstens die ersten 16.385 Bytes mit einem Ein-Byte-Schlüssel aus dem Passwort. Highest verwendet 256-Bit-Blowfish. Die ersten beiden Varianten sind offensichtlich schwach, weil nur 256 Schlüssel möglich sind und bekannte Dateisignaturen den Schlüssel sofort verraten. Der Autor wählte die höchste Stufe und ließ die KI prüfen, ob sich eine so geschützte Datei ohne Passwort wiederherstellen lässt.
Die KI fand die geschützten Daten in einem ungewöhnlichen Verzeichnisbaum auf dem exFAT-Datenträger. Die Ordner HPSafeBox und NLLastF trugen versteckte Systemattribute. Ein Teil hieß Com1 mit einer CLSID-ähnlichen Endung, ein anderer begann mit zwei DEL-Zeichen und einem Unicode-Zeichen aus dem privaten Bereich. Diese Namen verwirren die normale Windows-Pfadbehandlung und halten den Baum aus dem Explorer heraus. In der 667-Byte-Testdatei lagen acht Bytes Salt, acht Bytes CBC-IV und ab Offset 0x10 der Blowfish-Ciphertext. Ein 75-Byte-Nachspann enthielt einen 32-Zeichen-Verifier sowie die lesbaren Strings kakaencryption und BlowFish.
Der entscheidende Fehler lag nicht in Blowfish, sondern in der Schlüsselableitung. Der Client ist ein 32-Bit-Delphi-Programm. Die KI folgte seiner Klasse TBlowfishEncryption und stieß auf eine veränderte MD5-Variante. Die Rotationswerte in der dritten Runde wichen vom Standard ab, und die hexadezimale Ausgabe verwendete ein permutiertes Alphabet. Statt diesen Hash von Hand nachzubauen, emulierte die KI den relevanten Code und erhielt ein festes internes Passwort. Damit ließ sich die Datei ohne Nutzerpasswort entschlüsseln und in ihre ursprünglichen Bytes zurückverwandeln.
Der Aufwand blieb überschaubar: etwa zwei Minuten zum Entpacken des Installers, sieben Minuten für die Kryptoanalyse und zwei Prompts. Nach Einlegen des geschützten Laufwerks brauchte die KI rund 26 Minuten und sechs kurze Rückfragen. Meist ging es um die Bestätigung des Laufwerks, des Testpassworts und der Analyserichtung. Das Ergebnis ist ein Kopierschutz, der das Kopieren nicht verhindert und zusätzlich die Dateien ohne Passwort zugänglich macht.
Nexcopy: Passwortprüfung als Fassade vor festem Zertifikat
Nexcopy Copy Secure, eingerichtet mit Drive Wizard 1.0.81, enthielt Windows- und macOS-Viewer. Der Mac-Viewer behielt Objective-C-Methodennamen, was die Analyse erleichterte. Die geschützten Inhalte waren diesmal mit Triple-DES im CBC-Modus und drei Schlüsseln verschlüsselt. Das Problem war erneut die Ablage des Schlüssels. Eine verschlüsselte Konfigurationsdatei wurde mit einem festen 32-Byte-Zertifikat geöffnet, das in der Anwendung eingebettet war.
Die 324-Byte-Konfiguration und die 140-Byte-Testdatei begannen mit demselben 36-Byte-ASCII-Marker. Bei der Testdatei folgten dem Marker 104 Byte gepolsterter 3DES-CBC-Ciphertext. Bei der Konfiguration waren es 288 Byte. Die entschlüsselte Konfiguration enthielt ein Feld namens key, den eigentlichen Inhaltsschlüssel: ein 24-Byte-3DES-Schlüssel plus acht Bytes IV. Das Passwort war nur eine separate Oberflächeneinstellung und floss nicht in den Dateischlüssel ein. Der Mac-Viewer holte sogar das gespeicherte Passwort und verglich es direkt per isEqualToString mit der Eingabe. Mit Inhaltsschlüssel und IV konnte die KI den Ciphertext entschlüsseln und den ursprünglichen Inhalt wiederherstellen.
Nexcopy versuchte durchaus, Kopieren zu erschweren. Der Viewer zählte Prozesse auf, fing screenshotbezogene Tasten ab, nutzte Clipboard-APIs und suchte nach Programmen wie ScreenFlow, Camtasia, Debut, Grab und QuickTime. Solche Prüfungen mögen Gelegenheitskopien bremsen. Wer den Viewer untersuchen und seine Entschlüsselung nachbauen kann, wird dadurch nicht am Zugriff auf den Inhaltsschlüssel gehindert.
Was KI-gestütztes Reverse Engineering verändert
Der Autor war überrascht und etwas beunruhigt, wie schnell die KI arbeitete. Zugleich sieht er darin eine produktive Verstärkung für Sicherheitsforschung. Die KI hat AES nicht gebrochen und keine kryptografische Revolution ausgelöst. Sie hat Code gelesen, Datenflüsse verfolgt, Installer entpackt, Klassen und Konstanten gefunden und vorhandene Fehler schneller sichtbar gemacht. Das ist der Kern von KI-gestützter Sicherheitsanalyse: keine Magie, sondern Beschleunigung sorgfältiger Arbeit.
Wer Binary Ninja für Vulnerability Research nutzt, bekommt durch einen MCP-Anschluss eine andere Arbeitsweise. Ein Modell kann Funktionen, Strings, Cross-References und Disassembly abfragen, ohne dass der Mensch jede Adresse selbst anklickt. Das senkt die Einstiegshürde und macht lange Analyseketten in Minuten durchlaufbar. Es ersetzt keine Verifikation. Der Bericht zeigt an mehreren Stellen, dass die KI zunächst vage blieb und erst durch konkrete Rückfragen, Testdateien und Emulation belastbare Ergebnisse lieferte. Wer solche Werkzeuge einsetzt, muss die Funde nachprüfen und die Grenzen des Modells kennen.
Für Hersteller verschlüsselter USB-Laufwerke ist das unangenehm. Ein Produkt, dessen Sicherheit auf einem festen Schlüssel, einem versteckten Konto oder einem eingebetteten Zertifikat beruht, hält einer offenen Prüfung nicht stand. Für Einkäufer und Anwender heißt das: Verschlüsselung ist nur so gut wie die Schlüsselverwaltung. Wer ein solches Laufwerk kauft, sollte fragen, wo der Schlüssel entsteht, ob er pro Datei oder pro Gerät eindeutig ist, ob das Passwort wirklich in die Ableitung eingeht und ob das Produkt unabhängig geprüft wurde. Die Schlüsselverwaltung entscheidet.
Quelle: binary.ninja
