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

https://media.ccc.de/c/34c3/34c3-8784-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

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.

oranav

https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8784.html

34c3 intro

Herald: Right, so. Once again, good
morning. Our next talk, next speaker

today, this morning is an independant
security researcher. He founded the Pasten

CTF group, which some of you might have
heard of. And he has previously worked on

OpeniBoot. Please give a big round of
applause to Oran Avraham.

applause

Oran: Can you hear me? OK. So I'm going to

talk about how I hacked the eMMC chips or
how we fixed dead Galaxy S3 devices.

First, an introduction about myself or:
Who am I? I'm Oran Avraham, 25 years old.

I'm a security reasearcher based in
Isreal. I'm currently working at a startup

called Medigate. However this talk has no
connection to my employer whatsoever. I

previously worked on OpeniBoot which was
an open-source alternative bootloader for

Apple iOS devices. We aimed to boot Linux
on iPhone 3G, 3GS, and iPhone 4. We had

some success. I also found vulnerabilities
in the early iPhone baseband, which were

used to unlock and SIM free these devices
and I'm also a CTF player with the Pasten

team. We're playing tonight, so good luck
for us. This is my contact info, if you

want to reach me, you can find on my
website and there's also my twitter

username. OK, so, an outline about this
talk. I am going to start with an

introduction about the story. How I got to
hack eMMC devices. Then, we'll talk about

Samsung's eMMC patch, which they used for
Galaxy S3 devices, then I will talk about

how I obtained the firmware of those eMMC
chips and analysed it. We'll cover the bug

itself, that was in Samsung Galaxy S3
devices. And then, I'm going to talk about

how do we resurrect bricked devices. So,
let's start with the introduction. This

phenomenon was called "Sudden Death
Syndrome". This was the name that they

gave it over forums, and it started in
2012. Samsung Galaxy S3 devices just

started dying with no apparent reason. You
could use your phone and then one day it

will get stuck and if you try to reboot
it, it won't boot anymore. The phone is

basically a brick. And if you're lucky,
the phone will boot into the bootloader so

you'll see a loading screen, but it won't
boot Linux or Android. And if you're not

lucky then it's just a brick. You can't
use it, you cannot turn it on. If you plug

in a USB cable, you'll see nothing. You
cannot even charge the battery because the

actual charging
mechanism isn't powered on, so… yeah. And

there were a lot of rants in forums. This
is an example: Somebody said, "this is

happening to a lot of people. I hope,
Samsung do something about this!" And,

actually, they did, but it wasn't, like, a
proper fix, and we'll talk about it later.

So, let's talk about how do you diagnose
such devices? So, this is a working S3.

You can see the beautiful background and
everything is powered on. And this is a

dead one. laughter Yeah, the screen is
just black, you cannot do anything.

Actually, as I said before, if you're
lucky, you'll see this screen which is

drawn by the bootloader, which is called
"Samsung sboot" and it won't boot … this

is the last screen you'll see. And if you
press a specific combination of keys, you

will get this screen which is called
"Download Mode", and we will talk about it

later. So this is my understanding … this
is my current understanding on how S3

works. So, this is a rough schematics;
there's a lot of different peripherals

that are not there, obviously. There's the
main CPU, which is called "Samsung

Exynos", it is an ARM-based CPU. And then
you have the eMMC chip, which is a storage

device. It is the standard storage device
for phones. And there is some NAND flash

inside of it. So, it is one package. And
if you inspect the silicon, you'll see a

NAND flash chip- OK, so … then, Samsung
dropped a patch. And what happened is that

they said to the press that they just
fixed this bug and since the Linux is GPL-

licensed, they had to publish the source
code. So, the patch was called "Soft-patch

MoviNAND VTU00M eMMC failure" and it's …
they modified the file responsible … the

code responsible for communicating with
eMMC devices. So in order to understand

this patch, we have to talk about what is
eMMC? So, what is eMMC basically? It's the

de-facto standard storage for phones.
Actually, nowadays, high-end phones are

starting to use UFS, which is the bus that
replaces eMMC, but the majority of phones

still use eMMC. And you
can think about it as an

SD-card in BGA form. It is a package that
you can solder onto a PCB and it is

basically an SD-card. It uses exactly the
same bus. And as you can see, some company

called HardKernel made a PCB which have an
eMMC chip soldered onto it and you can …

they made also an adapter which you can
plug and there's no logic to this adapter,

it just turns the eMMC into an SD-card
device. And it works. So, eMMC is

essentially a NAND flash chip with
convenient bus, which is the same bus as

