On Hacking MicroSD Cards

Today at the Chaos Computer Congress (30C3), xobs and I disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution — on the memory card itself. On the dark side, code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers.

In order to explain the hack, it’s necessary to understand the structure of an SD card. The information here applies to the whole family of “managed flash” devices, including microSD, SD, MMC as well as the eMMC and iNAND devices typically soldered onto the mainboards of smartphones and used to store the OS and other private user data. We also note that similar classes of vulnerabilities exist in related devices, such as USB flash drives and SSDs.

Flash memory is really cheap. So cheap, in fact, that it’s too good to be true. In reality, all flash memory is riddled with defects — without exception. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions. This is the result of a constant arms race between the engineers and mother nature; with every fabrication process shrink, memory becomes cheaper but more unreliable. Likewise, with every generation, the engineers come up with more sophisticated and complicated algorithms to compensate for mother nature’s propensity for entropy and randomness at the atomic scale.

These algorithms are too complicated and too device-specific to be run at the application or OS level, and so it turns out that every flash memory disk ships with a reasonably powerful microcontroller to run a custom set of disk abstraction algorithms. Even the diminutive microSD card contains not one, but at least two chips — a controller, and at least one flash chip (high density cards will stack multiple flash die). You can see some die shots of the inside of microSD cards at a microSD teardown I did a couple years ago.

In our experience, the quality of the flash chip(s) integrated into memory cards varies widely. It can be anything from high-grade factory-new silicon to material with over 80% bad sectors. Those concerned about e-waste may (or may not) be pleased to know that it’s also common for vendors to use recycled flash chips salvaged from discarded parts. Larger vendors will tend to offer more consistent quality, but even the largest players staunchly reserve the right to mix and match flash chips with different controllers, yet sell the assembly as the same part number — a nightmare if you’re dealing with implementation-specific bugs.

The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die. Amazingly, the cost of adding these controllers to the device is probably on the order of $0.15-$0.30, particularly for companies that can fab both the flash memory and the controllers within the same business unit. It’s probably cheaper to add these microcontrollers than to thoroughly test and characterize each flash memory chip, which explains why managed flash devices can be cheaper per bit than raw flash chips, despite the inclusion of a microcontroller.

The downside of all this complexity is that there can be bugs in the hardware abstraction layer, especially since every flash implementation has unique algorithmic requirements, leading to an explosion in the number of hardware abstraction layers that a microcontroller has to potentially handle. The inevitable firmware bugs are now a reality of the flash memory business, and as a result it’s not feasible, particularly for third party controllers, to indelibly burn a static body of code into on-chip ROM.

The crux is that a firmware loading and update mechanism is virtually mandatory, especially for third-party controllers. End users are rarely exposed to this process, since it all happens in the factory, but this doesn’t make the mechanism any less real. In my explorations of the electronics markets in China, I’ve seen shop keepers burning firmware on cards that “expand” the capacity of the card — in other words, they load a firmware that reports the capacity of a card is much larger than the actual available storage. The fact that this is possible at the point of sale means that most likely, the update mechanism is not secured.

In our talk at 30C3, we report our findings exploring a particular microcontroller brand, namely, Appotech and its AX211 and AX215 offerings. We discover a simple “knock” sequence transmitted over manufacturer-reserved commands (namely, CMD63 followed by ‘A’,’P’,’P’,’O’) that drop the controller into a firmware loading mode. At this point, the card will accept the next 512 bytes and run it as code.

From this beachhead, we were able to reverse engineer (via a combination of code analysis and fuzzing) most of the 8051’s function specific registers, enabling us to develop novel applications for the controller, without any access to the manufacturer’s proprietary documentation. Most of this work was done using our open source hardware platform, Novena, and a set of custom flex circuit adapter cards (which, tangentially, lead toward the development of flexible circuit stickers aka chibitronics).

