Xusheng Li opisał 22 października 2026 r. luki w zabezpieczeniach czterech produktów USB: SecZure YutianDun, NetacFileLock, KakaSoft USB Copy Protection i Nexcopy Copy Secure. W jego testach kontrola hasła lub ograniczenia kopiowania nie zawsze chroniły klucz potrzebny do odszyfrowania pliku. OpenAI Codex wspierał analizę prowadzoną przez badacza.
Dlaczego hasło nie zawsze chroni klucz pliku
Program może sprawdzić, czy użytkownik podał właściwe hasło, a mimo to używać oddzielnego klucza do odszyfrowania pliku. Jeśli ten klucz da się odzyskać z programu albo jego konfiguracji, samo hasło nie stanowi dla niego ochrony. Li opisał takie rozdzielenie w kilku badanych produktach, choć mechanizm różnił się w każdym z nich.
Jakie luki Li opisał w poszczególnych produktach
| Produkt i konfiguracja | Opisana słabość | Zakres testu opisanego przez Li |
| SecZure YutianDun | Wbudowane konta Buffer i System dawały dostęp do identyfikatora treści, z którego wyprowadzano klucze plików. | Na dwóch testowanych nośnikach oba konta otworzyły ten identyfikator. |
| NetacFileLock | Program miał zapisany na stałe 32-bajtowy klucz inicjujący AES-256, niezależny od sprawdzania hasła. Li opisał też hasła w logach, weryfikację hasła i sygnaturę pliku oparte na MD5 oraz osobny stały klucz dla trybu SM4. | W trybie szybkim szyfrowano jedną trzecią kwalifikujących się plików większych niż 1 024 bajty. |
| KakaSoft USB Copy Protection 5.6.0.299 | Tryb Normal nie szyfrował plików. High stosował XOR do maksymalnie pierwszych 16 385 bajtów, używając jednego z 256 kluczy jednobajtowych. Highest korzystał z Blowfish-CBC, ale wyprowadzanie klucza opierało się na ziarnie zapisanym w programie. | Li opisał odzyskanie pliku testowego bez skonfigurowanego hasła. |
| Nexcopy Copy Secure, przygotowany przez Drive Wizard 1.0.81 | Stała wartość w przeglądarce odszyfrowywała konfigurację zawierającą klucz treści i wektor inicjalizujący. Kontrole hasła i urządzenia dotyczyły przeglądarki, a nie wyprowadzania klucza pliku. | Li opisał odzyskanie pliku testowego zaszyfrowanego trzykluczowym Triple DES w trybie CBC. |
W przypadku YutianDun konta Buffer i System miały odpowiednio hasła 123456 i SECZURE.COM. Li nazwał ten mechanizm technicznym backdoorem, opisując dostęp do identyfikatora na dwóch sprawdzonych nośnikach.
NetacFileLock pokazywał, jak łatwo kontrola dostępu może rozmijać się z ochroną danych: w opisanej konfiguracji hasło nie wyznaczało klucza AES-256. Tryb szybki szyfrował tylko część kwalifikujących się plików, a nie całą ich zawartość. Li wymienił także zapis haseł w logach diagnostycznych i użycie MD5 do weryfikacji hasła oraz sygnatury pliku.
W KakaSoft poziomy ochrony różniły się zasadniczo. Normal blokował dostęp do plików, ale ich nie szyfrował; High zmieniał tylko początkową część pliku. W najwyższym poziomie klucz Blowfish-CBC zależał od ziarna osadzonego w programie. Li podał, że analiza pozwoliła odtworzyć oryginalne bajty jego pliku testowego bez ustawionego hasła.
W Nexcopy Copy Secure Li opisał plik konfiguracji zawierający 24-bajtowy klucz Triple DES i 8-bajtowy wektor inicjalizujący. Stała wartość w przeglądarce odszyfrowywała tę konfigurację, a kontrole hasła i urządzenia nie dostarczały klucza używanego do odszyfrowania pliku.
Codex pomagał w analizie kierowanej przez Li
Li wybierał produkty, dostarczał chronione nośniki, kierował analizą i potwierdzał odzyskanie plików. Codex nie działał w tym opisie jako samodzielny badacz. W NetacFileLock odtworzył wcześniejsze ustalenia Li podczas siedmiu minut analizy statycznej, czyli badania pliku programu bez jego uruchamiania.
Dla KakaSoft Li podał około 26 minut pracy i sześć krótkich poleceń; dla Nexcopy opisał około dziesięciu minut i pięć poleceń. To czasy dwóch różnych zadań, a nie porównywalny pomiar szybkości. W obu przypadkach chodziło o pliki testowe dostarczone przez badacza.
Wcześniejsze badanie YutianDun
Li podał, że wcześniejszy wynik dotyczący obejścia ochrony przed kopiowaniem YutianDun ukazał się w listopadzie 2024 r. w piątym numerze „Paged Out!”. Odróżnił tamto badanie od analizy kryptografii i wbudowanych kont, którą opisał w październiku 2026 r. Jego ustalenia dotyczą czterech wymienionych produktów i opisanych testów.
