Mask off: analyzing a secure SD card

Mask off: analyzing a secure SD card

Speakers: Nicolas Oberli, Security Researcher

Conference: Area41

YouTube: https://www.youtube.com/watch?v=yhvwUOrecxA

Overview

In this compelling talk at Area41, security researcher Nicolas Oberli dissects the security claims of the Flexxon X-Mask SD card, a product marketed as offering robust data protection through password authentication and encryption. Oberli's investigation, driven by an inherent curiosity for hardware security and prior work on SD card vulnerabilities, systematically dismantles these claims, revealing a product with fundamental security flaws. The talk highlights the critical disconnect between advertised security features and their actual implementation, exposing a system that relies on easily bypassed mechanisms rather than genuine cryptographic strength.

Oberli’s research provides a detailed technical walkthrough of how the X-Mask card’s "security" functions, or rather, fails to function. He uncovers multiple critical vulnerabilities, including a steganographic encoding scheme masquerading as encryption, a complete bypass of the password protection mechanism, and a cleartext password leak for the original X-Mask version. Beyond the technical exploits, the presentation also serves as a stark reminder of the challenges researchers face in responsible disclosure when vendors are unresponsive or lack proper security contact channels. This talk is essential viewing for anyone interested in hardware security, embedded systems, or the often-misleading nature of product marketing in the cybersecurity space.

Background

▶ Watch: Introduction and X-Mask SD card security claims (0:00)

SD cards, standing for Secure Digital cards, have been a ubiquitous storage medium for over two decades. Initially designed for portable devices, their evolution has seen various formats (SD, SDHC, SDXC, SDUC) and form factors (standard SD, miniSD, microSD). Communication with SD cards primarily occurs via two modes: SPI (Serial Peripheral Interface) for microcontrollers and the more common SD bus protocol. Newer cards also support SD Express, utilizing PCI Express for higher data transfer rates. The SD bus protocol, shared with eMMC devices, uses a minimum of three signals: a clock for synchronization, a CMD (command) line, and at least one data line (D0), potentially expanding to four or eight data lines (D0-D3).

The SD standard defines a set of 64 commands (CMD0 to CMD63), each with a 6-bit ID and an optional 32-bit argument. Data transfer is structured around 512-byte blocks, which cannot be altered. Common commands include CMD17 for reading a block and CMD24 for writing a block. The host sends a command, the card replies with a status, and then data blocks may be transferred, all protected by a CRC (Cyclic Redundancy Check). Crucially, the SD standard itself includes a basic password protection feature via CMD42 (Lock/Unlock Card). Previous research, notably a talk at Hardware.io seven years prior, demonstrated a timing attack against this standard CMD42, allowing byte-by-byte brute-forcing due to a lack of lockout policies. This prior work by Oberli himself served as a catalyst for investigating the Flexxon X-Mask, which promised enhanced, proprietary password protection. The Flexxon X-Mask card makes bold claims, including "hidden card" functionality, "data encryption," and protection against "side channel attacks and potential hackers" who "cannot crack the passcode for non-standardization." These assertions formed the primary target for Oberli's analysis.

Key Findings

▶ Watch: Analysis methodology: Hardware vs. Software sniffing (6:00)

Nicolas Oberli's analysis of the Flexxon X-Mask SD card revealed a series of significant security vulnerabilities that fundamentally undermine the product's advertised protection. These findings expose a stark contrast between marketing claims and actual security implementation.

1. Steganographic Encoding, Not Encryption: The core mechanism for protecting data and transmitting passwords was found to be a rudimentary steganographic bit-fusing scheme, not actual encryption. The software encodes password information by subtly modifying specific bits within an output buffer, appearing as random data to an uninformed observer. The Mersenne twister random number generator used by the host software was irrelevant to the card's security, as its seed (based on host time) was never transmitted, meaning the "randomness" was purely cosmetic from the card's perspective. This design choice means that data is not cryptographically protected in transit or at rest in the manner typically associated with "data encryption."