SD-cards. So, for this reason, some people
also called this an "internal SD-card", or

something like that. And if I am going to
say card later in my talk, I'm going to

talk about the eMMC chip. So, when you
communicate with the eMMC bus, you send

commands to the card and there are 64
commands. And they are denoted from

command 0 up to 63. For example, you have
command 17, which is READ_SINGLE_BLOCK,

and command 24, which is WRITE_BLOCK, and
each command takes a single 32-bit

argument. So you send a command, it has a
number, and an argument. And all the

commands are categorised into classes. And
there is one specific interesting class,

which is class 8. Because if you look at
the specific section, you'll see that

command 60 up to 63 are reserved for the
manufacturer. So if something interesting

is going to happen, it will be probably
happen with these commands. So let's go

back to the patch. Samsung said, they
fixed the bug, right? So S3 devices

shouldn't get bricked anymore. Let's … so,
this patch actually, the first thing that

… it compares the card's name to VTU00M,
which is the hardware revision of the

faulty chip, and then they compare a
number to the value 0xF1, and this is

actually the firmware version of this
chip. And then, they call a function which

is called mmc_start_movi_smart, which
isn't that interesting, so I'm not going

to talk about. And if all this comparisons
are true, then it will call

mmc_start_movi_operation, which is the
main logic

responsible for fixing the chip. And the
thing to note about this patch is that it

… this code runs everytime you boot the
device. So everytime the eMMC chip is

powered on, this code runs. OK, so let's
talk about mmc_start_movi_operation. So,

this is … I edited the code for brevity,
it's not the exact same patch but this is

basically the logic that they used. And
this is very interesting. There is one

strange thing about this function. This
mmc_movi_erase_cmd … erase is … an eMMC

command which takes two arguments. It uses
two arguments because you precede it with

a different command, so you can give it
two arguments. And the first arguments is

this start block number to erase, and the
second one is the end block number to

erase. And it erases all the blocks in-
between. So what should happen is that the

first call to this function should erase
all the blocks starting with 40300 up to

block number 4A03B510, right? This doesn't
make any sense, and then the next call is

the … the ranges overlap. And this was
very strange. So my guess was that this is

probably not an erase command. It is
probably something else, somehow. And the

next thing to note about this function is
that you see the first two calls are

mmc_movi_cmd, and the last calls are also
to the function mmc_movi_cmd. And

mmc_movi_cmd is basically command 62,
which is a class-8-command. So it is

reserved to the manufacturer. And my guess
was that the first two calls basically

enter some secret backdoor mode that
Samsung hid inside the eMMC chip. And the

last two calls leave this mode. So when
you're in this mode, erase command doesn't

do erase anymore. It does something else.
And then, I saw that if you inspect the

first argument, you'll see that the
numbers are consecutive and they increment

by four, except for the last number. All
the first … the first five numbers are

consecutive. And the next thing … so it
looks something like memory addresses,

right? And if you look at the second
argument, I noticed

something very interesting. If I assumed
this is memory data, then if you look at

it like as little-endian numbers, you'll
see 10B5, so it starts with 10B5. And I

used to code a lot of ARM-assembly, and
10B5 is PUSH in Thumb. And Thumb is an

instruction set from the ARM
specification. And functions in Thumb

start with PUSH, right? So this is an eMMC
next to a thumb. laughter And basically,

this is my current understanding of how
eMMC works. So you have this whole eMMC

chip, but there is not only a NAND flash
inside it, there is also a

microcontroller. And in Samsung's case,
this is an ARM-based microcontroller which

contains some firmware. So I thought this
patch might modify the internal memory of

this chip somehow. So what I wanted to do
is to examine what this patch does. So I

just took all this data that it writes and
put it into a binary file which I called

patch.bin and this is, I just used IDA to
see what is going on there and this is

Samsung's patch. So … at the bottom, you
can see the actual Thumb instructions but

if you're not familiar with Thumb, you can
see also a C-like pseudocode. And what

they do is basically, they call a function
and if it returns zero, the chip will go

into an infinite loop. And this is
interesting, because later on, I

understood that what was there before the
patch, it was just a call to this function

and there wasn't this check. So they took
a single call to a function and turned it

into a call to the same function, but if
it returned zero, they just go into an

infinite loop. So my thought was, this
can't fix anything, right? laughter

Because the chip is either going to do the
same thing as before or it is going to go

into an infinite loop. And then I read
some threads over forums and I saw this

thread. "Ultimate Galaxy S3 unusual
freezing thread" And this is a quote from

the actual thread, you can see that
"Galaxy S3 is freezing with lockups,

