Hey, Habr! Ivan Glinkin is here again, head of the hardware research group from the Bastion team.
"A flash drive with a combination lock," "a flash drive with hardware encryption," "an encrypted USB drive," and finally, the proper term — "Cryptographic Module". An encrypted USB flash drive goes by many names, but the core concept remains the same.
The purpose of such a device is to protect sensitive information from unauthorized access at both the software and hardware levels through encryption, anti-tampering mechanisms, and various other safeguards. But are these secure USB drives really as reliable as they're made out to be, or is it all just smoke and mirrors?
We decided to look past the marketing claims and conduct our own investigation, attempting to crack several of these devices using hardware reverse engineering. We attempted to extract data, identify the encryption algorithms used, physically open the drives, and read their memory chips.
The results were quite interesting. Read on for the details.
Understanding the Standards
Before we break out the scalpel and start dissecting these flash drives, let's first look at the theory and standards. How else can we determine if a device's actual level of protection meets its official specifications?
In Russia, there is a general standard whose name alone looks like a cipher: GOST R 54583-2011/ISO/IEC/TR 15443-3:2007.
This standard establishes a methodology for analyzing and justifying the compliance of an information security system with security requirements. However, it doesn't directly address encrypted flash drives, so the local regulatory landscape is rather vague.
International standards, on the other hand, offer more specifics. The NIST FIPS PUB 140 standard outlines the operating principles and security mechanisms for cryptographic modules. The current version is FIPS 140-3.
The standard itself is brief and not very helpful for our purposes. However, the accompanying "Implementation Guidance," a dense 218-page document, is another story entirely.
At a high level, the standard describes four security levels for cryptographic modules:
Security Level | Security Measures | Keys and SSPs (Sensitive Security Parameters) | Example Devices |
Level 1 (Basic): | Regular enclosure with no special tamper mechanisms. Software/logical protection only. | Can be stored in memory without additional protections. | Software tokens, regular USB flash drives with software-based encryption. |
Level 2 (Moderate) | Tamper-evident seals/enclosure, simple physical protection, basic authentication. | Keys are protected, but limited physical access to them is possible. | Smart cards with basic tamper protection, mid-range USB tokens. |
Level 3 (High) | Tamper-resistant enclosure, auto-erasure of keys upon tampering attempts. Protection against side-channel attacks (e.g., power analysis). | Keys are inaccessible from the outside even with direct physical access. | HSMs, secure tokens/flash drives, enterprise crypto keys. |
Level 4 (Maximum) | Full active tamper protection, resistance to extreme environmental conditions (temperature, humidity), active protection against all known side-channel attacks. | Automatic zeroization of keys upon tampering attempts (keys are immediately erased upon attempted intrusion). | Military/government HSMs, modules for mission-critical systems. |
From Theory to Practice
With a general understanding of the standards and requirements established, it is now time to begin our research. We started by reviewing past studies to see what our colleagues had accomplished when attempting to crack secure USB drives. This historical review revealed several possible attack vectors.
For instance, in some cases, physically disassembling a drive revealed an internal SD or microSD card. This card could be easily removed and read with a standard card reader, as the data on it was stored in cleartext.
The so-called "hardware password" protection was implemented solely as a power gate: a correct password would complete the circuit to the memory chip, while an incorrect one would leave it unpowered. Fellow researchers bypassed this simple mechanism by creating a bridge to supply power directly to the memory card, circumventing the controller module entirely.
In 2017, a Google research team tested a whole range of such secure flash drives and reported finding only a few vulnerabilities. So, what if we had better luck? We purchased several secure flash drives of various types and price points to begin our own testing.
Disclaimer: Due to legal restrictions, all mentions of Russian brands in this article have been anonymized, and their logos have been obscured.
Patient #1: A $40 Russian Secure Flash Drive
First up was a budget-friendly, Russian-made flash drive with 32 GB of storage. We began by studying the user manual and giving the device a thorough physical inspection.
Initial Inspection
The drive features a metal casing with a pleasant tactile feel. The rubberized buttons are easy to press. Its speaker is quite loud, and the audible signal is, as expected, piercing.
Next, we remove the cap and...
Following the instructions, we press the power button and enter the default PIN code (1122334) We then press the lock button, and the flash drive becomes operational.
Now for the security features. The manual states, verbatim:
"After 10 times incorrect input, flash drive will be reset to factory settings. Data will be erased completely and PIN will be initiated (initial PIN1122334)".
This warning is reiterated in the "Notifications" chapter. However, considering the time required for secure data destruction, as we've measured in a previous article (in Russian), we are highly skeptical of this "complete erasure" claim. We'll file that away and revisit this point later.
Initialization and Initial File Recovery Attempts
Again, we decided to hold off on any "surgical intervention" and focus on the software side first. We entered the default PIN, activated the drive, and accessed its contents.
For our test, I prepared a set of files to write to the drive for a subsequent recovery attempt ☺
I also calculated their integrity checksums to be certain of the results.
After writing the data, we entered an incorrect PIN 10 times in a row, triggering the factory reset. We then formatted the drive to FAT32, following the manufacturer's instructions — a necessary step for the OS to recognize it.
Then, we followed the standard procedure: running PhotoRec from the TestDisk suite to attempt data recovery.
The initial haul was meager: a single 2 GB Shockwave Flash file. Based on my previous experience recovering data from an encrypted LUKS2 disk, I suspected this was a false positive — the software had found a file we never wrote to the media.
This brought to mind my former manager's advice: "Stop thinking, start doing. You can analyze it later!" So, I decided to run a few basic verification tests.
First, I calculated the hash of the recovered file and compared it with the hashes of our original test files. As expected, it was a miss.
Okay, I tried a different approach: extracting readable strings from the file using the strings utility.
I then searched for any of those strings in our original test files.
Another miss. At this point, a wild idea for an attack scenario came to me (big thanks to my colleague Alexey Trofimov — Lead Specialist in Bastion's Mobile and Web Application Security Analysis group — for the help).
A Lesson in Repetition
Recalling the old Russian adage, "Pushkin is our everything" — which essentially means when in doubt, turn to the classics — I downloaded the poet's collected works and saved them as a plain text file. I chose the TXT format because it looks the same in applications as it does in its raw form.
I then copied this file onto the flash drive, filling it to the brim with duplicates.
An interesting thing happened: only 16,383 files were written to the drive, totaling about 16 GB. But what about the other half of the drive's capacity? The cp command reported no space left, yet the file explorer showed 13.5 GB free.
Windows, by the way, reported the same.
However, if we wrote 7-8 files of around 4 GB each, the entire drive would fill up. This meant the number of files was capped at just over 16,000. As it turned out, this is a limitation of the FAT32 format (a problem that exFAT, for instance, doesn't have).
We again triggered a factory reset with 10 incorrect PINs and attempted data recovery — and again, came up empty.
Could it be that not a single one of the 16,000 files was recoverable?
We looked at the raw data.
There was something there, but it was mostly incoherent strings of characters.
Just in case, we ran the drive's image through the strings utility one more time.
This time, we found multiple repetitions of the same text. Now that was something we could work with. But let's not get ahead of ourselves.
I hadn't created a snapshot of the "Pushkin" flash drive before the reset, so I had to start over. I reset the secure USB drive by entering 10 incorrect PINs and then copied the same file of Pushkin's collected works onto it, resulting in the same 16,383 duplicate files plus the original.
After that, I took a full snapshot of the drive using the dd command:
sudo dd if=/dev/sda of=pushkin_full.img
Then, I reset the drive again with 10 incorrect PINs. To avoid losing data and to speed things up, I also took a snapshot of the re-encrypted drive, naming it pushkin_full_recrypt.img.
I searched for repetitions one more time.
Bingo! All 16,384 files were present, although their content had turned into what looked like gibberish.
Identifying the Encryption Method
So, I had repeating data blocks and their storage addresses. The next step was to compare this with the original, unencrypted version.
Unfortunately, the original Russian text (in UTF-8) was rendered as dots, so I had to find Latin characters within the text to use for comparison.
The files were indeed still in place.
What did this mean, and what encryption algorithm was at play?
Let's review the facts. I had at least three (out of 16,384) identical blocks of ciphertext that corresponded to identical blocks of plaintext at different offsets in the original file: cipher(offset_1) = cipher(offset_2) = cipher(offset_3).
This immediately ruled out stream ciphers like ChaCha20 and RC4, which use a continuous keystream that ensures the same plaintext encrypts to different ciphertext at different locations.
AES modes like CTR, GCM, and XTS were also out of the question, as they use a counter or nonce to guarantee unique ciphertext for identical plaintext blocks at different offsets.
The process of elimination pointed directly to a block cipher in Electronic Codebook (ECB) mode (AES-ECB or a similar scheme). Its defining characteristic is that identical plaintext blocks produce identical ciphertext blocks, as it uses no Initialization Vector (IV), nonce, or counter — just pure block-for-block substitution. It seemed I was dealing with AES-256 in ECB mode, using a 32-byte key.
If the key was properly generated from 256 random bits, extracting it from a known plaintext → ciphertext pair would be virtually impossible, as AES is secure against known-plaintext attacks. In practice, however, keys are often derived from a password or a weak generation procedure, making them vulnerable to brute-force, dictionary attacks, or by testing hypotheses about the Key Derivation Function (KDF). That said, my attempts to brute-force the key on this flash drive yielded no results. In this respect, the device was a tough nut to crack.
Data Recovery
AES-256 encryption in ECB mode is vulnerable, making it possible to recover files.
To demonstrate this, I created several large BMP images featuring a white background and three multicolored geometric shapes — an abstract composition reminiscent of Malevich and Kandinsky. As shown in the screenshot, one such image is 21.5 MB.
Next, I zeroed out the first 100 MB of the flash drive to create a clean slate, separating my test files from any residual data:
sudo dd if=/dev/zero of=/dev/sda bs=1M count=100
I verified the operation was successful with hexdump -C /dev/sda | head.
As shown, the drive sectors from 00000000 to 06400000 are now completely filled with zeros.
After preparing the drive, I began writing the test files sequentially, starting after the 100 MB mark. To clearly demarcate the files, I inserted a 1 MB block of zeros between each one. Performing this manually would be tedious, so I wrote a bash script to automate the process:
#!/bin/bash DEVICE="/dev/sda" offset=100 # starting offset in MB files=( "1.bmp" "1.png" "secret72_1.bmp" "secret72_1.png" "secret72_2.bmp" "secret72_2.png" ) # --- Write files --- for f in "${files[@]}"; do echo " Writing 1 MB of zeros before $f" sudo dd if=/dev/zero of="$DEVICE" bs=1M seek=$offset count=1 conv=notrunc offset=$((offset+1)) size_mb=$(du -m "$f" | cut -f1) echo "Writing file $f, size $size_mb MB" sudo dd if="$f" of="$DEVICE" bs=1M seek=$offset conv=notrunc offset=$((offset+size_mb)) done # --- Write zeros to the end of the disk --- echo " Writing zeros to the end of the disk, starting from offset ${offset} MB" sudo dd if=/dev/zero of="$DEVICE" bs=1M seek=$offset conv=notrunc echo "Done."
After running the script, the files look like to be written to their designated offsets, and the remainder of the drive was zeroed out from the 199 MB mark onward.
A quick check of the raw data confirmed that everything was laid out as planned.
To preserve the drive's current state for later comparison, I dumped the first 250 MB into a binary file:
sudo dd if=/dev/sda of=clean_first_250MB.bin bs=1M count=250 status=progress
The process looks completed without any data loss.
Next, I reset the drive to its factory settings by entering an incorrect PIN 10 times. An audible beep confirmed that the data was "erased" and the PIN was reset to the default. After entering the factory PIN (1122334) and mounting the drive, I examined the raw data again.
As expected, it was all encrypted gibberish. Here, however, the repeating patterns in the ciphertext were duplicated as expected, just like in the unencrypted data.
I dumped the same 250 MB from the encrypted drive:
sudo dd if=/dev/sda of=crypted_first_250MB.bin bs=1M count=250 status=progress
The next step was to carefully extract the files from this drive image without losing a single byte. This was straightforward, as I had the original files and knew their exact sizes. To simplify the task, I wrote another bash script:
#!/bin/bash DEVICE="crypted_first_250MB.bin" offset=100 # starting offset in MB files=( "1.bmp" "1.png" "secret72_1.bmp" "secret72_1.png" "secret72_2.bmp" "secret72_2.png" ) echo " Restoring files from device $DEVICE" for f in "${files[@]}"; do offset=$((offset+1)) # skip the 1 MB of zeros before the file size_mb=$(du -m "$f" | cut -f1) echo " Extracting $f: offset=${offset} MB, size=${size_mb} MB" sudo dd if="$DEVICE" of="restored_$f" bs=1M skip=$offset count=$size_mb status=progress offset=$((offset+size_mb)) done echo "Done. Files restored with the prefix restored_."
After running the script,
the files were restored, but I couldn't view them. I opened them in hexedit to see what might be wrong.
It became clear why I couldn't view the image: the file header was garbled instead of containing the correct format identifier. I corrected the header of the restored file to the proper BMP signature.
Finally, I tried opening the restored file.
Amazingly, my 'abstract' image was recovered! Some of the colors even matched the original. What about the other restored file, the one that was supposed to contain text?
It also recovered perfectly.
This led to my first major conclusion: the manufacturer's claim that resetting the drive 'erases' the data is misleading. In reality, the data remains in place; only the encryption key is changed. As my research demonstrates, the data is recoverable, at least in part.
This type of vulnerability, by the way, is eligible for a CVE identifier. For instance, a Verbatim flash drive with a similar insecure design led German researchers to successfully register a CVE in the international NIST database. I decided to follow their example and submitted my findings as well:
Returning to my experiments, they were conducted in a controlled lab environment where I knew exactly what to look for and where. But how would this play out in a real-world scenario, 'in the wild'? Challenge accepted. The next step is to write an analysis tool.
I'll use my favorite tool, a bash script, to write the following code:
#!/usr/bin/env bash set -e DUMP="$1" shift if [[ -z "$DUMP" || ! -f "$DUMP" ]]; then echo "Usage: $0 dump.bin [width1 width2 ...]" exit 1 fi DUMP_SIZE=$(stat -c%s "$DUMP") MAX_CHUNK=$((20*1024*1024)) # 20 MB WIDTHS=("$@") [[ ${#WIDTHS[@]} -eq 0 ]] && WIDTHS=(640 760 1000 1024 1500 2000 2480 3000 3328) # little-endian helpers le16() { printf "%04x" "$1" | tac -rs .. | xxd -r -p } le32() { printf "%08x" "$1" | tac -rs .. | xxd -r -p } for WIDTH in "${WIDTHS[@]}"; do BYTES_PER_PIXEL=3 ROW_RAW_SIZE=$((WIDTH * BYTES_PER_PIXEL)) ROW_PAD=$(( (4 - (ROW_RAW_SIZE % 4)) % 4 )) ROW_SIZE=$((ROW_RAW_SIZE + ROW_PAD)) echo "[*] WIDTH = $WIDTH" OFFSET_BYTES=0 PART=1 while [[ $OFFSET_BYTES -lt $DUMP_SIZE ]]; do MAX_ROWS=$((MAX_CHUNK / ROW_SIZE)) REMAIN_BYTES=$((DUMP_SIZE - OFFSET_BYTES)) REMAIN_ROWS=$((REMAIN_BYTES / ROW_SIZE)) HEIGHT=$(( REMAIN_ROWS < MAX_ROWS ? REMAIN_ROWS : MAX_ROWS )) [[ $HEIGHT -le 0 ]] && break IMAGE_SIZE=$((ROW_SIZE * HEIGHT)) FILE_SIZE=$((54 + IMAGE_SIZE)) OUT="out_${WIDTH}px_part${PART}.bmp" echo " -> $OUT (${WIDTH}x${HEIGHT})" SKIP_BLOCKS=$((OFFSET_BYTES / ROW_SIZE)) { # BITMAPFILEHEADER printf "BM" le32 "$FILE_SIZE" le16 0 le16 0 le32 54 # BITMAPINFOHEADER le32 40 le32 "$WIDTH" le32 "$HEIGHT" le16 1 le16 24 le32 0 le32 "$IMAGE_SIZE" le32 2835 le32 2835 le32 0 le32 0 # PIXELS dd if="$DUMP" bs="$ROW_SIZE" skip="$SKIP_BLOCKS" count="$HEIGHT" status=none } > "$OUT" OFFSET_BYTES=$((OFFSET_BYTES + HEIGHT * ROW_SIZE)) PART=$((PART + 1)) done done
Let me explain how the script works in more detail. We provide an encrypted region as an argument, which can be either a binary file or a raw device like /dev/sda. The script divides it into 20-megabyte chunks, then replaces the header of the resulting pieces with a BMP header. It also specifies the image width in the header (I set default values of 640, 760, 1000, 1024, 1500, 2000, 2480, 3000, and 3328) and saves the output.
After this initial brute-force search, you can input a more precise width for the encrypted region.
Next, I'll run it on the previously prepared data region.
Great, the files have been generated and saved. Now for the most challenging part: reviewing all the files. If we were dealing with actual 100+ gigabyte drives, this would be quite a quest.
And here's the first hit. In part 8 (160–180 megabytes from the start of the disk) of the file with a width of 2480 pixels, words and numbers are visible. This means we've found approximately the correct width. Now, we'll try to pinpoint the exact value, which our script is designed to do.
And here's another hit: part 6 (120–140 megabytes from the start of the drive) of the file with a width of 3328 pixels.
In short, even 'in the wild,' the crypto flash drive under investigation stands no chance against this type of attack. Admittedly, in a real-world scenario, one would have to spend more time writing analysis programs, but the data is ultimately recoverable.
If you'd like to try it yourself, here is a link to the files.
Dissecting the Device
With the non-invasive analysis complete, it's time for some "surgical intervention". First, we remove the screws and open the case.
After removing three more screws, we can completely separate the PCB from the enclosure.
What do we have here? A battery to maintain power, a controller, a memory chip, some supporting circuitry, and a speaker. The lack of any anti-tamper mechanisms is immediately noticeable. And, as our testing confirmed, the drive continues to function even with the case open.
Examining the Chips
The controller chip, an i560-N200C, is a System on Chip (SoC) — essentially a mini-computer with a CPU, RAM, and other features, including encryption. Its datasheet lists the supported encryption technologies:
On the list, we find our "old friend": AES-256 in ECB mode. This raises the question: if the chip supports stronger encryption modes, why didn't the manufacturer implement them? Anyway, let's move on.
The chip has UART, JTAG, and other debug interfaces. We were happy to see that the UART pins are broken out to dedicated test pads on the PCB. Without delay, we grab our PCBite Probes and connect to the UART interface.
We fire up Logic 2 and begin interacting with the drive.
We set a standard baud rate of 115200. Upon power-on, it outputs a log message confirming the eMMC flash is detected. Entering the correct password yields a cryptic pressed fun message, while an incorrect one outputs password error: 2. Unfortunately, the UART interface doesn't provide any more detailed information.
I tested what would happen if I cut the power after several incorrect password attempts. It turns out the count of failed attempts is stored in non-volatile memory. If you disconnect the battery, wait a couple of minutes for any capacitors to discharge, and then power it back on, the countdown continues from where it left off. So, we'll give the manufacturer a plus for this security feature.
Now, let's take a look at the memory chip. It's a 32 GB BGA153 chip from MMY, model G1DH07DA-301.
Nothing unusual or particularly noteworthy here.
Swapping the Brains
One attack methodology for flash drives involves swapping the controller chip with another from the same batch to gain access. So, let's give it a shot, especially since we have an identical flash drive on hand.
We'll write different data and files and set different hardware passwords on each USB drive. Then, we'll try swapping the SOC chips, hoping the data will be readable. The chances of this attack succeeding are slim, but the urge to solder is stronger than dry theory.
First, we'll wrap the drives in Kapton tape to avoid accidentally melting or blowing off any components with the hot air gun.
Next, we desolder the SOC from both flash drives.
We then swap the chips and solder them onto the respective boards.
And we've already hit our first snag: I completely forgot about the plastic buttons on the back of the PCB, and they melted slightly — even the Kapton tape couldn't save them. Oh well, we're after the data, not a pristine-looking device...
Drumroll, please! We power on the first flash drive, enter the password from the second one, and... the hardware password is accepted! This confirms that the password is indeed stored on the SOC. We plug the USB drive into the computer.
The system detects it as /dev/sda, but the filesystem is not recognized. Running the strings command on the raw device yields gibberish, as expected.
Essentially, this attack achieved the same result as a factory reset after 10 incorrect password attempts. Just in case, I created a full dump of the drive using dd for later analysis.
The Final Test
Our "Patient #1" had already been thoroughly dissected; the only remaining step was to desolder the flash memory chip and attempt a direct data extraction. One might ask: why resort to such drastic measures? The reason is that the crypto flash drive operates on a simple principle: without the correct hardware password, the drive is invisible to the computer. The SOC essentially functions as a gatekeeper: a correct password allows data to flow, while an incorrect one blocks it entirely.
Furthermore, there was a possibility that the data on the chip was stored in a raw format, different from what the strings utility would display — it could even be unencrypted. Consequently, this attack vector was worth exploring.
Time to get to work. We desoldered the flash memory from the PCB.
As previously noted, the chip uses a BGA153 package.
The next step was to use an adapter with our XGecu programmer, but the required one wasn't in my arsenal.
A quick trip to a Chinese online marketplace and $40 later, I had the necessary adapter.
However, it turned out that the XGecu programmer lacked official support for this specific chip. Fortunately, the adapter featured a universal reader function, "Auto EMMC," which offered a slim hope of success.
The adapter finally arrived, bringing the moment of truth. Unfortunately, the attempt to read data directly from the flash memory was unsuccessful — the data was encrypted. This earned the device another plus for its security.
Patient #2: A $150 Made-in-Russia Flash Drive
Next on the bench was a flash drive from a different Russian radio-electronics manufacturer, this one being an order of magnitude more expensive.
Initial Inspection of Patient #2
The drive feels quite hefty, constructed from a solid, dense material that gives it a reliable and secure appearance. The sturdy cardboard packaging further enhances its premium feel. Of course, one doesn't purchase a crypto flash drive for its packaging, so let's proceed to the more critical aspects.
This USB drive also included a manual. However, it was an abridged version; the full manual was only accessible by scanning a QR code. This was presumably the manufacturer's attempt at being eco-conscious (or simply a cost-saving measure on paper).
Initialization and Initial File Recovery Attempts
We begin with initialization. After entering the code and inserting the flash drive, the system fails to detect it. A quick format to NTFS resolves the issue, and the drive is successfully initialized.
First, I checked for any leftover files on the media.
Finding nothing of interest, I proceeded to the next step.
So, it was time to bring in Pushkin again
Following our standard procedure, I wrote several thousand copies of his collected works onto the drive to identify the encryption format.
After rebooting the drive, the result was as expected: the device uses the same insecure AES-256-ECB encryption as the previous one.
I will not detail the subsequent steps, as the procedure is identical to the one used for the previous flash drive. Suffice it to say, the data was successfully recovered.
Moving on to the hardware analysis
At first glance, our "patient" appeared to be tamper-resistant, as all parts of the casing fit snugly together with no visible screws.
However, the enclosure opened with surprising ease. I rested the wide part of the case near the USB connector on a table and applied gentle pressure to the lanyard hole with a flathead screwdriver. The cover slid right off.
A Look Inside
Inside, I found a battery, an SD card (unexpectedly), and the familiar i560-N200C control chip from the previous model. I started by removing the SD card to examine its contents, which turned out to be encrypted.
I removed the silicone keypad to see what was on the other side of the board.
To my surprise, I found an additional chip and six more unpopulated pins on the board (spoiler: they will come in handy soon).
First, I examined the newly discovered chip under a microscope.
It was an STC 8G2K64S4, an 8-bit microcontroller based on a high-speed 8051 core, designed for electronic control applications. A full description of the microchip and its datasheet can be found at the following link.
Attempting to Read the Chip
After studying the datasheet and carefully examining the board layout, I located the UART contacts and connected a logic analyzer using PCBite probes.
After powering on the flash drive, data began streaming to the RX contact; some of it was readable, but part of it was garbled. Strangely, not all the characters could be decoded.
To speed up the process, I used an AI for assistance, but the result was somewhat surprising.
Never mind that the data on a Russian flash drive was in Chinese. The most concerning part was the last phrase: "version with extended password / additional password mode." This typically implies the existence of a master password and an administrator mode. This suggests the manufacturer could have embedded a backdoor, with all the attendant security implications. We were unable to verify this, so we cannot state it with certainty.
Unfortunately, no additional information could be obtained via the UART, even after connecting an RS232 adapter and inputting various commands and combinations.
However, the device's documentation states that interacting with and reflashing the chip requires special software — the STC ISP Tool, which can be found with a quick online search.
Unfortunately, this glimmer of hope quickly faded, as installing and running the program yielded no useful information.
The STC bootloader does not provide commands such as "read flash," "read EEPROM," or "memory dump." Its functionality is limited to uploading new code to the microcontroller and reading its UID and clocking parameters.
However, the documentation offered another clue: several additional RX/TX contacts. I decided to connect to them …
… and was met with another surprise. After powering on the flash drive, every keypress on the device's keypad produced a response, each one different from the last. I was unable to determine the correct baud rate and other UART parameters required to decode the data correctly. For reference, the total signal duration was 36.916 milliseconds, with a minimum pulse width of 2.75 milliseconds.
I captured all keypress combinations (from 1 to 0) and saved them in the Saleae Logic 2 format, which is available for download via the provided Google Drive link.
An interesting observation: pressing the "1," "9," and "0" keys caused a continuous signal to be transmitted until the key was released, instead of a single pulse. The functions for the "1" and "0" keys are documented in the manual (for changing the main password and the data-wiping password, respectively). The manual, however, contained no information about the "9" key. This again raised the suspicion of a possible master password.
Furthermore, this vulnerability opens up the possibility of installing a keylogger as a hardware implant. While space is limited, a skilled attacker could feasibly install a device to record the user's PIN code.
Patient #3: Kingston IronKey Keypad 200
Finally, I shifted my focus from Russian devices to examine an encrypted flash drive from the well-known American manufacturer, Kingston Technology.
The packaging states that the drive is FIPS 140-3 compliant and uses AES-256-XTS encryption.
Moreover, the vendor boldly claims the drive meets Level 3 certification requirements, which include protection against physical tampering, side-channel attacks, and key erasure upon device intrusion.
As the saying goes, "trust, but verify."
Attempting to Extract Files
After initializing the drive, I connected it to a USB port, mounted the file system, and inspected its contents to see what files could be extracted.
The manual, available in both full and condensed versions, explains that the drive supports both a user password and an admin/master password; the latter is not set by default but can be used to regain access if the user password is forgotten. Notably, the device displays a specific notification regarding the admin password — a feature absent in the previously examined drive. The drive is also designed to perform a factory reset after 10 incorrect password attempts.
Following my standard procedure, I checked the drive for extractable files and found nothing beyond those already mentioned.
Verifying the Encryption Methods
It was time to verify if the device actually uses the claimed encryption rather than the vulnerable AES-256-ECB. For the umpteenth time, I took our collected works of Pushkin and wrote the file 5,000 times to the drive — a process that had become routine.
Next, I followed the established procedure: reset the drive to its default settings after 10 incorrect password entries, set a new password, and connected it.
This time, to my surprise, there were absolutely NO repeating patterns.
A single manly tear almost rolled down my cheek: could it be that at least one of the devices I've tested has reliable (or at least not-so-shoddy) security?
Unfortunately, it's impossible to be 100% certain that the flash drive uses AES-256-XTS with only the gibberish from a hexdump in hand. The ciphertext of AES-XTS — like any modern, correctly implemented cipher — looks like cryptographically random noise; it has no repeating patterns, signatures, headers, or "magic bytes". It is statistically indistinguishable from random data.
The algorithm can only be verified using indirect indicators, such as entropy.
Here, we see the maximum possible entropy of 8.0 (across 15 gigabytes), a value that strongly indicates the use of AES-XTS. In turn, the optimum compression is 0%, meaning the data is incompressible, which is also consistent with AES-XTS.
Other indicators also indirectly confirm the use of the claimed encryption, but the key word here is "indirectly".
Disassembling the Device
Disassembling the device proved to be quite a puzzle. At one point, I even thought the casing was glued from the inside and futilely attempted to melt the adhesive.
When gentle methods failed, I switched to "Hulk mode." I started by cracking the plastic near the USB port to free up at least one side. Then, with a little effort, I pulled on the lanyard loop, and things finally started moving.
Reptilian-Proofing
To my surprise, the device's internals were wrapped in gold-colored foil.
The comparison to tinfoil hats, which supposedly stop aliens from reading minds, is unavoidable. However, in this case, the foil isn't protecting data from reptilians but from side-channel and electromagnetic leakage, as required by the FIPS standard. The foil on the circuit board is intended to minimize these emissions.
Stripping the Drive Bare
I carefully peeled back the foil... only to be met with another surprise. The entire board was potted in epoxy — not just a single IC or memory chip, but the whole thing. So this is what regulatory compliance looks like in the wild.
With no other choice, I proceeded to remove the protective coating. The main challenge was to avoid accidentally scraping off SMD components along with the epoxy. Since I didn't have any nitric acid on hand, I had to resort to physical brute force with a flathead screwdriver.
A few components came off with the epoxy, but the drive surprisingly kept working — I must have knocked off some non-essential pull-up/pull-down resistors.
Examining the Chip
The BGA memory chip also came off the board, making it impossible to examine how the data was stored at rest. The controller chip, however, proved more resilient; it continued to accept the correct password and differentiate between the right and wrong PIN.
It was a PHISON PS2251-13-Q. A Google search for the chip model yielded an interesting result. It turns out that in 2021, researchers Sergey Skorobogatov and Olga Larina had already thoroughly analyzed a line of Kingston crypto flash drives, even conducting an X-ray examination.
The overall conclusion of their research was that while the product line is generally well-secured, it is vulnerable to NAND mirroring attacks, a method used to bypass password attempt limits. This technique involves making a bit-for-bit copy of the entire flash memory to enable offline brute-forcing of the password.
Conclusion
We tested a total of five devices across a wide price range. This article deliberately focuses on only three of them, as many of the flash drives share similar strengths and weaknesses, appearing as if they were cookie-cutter copies of one another. None of the tested crypto flash drives from Russian manufacturers can boast robust security. They all use the obsolete and insecure AES-256-ECB encryption mode and share the same i560-N200C controller chip — which, notably, is capable of supporting stronger, more resilient encryption methods.
These Russian-made drives are not potted in epoxy resin and lack any anti-tampering mechanisms. Some even use a standard SD card instead of a BGA chip, making it possible to remove the card, dump its entire memory, and reinstall it without leaving any visible external evidence or logs on the controller chip.
This is despite the fact that most of the tested devices contain all the necessary basic components: a metal casing, a controller chip (albeit a Chinese one) that supports AES-256-XTS, BGA NAND chips, and more. All that is needed is to reconfigure the i560-N200C controller to use proper encryption, pot the internals in epoxy, wrap them in foil, and weld the casing shut. These changes would not significantly impact the production cost but would increase security exponentially.
Their foreign counterparts are not without flaws either, but they generally uphold high security standards in practice, not just on paper. Frankly, it's disappointing to see the state of domestic products.
This review does not claim to be the final word on the matter. For instance, I was unable to investigate the i560-N200C controller, as I lacked the necessary adapter for my chip programmer. If any readers have experience with this chip, I encourage you to share your insights in the comments.
At first glance, purchasing these devices seems like a waste of money. The expensive flash drives, priced at $150–$200, do not differ in design or components from those costing around $20. If there's no real difference, why pay a premium for the brand?
P.S. For the truly budget-conscious, there's even a $2 option:
If this article gets 100,000 likes, we'll review it on Habr. ☺
I'd also like to invite you to my Telegram channel (in Russian), where you'll find plenty of interesting content on reverse engineering: http://t.me/glinkinivan
