If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!
Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.
<p>Few years ago Samsung Galaxy S3 devices started dying all around the world (a phenomenon known as "Galaxy S3 Sudden Death"). The faulty hardware was pinpointed to its eMMC chip (made by Samsung). eMMC are basically SD cards in BGA form soldered to the PCB, but as it apperas - they hide a CPU and a firmware inside.</p>
<p>Samsung eMMC chips support some vendor-specific, undocumented eMMC commands. By doing some guesswork and finding the right sequence of commands I was able to dump the entire RAM (and firmware) of the eMMC chip, which appears to sport an <i>ARM Cortex-M3</i> chip inside. But how can we know what causes the device to fail?</p>
<p>Samsung has written a Linux patch which patches the eMMC's RAM in order to fix the problem. However, investigating the patch itself reveals that it does nothing more than jumping to an infinite loop when something goes wrong. We needed a more inherent fix. By utilizing Samsung's own vendor-specific commands, we can write the eMMC's RAM in order to achieve code execution, or even write to the eMMC's NAND flash memory directly. We can update its firmware and fix the problem altogether.</p>
<p>However, when a device is bricked, how do we even get to send commands to its soldered eMMC chip by software-only means? I will show a working exploit against Samsung's boot-loader to be able to send commands to the eMMC chip.</p>
<p>Nevertheless, this is not enough. A bricked device usually means that the eMMC is now in an infinite loop and won't accept and eMMC commands. Although it appears to be a dead-end, there's a way: by triggering a power reset on the eMMC chip, there's a time window in which the chip boots itself. There's a way to stop the eMMC chip from loading its own firmware, instead putting itself in some "recovery mode". I was finally able to execute my own code on the faulty chip.</p>
<p>The research not only applies to Galaxy S3 devices (which are obviously old), as it appears to be relevant for new Samsung eMMC chips, even though they have a slightly different firmware, which will be briefly overviewed.</p>