Nel resoconto pubblicato il 22 ottobre 2026, il ricercatore Xusheng Li ha descritto debolezze nella gestione delle chiavi o nei controlli di copia di quattro prodotti USB. Nei test riferiti da Li, OpenAI Codex ha contribuito ad analizzare il software e a recuperare file di prova. I risultati riguardano i prodotti e le configurazioni esaminati, non la cifratura USB in generale.
Perché una password può non proteggere un file
La verifica della password e la derivazione della chiave di decifratura sono due passaggi diversi. La prima controlla l’accesso; la seconda determina la chiave che rende leggibile il file. Se il programma usa una chiave fissa incorporata nel software, o se un controllo del visualizzatore resta separato da quella chiave, la password può non impedire il recupero dei dati.
Le debolezze descritte nei quattro prodotti
| Prodotto e configurazione | Debolezza descritta da Li | Ambito dei test riferiti |
| SecZure YutianDun | Gli account integrati Buffer e System consentivano di accedere all’identificatore da cui venivano derivate le chiavi dei file. | Li riferisce di aver verificato il comportamento su due unità. |
| NetacFileLock | Una chiave fissa di 32 byte, incorporata nell’eseguibile, inizializzava AES-256 indipendentemente dalla verifica della password. | La modalità rapida cifrava un terzo dei file idonei più grandi di 1.024 byte. Codex riprodusse i risultati dell’analisi statica descritta da Li in sette minuti. |
| KakaSoft USB Copy Protection 5.6.0.299 | Normal nascondeva e bloccava i file senza cifrarli. High applicava XOR a un massimo di 16.385 byte iniziali, lasciando in chiaro i successivi. Highest usava Blowfish-CBC con una chiave derivata da un seed incorporato. | Li riferisce di aver recuperato un file di prova senza la password impostata. |
| Nexcopy Copy Secure, configurato con Drive Wizard 1.0.81 | Un valore fisso nel visualizzatore decifrava una configurazione con la chiave del contenuto e un vettore di inizializzazione. I controlli della password e del dispositivo non fornivano la chiave del file. | Li riferisce di aver recuperato un file di prova cifrato con Triple-DES a tre chiavi in modalità CBC. |
I casi riguardano meccanismi diversi. Su YutianDun, secondo Li, gli account integrati aprivano l’identificatore usato per derivare le chiavi; su NetacFileLock, la chiave di AES-256 era fissa e separata dal controllo della password. Per KakaSoft, il livello Normal non cifrava i file, mentre gli altri due livelli avevano limiti o dipendenze specifiche. Nel caso Nexcopy, i controlli del visualizzatore non determinavano la chiave usata per decifrare il file.
Il ruolo di Codex nei test
Li scelse i prodotti, fornì i supporti protetti, guidò l’analisi e verificò il ripristino dei file. Per KakaSoft riferisce circa 26 minuti di lavoro e sei brevi istruzioni; per Nexcopy, circa 10 minuti e cinque istruzioni. Nel caso NetacFileLock, Codex riprodusse l’analisi statica in sette minuti. Sono attività diverse descritte da Li, non un confronto standardizzato della velocità di Codex.
Il precedente su YutianDun
Li colloca nel novembre 2024 una precedente ricerca sulla protezione dalla copia di YutianDun, pubblicata nel quinto numero di Paged Out!. La distingue dall’analisi del 2026, che riguardava la crittografia e gli account integrati del prodotto.