screen not responding … and ending with
unusual rebooting and bootlooping …

Angry S3 users reporting this problem …
And it keeps freezing every five minutes

or 50+ freezes a day". This is insane,
right? This phone is not usable. I can't

use it as my phone if it freezes every
five minutes. And I had an S3 back then,

and I noti… I started observing freezes in
my phone as well. So the next step that I

wanted to do is to obtain the eMMC
firmware in order to understand how it

works. So how do you get a firmware? The
first way to do it is to write … so I can

write the eMMC's memory, right? So I can
just write code to random locations and

hopefully it will get run somehow. And
then, just write things to different

addresses and do lucky guesses and maybe I
will see something on the eMMC bus and

then try to obtain the firmware. But it is
like a shot in the dark. So the next thing

I thought about doing is to fuzz different
commands. Like use command 60, 61,

different class-8-commands. But I didn't
want to destroy my own eMMC, which was

still working. So the last thing I thought
about then is to look for clues. So how do

you look for clues? I just googled these
numbers that Samsung used to enter this

backdoor mode. And I saw a different
patch. So this is a patch from a different

device, and it is called "Patch the
firmware of certain Samsung emmc parts to

fix a bug" … ehhh laughter … and it used
the same mode as before, so notice that

they use arguments 0xEFAC62EC and then it
is 0x10210000. And this is important. So

they use 0x10210000, right? And then they
write the value 0xFF to the address for

the D9C. But then there was something else
afterwards. So if you continue to read

this patch, you will se this thing. This
is a snippet which is enclosed by #ifed,

which is called test_mmc_fw_patching, and
they used the same emmc 62EC as before,

but now they use the argument 10210002.
And the next thing is that they … they use

an erase command with the same addresses
as before, but then they do a read

command, right? I was wondering … hm …
this might be

Samsung's way of reading the memory
address of the … the memory of the eMMC

chip. Because they use an erase command
with the same address as before. The

second argument is 4, which looks like a
size, and then they read a DWORD from the

eMMC. So I took this snippet of code and
modified it into … what if I did into this

snippet of code? Which basically just
loops over all the addresses in the

address space. I just guessed how big the
address space is. And I just read a single

DWORD everytime and I dumped it into a
file. And then, I got this thing, which

looks like a firmware, right? So … the
names aren't the names that you see, like,

MMI, and hard_fault … these are all my
names. What I saw was addresses, but this

looks like a Thumb vector table. So I
understood that I basically got the

firmware of my own chip. So the next step
was to reverse the firmware in order to

analyse what the bug is. So luckily for
me, the firmware contains Strings, so I

can use them as part of my reverting
process. But unfortunately, it contained a

String. A single String. And it was this
string,. Which isn't very useful, if you

are trying to reverse a firmware. And as
you can see, this is a snippet of my

reversing process. I used a lot of, like,
names, flip_bit_in_somewhere, memory

mapped I/O 1000 2 DWORDS … But, I
basically understood the high-level logic

of this code. And I got to the point in
which I can understand most of the

firmware. So let's talk about debug.
Before we talk about debug, we have to

talk about what is eMMC exactly. So let's
talk about normal storage first. This is,

like, hard-drives. You have two operations
which you can do. You have a read

operation which reads data from the device
and then you have a write operation which

writes data onto the device. This is
pretty normal. Then you have NAND flash

storage. So if you have NAND flash
storage, you can do a read operation which

still reads data, and this is as before,
but write operation actually turns off

bits. If a bit was already 0,
it won't turn into

a 1. So this is basically applying a mask
to bits on the storage. And then you have

an erase command, so you have to … you got to
have same way for reversing this process.

An erase operation erases a whole erase-
block. It turns all this bits in the block

all to 1s, but it's a slow operation. And
there's another problem: Erase-blocks have

a limited program/erase cycle. So if you
issue something like a 1000 or 10'000 or

100'000 erases, the block will eventually
die and is not usable anymore. So

something have to … some software have to
do this translation to take this (…?)

storage and do an abstraction which will
show it like normal storage. So, this is

called an FTL---or Flash Translation
Layer. This is common. And the FTL is

responsible for many things but some
examples are wear leveling, which is

spreading out erases among different
blocks, so no single block gets erased a

lot of times. And then it also does bad
block management; if block already died,

then it will remap it internally to a
different block. It actually has spare

blocks and then it … the firmware in
Samsung's case is also responsible for the

eMMC bus communication---or some of it. So
what is the bug exactly? So … when you do

write operations on the device, the FTL
has to save some metadata for itself,

because it has to keep track on how many
times this block was erased and what is