Significantly, the SD command processing is done via a set of interrupt-driven call backs processed by the microcontroller. These callbacks are an ideal location to implement an MITM attack.

It’s as of yet unclear how many other manufacturers leave their firmware updating sequences unsecured. Appotech is a relatively minor player in the SD controller world; there’s a handful of companies that you’ve probably never heard of that produce SD controllers, including Alcor Micro, Skymedi, Phison, SMI, and of course Sandisk and Samsung. Each of them would have different mechanisms and methods for loading and updating their firmwares. However, it’s been previously noted that at least one Samsung eMMC implementation using an ARM instruction set had a bug which required a firmware updater to be pushed to Android devices, indicating yet another potentially promising venue for further discovery.

From the security perspective, our findings indicate that even though memory cards look inert, they run a body of code that can be modified to perform a class of MITM attacks that could be difficult to detect; there is no standard protocol or method to inspect and attest to the contents of the code running on the memory card’s microcontroller. Those in high-risk, high-sensitivity situations should assume that a “secure-erase” of a card is insufficient to guarantee the complete erasure of sensitive data. Therefore, it’s recommended to dispose of memory cards through total physical destruction (e.g., grind it up with a mortar and pestle).

From the DIY and hacker perspective, our findings indicate a potentially interesting source of cheap and powerful microcontrollers for use in simple projects. An Arduino, with its 8-bit 16 MHz microcontroller, will set you back around $20. A microSD card with several gigabytes of memory and a microcontroller with several times the performance could be purchased for a fraction of the price. While SD cards are admittedly I/O-limited, some clever hacking of the microcontroller in an SD card could make for a very economical and compact data logging solution for I2C or SPI-based sensors.

Slides from our talk at 30C3 can be downloaded here, or you can watch the talk on Youtube below.

Team Kosagi would like to extend a special thanks to .mudge for enabling this research through the Cyber Fast Track program.

This entry was posted on Sunday, December 29th, 2013 at 10:43 pm and is filed under Hacking, Made in China. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

Thank you for the talk, it was very interesting to hear about this. At the end you gave away 128MB SD cards with the AX215. What would someone need to do to program this? I would guess open the chip, solder some wires to the testpoints and hook it up to something like a Raspberry PI. Are you interested in making a tutorial for this?

Yes, you could program the MCU with a simpler pass-thru commandset, and make an MTD driver for it.
I imagine you could expand upon this commandset to make SD cards perform thousands of times the normal speed for certain tasks.

It would be awesome if someone made a framework to use a MicroSD card as a general-purpose high-speed microcontroller! We could make thumb-sized robots that are controlled by their onboard Micro-SD card and even recording onboard video to flash storage!

As for cheap microcontrollers: today it’s possible to buy STM32 Cortex M3 for price barely above $1 or so (STM32F104 can go really cheap for low-end model). And that would be 24MHz 32-bit ARM core with load of cool peripheral stuff and so on. Then you can etch PCF using direct toner transfer nearly free of charge, etc. So as for me, $20 for arduino means Atmel and Arduino guys are in mood for really fat margins. In fact Arduino price/fratures and price/computation power ratio is really bad and it only good for real newbies. Those who got idea what is microcontroller can get far better deals…

[…] An SD card isn’t just a dumb chunk of memory; it’s a dumb chunk of memory with a built-in brain, a microcontroller. And at this year’s Chaos Computer Congress, enterprising hackers showed off exactly what those brains can be used for: cheap hardware for makers or malware machines for malcontents. […]