1. Password Protection Bypass (CMD9 Vulnerability): Oberli discovered a critical "vendor command" (accessed by writing to block address 9) that allows an attacker to control the start address of the password-protected region. By setting this value to FFFFFFFF (the maximum 32-bit unsigned integer), the attacker can effectively move the protection boundary beyond the card's physical capacity. This renders the entire card readable and writable without ever needing to know or provide the password. This bypass is persistent, meaning once applied, the card remains unlocked even after removal and reinsertion, unless explicitly reset.

1. Cleartext Password Leak: Through systematic fuzzing of vendor command block addresses, Oberli identified a specific block (found around block 92, though not fixed) that, when read in command mode, directly reveals the user's password in cleartext. This vulnerability allows an attacker to retrieve the password from a locked card without any authentication, completely negating the password protection. This specific leak was demonstrated on the original X-Mask cards but was not found on the newer X-Mask Pro version within the scope of the talk.

1. Applicability to X-Mask Pro: The password protection bypass (CMD9 vulnerability) was confirmed to also affect the newer, more expensive Flexxon X-Mask Pro cards. This indicates that the fundamental design flaws persist across product revisions, at least for this particular bypass.

1. Vendor Disclosure Failure: Despite multiple attempts to contact Flexxon through their website, email addresses, and even a chatbot over several months, Oberli received no response regarding the vulnerabilities. This highlights a significant lack of a proper security contact and vulnerability disclosure process for a company selling "cybersecurity" products, leaving users exposed and demonstrating irresponsible vendor behavior.

In summary, the Flexxon X-Mask SD card, despite its robust marketing, fails to provide any meaningful security. Its "protection" mechanisms are easily defeated, exposing user data and passwords through simple, unauthenticated commands.

Technical Deep Dive

▶ Watch: Vulnerability: Bypassing protection by setting start address (14:40)

Oberli’s technical investigation began with an attempt to observe the communication between the host PC and the Flexxon X-Mask SD card. His initial approach involved hardware analysis using a logic analyzer. He custom-built an SD card extender and later purchased a commercial one from AliExpress. However, this method proved challenging due to the continuous background commands sent by Windows (e.g., to check card presence), making it difficult to set a precise trigger. Furthermore, the limited memory of typical logic analyzers restricted captures to only a few seconds, which was insufficient for comprehensive analysis.

Switching to a software-based approach, Oberli utilized usbmon, a Linux kernel module for sniffing USB traffic, in conjunction with Wireshark. This setup involved plugging a USB SD card reader into a Linux machine, running a Windows VM with the Flexxon tool, and mounting the USB drive within the VM. This allowed for unlimited capture of USB packets, including all SD card commands and data transfers. By performing actions like setting a password, locking, and unlocking the card, Oberli gathered extensive data on the card’s behavior.

Analysis of the Wireshark captures revealed a specific sequence of operations when setting a password:

1. Write to block zero.
2. Read block five twice.
3. Write random data to block eight.
4. Write fixed data to block zero.

When entering a password, the only change observed was writing random data to a different block (block six). This led to the hypothesis that the initial write to block zero might initiate a "vendor command mode." The subsequent reads from block five were speculated to be a challenge from the card, and the writes to block eight (for setting a password) or block six (for authentication) were interpreted as the host sending an encoded payload (the password) to the card. A crucial observation was that specific block addresses were being used as "commands" within this vendor mode (e.g., writing to block 8 to set a password, writing to block 6 to authenticate).

To understand the payload encoding, Oberli turned to reverse engineering the Flexxon Windows tool using Ghidra. He identified a C++ function responsible for taking the password and the challenge data (from block five) and constructing the 512-byte buffer sent to the card. Inside this function, he found that it first initializes a Mersenne twister pseudo-random number generator, seeded by the host's system time. Critically, this seed (and thus the "randomness") is never transmitted to the card. This immediately raised suspicions about the claim of "data encryption."

The actual encoding process was revealed to be a form of steganography or bit-fusing:

