OpenAI Codex-assisted reverse engineering exposes embedded keys and hidden accounts in four encrypted USB and copy-protection products
Researcher Xusheng Li used OpenAI Codex with Binary Ninja's Model Context Protocol interface to analyze four encrypted USB and copy-protection products, and published the results on October 22, 2026. The flaws are in key management and authentication design, not in the encryption algorithms. In several cases the password gated access in the vendor software but did not protect the file keys. Codex reproduced a previously identified flaw in NetacFileLock in seven minutes. Li published without conventional coordinated disclosure because recalling or updating deployed devices is difficult. The article does not report in-the-wild exploitation or vendor patches.
Entenda a falha
A vulnerabilidade
Four encrypted USB and copy-protection products have key-management and authentication design flaws, not weaknesses in the cipher algorithms. They are NetacFileLock, SecZure YutianDun, KakaSoft USB Copy Protection 5.6.0.299 and Nexcopy Copy Secure provisioned with Drive Wizard 1.0.81. In each, the password gates the vendor software but does not protect the file key, so someone holding the protected drive or its client software can recover files without the password. No CVEs are assigned, and the articles give no fixed versions or vendor patches.
Como funciona
The user plugs in the drive and enters a password in the vendor's viewer or client. The software checks the password in one step, while the key that actually encrypts the files comes from somewhere else. In NetacFileLock it is a fixed AES-256 key inside the executable. In YutianDun, hidden Buffer and System accounts with fixed passwords each hold a wrapped copy of the same content identifier from which the file key is derived. In KakaSoft's highest level the key comes from an embedded seed, and in Nexcopy an embedded application value leads to an encrypted configuration holding the key and IV. The password check therefore only affects the viewer's behavior, and the files stay decryptable by other means.
Por que é vulnerável
The root cause is a design error: file keys are not derived from a user secret but are fixed, embedded in client software, or recoverable through built-in accounts, and password verification is decoupled from the encryption key. Weak primitives add to it: MD5-based password verification, an unkeyed MD5 file signature, ECB-style blocks with no IV or chaining, a one-byte-range scramble in KakaSoft's High level, MD5/HMAC-MD5 derivation with hex truncation limiting YutianDun's AES key to at most 64 bits of entropy, and a Netac fast mode that encrypts only one-third of eligible files. The articles report no fixes.
Como foi descoberta
Researcher Xusheng Li used OpenAI Codex through Binary Ninja's Model Context Protocol interface for static analysis of the four products and published the results on October 22, 2026. Codex reproduced a previously identified NetacFileLock flaw in seven minutes from a simple prompt asking whether its cryptosystem was secure. Li published without conventional coordinated disclosure, saying that recalling or updating deployed devices is hard. The articles report no in-the-wild exploitation.
Explicação gerada por IA a partir da matéria e dos artigos, em 26/10/2026 04:16.
Detalhes técnicos
- NetacFileLock: a fixed 32-byte AES-256 key is embedded in the executable, and password verification is separate, so files can be decrypted without the password. Other issues: plaintext passwords in diagnostic logs, MD5-based password verification, an unkeyed MD5 file signature, a fixed SM4 key, ECB-style behavior on independent 16-byte blocks with no IV or chaining, and a fast mode that encrypts only one-third of eligible files larger than 1,024 bytes.
- SecZure YutianDun: built-in Buffer and System accounts with fixed passwords each hold a wrapped copy of the same content identifier used to derive the file encryption key. On two tested drives this allowed decryption without the Administrator password. Li described it as a technical backdoor without implying malicious intent. MD5/HMAC-MD5 derivation and hexadecimal truncation limit AES key entropy to at most 64 bits.
- KakaSoft USB Copy Protection 5.6.0.299: the Normal level does not encrypt files, and High scrambles only a limited prefix with a key of 256 possible values. Highest uses Blowfish-CBC but derives the key from an embedded seed rather than the user's password. Analysis took about nine minutes, and recovery from the supplied drive took 26 more minutes and six short prompts.
- Nexcopy Copy Secure (Drive Wizard 1.0.81): an embedded application value leads to an encrypted configuration holding the content key and IV for three-key Triple-DES CBC. Password and USB device checks affect only viewer behavior. The analysis took about ten minutes and five prompts.
The findings do not imply that every encrypted USB product is vulnerable.
Remediação
The article gives no vendor fixes. Its main takeaway is that password prompts and copy restrictions do not guarantee cryptographic confidentiality. Defenders should not rely on these products for sensitive data. They should prefer solutions whose keys are derived from user secrets and are not embedded in client software.
Linha do tempo
-
OpenAI Codex-assisted reverse engineering exposes embedded keys and hidden accounts in four encrypted USB and copy-protection products
ler a análise desta fonte ocultar
Researcher Xusheng Li used OpenAI Codex with Binary Ninja's Model Context Protocol interface to analyze four encrypted USB and copy-protection products, and published the results on October 22, 2026. The flaws are in key management and authentication design, not in the encryption algorithms. In several cases the password gated access in the vendor software but did not protect the file keys. Codex reproduced a previously identified flaw in NetacFileLock in seven minutes. Li published without conventional coordinated disclosure because recalling or updating deployed devices is difficult. The article does not report in-the-wild exploitation or vendor patches.
Technical Details
- NetacFileLock: a fixed 32-byte AES-256 key is embedded in the executable, and password verification is separate, so files can be decrypted without the password. Other issues: plaintext passwords in diagnostic logs, MD5-based password verification, an unkeyed MD5 file signature, a fixed SM4 key, ECB-style behavior on independent 16-byte blocks with no IV or chaining, and a fast mode that encrypts only one-third of eligible files larger than 1,024 bytes.
- SecZure YutianDun: built-in Buffer and System accounts with fixed passwords each hold a wrapped copy of the same content identifier used to derive the file encryption key. On two tested drives this allowed decryption without the Administrator password. Li described it as a technical backdoor without implying malicious intent. MD5/HMAC-MD5 derivation and hexadecimal truncation limit AES key entropy to at most 64 bits.
- KakaSoft USB Copy Protection 5.6.0.299: the Normal level does not encrypt files, and High scrambles only a limited prefix with a key of 256 possible values. Highest uses Blowfish-CBC but derives the key from an embedded seed rather than the user's password. Analysis took about nine minutes, and recovery from the supplied drive took 26 more minutes and six short prompts.
- Nexcopy Copy Secure (Drive Wizard 1.0.81): an embedded application value leads to an encrypted configuration holding the content key and IV for three-key Triple-DES CBC. Password and USB device checks affect only viewer behavior. The analysis took about ten minutes and five prompts.
The findings do not imply that every encrypted USB product is vulnerable.
Remediation
The article gives no vendor fixes. Its main takeaway is that password prompts and copy restrictions do not guarantee cryptographic confidentiality. Defenders should not rely on these products for sensitive data. They should prefer solutions whose keys are derived from user secrets and are not embedded in client software.