That’s most likely just SDIO (which has been around for years, albeit unpopular)
It’s an official standard. I have yet to hear of anyone hacking a regular SD / uSD card aside from things like setting hardware write-protection bits. Until now, of course. Nice work :)
Can’t wait for a followup.
Some might already know this, but flashdrives work in exactly the same way and seem to use the same vendors for controllers. Specifically, Alcor Micro and Phison have utilities which allow one to do some pretty cool things with most flashdrives, including changing vendor and product IDs as well as strings, partitioning the drive into a normal part and a virtual CD ROM part (often seen in promotional flash drives), or even a hardware encrypted portion (which most controllers support but is off by default), changing LED configuration, the list goes on.
Due to the wide range of controllers, it can often be difficult to find the utility which works, but they’re pretty easy to find. Good chance that the controllers in SD/uSD cards have similar capabilities as only the interface to the host differs. Or maybe that’s just wishful thinking :)

[…] running as firmware that a recent article suggests could be used for man-in-the-middle attacks: http://www.bunniestudios.com/blog/?p=3554 Although the article mentions SD cards, all flash media have microcontrollers embedded in them, and […]

[…] An SD card isn’t just a dumb chunk of memory; it’s a dumb chunk of memory with a built-in brain, a microcontroller. And at this year’s Chaos Computer Congress, enterprising hackers showed off exactly what those brains can be used for: cheap hardware for makers or malware machines for malcontents. […]

I’ve theorised that uSD cards failing due to “user error” ie unwriteable could actually still have useful data on them, so buying cards online as “defective” might be a way to obtain sensitive information.

