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