the internal mapping and so on. So it has
some metadata that it saves for itself.

And when you do write operations, it has
to modify this metadata. And the actual

bug was a miscalculation in this code
which---not always, but sometimes---made

the data corrupt. And once it happened---
it should only happen once---if the data

got corrupted---and this is before
Samsung's patch---everytime you try to

power on the eMMC chip, the FTL will try
to parse this data, and it's corrupt, so

it will raise a CPU exception. And the
default exception handler in Samsung's

case is just an infinite loop. So
the device … so … so you use the device

and one day, the metadata gets corrupted
and then you try to turn it on and it

tries to parse the metadata and it's
corrupt, so it throws an exception and

then the eMMC goes into an infinite loop
and you can't access it anymore. And the

eMMC is basically, essentially, dead.
Because you send commands into it and

nothing responds because the firmware is
the one is dead, the software … that is

responsible for answering eMMC commands.
So Samsung's patch was something about

this. Something like this. Right before
the metadata is about to get corrupted,

halt the CPU. So, there's no bug, right?
Right before the bug is about to happen,

just halt the CPU so it never happens. And
this then, like, sudden death syndrome

into sudden freeze syndrome. So I wanted
to fix my own device. So, a quick recap: I

got the eMMC firmware by analysing
Samsung's patch. The firmware had the bug

causing FTL corruption. Once it happened,
the chip won't boot anymore and Samsung's

patch was to avoid the bug happening at
all. So the next step is, obviously, to

resurrect dead phones, right? … yeah,
what?! How do I … So the eMMC gets into a

loop at boot. But what happens before it
gets into this loop? So I took a look at

the firmware and I saw this memory layout.
As you can see at address 0, there's

something that I called a "Boot ROM". And
it's a ROM, you can't write into it. And

it is a code and what it does, it
initialises the eMMC hardware and it loads

the firmware from the NAND flash chip
itself. And this is strange, because if

the boot ROM is already there, why don't …
why doesn't it already doing the things

that the firmware is responsible to do? So
my guess was that the firmware was too big

to reside wherever the boot ROM resides,
so they had to, like, bootstrap it from

the external NAND flash. And then it also
has it's own machinery for eMMC commands,

which is strange, because all it has to do
is just load its firmware. So my guess is

that, during their
production process, the NAND flash is

empty and there's no firmware. And then,
when Samsung produces these chips, they

plug them in and there's no firmware, so
the boot ROM goes into some kind of

recovery mode and it exposes an eMMC bus
and from there you can write your new

firmware. And the boot ROM is basically a
stripped-down firmware. There's no FTL,

but it looks like the firmware itself. And
this is my current understanding of how S3

works. So inside the eMMC you have two
silicon dies, and the first is an ARM chip

which has a boot ROM, which loads the
firmware from the external NAND flash and

then boots it. So, if we could ever talk
to boot ROM, this might be interesting

because we could maybe do something
interesting. But the firmware loading

actually succeeds because the firmware is
still intact. The boot ROM will try to

load the firmware, the firmware is still
there and it will jump into it and the

firmware executes and goes into infinite
loop so there is no chance of every

talking to the boot ROM, right? Though,
actually, not. This is not correct,

because on boot, there's this function at
address 7DBC and a timer is being set for

35ms and if during this time period, some
interrupt fires, this is interrupt #7, I

don't know what it is yet. They read a
value from a memory-mapped I/O address and

they compare it to this constant magic.
And if this comparison is true, firmware

loading is skipped and it goes right into
this recovery mode. And my guess is that …

so this is a schematic of the boot process
and the right … the left column is the

normal boot process and if we ever get to
the right column, we will get into this

recovery mode. So my guess is that this
interrupt #7 corresponds to some eMMC

command. And this value that they read
from memory-mapped I/O is probably the

eMMC argument, because it is 32 bits. So
that eMMCs get stuck on boot. So this is

if the chip is already dead. However,
right before it gets stuck, there is a

time window and during this time
window, if you somehow

trigger this interrupt, the boot process
is aborted and it goes right into eMMC

boot ROM recovery mode, which is
interesting. But the phone is already

dead. How do I even talk to the eMMC chip?
So I could've used the hardware mod, like,

desolder the eMMC and send commands
externally but … ehh … I wanted to, like,

do something with software, because I
don't know how to desolder BGA chips. So

the next step is to talk to the eMMC by
some kind of magic and then we'll access

the eMMC boot ROM. And then, we can repair
it from this boot ROM recovery mode. So I

said, if you're lucky, you get this
screen. So this is the phone's bootloader.