A lot of 64GB cards are also failing due to apparent unwanted interaction between this chip and the *am*ung *4 /*3 controller so this might be a way to get them working again and even increase reliability.
Some owners of phones are getting through several cards before having to send the phones back as faulty.
Even the *phones are getting the same problem as the 4S is rumoured to be experiencing Flash corruption problems caused by temperature changes when writing which eventually leads to the greyed out WiFi issue and its subsequent temporary fix via controller overheating.

[…] solutions, presenting their findings at the Chaos Computer Congress (30C3). In a detailed blog post on bunnie:studios, Huang explained how the hack works, and why many flash cards are susceptible to […]

Could this mean that someone could reprogram a card to provide unfettered access to the “secure area” of the Flash memory, in order to extract CPRM-protected, or “hidden” data (e.g. the tracks on SlotMusic cards, cards formatted in Windows Phone 7 handsets, or “SD Audio” data generated by some obscure Japanese-market products)?

Also, I guess that nothing stops someone from implementing a “dummy password protect” function in the firmware that leaves the user-specified password unset?

A way around that is to have something like tilt switches. Namely, if a card only has 2GB of storage, it’ll only be able to keep 1GB of encrypted data, otherwise the system writing to the memory would know something’s up when it tries to read it back! XD It’s also possible (read: likely) that Sony uses public-key methods (hash-signing and one-way encryption) just like Nintendo does with their game carts and Sony does with it’s own system updates. If not, guess what’s in the next firmware update, hehe.

The irony is that the updating feature is also sort of a mandatory part of newer DRM’s where they don’t want the patch-once-broken-everywhere effect from protection crackers. The skilled people still can hack the protocols for DRM, but the typical user is not supposed to be able to easily use old exploits like with CSS on DVD’s. I’m not sure if it’s ever actually been used for this purpose, but it might become common in the next generation of SD-compatible hardware thanks to this article.

This is a wonderfully researched investigation. I don’t know why you’re the only one posting about hardware in an accessible and yet in-depth way, Bunnie, but Thank You so much for doing so. Have a happy New Year!

That’s a shame!, it’s goto be the coolest shirt design I have seen ! Thanks for the fascinating and inspirational talk, it was an amazing insight into the underground world of electronics.

In the midst of the talk I kept saying ” this should be a documentary!”. I would have loved to of seen some live footage of the dodgy premises with chickens running around. It’s all so blade runner’esk.

[…] media is crafted through sophisticated error correction and bad block management functions,” Huang explained in a related blogpost. “This is the result of a constant arms race between the engineers and mother nature; with every […]

The ANT division doesn’t just manufacture surveillance hardware. It also develops software for special tasks. The ANT developers have a clear preference for planting their malicious code in so-called BIOS, software located on a computer’s motherboard that is the first thing to load when a computer is turned on. ”

I remember a recent 60 minutes documentary where it was claimed that a mass-scale potential ‘bricking’ involving computer BIOS’s was allegedly prevented by the agency. One wonders what (Swiss-cheese) they have made of uEFI. :(

Scarier part (for security folks) is that you don’t exactly have to be a top-trained computer scientist for the NSA, to exploit hardware – but if you want to get paid legally while doing it, you might. ;)

Various sources claim there are some SD cards that are raw flash arrays and don’t contain a microcontroller with FTL firmware, but instead rely on a host FTL driver. But I haven’t found these mythical beats yet.

What I did find was that the obsolete-but-still-available Olympus/Fujifilm xD cards (16 MiB to 2 GiB) are raw flash and have no microcontroller. Cards and readers are still available for them.

It also appears that Sony Memory Sticks lack controllers. You’d have to use the Memory Stick Pro to get at most 4 GiB.

These can still suffer from the bit rot malady that all flash devices have.

But at least they couldn’t be used for Evil Maid and other malware attacks.

Awesome talk and article! I was a bit bummed to see that some of the second-hand coverage of it, though, propagated some lingual ambiguities that sort of alter the meaning for the worse. For example, you say
” Flash memory is really cheap. So cheap, in fact, that it’s too good to be true. In reality, all flash memory is riddled with defects — without exception. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions. ”

I understand this to mean “the theory of flash memory function vs the reality as implemented in silicon isn’t consistent due to scaling challenges, and these challenges are handled transparently by the memory controller.” As covered in the Tech Crunch article, though, it comes across more as “SD card manufacturers are doing evil, shady things between you and your memory.” Specifically, “bad block management functions” – this lends to the overall tone that engineers are playing fast and loose with your data, when you actually mean “the memory controller implements functions to manage bad blocks, sectors of memory that go bad either because of totally normal manufacturing defect or because of extended use and wear in the field.”

The passage “… riddled with defects…” further enforces the idea that manufacturers-don’t-give-a-crap-about-quality, when what you actually mean is a lot of engineering and complexity goes into fixing the otherwise insurmountable manufacturing challenges.

Like I said, it’s an awesome article, and I’d hate for the real meaning to be lost on readers who are less technical or at least less aware of flash memory (or simply overly cynical).

[…] wish that piece of electrical tape denoted unreasonable paranoia, but it doesn’t — like so many things these days, webcams contain their own micro-controllers that can be hacked into without even […]

Hacking flash memory to make it lie about its capacity has been happening for a while. I was sold some “2GB” USB sticks which turned out to be 128MB in the large everything-emporium we called the “Blue Building” just across the HK/Shenzhen border at Lo Wu in 2006. Should have realised the price was too good to be true; I was unable to watch the movie that I’d (legally) taken a copy of home with me, because copying it on “worked fine”, but reading greater than 128MB just returned zeroes.

[…] wish that piece of electrical tape denoted unreasonable paranoia, but it doesn’t — like so many things these days, webcams contain their own micro-controllers that can be hacked into without even […]

I wonder at which stage these additions are being added (also with regard to your previous discoveries on fake sd cards and how they have been programmed) and who really benefits of this scheme. And, given that these dies aren’t made in a backyard shop – just who designs these setups?

I wonder if these discoveries could not give a different approach to alt.-firmware loading vis flash cards as in the CHDK* Project ? I guess Loading the firmware via a MITM attack would be possible but would it give a substancial advantage for the code execution performance ?

Or you can even just use encrypted files with a layer of encryption depending on a key tied to a specific device. But your idea would make even someone with literally infinite processing power unable to get it back. Sadly, that includes the dumb users that had no backup of their dime-sized memory card with 6 months of work on it.

[…] found here and live streams here), as many interesting talks are happening. One of them addressed hacking the memory controllers embedded in all memory cards that you may have. As memory storage density increases, it’s […]