Xusheng Li berichtete am 22. Oktober 2026 über Schwächen in vier USB-Schutzprodukten: Bei seinen Tests schützten Passwort- oder Viewer-Prüfungen teils nicht den Schlüssel, mit dem Dateien entschlüsselt wurden. OpenAI Codex unterstützte Li bei der Analyse und beim Wiederherstellen geschützter Testdateien.
Was die Tests untersuchten
Li beschrieb Prüfungen an SecZure YutianDun, NetacFileLock, KakaSoft USB Copy Protection und Nexcopy Copy Secure. Seine Befunde betreffen die untersuchten Produkte und Konfigurationen.
Ein Passwort kann den Zugriff auf eine Benutzeroberfläche kontrollieren, ohne den Schlüssel abzusichern, der eine Datei entschlüsselt. Entscheidend ist daher, ob die Prüfung des Passworts tatsächlich in die Erzeugung oder den Schutz des Dateischlüssels einfließt. Li berichtete bei mehreren der untersuchten Produkte von einer Trennung zwischen diesen Funktionen.
Die berichteten Schwächen im Vergleich
| Produkt und untersuchte Konfiguration | Von Li beschriebene Schwäche | Umfang der beschriebenen Tests |
| SecZure YutianDun | Eingebaute Konten konnten laut Li den Inhaltsbezeichner öffnen, aus dem Dateischlüssel abgeleitet wurden. Die Ableitung nutzte MD5 und HMAC-MD5; durch die Kürzung auf 16 Hexadezimalzeichen war das Schlüsselmaterial auf höchstens 64 Bit Entropie begrenzt. | Li testete zwei Laufwerke. |
| NetacFileLock | Ein fester, in der ausführbaren Datei gespeicherter 32-Byte-Schlüssel initialisierte AES-256 unabhängig von der Passwortprüfung. Li berichtete außerdem von protokollierten Passwörtern, MD5-Prüfungen und einer festen Schlüsselverwendung für die SM4-Option. | Im Schnellmodus wurde laut Li ein Drittel der geeigneten Dateien mit mehr als 1.024 Byte verschlüsselt. |
| KakaSoft USB Copy Protection 5.6.0.299 | Normal verschlüsselte Dateien nicht. High veränderte per XOR höchstens die ersten 16.385 Byte mit einem von 256 möglichen Byte-Schlüsseln. Highest nutzte Blowfish-CBC, leitete den Schlüssel aber aus einem eingebetteten Startwert ab. | Li untersuchte die Version 5.6.0.299. |
| Nexcopy Copy Secure, eingerichtet mit Drive Wizard 1.0.81 | Ein fester Wert im Viewer entschlüsselte eine Konfigurationsdatei mit dem Dateischlüssel und dem Initialisierungsvektor. Passwort- und Geräteprüfung im Viewer flossen laut Li nicht in die Ableitung des Dateischlüssels ein. | Li beschrieb die Einrichtung mit Drive Wizard 1.0.81 und eine geschützte Testdatei. |
Die Fälle unterscheiden sich darin, wo die Schutzprüfung vom eigentlichen Dateischlüssel getrennt war: bei YutianDun über zusätzliche Konten, bei NetacFileLock über einen im Programm enthaltenen Schlüssel und bei KakaSoft über die jeweilige Schutzstufe. Bei Nexcopy lag der Schlüssel in einer Konfiguration, die der Viewer mit einem festen Wert entschlüsseln konnte.
Welche Rolle Codex spielte
Li wählte die Produkte aus, stellte die geschützten Datenträger bereit, steuerte die Analyse mit Eingaben und prüfte, ob die Testdateien wiederhergestellt worden waren. Codex unterstützte damit einen von Li geleiteten Ablauf.
Bei NetacFileLock reproduzierte Codex Li zufolge dessen frühere Erkenntnisse durch statische Analyse in sieben Minuten. Für die Wiederherstellung einer KakaSoft-Testdatei nach sechs kurzen Eingaben gab Li rund 26 Minuten an. Bei Nexcopy dauerte die von Li beschriebene Analyse etwa zehn Minuten und umfasste fünf Eingaben.
YutianDuns Vorgeschichte
Li zufolge hatte er bereits im November 2024 in Ausgabe 5 von Paged Out! einen früheren Angriff auf den Kopierschutz von YutianDun beschrieben. Dabei ging es um DLL-Injection und Lesezugriff. Diese Untersuchung unterschied Li von seiner Analyse des Kryptosystems und der eingebauten Konten im Jahr 2026.