This is sboot. And it is saved on the eMMC
itself. So how do you get this? If the

eMMC chip doesn't respond, how the main
CPU gets to execute this bootloader? So,

apparently, if you read Samsung's
specification, you will see that the eMMC

has two partitions and it's not a
partition in the filesystem-sense, it's a

partition in the eMMC-sense. And there's a
boot partition and a user partition. And

the boot partition holds sboot in
Samsung's case, which is the bootloader

for the main CPU. And the user partition
holds everything else. So it stores Linux

and all the Android filesystem and all the
apps etc. So the boot partition has its

own FTL metadata and the user partition
also has its own metadata. A friend of

mine had a bricked S3 which does load
sboot. So he gets this screen. And … what

I understood had happened is that only the
user's … the user partition metadata got

corrupted, so the boot partition is still
intact. And I suspect, this is a common

scenario. When you write to your device,
you usually don't try to write to the boot

partition, you write to the user
partition. So if something is about to get

corrupted, it probably will be in the user
partition. So this is how S3 breaks. The

main CPU will power on and it will try to
access the eMMC and asks: Give me sboot.

And the eMMC parses the boot partition and
it will return sboot to the main

CPU and then sboot will try to access the
user partition in order to load Linux and

then the eMMC tries to parse the user
partition metadata and it's corrupt, so it

goes into a loop. So sboot actually has a
device firmware update mode, that is

called "Download mode", and there is
protocol of USB, the phone side is called

Loke and the computer side is called Odin.
I guess, this is a reference to the Norsk

methology. And there's no way of sending
low-level eMMC commands. So if you ever

saw this screen, this is Odin software.
It's a software made by Samsung to talk to

this protocol. And in this protocol, you
can't send raw eMMC commands to the eMMC

chip, so I need to send commands to the
chip, but the code isn't there in sboot.

So, obviously, the thing that I'll have to do
is to exploit sboot, and run my own code.

This is taken from USB PIT packets handler
from sboot. This is a C pseudocode that I

wrote. So, you control this variable is
dumped and if it is 1, it will read

something from the USB packet that you
send to it and then it will give you a

buffer and it will use this number that
you gave it as an offset to this buffer

but it doesn't do any boundary checks at
all. So this is an out-of-bounds read

vulnerability. And the second case reads a
size from the USB packet and then reads it

into this USB buffer, which is constantly
allocated on the heap, it's of size 2000,

but it doesn't do any boundary checks at
all either. So, this is a heap-overflow

vulnerability, right? So eventually I
found that this is not actually a 0-day.

If you take, like an S8 or S7, this
vulnerability is fixed but for S3, which

is end-of-life, these vulnerabilities are
still there. So if you have an S3, you can

use it … So, let's talk about Samsung's
sboot heap implementation. So if you

wanted to allocate some size and the heap
chose to use a chunk which is larger than

the size that you wanted to allocate, it
will split it from the end. And you will

see an illustration in a moment.
And the thing to

note about this heap implementation is
that there is no security mitigations at

all. It's very basic. So … let's say that
you wanted to allocate 50 bytes and the

chunk that it chose was 100 bytes, then it
will give you this part, which is the

bottom part of the buffer. And the buffer,
the chunk header, has a size number … a

size parameter and it will use this size
to go to the end. So I wanted to achieve

write-what-where in order to exploit
sboot. And I used … I exploited the chunk

splitting technique. So the first thing to
do was to fake a chunk header which I can

control with some large size, so it will
get split, and then I had to figure out

its address. And I can do this with the
first vulnerability, the relative read,

and then the next step is to make sure
this chunk is actually selected when you

call malloc. And then, it will try to give
you the bottom part of the buffer. So it

will start from the chunk address and then
it will go all the way to the bottom,

which is adding chunk size, and then it
will go back the size you wanted to

allocate, right? And we want to control
this number and we can control this

number. So if I just turn around this
equation, if I want to control address, I

can just use this number as the chunk size
and then it will give me this address. So

the actual details in my opinion are
boring. So you can find the exploit under

this repository. It's public, so you can
just take an S3 and use it, and this is a

demo. This is download mode, and this is
Hello World sboot exploit, so it works.

OK, so, what if it's really dead? What if
this happened, right? What if also the

boot partition is gone? So, obiously
something has to load. Has to talk with

the eMMC and load sboot, right? So there's
also another piece of code which is called

Exynos boot rom. And it is … it resides in
the main CPU. And what happens normally is

that the Exynos boot ROM starts and then
it loads something which I call the "first

bootloader", which is prepended
to sboot, and it is

signed and it just verifies the signature
of sboot and then jumps into it. So you

can just think about it as, it's together
with sboot. And then sboot loads the

kernel. But the boot ROM has to load the
first bootloader and sboot from somewhere,

so what does it try to do? So it first
starts with the eMMC. But if this fails,

it goes to the external SD-card. So I just
took sboot and the first bootloader and

dropped them onto an SD-card. But that
didn't work because sboot boots into, in

this case, sboot boots into SD-card mode,
in which there's is no USB protocol, so

you can't exploit it. And, as I said, it
is signed, so I can't patch it. But

apparently some people over a forum, their
nicknames are AdamOutler, Rebellos, and

Ralekdev. They found out that there is a
development board, called ODROID-X, which

uses exactly the same CPU, so it's the
same boot ROM, which uses the same

signature, but it uses a different first
bootloader, which doesn't do any signature

checks at all. So if you take this first
bootloader and append to it a patched

sboot, it will jump into this patched
sboot and then you can just exploit it and

run your code. And this is the modified
boot process, so you start with Exynos

boot ROM, you plug in an external SD-card,
the externel SD-card has ODROID-X first

bootloader, which is signed, so the boot
ROM will jump into it and then the first

bootloader will jump to the patched sboot
and then you can exploit it and run you

shell code. And no hardware mode is
required at all. So if the boot partition

is still intact, the phone loads sboot and
it is stored in your eMMC. But if it is

corrupt, the phone uses the external SD-
card. And either way, I can load sboot.

And then I can exploit a vulnerability to
gain code execution in sboot. And the next

step is to access the eMMC boot ROM. And
as I said before, I need to trigger this

interrupt #7 and send it … send this
argument somehow. So I just iterated over

all the possible eMMC commands,
which is from 0 to 63, and I

powered off the eMMC, powered it back on,
so the boot process gets started again.

And then I quickly sent a command X with
this argument and I waited for some time

for the boot process to finish. And then I
sent any command which is supported by the

boot ROM recovery mode and I checked if I
got any response. And I said, ehhh, this

is … maybe it's going to work, maybe not,
and then I tried command 0 and it failed,

and I said, naah, it's never going to
work, and then command 1 worked.

laughter So this was very exciting for me
because this is the first time, the eMMC

actually responds. And up until then, on
the bricked device, I tried to send

several commands to the eMMC and I never
saw a response. And this is the first time

I actually saw a response from the eMMC
and this was very exciting. And the eMMC

even has command 62, you know, this
backdoor mode, so let's fix it. Let's

repair the eMMC. So, there are two
revisions of this faulty chip. The first

revision uses a firmware 0xF1, which is
buggy, and then there were phones with

firmware revision 0xF7 in which the bug
never occurred. So probably Samsung fixed

the bug in later hardware revisions. So my
goal was to update the chip to firmware

0xF7 and format the FTL metadata so
the corruption is gone. OK, so … what I

did was to write a dump tool, a firmware
dump tool, which is a kernel module. And

then I had to convince anybody over … the
Internet … to run my code which sends low-

level eMMC commands to … on their own
device. laughter And thanks to @artesea,

which was courage enough to try it, I got
a dump of firmware 0xF7 and it worked. And

now I just had to write it to the eMMC
itself. So this is absolutely doable

because I could've used the memory write
backdoor to write my own code and access

the NAND flash chip and write a new
firmware. But then I found out something

simpler. So there's another backdoor,
which is command 60, and it has two

firmware upgrade modes for some
reason. So the former mode,

which is 0xCBAD1160, supports FTL
metadata format. You can send an erase

command and it will format all the FTL
metadata. And then you can write a new

firmware and it will do everything for
you. So how do I fix a dead S3? I just get

a dead S3, which should be … this is
important to note … the … many … there's

different revisions of Galaxy S3. I'm
talking about GT-I9300, which is the

international version. Boot to sboot,
either directly, if the boot partition is

still intact, or by using an external SD-
card. Then exploit sboot to run your own

code. From the shell code, reboot the eMMC
into boot ROM recovery mode and then use

command 60 to format the FTL metadata and
flash the new firmware, 0xF7 firmware.

Then reboot the eMMC so the firmware
loading … actually boots and then you can

write sboot to the eMMC's boot partition.
And there is another step, which is … to

profit. And this means, it is demo time!
So, I pray to the demo gods that it is

going to happen, it is going to succeed.
So, yeah … This … OK, so I have a bricked

device, I bricked it on purpose. This is
the device. If I try to turn it on---

there's a battery inside---nothing
happens. It is bricked. If I try to get