1. The function reads the challenge packet, verifies a header, and extracts two bytes from fixed offsets.
2. These two bytes are added to form an offset within the packet, pointing to 8 bytes of "key" data.
3. The first byte of this 8-byte key acts as an offset, and the three least significant bits of the subsequent bytes provide a value between 0 and 7.
4. The password argument is converted into a bit array (most significant bit first).
5. The 8-byte key is converted into 64 bits (least significant bit first).
6. For each bit of the 64-bit key, four bits of the password argument are processed: if the key bit is zero, the four password bits are inverted; if one, they remain unchanged.
7. Finally, this encoded argument is used to modify a 512-byte output buffer, bit by bit. Specifically, one bit of each byte in the output buffer is set at the position determined by the 0-7 value derived from the key.

This elaborate process, rather than encrypting data, merely hides the password within the output buffer by manipulating specific bits. The "randomness" from the Mersenne twister was found to be a distraction, as a buffer of all zeros could achieve the same result for the card, simply by setting the required bits.

With the encoding algorithm understood, Oberli used HydraBus, a hardware hacking tool he co-develops, to interact with the SD card. HydraBus allowed for precise control over the commands sent to the card, bypassing the complexities of an operating system. He re-implemented the encoding algorithm in Python, integrated it with HydraBus, and successfully authenticated to the card using a known password ("123456"). This confirmed the understanding of the encoding mechanism and established a platform for further testing.

Demo / Proof of Concept

▶ Watch: Vulnerability: Retrieving plaintext password from card (18:00)

Nicolas Oberli provided compelling demonstrations of the vulnerabilities he discovered, leveraging his custom-built tools to interact directly with the Flexxon X-Mask SD card.

The first major proof of concept involved the password protection bypass using the undocumented "vendor command" accessed by writing to block address nine. Oberli demonstrated that this command accepts an argument that defines the starting block address for password protection. By default, this value is zero, meaning all blocks from zero to the end of the card are protected. However, by sending a command to write to block nine with the argument FFFFFFFF (the maximum 32-bit unsigned integer), the protection boundary is effectively moved beyond the card's physical capacity.

In the live demo, Oberli first showed a locked card mounted on his Linux system, attempting to read a specific block (mmcblk0), which returned all FFFFFFFF (empty/protected data). He then executed his custom command-line tool (developed in C, translated from Python using Copilot) with an unlock option. After running the tool, reading the same block now revealed the actual data stored on the card. He emphasized that this state is stored within the card itself; removing and replugging the card would still result in an unlocked state. To re-enable protection, he demonstrated running the tool with a lock option, which presumably resets the protection start address back to zero, causing subsequent reads to return FFFFFFFF again. This demonstrated a persistent and complete bypass of the card's primary security feature without ever knowing the password.

The second critical proof of concept showcased the cleartext password leak. After demonstrating the bypass, Oberli described how he had systematically fuzzed other potential vendor command block addresses by trying to read from them (specifically from block 92 onwards). He discovered that reading from a particular, undocumented block address (the exact number was not fixed as it could vary, but was found by fuzzing) while in "command mode" would return the user's password in cleartext.

He then integrated this finding into his custom tool. With the card still locked, he executed his tool with a --password option. The tool communicated with the card, read the specific block, and instantly displayed the user's password on the terminal. This demonstrated a straightforward, unauthenticated method to extract the password from any original Flexxon X-Mask card.

Oberli also addressed the newer X-Mask Pro cards. He confirmed that the password protection bypass (using the FFFFFFFF block nine trick) also works on the Pro version, requiring only a minor code change in his tool to support it. However, he noted that the cleartext password leak was not found on the Pro version within the blocks he fuzzed, suggesting it might be located at a different address or potentially patched in that specific aspect. The tools used, including the Python scripts and the C command-line utility, are available on GitHub, allowing others to verify and reproduce the findings.

Defensive Implications

▶ Watch: Q&A: Card encryption is not password dependent (23:40)

The findings presented by Nicolas Oberli regarding the Flexxon X-Mask SD cards carry significant defensive implications for both users and manufacturers of "secure" storage solutions.

