back

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

A journey on how to fix broken proprietary hardware by gaining code execution on it

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.

Video duration
00:56:07
Language
English
Abstract
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.

<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>

Talk ID
8784
Event:
34c3
Day
1
Room
Saal Dijkstra
Start
12:45 p.m.
Duration
01:00:00
Track
Security
Type of
lecture
Speaker
oranav
Talk Slug & media link
34c3-8784-emmc_hacking_or_how_i_fixed_long-dead_galaxy_s3_phones

Talk & Speaker speed statistics

Very rough underestimation:
139.0 wpm
735.7 spm
140.7 wpm
744.2 spm
100.0% Checking done100.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
0.0% Nothing done yet0.0%
  

Work on this video on Amara!

Talk & Speaker speed statistics with word clouds

Whole talk:
139.0 wpm
735.7 spm
oranav:
140.7 wpm
744.2 spm