into download mode, nothing works. I have
this external SD card which does have

sboot as I said before. And if I plug it
in, and I try to boot the device, it

should boot into … Yeah, okay. So, it
boots into something and now I can use …

Just go back to the … yeah. And now I can
plug it into the USB and sboot answers,

and now I am going to run a shell code,
which fixes the eMMC. It’s retrying, it is

okay. Shell code started. It rebooted the
eMMC into bootrom mode, and now it will

write the new firmware. And it should take
a couple of seconds, so … hold tight, as

it said… Okay, yeah, so the next thing is
going to be to reboot into the firmware

and then change the boot partition size so
that there's actually a boot partition.

Yeah, and now the shell command is done
and I can just use a different SD card

which loads sboot normally and it goes
into SD card mode and in this SD card

mode, it will write sboot to the boot
partition, so … Let me just … Yeah, okay.

So this is SD card mode. I think you can't
see, but if I now remove this SD card,

right? And just reboot the device, so …
the battery is outside and now it's … yeah

… It should boot into … yeah! So, this is
sboot! So the device is fixed.

applause

Thank you! So, conclusion. A few
shoutouts, so … Rebellos, AdamOutler, and

Ralekdev did all the Exynos U-Boot, first
bootloader, ODROID-X work, so … Thanks to

them! I couldn't … if it weren't for them,
I couldn't boot bricked devices.

Entropy512 was involved in the eMMC
research back in 2013 and bunnyxobs held a

wonderful talk here at CCC some years ago.
And he talked about hacking Chinese SD

cards and they mentioned my research, and
this motivated me to complete it because it

was still in progress. This is the reason
for which I'm talking today, so … thanks!

applause

So, I can basically own Samsung
eMMCs, I can fix bricked S3 with just

software, and, imagine, this is just a
use-case, because now you can do

interesting stuff with your eMMC chip. And
what I think we should do next is to look

at newer eMMCs which I suspect still has
this backdoor, because I tried some chip

which I could get my hands on and it had
this backdoor, so … Maybe even the new

ones also has this mode. And then there's
UFS, which is the bus which replaces eMMC

and it is based on SCASI and Samsung also
produces UFS chips so it might be wanting

to see if there's a similar backdoor. And
it's also interesting to look at different

vendors of eMMCs and maybe one day write
an open-source alternative firmware for

these devices. So this is question time.
You can find the code that I wrote to

experiment with these devices over the
following links, and you can find the

slides in the bottom link. It's already
public, so go ahead. And if you have any

questions, this is the time, so … thanks!

applause

Herald: So thank you very much, Oran, for

a really interesting talk. If you have
questions, there are two microphones in

this aisle, and then two on the sides, and
first question from microphone #2.

Microphone #2: It's pretty amazing what

you did. Did you guys get any feedback
from Samsung on this?

Oran: Yeah, so … I published my research

back in 2012 … 2013, sorry, over forums
and I didn't use it from a security

perspective. I wanted to fix S3. They
never responded or … they didn't contact

me in any way. I didn't contact them about
the boot ROM recovery mode, because in my

opinion it is not a security issue. And it
can be fixed. And regarding the sboot

vulnerabilities, there is no … it's
already patched, so … No, the answer is:

No.

Microphone #2: So, the way I understand
it, this is the only way to fix some of

the phones that are broken
out there, right?

Oran: Yeah, I don't know any other way to

do it.

M#2: OK, thanks.

Herald: Microphone #1.

Microphone #1: After seeing a real-life
FTL, do you still use SSDs?

Oran: Sorry?

Microphone #1: After seeing a real-life

FTL, do you still use SSDs or
other flash devices?

Oran: Yeah, this is a good question … it's

okay. And I don't … there's no
alternative, right? So … but we might

make something, so …

Herald: Mic number three.

Microphone #3: Do you have any idea what
other devices have this model eMMC and

support the same commands that let you
access the firmware? ’cause there is other

devices that had bad eMMC.

Oran: Ah, okay, so … Samsu… Galaxy S2 had
a similar bug and Kindle Fire, I think,

one of their versions. And some of them
got patches by Samsung and it's usually

was something like this, like: Patch the
internal memory everytime the device boots

so the bug never happens. I think, in the
other devices, the bug was actually fixed.

Microphone #3: But are you aware of any

non-Samsung devices that have Samsung MMCs
in them that might be the same MMC?

Oran: I'm sorry?

Microphone #3: Are there other devices

that aren't Samsung phones but still have
Samsung parts in them?

Oran: Yeah, ah! So, there's not a lot of

