En un análisis publicado el 22 de octubre de 2026, el investigador de seguridad Xusheng Li describió fallos de gestión de claves en SecZure YutianDun, NetacFileLock, KakaSoft USB Copy Protection y Nexcopy Copy Secure. En sus pruebas, algunas comprobaciones de contraseña o del visor no protegían la clave que descifraba los archivos. Li también contó que OpenAI Codex le ayudó a recuperar archivos de prueba de KakaSoft y Nexcopy.
Cómo puede fallar la protección aunque haya una contraseña
La contraseña puede limitar el acceso a un programa sin proteger la clave criptográfica que descifra el archivo. Si esa clave, o la información para recuperarla, está en el propio programa o en su configuración, comprobar la contraseña no basta para mantenerla protegida. Li describió variantes de este problema en los productos que analizó.
Qué debilidad describió Li en cada producto
| Producto y configuración | Mecanismo descrito | Alcance de las pruebas descritas |
| SecZure YutianDun | Las cuentas integradas Buffer y System permitieron acceder al identificador de contenido del que se derivaban las claves de archivo. Li describió una derivación basada en MD5 y HMAC-MD5, truncada a 16 caracteres hexadecimales, con un máximo de 64 bits de entropía para el material de clave. | Li afirmó que ambas cuentas abrieron el identificador en dos unidades probadas. |
| NetacFileLock | Una clave fija de 32 bytes integrada en el ejecutable iniciaba AES-256 al margen de la verificación de la contraseña. Li también describió contraseñas en registros de diagnóstico, comprobación de contraseñas con MD5, una firma de archivo basada en MD5 sin clave y una clave fija para la opción SM4. | En el modo rápido, el programa cifraba un tercio de los archivos aptos de más de 1.024 bytes, según Li. |
| KakaSoft USB Copy Protection 5.6.0.299 | El modo Normal ocultaba y bloqueaba archivos, pero no los cifraba. High aplicaba XOR a un máximo de 16.385 bytes iniciales con una clave de un byte, dejando el resto en texto claro. Highest usaba Blowfish-CBC con una clave derivada de una semilla integrada. | Li dijo que Codex ayudó a recuperar un archivo de prueba sin la contraseña configurada. |
| Nexcopy Copy Secure, preparado con Drive Wizard 1.0.81 | Un valor fijo de 32 bytes en el visor descifraba una configuración con la clave de contenido de 24 bytes y un vector de inicialización de 8 bytes. El archivo usaba Triple-DES de tres claves en modo CBC; las comprobaciones de contraseña y dispositivo del visor no intervenían en la derivación de la clave del archivo. | Li describió la recuperación de un archivo de prueba protegido. |
Los mecanismos eran distintos. En YutianDun, el problema descrito estaba en las cuentas integradas; en NetacFileLock y Nexcopy, en la separación entre el control de acceso y la clave del archivo. KakaSoft ofrecía tres modos con protecciones diferentes, y el modo Normal ni siquiera cifraba los archivos.
Los resultados se refieren a esos productos y a las pruebas que describió Li. No permiten extender la conclusión a todo el cifrado USB.
Codex asistió un análisis dirigido por Li
Li eligió los objetivos, aportó los soportes protegidos, orientó el análisis y confirmó la recuperación de los archivos. En NetacFileLock, dijo que Codex reprodujo hallazgos anteriores mediante análisis estático en siete minutos. Para KakaSoft, informó de unos 26 minutos de trabajo y seis indicaciones breves; para Nexcopy, de unos diez minutos y cinco indicaciones. Eran tareas diferentes: los tiempos no constituyen una comparación de rendimiento.
El antecedente de YutianDun
Li situó en noviembre de 2024 un trabajo anterior sobre la protección contra copias de YutianDun, publicado en el número 5 de Paged Out!. Aquel resultado se refería a la protección contra copias; el análisis de octubre de 2026 examinó el sistema criptográfico y las cuentas integradas.
