Every complex modern device needs non-volatile storage to keep program and configuration data while unpowered. There are several competing options on the market available to today’s systems designers: serial Flash, raw NAND chips, (micro)SD, and Embedded MultiMediaCard (eMMC). eMMC is the topic of this discussion, and specifically how to interact with it without removing the chip from the system.
Such an approach is often desirable – after all, even when you are exceptionally skilled with BGA re-balling, there are only so many heating and cooling cycles the chip and the PCB can withstand before the probability of a failure gets too high. That is not to mention the exceptionally fine pitch of the most often encountered packages used by eMMC. The contact balls/pads are just 0.5mm (0.02in) apart, making the whole process rather fiddly and error-prone. Nobody really wants to bodge-wire this every time something needs to be changed!
Figure 1 - An eMMC chip in BGA153 bodged to a microSD-to-SD adapter. Source: @GetHypoxic onX/ Twitter
Thus, it’s desirable to avoid all that and still be able to read and write the chip’s data to. As to how to accomplish that, various bits and pieces of information have been floating around, a lot of it on phone repair forums, but I felt it could be beneficial to collect, process, and present the collective experience in a more structured way. Let’s explore this idea and how it can be made a reality.
PREREQUISITES
First, the basics. The following are necessary to be able to accomplish anything at all:
· A device to be researched, obviously.
· An interface device to interact with the eMMC chip. Options can vary, but you can pick anything that can speaks 1-bit MMC. I use a custom-made STM32-based adapter for that, which gives some additional hacking and debugging capabilities, while on the other hand being quite slow. Other options are also available, but I have not personally tested them (yet).
· Some machine with a program to consume disk images. This depends on the actual interface device you will be using. Maybe a Linux laptop and “dd”?
· Microsoldering equipment and skills to go with it. Unfortunately, there will still be some fiddly soldering involved as you will need to wire some things up. A pointy tip for your soldering iron that can tack things to passives smaller than size 0603, and some “magnet” wire of a reasonable diameter is a must. If you don’t feel confident enough, practice on some not-that-important equipment first.
· Equipment to probe signals. A multimeter is obligatory, but you will also need a logic analyzer and an oscilloscope. Neither needs to be high-end, but they should be able to handle frequencies up to 100MHz at a minimum.
· An adjustable bench power supply. This may be needed to power your device, either in whole or in part.
eMMC basics
Despite eMMC chips having a hundred and a half contact balls, only several actually do anything; the rest seem to be for mechanical stability and/or reserved for future use. While the full description of the eMMC protocol is provided in JESD84 [PDF], here is a short rundown of signals of particular interest and their properties:
· The CLK line is provided by the host and synchronizes everything that happens on the bus.
· The CMD line is for bidirectional communications between the host and eMMC devices on the bus. Host commands and device responses are sent via this line.
· A set of bidirectional lines DAT0 through DAT7 for data exchange between the host and eMMC devices. These carry everything else apart from commands and responses.
· The VDD and VDDQ lines, and corresponding VSS and VSSQ lines, supply power to eMMC devices. The eMMC standard defines several acceptable combinations of voltages, but in all cases VDDQ is less than or equal to VDD. Notably, VDDQ defines voltage levels on all external signals on the eMMC bus!
And that’s basically it. In fact, we will cut things down further and only deal with CLK, CMD, DAT0 and power lines, this being the so-called 1-bit bus width with the two other options being 4 and 8 bits.
Higher speeds often necessitate series resistors for all the signals of the eMMC bus. This results in eMMC devices being closely surrounded with 8 or more resistors, which make excellent points of contact. The eMMC standard also suggests all the lines to be pulled up to VDDQ via resistors to ensure signal levels are well defined.
The whole adventure presents a set of several interrelated problems, the solution to which is vital for successful communications to be established.
Problem #1: Locating eMMC signals on the board
Before we connect to anything, we need to understand what to connect to exactly. If you are lucky, the device PCB has silkscreen markings that note some or all of the eMMC signal locations.
Figure 2 - An example where we got lucky
More often than not, though, there is no such luck, and the PCB is devoid of any markings. How to proceed?
First of all, take note of traces around the eMMC device on your board. Some of them will likely come from under the device. Where do they go? To the SoC, perhaps? Is there a passive in series? Make sure to thoroughly inspect the other side of the board as well. While it is not impossible for eMMC signals to be routed on internal layers, if the board has enough of them, nonetheless in a 4 layer board it is more common for the internal layers to be power and ground while the top and bottom layers carry signals.
Figure 3 - An example where we did not get as lucky, but not too bad either
One could also overlay the package pinout on top of the board photo to approximately identify the location of signals of interest.
This investigative exercise should leave you with a set of potential candidates for eMMC signals. Now we need to weed them out. The easiest way around is probably to just tap all the candidates with some magnet wire and use a logic analyzer to watch the activity as the device under hack is powered up.
Figure 4 - The eMMC device is on the other side of the board at the top of this image, and the SoC is at the bottom
In Figure 4, several traces making their way top to bottom can be seen, all good candidates for probing.
At power up or system reset, the only active interaction on the bus will be via the CMD line: switching the bus to idle state, interrogating supported voltages, assigning device address, etc. You should see bursts of slow CLK signal with less regular activity on the CMD. Something like this:
Figure 5 - Sample bursts of slow CLK signals
Note that, as the eMMC standard allows bus operation using low voltages such as 1.8V, your logic analyzer may need to be configured appropriately.
The CMD line activity always begins with bit sequence 01; these are the start bit (always 0) and the direction bit (1 for host-to-device). Naturally, CMD transitions must be synchronized to the falling edge of potential CLK. At some point you will probably see the frequency of CLK change to a much higher one — something like 50MHz — with CMD also following. Using these clues, it should be possible to spot the CLK and CMD lines among your candidates. You can confirm the guesses by configuring a protocol analyzer in your logic analyzer software and seeing if it shows anything reasonable.
If there is something that looks like CMD but no CLK, you will have to find more candidates. Note that of all the signals, the CLK line is the least likely to have a series resistor close to the eMMC chip. The host is the only one driving that line, so the resistor will be placed closer to the host.
Now only the data lines are missing. These can be spotted once you spot your CMD and CLK and use a protocol analyzer. Look for the host issuing any command that will result in the device sending data over, for example, asking for the extended CSD contents or reading some sectors. The former typically occurs before a speed switch, and the latter after. High-speed devices are also likely to use the 8-bit mode; 8 lines going low and then showing activity can be a good clue too. Figuring out which of those 8 lines is DAT0 is easy if your device under hack performs any read-like operations before speed switch: there will be only one data line active at that time, whereas 8 of them will be active after the switch. You can also connect CMD and CLK to your 1-bit interface device and see what happens. Since there should be no bus width switch from 1 bit to higher width, only one line out of 8 candidates should show any activity. However, this requires being able to power the eMMC chip and keep the rest of the system out of the way.
Problem #2: Powering the eMMC chip
Of course, your eMMC chip needs to be powered before you can do anything with it. This power can be supplied by the device under hack itself, or it can be provided externally. Both approaches have their pros and cons.
The easiest approach is just letting the device do its thing. However, there can be trouble as you will have the whole system powered up and, to provide an example, there might be some kind of a watchdog circuit expecting a signal from the main SoC to show it has actually booted up. If this signal is not detected within a short amount of time, then the watchdog will power cycle the system. You will have then to find that circuit and bypass it, which may be more trouble than it’s worth.
On the other hand, you can provide your own power to only power the eMMC chip by connecting a power supply (or supplies, see below) across some capacitors under the chip. This circumvents the power-cycling problem but also requires connecting extra wires. The approach is not without its drawbacks: providing power in an uncontrolled manner may damage the board, so some form of current limiting is strongly advised—watch the current consumption and abort the exercise if it is too high to avoid permanent damage.
Whichever option is chosen, please be aware that there can be considerable current draw on those power lines, as more things will likely be connected to the VDD power rail than just the eMMC of interest. Using your bench supply to provide power is a good idea.
Before proceeding, we should figure out whether the system uses a single or separate supplies for VDD and VDDQ power rails, as well as the voltage required for each. In the case of separate supplies, we may not know what else is connected to the possibly lower-voltage VDDQ supply and whether it will tolerate the VDD supply should we decide to just use that by connecting VDD and VDDQ together; it might work fine, or it might force some magic smoke to escape from the $1000+ device under hack. Whether to accept this risk is up to personal judgment. The text below assumes the risk is too high, and we’ll want to supply two separate power rails.
Figure 6 - The opposite side, with many capacitors of varying sizes sprinkled around
As seen in Figure 6, there are several metal pour areas (light green area), with the larger ones being ground, and smaller ones VDD and VDDQ – in this case connected together.
As the VDDQ voltage can be easily determined by probing the CMD and CLK signals on system startup and noting the value shown, the only thing to do really is to probe the decoupling capacitors under the eMMC in an attempt to find a different, higher voltage there, which would then have to be VDD. Or, as in the case above, you can eyeball it and double check with your multimeter.
Split supplies and lower voltages raise another issue as well. Whatever interface device is used, it needs to be adapted to the hack that is underway. Specifically, your interface device may or may not support the lower signal voltage used in your device under hack. For example, the interface at my disposal is 3.3V only. All this means is that a bidirectional voltage level translator must be used.
There is some choice of devices on the market for that task. Unfortunately, the widespread TXB series of translators from TI cannot be used as they do not work when signals are pulled up at either side. Instead, the TXS series devices can be used; this was confirmed experimentally. They can be purchased in the hacker-friendly form of being mounted on a small PCB. Then it is just the matter of wiring the adapter PCB between your interface and the eMMC chip.
Figure 7 - An example of a breakout PCB for TXS0108E
Problem #3: Keeping the rest of the system quiet
Whichever way you choose to power the eMMC chip, the rest of the system may also want to kick into action, either in full or partially, and it may have to be pacified. This is especially important if whatever device is connected to the eMMC will become powered and active. This is naturally expected should you choose to power the whole system up instead of just the eMMC. Powering the eMMC only may or may not result in activity over the eMMC bus. This could be easily verified by powering the eMMC up and observing whether there is any activity on the CMD line; normally it should be pulled up to VDDQ and stay that way.
Should the system under hack be overly active, a couple options may be available to choose from depending on the design of said system.
· If not already, try powering the eMMC only through its power connections below instead of the whole system.
· If there are silkscreen signal labels, look for anything that resembles a reset signal for whatever wants to talk to the eMMC. Forcibly asserting that signal should keep the thing in reset—but some other part may become unhappy about that (see the text above concerning watchdogs). The reset a signal could also be found on a variety of debugging connectors or even a hardware reset button.
· If the SoC talking to the eMMC has this eMMC as a secondary boot device in a chain with, for example, a serial Flash chip, see how that primary device could be “disabled” to make the system not boot and get stuck in a loop instead, not touching the eMMC interface.
· Alternatively, one could try disabling the clock source by tampering with the crystal and e.g. removing it from the board or tying the SoC oscillator input to a power rail via a low-value resistor. Whether this works or not can be confirmed by probing with an oscilloscope.
Other options may also exist on your device under hack; do experiments and see what does the trick!
Once this problem is solved, you should search for DAT0, if it has not already been discovered, as everything is in place to facilitate that effort. And after that, well, depending on what kind of interface you are using, you should be able to freely interact with the eMMC as if it was part of your own machine: you can dump it, you can mount it, etc. The only downside here is, dumping non-user areas will likely be impossible if non-specialized interfaces are used as they do not provide means to switch areas. This can be overcome once initial access to the live device under hack is obtained through the research and analysis of whatever software is found in the user area of the eMMC.
Before we wrap up, some caveats should be mentioned. Above all else, remember that eMMC chips are high-speed devices, so wire lengths should be kept to a practical minimum. Even then, the device under hack may not work properly due to signal integrity issues. In that case, all the signal wires need to be removed after you are done tampering with the eMMC and you want to once more observe the operation of the device as a whole. Naturally, you will have to solder them back if more work needs to be done, but this is still much easier than removing and putting back the chip itself. Second, depending on your interface, boot and RPMB partitions may not be accessible. Fortunately, the boot partitions typically contain the bootloader—likely U-Boot—and are typically not that interesting if your research does not aim at, say, bypassing secure boot. Contents of these non-user partitions can be obtained later when access to the OS has been gained.
Conclusion
While this is by no means an exhaustive guide to interfacing with eMMC memory, I have tried to incorporate all the real-world cases encountered in work so far. Any questions, additions, corrections, and other feedback are always welcome, and who knows, maybe we will see the second iteration of this guide soon. In the meantime, I can offer good material for further reading about more invasive techniques.
You can reach me on Mastodon at @InfoSecDJ, and be sure to follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.
