![]() 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. The crux is that a firmware loading and update mechanism is virtually mandatory, especially for third-party controllers. 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 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. 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. 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. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die. The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. 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. 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. It can be anything from high-grade factory-new silicon to material with over 80% bad sectors. In our experience, the quality of the flash chip(s) integrated into memory cards varies widely. You can see some die shots of the inside of microSD cards at a microSD teardown I did a couple years ago. 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). 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. 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. 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. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions. In reality, all flash memory is riddled with defects - without exception. So cheap, in fact, that it’s too good to be true. We also note that similar classes of vulnerabilities exist in related devices, such as USB flash drives and SSDs.įlash memory is really cheap. ![]() 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. ![]() In order to explain the hack, it’s necessary to understand the structure of an SD card. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |