34C3 - eMMC hacking, or: how I fixed long-dead Galaxy S3 phones

https://media.ccc.de/v/34c3-8784-emmc... A journey on how to fix broken proprietary hardware by gaining code execution on it How I hacked Sasmung eMMC chips: from an indication that they have a firmware - up until code execution ability on the chip itself, relevant to a countless number of devices. It all started when Samsung Galaxy S3 devices started dying due to a bug in their eMMC firmware. I will cover how I figured out there's a firmware inside the chip, how I obtained it, and my journey to gaining code execution on the chip itself — up until the point in which I could grab a bricked Galaxy S3, and fix it by software-only means. 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. 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 ARM Cortex-M3 chip inside. But how can we know what causes the device to fail? 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. 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. 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. 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. oranav https://fahrplan.events.ccc.de/congre...