eMMC manufacturers and Samsung is a big
manufacturer, so … A lot of different

phones and devices use Samsung eMMCs, so …
yes. It is relevant to non-Samsung devices.

Herald: Number one.

Microphone #1: Hey, thanks for your
amazing talk and research. Two questions:

There's the Samsung Galaxy Note 2 that has
more or less the same bug, does your fix

and your research also apply to that
device? And is there a way to a chip-off

dump without erasing the FTL
and contents of the card?

Oran: Yeah, so, this is a good question.

The first question was … the S2
has the same bug, right?

Microphone #1: The Note 2! The …

Oran: Ah! The Note 2! Ah, okay. I don't

know. I never had a Note 2, so.

Microphone #1: I have one
that is bricked that way.

Oran: But would be interesting to try.

True! So, that's that. And regarding the
second question: My code actually formats

all the FTL metadata which is not that
good because it erases all this

information about how many times every
block was erased. A more proper fix would

be to actually fix the corrupted metadata
but I haven't got to the point in which I

can fully understand the inner workings of
the FTL. So, this is my current code but

you are welcome to try to improve it.

Microphone #1: Wonderful.

Herald: Microphone number two.

Microphone #2: I'd like to know what the
timeframe was from you working on the

issue 'til you had the first fixed S3.

Oran: Yeah, so, I obtained the firmware
back in 2013 and I had a working device

and I didn't want to do … like … bad stuff
to it. So I stopped back in this year, and

then last year, a friend of mine said that
he had a bricked S3 so I said, let's try

to fix it. So I think if you, like,
accumulate the time, it's probably going

to be, like, a timeframe which I worked,
actively worked on this, was something

like a few months. Probably four or five
months. But it started back in … four

years ago, and I finished it something
like a couple of months ago

Microphone #2: Cool. Thanks!

Herald: Number One.

Microphone #1: Do … Do Samsung SD cards

have the same undocumented commands?

Oran: Yeah, I suspect, they do. Some of
them. I actually bought some Samsung SD

cards and they had controllers made by
Silicon Motion but I read over the

Internet that some specific cards, I think
it's Evo+ Plus have Samsung controllers

which should have the same backdoor, so,
I'm trying to buy one but as soon as I

find out, I will probably post about it.

Microphone #1: Thank you.

Herald: Number three.

Microphone #3: OK, thanks for the great
talk. So, I'm using an S3 as my everyday

phone, so what actually happened a few
months ago, it broke down but … so I still

saw the Samsung bootloader, the sboot,
what it is called, and afterwards it got

stuck at the bootscreen from the OS, so in
my case it was Cyanogenmod, but also, when

I flashed on something else, like
LineageOS, or the default Samsung's

firmware, it still got stuck. I really had
to re-flash everything and then it worked

again. That somehow sounds really similar
to the bug you described, but in a way it

also doesn't. Do you think
it's the same thing?

Oran: So, if it's related, my guess would

be that your device have this in-memory
patch which freezes the eMMC and when you

used LineageOS or what it was before, this
infinite loop triggered at some point in

the boot process so the device actually
froze before it got to boot Android. But

then, when you flashed it, somehow, the
internal block mapping got changed and now

it doesn't trigger this freezing. But if
your chip is VTU00M and its firmware is

0xF1, then you definitely have the bug.

Microphone #3: OK, thanks.

Herald: Number One.

Microphone #1: Hi! Thanks for the great
work. One question: You said, you upgraded

the firmware of the eMMC with a newer
revision. Are these firmwares actually

signed or can you flash anything
on the eMMC controller?

Oran: You can flash anything … yeah. They

have a simple heuristic which checks if
the stack address is … looks normal, but

other than that, it boots every firmware
you give it. I think, in your eMMCs, which

is eMMC 5.1, there's a mechanism of
flashing new firmwares and I think it

should be signed but I don't have a newer
eMMC, so … I don't know about it, but

yeah.

Microphone #1: Thank you.

Herald: So … I have one last question,
about the Samsung patch. You said that it

basically goes into some sort of infinite
loop. But do you think they tried to some

busy wait or they're waiting
for something to happen?

Oran: No, I think they just want … they

want the bug to never happen, so … Yeah, I
… my phone froze a lot of times and I

waited like, I don't know, 30 minutes. And
the code in the Linux kernel doesn't do

anything, and the code in the eMMC
firmware doesn't do anything, so my guess:

It just waits forever.

Herald: I see no more questions, so again,
a big round of applause to Oran for great

work.

applause

34c3 outro

subtitles created by c3subtitles.de
in the year 2018. Join, and help us!