For users of Flexxon X-Mask SD cards, the primary implication is that the product offers no meaningful security. Despite claims of "data encryption," "hidden card" functionality, and protection against "hackers," the card's password protection can be entirely bypassed, and for the original version, the password itself can be retrieved in cleartext without authentication. Therefore, these cards should not be used for storing any sensitive or confidential data. Users who have relied on these cards for security should immediately migrate their data to truly secure storage solutions and discontinue use of the X-Mask cards for protected information. The advertised security is fundamentally broken, providing a false sense of protection.

For manufacturers of security products, especially those in the hardware and embedded systems space, this talk serves as a critical cautionary tale:

1. Do not make misleading security claims: Exaggerated marketing that promises robust security without actual cryptographic backing is irresponsible and dangerous. Claims of "data encryption" must be supported by genuine, well-implemented cryptographic primitives, not rudimentary steganography.
2. Implement actual security, not obscurity: The reliance on bit-fusing and undocumented "vendor commands" is a classic example of security through obscurity, which is not security at all. Proper security requires transparent, peer-reviewed cryptographic algorithms and protocols.
3. Validate security through independent audit: Products claiming security features should undergo rigorous independent security audits and penetration testing to ensure their claims hold up to scrutiny.
4. Establish a clear vulnerability disclosure process: A company selling security products must have an accessible and responsive channel for security researchers to report vulnerabilities. Flexxon's complete lack of response to multiple disclosure attempts is unacceptable and leaves their customers exposed. A dedicated security contact (e.g., [email protected]) is a fundamental requirement.
5. Consider firmware updates or recalls: For products with fundamental security flaws that cannot be mitigated by users, manufacturers must have a plan for addressing the vulnerabilities, which may include firmware updates (if technically feasible on the device) or product recalls. The inability to update the firmware on an SD card controller makes the situation particularly dire for existing Flexxon X-Mask users.
6. Avoid "software-only" password protection for hardware: The apparent reliance on a simple software-level password check within the controller, rather than robust hardware-backed encryption or authentication, is a critical design flaw. True hardware security often involves secure elements, trusted execution environments, or dedicated cryptographic modules.

In essence, defenders (and product managers) must be highly skeptical of security claims that lack transparent, verifiable cryptographic implementations. This case underscores the importance of a "trust but verify" approach, especially when dealing with proprietary "secure" hardware.

Key Takeaways

Here are the main points from Nicolas Oberli's talk on the Flexxon X-Mask SD card:

• False Sense of Security: The Flexxon X-Mask and X-Mask Pro SD cards, despite being marketed as providing "data encryption" and robust password protection, offer no real security and provide a false sense of protection to users.
• Steganography, Not Encryption: The core "security" mechanism for password and command transmission is a simple steganographic bit-fusing technique, not cryptographic encryption, making it easily reversible and insecure.
• Complete Password Bypass: A critical vulnerability allows attackers to completely bypass the password protection by setting the protected region's start address to FFFFFFFF via an undocumented vendor command (writing to block 9), rendering the entire card readable and writable without authentication. This bypass is persistent across device reboots.
• Cleartext Password Leak: For the original X-Mask cards, the user's password can be retrieved in cleartext by reading a specific, undocumented internal memory block while the card is in command mode, further compromising any perceived security.
• Vendor Disclosure Failure: Flexxon demonstrated a complete lack of a responsible vulnerability disclosure process, failing to respond to multiple contact attempts from the researcher, leaving their customers exposed to known, critical flaws.
• Importance of Verification in Hardware Security: This case highlights the crucial need for independent verification of security claims in hardware products, emphasizing that proprietary "security" often equates to security through obscurity, which is inherently flawed.

About the Speaker(s)

Nicolas Oberli is a dedicated security researcher based in Switzerland, with a particular focus and passion for hardware security. He conducts research for both his professional work and personal interest, demonstrating a deep commitment to exploring the vulnerabilities and intricacies of embedded devices. Beyond his individual research, Oberli is an active member of the cybersecurity community. He is part of the organization team for Black Alps, which is recognized as the third-largest security conference in Switzerland. Furthermore, he contributes to the development of HydraBus, an open-source tool specifically designed to assist hardware hackers in interacting with and analyzing embedded systems. His prior work includes research into vulnerabilities in standard SD card password protection, which directly inspired his investigation into the Flexxon X-Mask card.