Le 22 octobre 2026, le chercheur Xusheng Li a décrit des faiblesses de chiffrement ou de protection contre la copie dans quatre produits USB : SecZure YutianDun, NetacFileLock, KakaSoft USB Copy Protection et Nexcopy Copy Secure. Dans les essais qu’il rapporte, certains contrôles de mot de passe ou d’accès au lecteur ne protégeaient pas la clé servant à déchiffrer les fichiers. Codex l’a aidé à analyser les produits et à restaurer des fichiers de test. Ces constats portent sur les produits et configurations examinés par Li, pas sur le chiffrement USB en général.
Pourquoi un mot de passe peut ne pas protéger un fichier
La vérification d’un mot de passe et la protection de la clé de déchiffrement sont deux opérations différentes. La première autorise ou refuse l’accès à une interface ; la seconde protège le secret qui transforme un fichier chiffré en fichier lisible. Si le logiciel contient cette clé, ou permet de la récupérer depuis sa configuration, l’écran de connexion ne suffit pas à protéger le contenu.
Li décrit ce type de séparation dans plusieurs des produits examinés. Les faiblesses ne reposaient toutefois pas toutes sur le même mécanisme.
Les mécanismes décrits dans les quatre produits
| Produit et configuration | Faiblesse décrite par Li | Portée des essais rapportés |
| SecZure YutianDun | Les comptes intégrés Buffer et System, associés aux mots de passe 123456 et SECZURE.COM, donnaient accès à l’identifiant de contenu utilisé pour dériver les clés des fichiers. Li décrit une dérivation reposant sur MD5 et HMAC-MD5, dont la sortie était ramenée à 16 caractères hexadécimaux. | Les deux comptes ont ouvert l’identifiant de contenu sur deux clés USB testées par Li. |
| NetacFileLock | Une clé fixe de 32 octets intégrée au programme initialisait AES-256 indépendamment du mot de passe utilisateur. En mode rapide, un tiers des fichiers admissibles de plus de 1 024 octets était chiffré. | Codex a reproduit les constats de Li par analyse statique. |
| KakaSoft USB Copy Protection 5.6.0.299 | Le mode Normal verrouillait les fichiers sans les chiffrer. High appliquait XOR aux 16 385 premiers octets au maximum, avec une clé d’un octet parmi 256 valeurs. Highest utilisait Blowfish-CBC avec une clé dérivée d’une graine intégrée. | Li rapporte la restauration d’un fichier de test protégé sans le mot de passe configuré. |
| Nexcopy Copy Secure, préparé avec Drive Wizard 1.0.81 | Une valeur fixe intégrée au lecteur déchiffrait un fichier de configuration contenant une clé Triple-DES de 24 octets et un IV de 8 octets. Les contrôles du mot de passe et de l’appareil ne participaient pas à la dérivation de la clé du fichier. | Li rapporte la restauration d’un fichier de test protégé. |
Dans NetacFileLock, Li relève également que le logiciel consignait les mots de passe, vérifiait les mots de passe par MD5 et utilisait une empreinte MD5 sans clé comme signature de fichier. L’option SM4 reposait sur une autre clé fixe. Le logiciel traitait aussi des blocs indépendants de 16 octets sans IV ni chaînage, un fonctionnement de type ECB.
Codex a assisté un travail dirigé par Li
Li a choisi les produits, fourni les supports protégés, guidé l’analyse par ses consignes et vérifié les fichiers restaurés. Codex n’a donc pas mené seul la sélection des cibles ni la validation des résultats.
Pour NetacFileLock, Li indique que Codex a reproduit ses constats par analyse statique en sept minutes. Pour KakaSoft, il rapporte environ 26 minutes de travail et six consignes courtes avant la restauration du fichier de test. Pour Nexcopy, il décrit environ dix minutes d’analyse et cinq consignes.
Un précédent sur YutianDun en 2024
Li indique qu’un travail antérieur sur le contournement de la protection contre la copie de YutianDun avait paru dans le numéro 5 de Paged Out! en novembre 2024. Ce résultat, lié à l’injection de DLL et à l’accès en lecture, précédait son analyse distincte du système cryptographique et des comptes intégrés.
