Xusheng Li’s account, published October 22, 2026, described key-management and copy-protection weaknesses in four USB products: SecZure YutianDun, NetacFileLock, KakaSoft USB Copy Protection, and Nexcopy Copy Secure. Li said OpenAI Codex assisted his analysis, in which he selected the targets, supplied protected media, directed the work, and confirmed recovered test files. His findings concern the products and tests he described, not USB encryption as a whole.
How a password check can be separate from file encryption
A password check controls whether software grants access. Key management determines what secret actually decrypts a file. If those steps are separate, a password prompt can appear without the password protecting the file’s decryption key.
Li described that separation in several of the products he analyzed. The specific mechanisms differed: built-in accounts exposed a content identifier in YutianDun, while NetacFileLock and Nexcopy used fixed values in their software or configuration. KakaSoft’s protection depended on which of its three modes was selected.
What Li reported in each product
| Product and configuration | Reported protection or key-management weakness | Test scope Li described |
| SecZure YutianDun | Built-in Buffer and System accounts reportedly exposed the content identifier used to derive file-decryption keys. The account credentials were 123456 and SECZURE.COM. | Li said both accounts opened the identifier on two tested drives. |
| NetacFileLock | A fixed 32-byte key embedded in the executable initialized AES-256 separately from the user-password check. Li also reported password logging, MD5 password verification, an unkeyed MD5 file signature, and a separate fixed key for the SM4 option. | Codex reproduced Li’s earlier findings through static analysis in seven minutes, according to Li. In fast mode, the software encrypted one-third of eligible files larger than 1,024 bytes. |
| KakaSoft USB Copy Protection 5.6.0.299 | Normal mode did not encrypt files. High mode XORed up to the first 16,385 bytes using one of 256 possible byte-sized keys. Highest mode used Blowfish-CBC with key derivation based on an embedded seed. | Li said Codex-assisted analysis restored the original bytes of a protected test file without its configured password. |
| Nexcopy Copy Secure, provisioned with Drive Wizard 1.0.81 | A fixed value in the viewer decrypted a configuration containing the content key and IV. The viewer’s password and device checks did not supply the file key. Li reported three-key Triple-DES in CBC mode. | Li said the analysis restored a protected test file. |
The products did not share one failure mechanism. In YutianDun, the reported issue involved alternative built-in accounts and the identifier used to derive file keys. In NetacFileLock and Nexcopy, Li described fixed values that separated the user-facing checks from the secret used for decryption.
KakaSoft’s settings also differed substantially. Normal mode locked and hid files without encryption; High mode altered only a limited prefix of a file; Highest mode used Blowfish-CBC, but its key derivation relied on an embedded seed. Li said the High-mode byte-sized key could be identified from file signatures.
Codex assisted a researcher-directed investigation
Li described Codex as part of a workflow he led, rather than an independent discovery process. He chose the products, supplied the protected drives, gave prompts, and checked whether the original test-file bytes had been recovered.
For KakaSoft, Li reported about 26 minutes of work and six short prompts after he supplied the protected drive. For Nexcopy, he reported about ten minutes and five prompts. Those timings describe different tasks, so they do not form a direct performance comparison. Li also said Codex reproduced the NetacFileLock findings through static analysis in seven minutes.
The earlier YutianDun research was a separate finding
Li said an earlier YutianDun copy-protection result appeared in Paged Out!, issue 5, in November 2024. That work described a copy-protection bypass involving DLL injection and read access. Li distinguished it from the later analysis of YutianDun’s cryptography and built-in accounts, which he published on October 22, 2026.
