Lenovo's Encrypted Fingerprint USB Drive Was Just an SD Card in a Fancy Case

A security investigation has revealed that the Lenovo ThinkPlus FU100, a USB drive sold as an AES-256 hardware-encrypted device for protecting sensitive data, contained nothing more than a standard SD card with no encryption whatsoever. The fingerprint reader did not encrypt anything—it merely toggled the USB connection on or off.

Security researcher Xusheng Li of Vector 35 disassembled the device in 2025 and found that the internal circuit board held a standard SD card, with all files stored in plaintext. The biometric sensor simply closed or opened the electrical circuit of the USB connector. Anyone with physical access to the drive could read its files without the slightest difficulty.

A pattern of failures

The FU100 was the first in a series of discoveries that Li presented at the RE//verse conference in March 2026. His presentation carried a direct warning: "do not trust encrypted USB drives—verify what the manufacturer actually claims." What Li found was the most elementary form of security theater: the product fulfills the promise on paper ("AES-256 encryption") but implements none of the steps necessary to make that promise real.

The second device Li analyzed was the ThinkPlus TSD303, an external SSD also featuring fingerprint authentication. In this case, the data was genuinely encrypted—but the password was sent by the device itself in plaintext to the computer's software, so the program could compare it to what the user typed. Anyone capable of sniffing USB traffic or reading the software's memory could recover the password in clear text.

Li reported the problem to Lenovo in August 2025. Three months later, the company sent a test version: the SSD stopped sending the password in plaintext and began transmitting data encrypted with SM4, a block cipher similar to AES. Li investigated and found that the SM4 key was derived from a value that looked like a timestamp—specifically, 2021012700000000. Anyone running the verification program could derive the same key and decrypt the data. The fix was incomplete.

AI-assisted analysis

In October 2026, Li revisited the TSD303's software with OpenAI's Codex, connected to his reverse-engineering debugger. A single prompt sufficed: "this is a file encryption utility; analyze the cryptographic system and tell me if it is secure." In about seven minutes, Codex had found the hardcoded key embedded in the executable. The program logged the user's password to its diagnostic logs, verified passwords with MD5, and encrypted 16-byte blocks without an initialization vector—meaning identical input blocks produced identical output.

Li's research covered five brands: Lenovo, Netac, KakaSoft, Nexcopy, and SecZure. Lenovo's own SDK covered nine additional devices from multiple vendors. Most could reveal passwords to any technically skilled attacker; two stored data unencrypted on microSD cards.

The irony is particularly sharp: the same AI technology that manufacturers market as a security feature was used by Li to prove the encryption was nonexistent. Li used Codex—the same technology that companies sell as part of their security ecosystem—to demonstrate that the encryption was illusory.

A sixteen-year-old problem

This is not a new problem. In December 2009, the German security firm SySS cracked a SanDisk USB drive carrying a FIPS 140-2 certificate. The January 2010 CVE records describe SanDisk Cruzer Enterprise drives and three Kingston DataTraveler models with the same fundamental flaw: password validation via software on the computer rather than the device's own chip, and fixed 256-bit keys embedded in the firmware. In 2025—16 years later—the same mistakes recur.

The difference today is that AI makes reverse engineering accessible to anyone who can write a single prompt. Li did not need a team of researchers or months of manual reverse engineering. One query to Codex, connected to his debugger, was enough to find the fixed key that protected—or rather, failed to protect—customer data.

Proper encryption follows one principle: the key is derived from the password itself through a deliberately slow function like PBKDF2 or Argon2, so that each guess costs time. Or the verification happens inside the device's own chip, and neither the password nor the key ever leaves it. Without the password, there is nothing to compare and no key to find.

The devices Li tested do the exact opposite. They keep the password—or something derivable from it—outside the secure chip. They put the key in a configuration file readable by the viewer program. Or, in the extreme case of the FU100, they do not encrypt the data at all.

What to do

Lenovo published security advisory LEN-210545 on January 13, 2026, rated high severity, covering three CVEs. For the FU100, the company offers free firmware upgrades: users should call the Chinese support line at +86 400-640-1886, Lenovo verifies the device serial number, and schedules a firmware update or home visit. The company also recommends backing up data before sending the device for review and wiping the contents—which, ironically, does not solve the problem, since the data had been accessible to anyone from the beginning.

For anyone seeking real data protection in removable devices, the recommendation is straightforward: encrypt files with software where the key actually comes from the user's password. VeraCrypt, BitLocker To Go on Windows Pro, or gpg are solid options. A fingerprint reader or password screen on a USB drive should be treated as physical access control, not encryption—unless the manufacturer demonstrates that the encryption key actually depends on the password.

The question is: if the simple act of opening a USB drive reveals that "hardware security" was just marketing, how many other products claiming cryptographic protection are storing data in plaintext?

Sources: HackingPassion, Tom's Hardware, Meža

✓ Independent sources cross-checked and verified before publishing