WEBVTT
00:00:00.000 --> 00:00:16.869
34c3 intro
00:00:16.869 --> 00:00:21.539
Herald: Right, so. Once again, good
morning. Our next talk, next speaker
00:00:21.539 --> 00:00:26.910
today, this morning is an independant
security researcher. He founded the Pasten
00:00:26.910 --> 00:00:31.160
CTF group, which some of you might have
heard of. And he has previously worked on
00:00:31.160 --> 00:00:35.740
OpeniBoot. Please give a big round of
applause to Oran Avraham.
00:00:35.740 --> 00:00:43.670
applause
00:00:43.670 --> 00:00:46.830
Oran: Can you hear me? OK. So I'm going to
00:00:46.830 --> 00:00:55.240
talk about how I hacked the eMMC chips or
how we fixed dead Galaxy S3 devices.
00:00:55.240 --> 00:01:01.649
First, an introduction about myself or:
Who am I? I'm Oran Avraham, 25 years old.
00:01:01.649 --> 00:01:06.560
I'm a security reasearcher based in
Isreal. I'm currently working at a startup
00:01:06.560 --> 00:01:12.299
called Medigate. However this talk has no
connection to my employer whatsoever. I
00:01:12.299 --> 00:01:17.979
previously worked on OpeniBoot which was
an open-source alternative bootloader for
00:01:17.979 --> 00:01:25.309
Apple iOS devices. We aimed to boot Linux
on iPhone 3G, 3GS, and iPhone 4. We had
00:01:25.309 --> 00:01:34.449
some success. I also found vulnerabilities
in the early iPhone baseband, which were
00:01:34.449 --> 00:01:41.130
used to unlock and SIM free these devices
and I'm also a CTF player with the Pasten
00:01:41.130 --> 00:01:48.640
team. We're playing tonight, so good luck
for us. This is my contact info, if you
00:01:48.640 --> 00:01:53.369
want to reach me, you can find on my
website and there's also my twitter
00:01:53.369 --> 00:01:57.609
username. OK, so, an outline about this
talk. I am going to start with an
00:01:57.609 --> 00:02:03.869
introduction about the story. How I got to
hack eMMC devices. Then, we'll talk about
00:02:03.869 --> 00:02:11.100
Samsung's eMMC patch, which they used for
Galaxy S3 devices, then I will talk about
00:02:11.100 --> 00:02:20.630
how I obtained the firmware of those eMMC
chips and analysed it. We'll cover the bug
00:02:20.630 --> 00:02:25.850
itself, that was in Samsung Galaxy S3
devices. And then, I'm going to talk about
00:02:25.850 --> 00:02:33.540
how do we resurrect bricked devices. So,
let's start with the introduction. This
00:02:33.540 --> 00:02:38.960
phenomenon was called "Sudden Death
Syndrome". This was the name that they
00:02:38.960 --> 00:02:46.471
gave it over forums, and it started in
2012. Samsung Galaxy S3 devices just
00:02:46.471 --> 00:02:51.830
started dying with no apparent reason. You
could use your phone and then one day it
00:02:51.830 --> 00:02:57.250
will get stuck and if you try to reboot
it, it won't boot anymore. The phone is
00:02:57.250 --> 00:03:02.130
basically a brick. And if you're lucky,
the phone will boot into the bootloader so
00:03:02.130 --> 00:03:08.470
you'll see a loading screen, but it won't
boot Linux or Android. And if you're not
00:03:08.470 --> 00:03:14.230
lucky then it's just a brick. You can't
use it, you cannot turn it on. If you plug
00:03:14.230 --> 00:03:19.990
in a USB cable, you'll see nothing. You
cannot even charge the battery because the
00:03:19.990 --> 00:03:26.510
actual charging
mechanism isn't powered on, so… yeah. And
00:03:26.510 --> 00:03:31.250
there were a lot of rants in forums. This
is an example: Somebody said, "this is
00:03:31.250 --> 00:03:36.590
happening to a lot of people. I hope,
Samsung do something about this!" And,
00:03:36.590 --> 00:03:42.840
actually, they did, but it wasn't, like, a
proper fix, and we'll talk about it later.
00:03:42.840 --> 00:03:48.840
So, let's talk about how do you diagnose
such devices? So, this is a working S3.
00:03:48.840 --> 00:03:54.070
You can see the beautiful background and
everything is powered on. And this is a
00:03:54.070 --> 00:03:59.300
dead one. laughter Yeah, the screen is
just black, you cannot do anything.
00:03:59.300 --> 00:04:03.530
Actually, as I said before, if you're
lucky, you'll see this screen which is
00:04:03.530 --> 00:04:09.820
drawn by the bootloader, which is called
"Samsung sboot" and it won't boot … this
00:04:09.820 --> 00:04:15.500
is the last screen you'll see. And if you
press a specific combination of keys, you
00:04:15.500 --> 00:04:18.370
will get this screen which is called
"Download Mode", and we will talk about it
00:04:18.370 --> 00:04:26.640
later. So this is my understanding … this
is my current understanding on how S3
00:04:26.640 --> 00:04:33.160
works. So, this is a rough schematics;
there's a lot of different peripherals
00:04:33.160 --> 00:04:40.180
that are not there, obviously. There's the
main CPU, which is called "Samsung
00:04:40.180 --> 00:04:47.140
Exynos", it is an ARM-based CPU. And then
you have the eMMC chip, which is a storage
00:04:47.140 --> 00:04:52.530
device. It is the standard storage device
for phones. And there is some NAND flash
00:04:52.530 --> 00:04:58.130
inside of it. So, it is one package. And
if you inspect the silicon, you'll see a
00:04:58.130 --> 00:05:06.160
NAND flash chip- OK, so … then, Samsung
dropped a patch. And what happened is that
00:05:06.160 --> 00:05:14.340
they said to the press that they just
fixed this bug and since the Linux is GPL-
00:05:14.340 --> 00:05:19.860
licensed, they had to publish the source
code. So, the patch was called "Soft-patch
00:05:19.860 --> 00:05:29.730
MoviNAND VTU00M eMMC failure" and it's …
they modified the file responsible … the
00:05:29.730 --> 00:05:34.950
code responsible for communicating with
eMMC devices. So in order to understand
00:05:34.950 --> 00:05:43.000
this patch, we have to talk about what is
eMMC? So, what is eMMC basically? It's the
00:05:43.000 --> 00:05:49.400
de-facto standard storage for phones.
Actually, nowadays, high-end phones are
00:05:49.400 --> 00:05:57.470
starting to use UFS, which is the bus that
replaces eMMC, but the majority of phones
00:05:57.470 --> 00:06:01.730
still use eMMC. And you
can think about it as an
00:06:01.730 --> 00:06:06.990
SD-card in BGA form. It is a package that
you can solder onto a PCB and it is
00:06:06.990 --> 00:06:15.590
basically an SD-card. It uses exactly the
same bus. And as you can see, some company
00:06:15.590 --> 00:06:24.741
called HardKernel made a PCB which have an
eMMC chip soldered onto it and you can …
00:06:24.741 --> 00:06:29.480
they made also an adapter which you can
plug and there's no logic to this adapter,
00:06:29.480 --> 00:06:37.129
it just turns the eMMC into an SD-card
device. And it works. So, eMMC is
00:06:37.129 --> 00:06:42.520
essentially a NAND flash chip with
convenient bus, which is the same bus as
00:06:42.520 --> 00:06:49.510
SD-cards. So, for this reason, some people
also called this an "internal SD-card", or
00:06:49.510 --> 00:06:55.280
something like that. And if I am going to
say card later in my talk, I'm going to
00:06:55.280 --> 00:07:03.740
talk about the eMMC chip. So, when you
communicate with the eMMC bus, you send
00:07:03.740 --> 00:07:10.240
commands to the card and there are 64
commands. And they are denoted from
00:07:10.240 --> 00:07:16.430
command 0 up to 63. For example, you have
command 17, which is READ_SINGLE_BLOCK,
00:07:16.430 --> 00:07:22.540
and command 24, which is WRITE_BLOCK, and
each command takes a single 32-bit
00:07:22.540 --> 00:07:29.430
argument. So you send a command, it has a
number, and an argument. And all the
00:07:29.430 --> 00:07:33.580
commands are categorised into classes. And
there is one specific interesting class,
00:07:33.580 --> 00:07:37.810
which is class 8. Because if you look at
the specific section, you'll see that
00:07:37.810 --> 00:07:44.240
command 60 up to 63 are reserved for the
manufacturer. So if something interesting
00:07:44.240 --> 00:07:50.040
is going to happen, it will be probably
happen with these commands. So let's go
00:07:50.040 --> 00:07:55.660
back to the patch. Samsung said, they
fixed the bug, right? So S3 devices
00:07:55.660 --> 00:08:04.850
shouldn't get bricked anymore. Let's … so,
this patch actually, the first thing that
00:08:04.850 --> 00:08:10.570
… it compares the card's name to VTU00M,
which is the hardware revision of the
00:08:10.570 --> 00:08:15.669
faulty chip, and then they compare a
number to the value 0xF1, and this is
00:08:15.669 --> 00:08:21.920
actually the firmware version of this
chip. And then, they call a function which
00:08:21.920 --> 00:08:26.650
is called mmc_start_movi_smart, which
isn't that interesting, so I'm not going
00:08:26.650 --> 00:08:32.499
to talk about. And if all this comparisons
are true, then it will call
00:08:32.499 --> 00:08:35.419
mmc_start_movi_operation, which is the
main logic
00:08:35.419 --> 00:08:44.489
responsible for fixing the chip. And the
thing to note about this patch is that it
00:08:44.489 --> 00:08:48.920
… this code runs everytime you boot the
device. So everytime the eMMC chip is
00:08:48.920 --> 00:08:55.619
powered on, this code runs. OK, so let's
talk about mmc_start_movi_operation. So,
00:08:55.619 --> 00:09:02.189
this is … I edited the code for brevity,
it's not the exact same patch but this is
00:09:02.189 --> 00:09:07.980
basically the logic that they used. And
this is very interesting. There is one
00:09:07.980 --> 00:09:16.740
strange thing about this function. This
mmc_movi_erase_cmd … erase is … an eMMC
00:09:16.740 --> 00:09:23.269
command which takes two arguments. It uses
two arguments because you precede it with
00:09:23.269 --> 00:09:28.499
a different command, so you can give it
two arguments. And the first arguments is
00:09:28.499 --> 00:09:33.949
this start block number to erase, and the
second one is the end block number to
00:09:33.949 --> 00:09:39.689
erase. And it erases all the blocks in-
between. So what should happen is that the
00:09:39.689 --> 00:09:46.980
first call to this function should erase
all the blocks starting with 40300 up to
00:09:46.980 --> 00:09:56.769
block number 4A03B510, right? This doesn't
make any sense, and then the next call is
00:09:56.769 --> 00:10:02.279
the … the ranges overlap. And this was
very strange. So my guess was that this is
00:10:02.279 --> 00:10:08.390
probably not an erase command. It is
probably something else, somehow. And the
00:10:08.390 --> 00:10:13.009
next thing to note about this function is
that you see the first two calls are
00:10:13.009 --> 00:10:19.809
mmc_movi_cmd, and the last calls are also
to the function mmc_movi_cmd. And
00:10:19.809 --> 00:10:25.129
mmc_movi_cmd is basically command 62,
which is a class-8-command. So it is
00:10:25.129 --> 00:10:34.089
reserved to the manufacturer. And my guess
was that the first two calls basically
00:10:34.089 --> 00:10:39.589
enter some secret backdoor mode that
Samsung hid inside the eMMC chip. And the
00:10:39.589 --> 00:10:46.360
last two calls leave this mode. So when
you're in this mode, erase command doesn't
00:10:46.360 --> 00:10:52.839
do erase anymore. It does something else.
And then, I saw that if you inspect the
00:10:52.839 --> 00:10:56.949
first argument, you'll see that the
numbers are consecutive and they increment
00:10:56.949 --> 00:11:06.079
by four, except for the last number. All
the first … the first five numbers are
00:11:06.079 --> 00:11:12.199
consecutive. And the next thing … so it
looks something like memory addresses,
00:11:12.199 --> 00:11:18.060
right? And if you look at the second
argument, I noticed
00:11:18.060 --> 00:11:26.809
something very interesting. If I assumed
this is memory data, then if you look at
00:11:26.809 --> 00:11:33.240
it like as little-endian numbers, you'll
see 10B5, so it starts with 10B5. And I
00:11:33.240 --> 00:11:40.240
used to code a lot of ARM-assembly, and
10B5 is PUSH in Thumb. And Thumb is an
00:11:40.240 --> 00:11:45.869
instruction set from the ARM
specification. And functions in Thumb
00:11:45.869 --> 00:11:54.350
start with PUSH, right? So this is an eMMC
next to a thumb. laughter And basically,
00:11:54.350 --> 00:11:58.869
this is my current understanding of how
eMMC works. So you have this whole eMMC
00:11:58.869 --> 00:12:02.220
chip, but there is not only a NAND flash
inside it, there is also a
00:12:02.220 --> 00:12:06.839
microcontroller. And in Samsung's case,
this is an ARM-based microcontroller which
00:12:06.839 --> 00:12:14.119
contains some firmware. So I thought this
patch might modify the internal memory of
00:12:14.119 --> 00:12:21.150
this chip somehow. So what I wanted to do
is to examine what this patch does. So I
00:12:21.150 --> 00:12:27.050
just took all this data that it writes and
put it into a binary file which I called
00:12:27.050 --> 00:12:35.240
patch.bin and this is, I just used IDA to
see what is going on there and this is
00:12:35.240 --> 00:12:42.990
Samsung's patch. So … at the bottom, you
can see the actual Thumb instructions but
00:12:42.990 --> 00:12:47.509
if you're not familiar with Thumb, you can
see also a C-like pseudocode. And what
00:12:47.509 --> 00:12:52.420
they do is basically, they call a function
and if it returns zero, the chip will go
00:12:52.420 --> 00:12:57.589
into an infinite loop. And this is
interesting, because later on, I
00:12:57.589 --> 00:13:03.809
understood that what was there before the
patch, it was just a call to this function
00:13:03.809 --> 00:13:09.200
and there wasn't this check. So they took
a single call to a function and turned it
00:13:09.200 --> 00:13:15.469
into a call to the same function, but if
it returned zero, they just go into an
00:13:15.469 --> 00:13:20.899
infinite loop. So my thought was, this
can't fix anything, right? laughter
00:13:20.899 --> 00:13:26.119
Because the chip is either going to do the
same thing as before or it is going to go
00:13:26.119 --> 00:13:34.699
into an infinite loop. And then I read
some threads over forums and I saw this
00:13:34.699 --> 00:13:40.059
thread. "Ultimate Galaxy S3 unusual
freezing thread" And this is a quote from
00:13:40.059 --> 00:13:43.439
the actual thread, you can see that
"Galaxy S3 is freezing with lockups,
00:13:43.439 --> 00:13:47.509
screen not responding … and ending with
unusual rebooting and bootlooping …
00:13:47.509 --> 00:13:51.749
Angry S3 users reporting this problem …
And it keeps freezing every five minutes
00:13:51.749 --> 00:13:57.019
or 50+ freezes a day". This is insane,
right? This phone is not usable. I can't
00:13:57.019 --> 00:14:04.889
use it as my phone if it freezes every
five minutes. And I had an S3 back then,
00:14:04.889 --> 00:14:12.610
and I noti… I started observing freezes in
my phone as well. So the next step that I
00:14:12.610 --> 00:14:17.599
wanted to do is to obtain the eMMC
firmware in order to understand how it
00:14:17.599 --> 00:14:23.319
works. So how do you get a firmware? The
first way to do it is to write … so I can
00:14:23.319 --> 00:14:29.170
write the eMMC's memory, right? So I can
just write code to random locations and
00:14:29.170 --> 00:14:37.259
hopefully it will get run somehow. And
then, just write things to different
00:14:37.259 --> 00:14:43.380
addresses and do lucky guesses and maybe I
will see something on the eMMC bus and
00:14:43.380 --> 00:14:50.309
then try to obtain the firmware. But it is
like a shot in the dark. So the next thing
00:14:50.309 --> 00:14:55.649
I thought about doing is to fuzz different
commands. Like use command 60, 61,
00:14:55.649 --> 00:15:02.089
different class-8-commands. But I didn't
want to destroy my own eMMC, which was
00:15:02.089 --> 00:15:07.800
still working. So the last thing I thought
about then is to look for clues. So how do
00:15:07.800 --> 00:15:13.949
you look for clues? I just googled these
numbers that Samsung used to enter this
00:15:13.949 --> 00:15:18.850
backdoor mode. And I saw a different
patch. So this is a patch from a different
00:15:18.850 --> 00:15:23.660
device, and it is called "Patch the
firmware of certain Samsung emmc parts to
00:15:23.660 --> 00:15:31.929
fix a bug" … ehhh laughter … and it used
the same mode as before, so notice that
00:15:31.929 --> 00:15:41.761
they use arguments 0xEFAC62EC and then it
is 0x10210000. And this is important. So
00:15:41.761 --> 00:15:48.769
they use 0x10210000, right? And then they
write the value 0xFF to the address for
00:15:48.769 --> 00:15:55.699
the D9C. But then there was something else
afterwards. So if you continue to read
00:15:55.699 --> 00:16:01.939
this patch, you will se this thing. This
is a snippet which is enclosed by #ifed,
00:16:01.939 --> 00:16:08.809
which is called test_mmc_fw_patching, and
they used the same emmc 62EC as before,
00:16:08.809 --> 00:16:18.511
but now they use the argument 10210002.
And the next thing is that they … they use
00:16:18.511 --> 00:16:24.120
an erase command with the same addresses
as before, but then they do a read
00:16:24.120 --> 00:16:30.119
command, right? I was wondering … hm …
this might be
00:16:30.119 --> 00:16:35.219
Samsung's way of reading the memory
address of the … the memory of the eMMC
00:16:35.219 --> 00:16:39.709
chip. Because they use an erase command
with the same address as before. The
00:16:39.709 --> 00:16:46.670
second argument is 4, which looks like a
size, and then they read a DWORD from the
00:16:46.670 --> 00:16:52.079
eMMC. So I took this snippet of code and
modified it into … what if I did into this
00:16:52.079 --> 00:16:57.649
snippet of code? Which basically just
loops over all the addresses in the
00:16:57.649 --> 00:17:04.510
address space. I just guessed how big the
address space is. And I just read a single
00:17:04.510 --> 00:17:12.009
DWORD everytime and I dumped it into a
file. And then, I got this thing, which
00:17:12.009 --> 00:17:20.599
looks like a firmware, right? So … the
names aren't the names that you see, like,
00:17:20.599 --> 00:17:27.999
MMI, and hard_fault … these are all my
names. What I saw was addresses, but this
00:17:27.999 --> 00:17:36.250
looks like a Thumb vector table. So I
understood that I basically got the
00:17:36.250 --> 00:17:42.539
firmware of my own chip. So the next step
was to reverse the firmware in order to
00:17:42.539 --> 00:17:46.970
analyse what the bug is. So luckily for
me, the firmware contains Strings, so I
00:17:46.970 --> 00:17:51.800
can use them as part of my reverting
process. But unfortunately, it contained a
00:17:51.800 --> 00:18:00.990
String. A single String. And it was this
string,. Which isn't very useful, if you
00:18:00.990 --> 00:18:08.480
are trying to reverse a firmware. And as
you can see, this is a snippet of my
00:18:08.480 --> 00:18:17.500
reversing process. I used a lot of, like,
names, flip_bit_in_somewhere, memory
00:18:17.500 --> 00:18:26.619
mapped I/O 1000 2 DWORDS … But, I
basically understood the high-level logic
00:18:26.619 --> 00:18:32.240
of this code. And I got to the point in
which I can understand most of the
00:18:32.240 --> 00:18:37.740
firmware. So let's talk about debug.
Before we talk about debug, we have to
00:18:37.740 --> 00:18:45.700
talk about what is eMMC exactly. So let's
talk about normal storage first. This is,
00:18:45.700 --> 00:18:51.401
like, hard-drives. You have two operations
which you can do. You have a read
00:18:51.401 --> 00:18:54.710
operation which reads data from the device
and then you have a write operation which
00:18:54.710 --> 00:19:01.140
writes data onto the device. This is
pretty normal. Then you have NAND flash
00:19:01.140 --> 00:19:06.770
storage. So if you have NAND flash
storage, you can do a read operation which
00:19:06.770 --> 00:19:13.500
still reads data, and this is as before,
but write operation actually turns off
00:19:13.500 --> 00:19:17.789
bits. If a bit was already 0,
it won't turn into
00:19:17.789 --> 00:19:24.759
a 1. So this is basically applying a mask
to bits on the storage. And then you have
00:19:24.759 --> 00:19:30.990
an erase command, so you have to … you got to
have same way for reversing this process.
00:19:30.990 --> 00:19:37.720
An erase operation erases a whole erase-
block. It turns all this bits in the block
00:19:37.720 --> 00:19:48.330
all to 1s, but it's a slow operation. And
there's another problem: Erase-blocks have
00:19:48.330 --> 00:19:53.700
a limited program/erase cycle. So if you
issue something like a 1000 or 10'000 or
00:19:53.700 --> 00:20:01.309
100'000 erases, the block will eventually
die and is not usable anymore. So
00:20:01.309 --> 00:20:10.120
something have to … some software have to
do this translation to take this (…?)
00:20:10.120 --> 00:20:18.000
storage and do an abstraction which will
show it like normal storage. So, this is
00:20:18.000 --> 00:20:23.049
called an FTL---or Flash Translation
Layer. This is common. And the FTL is
00:20:23.049 --> 00:20:28.380
responsible for many things but some
examples are wear leveling, which is
00:20:28.380 --> 00:20:33.410
spreading out erases among different
blocks, so no single block gets erased a
00:20:33.410 --> 00:20:39.290
lot of times. And then it also does bad
block management; if block already died,
00:20:39.290 --> 00:20:44.630
then it will remap it internally to a
different block. It actually has spare
00:20:44.630 --> 00:20:50.809
blocks and then it … the firmware in
Samsung's case is also responsible for the
00:20:50.809 --> 00:20:59.259
eMMC bus communication---or some of it. So
what is the bug exactly? So … when you do
00:20:59.259 --> 00:21:05.509
write operations on the device, the FTL
has to save some metadata for itself,
00:21:05.509 --> 00:21:11.730
because it has to keep track on how many
times this block was erased and what is
00:21:11.730 --> 00:21:19.789
the internal mapping and so on. So it has
some metadata that it saves for itself.
00:21:19.789 --> 00:21:27.520
And when you do write operations, it has
to modify this metadata. And the actual
00:21:27.520 --> 00:21:35.840
bug was a miscalculation in this code
which---not always, but sometimes---made
00:21:35.840 --> 00:21:42.000
the data corrupt. And once it happened---
it should only happen once---if the data
00:21:42.000 --> 00:21:48.950
got corrupted---and this is before
Samsung's patch---everytime you try to
00:21:48.950 --> 00:21:56.049
power on the eMMC chip, the FTL will try
to parse this data, and it's corrupt, so
00:21:56.049 --> 00:22:01.070
it will raise a CPU exception. And the
default exception handler in Samsung's
00:22:01.070 --> 00:22:07.739
case is just an infinite loop. So
the device … so … so you use the device
00:22:07.739 --> 00:22:14.750
and one day, the metadata gets corrupted
and then you try to turn it on and it
00:22:14.750 --> 00:22:19.139
tries to parse the metadata and it's
corrupt, so it throws an exception and
00:22:19.139 --> 00:22:25.090
then the eMMC goes into an infinite loop
and you can't access it anymore. And the
00:22:25.090 --> 00:22:29.479
eMMC is basically, essentially, dead.
Because you send commands into it and
00:22:29.479 --> 00:22:33.220
nothing responds because the firmware is
the one is dead, the software … that is
00:22:33.220 --> 00:22:37.760
responsible for answering eMMC commands.
So Samsung's patch was something about
00:22:37.760 --> 00:22:42.960
this. Something like this. Right before
the metadata is about to get corrupted,
00:22:42.960 --> 00:22:50.739
halt the CPU. So, there's no bug, right?
Right before the bug is about to happen,
00:22:50.739 --> 00:22:58.549
just halt the CPU so it never happens. And
this then, like, sudden death syndrome
00:22:58.549 --> 00:23:06.201
into sudden freeze syndrome. So I wanted
to fix my own device. So, a quick recap: I
00:23:06.201 --> 00:23:11.820
got the eMMC firmware by analysing
Samsung's patch. The firmware had the bug
00:23:11.820 --> 00:23:16.540
causing FTL corruption. Once it happened,
the chip won't boot anymore and Samsung's
00:23:16.540 --> 00:23:22.940
patch was to avoid the bug happening at
all. So the next step is, obviously, to
00:23:22.940 --> 00:23:31.250
resurrect dead phones, right? … yeah,
what?! How do I … So the eMMC gets into a
00:23:31.250 --> 00:23:37.070
loop at boot. But what happens before it
gets into this loop? So I took a look at
00:23:37.070 --> 00:23:44.059
the firmware and I saw this memory layout.
As you can see at address 0, there's
00:23:44.059 --> 00:23:51.510
something that I called a "Boot ROM". And
it's a ROM, you can't write into it. And
00:23:51.510 --> 00:23:58.489
it is a code and what it does, it
initialises the eMMC hardware and it loads
00:23:58.489 --> 00:24:04.690
the firmware from the NAND flash chip
itself. And this is strange, because if
00:24:04.690 --> 00:24:10.729
the boot ROM is already there, why don't …
why doesn't it already doing the things
00:24:10.729 --> 00:24:16.269
that the firmware is responsible to do? So
my guess was that the firmware was too big
00:24:16.269 --> 00:24:21.559
to reside wherever the boot ROM resides,
so they had to, like, bootstrap it from
00:24:21.559 --> 00:24:26.370
the external NAND flash. And then it also
has it's own machinery for eMMC commands,
00:24:26.370 --> 00:24:31.510
which is strange, because all it has to do
is just load its firmware. So my guess is
00:24:31.510 --> 00:24:36.110
that, during their
production process, the NAND flash is
00:24:36.110 --> 00:24:43.010
empty and there's no firmware. And then,
when Samsung produces these chips, they
00:24:43.010 --> 00:24:47.830
plug them in and there's no firmware, so
the boot ROM goes into some kind of
00:24:47.830 --> 00:24:53.860
recovery mode and it exposes an eMMC bus
and from there you can write your new
00:24:53.860 --> 00:24:58.519
firmware. And the boot ROM is basically a
stripped-down firmware. There's no FTL,
00:24:58.519 --> 00:25:05.700
but it looks like the firmware itself. And
this is my current understanding of how S3
00:25:05.700 --> 00:25:13.120
works. So inside the eMMC you have two
silicon dies, and the first is an ARM chip
00:25:13.120 --> 00:25:17.190
which has a boot ROM, which loads the
firmware from the external NAND flash and
00:25:17.190 --> 00:25:23.200
then boots it. So, if we could ever talk
to boot ROM, this might be interesting
00:25:23.200 --> 00:25:29.240
because we could maybe do something
interesting. But the firmware loading
00:25:29.240 --> 00:25:33.730
actually succeeds because the firmware is
still intact. The boot ROM will try to
00:25:33.730 --> 00:25:37.000
load the firmware, the firmware is still
there and it will jump into it and the
00:25:37.000 --> 00:25:40.649
firmware executes and goes into infinite
loop so there is no chance of every
00:25:40.649 --> 00:25:46.950
talking to the boot ROM, right? Though,
actually, not. This is not correct,
00:25:46.950 --> 00:25:54.029
because on boot, there's this function at
address 7DBC and a timer is being set for
00:25:54.029 --> 00:25:59.970
35ms and if during this time period, some
interrupt fires, this is interrupt #7, I
00:25:59.970 --> 00:26:08.210
don't know what it is yet. They read a
value from a memory-mapped I/O address and
00:26:08.210 --> 00:26:16.211
they compare it to this constant magic.
And if this comparison is true, firmware
00:26:16.211 --> 00:26:22.399
loading is skipped and it goes right into
this recovery mode. And my guess is that …
00:26:22.399 --> 00:26:29.239
so this is a schematic of the boot process
and the right … the left column is the
00:26:29.239 --> 00:26:35.669
normal boot process and if we ever get to
the right column, we will get into this
00:26:35.669 --> 00:26:42.259
recovery mode. So my guess is that this
interrupt #7 corresponds to some eMMC
00:26:42.259 --> 00:26:49.269
command. And this value that they read
from memory-mapped I/O is probably the
00:26:49.269 --> 00:26:57.080
eMMC argument, because it is 32 bits. So
that eMMCs get stuck on boot. So this is
00:26:57.080 --> 00:27:02.800
if the chip is already dead. However,
right before it gets stuck, there is a
00:27:02.800 --> 00:27:06.430
time window and during this time
window, if you somehow
00:27:06.430 --> 00:27:13.789
trigger this interrupt, the boot process
is aborted and it goes right into eMMC
00:27:13.789 --> 00:27:18.179
boot ROM recovery mode, which is
interesting. But the phone is already
00:27:18.179 --> 00:27:25.080
dead. How do I even talk to the eMMC chip?
So I could've used the hardware mod, like,
00:27:25.080 --> 00:27:31.860
desolder the eMMC and send commands
externally but … ehh … I wanted to, like,
00:27:31.860 --> 00:27:40.680
do something with software, because I
don't know how to desolder BGA chips. So
00:27:40.680 --> 00:27:46.210
the next step is to talk to the eMMC by
some kind of magic and then we'll access
00:27:46.210 --> 00:27:53.970
the eMMC boot ROM. And then, we can repair
it from this boot ROM recovery mode. So I
00:27:53.970 --> 00:27:58.179
said, if you're lucky, you get this
screen. So this is the phone's bootloader.
00:27:58.179 --> 00:28:03.790
This is sboot. And it is saved on the eMMC
itself. So how do you get this? If the
00:28:03.790 --> 00:28:11.210
eMMC chip doesn't respond, how the main
CPU gets to execute this bootloader? So,
00:28:11.210 --> 00:28:16.990
apparently, if you read Samsung's
specification, you will see that the eMMC
00:28:16.990 --> 00:28:22.010
has two partitions and it's not a
partition in the filesystem-sense, it's a
00:28:22.010 --> 00:28:27.019
partition in the eMMC-sense. And there's a
boot partition and a user partition. And
00:28:27.019 --> 00:28:33.189
the boot partition holds sboot in
Samsung's case, which is the bootloader
00:28:33.189 --> 00:28:39.930
for the main CPU. And the user partition
holds everything else. So it stores Linux
00:28:39.930 --> 00:28:49.499
and all the Android filesystem and all the
apps etc. So the boot partition has its
00:28:49.499 --> 00:28:54.990
own FTL metadata and the user partition
also has its own metadata. A friend of
00:28:54.990 --> 00:29:02.250
mine had a bricked S3 which does load
sboot. So he gets this screen. And … what
00:29:02.250 --> 00:29:07.470
I understood had happened is that only the
user's … the user partition metadata got
00:29:07.470 --> 00:29:11.470
corrupted, so the boot partition is still
intact. And I suspect, this is a common
00:29:11.470 --> 00:29:15.490
scenario. When you write to your device,
you usually don't try to write to the boot
00:29:15.490 --> 00:29:19.269
partition, you write to the user
partition. So if something is about to get
00:29:19.269 --> 00:29:25.240
corrupted, it probably will be in the user
partition. So this is how S3 breaks. The
00:29:25.240 --> 00:29:31.270
main CPU will power on and it will try to
access the eMMC and asks: Give me sboot.
00:29:31.270 --> 00:29:41.600
And the eMMC parses the boot partition and
it will return sboot to the main
00:29:41.600 --> 00:29:47.210
CPU and then sboot will try to access the
user partition in order to load Linux and
00:29:47.210 --> 00:29:52.980
then the eMMC tries to parse the user
partition metadata and it's corrupt, so it
00:29:52.980 --> 00:29:59.690
goes into a loop. So sboot actually has a
device firmware update mode, that is
00:29:59.690 --> 00:30:03.689
called "Download mode", and there is
protocol of USB, the phone side is called
00:30:03.689 --> 00:30:08.129
Loke and the computer side is called Odin.
I guess, this is a reference to the Norsk
00:30:08.129 --> 00:30:13.559
methology. And there's no way of sending
low-level eMMC commands. So if you ever
00:30:13.559 --> 00:30:20.450
saw this screen, this is Odin software.
It's a software made by Samsung to talk to
00:30:20.450 --> 00:30:27.149
this protocol. And in this protocol, you
can't send raw eMMC commands to the eMMC
00:30:27.149 --> 00:30:35.240
chip, so I need to send commands to the
chip, but the code isn't there in sboot.
00:30:35.240 --> 00:30:41.749
So, obviously, the thing that I'll have to do
is to exploit sboot, and run my own code.
00:30:41.749 --> 00:30:53.110
This is taken from USB PIT packets handler
from sboot. This is a C pseudocode that I
00:30:53.110 --> 00:31:00.360
wrote. So, you control this variable is
dumped and if it is 1, it will read
00:31:00.360 --> 00:31:05.350
something from the USB packet that you
send to it and then it will give you a
00:31:05.350 --> 00:31:14.119
buffer and it will use this number that
you gave it as an offset to this buffer
00:31:14.119 --> 00:31:21.480
but it doesn't do any boundary checks at
all. So this is an out-of-bounds read
00:31:21.480 --> 00:31:27.409
vulnerability. And the second case reads a
size from the USB packet and then reads it
00:31:27.409 --> 00:31:35.249
into this USB buffer, which is constantly
allocated on the heap, it's of size 2000,
00:31:35.249 --> 00:31:40.010
but it doesn't do any boundary checks at
all either. So, this is a heap-overflow
00:31:40.010 --> 00:31:45.090
vulnerability, right? So eventually I
found that this is not actually a 0-day.
00:31:45.090 --> 00:31:53.119
If you take, like an S8 or S7, this
vulnerability is fixed but for S3, which
00:31:53.119 --> 00:31:58.759
is end-of-life, these vulnerabilities are
still there. So if you have an S3, you can
00:31:58.759 --> 00:32:08.100
use it … So, let's talk about Samsung's
sboot heap implementation. So if you
00:32:08.100 --> 00:32:15.639
wanted to allocate some size and the heap
chose to use a chunk which is larger than
00:32:15.639 --> 00:32:19.810
the size that you wanted to allocate, it
will split it from the end. And you will
00:32:19.810 --> 00:32:22.770
see an illustration in a moment.
And the thing to
00:32:22.770 --> 00:32:26.670
note about this heap implementation is
that there is no security mitigations at
00:32:26.670 --> 00:32:36.890
all. It's very basic. So … let's say that
you wanted to allocate 50 bytes and the
00:32:36.890 --> 00:32:41.769
chunk that it chose was 100 bytes, then it
will give you this part, which is the
00:32:41.769 --> 00:32:48.559
bottom part of the buffer. And the buffer,
the chunk header, has a size number … a
00:32:48.559 --> 00:32:57.199
size parameter and it will use this size
to go to the end. So I wanted to achieve
00:32:57.199 --> 00:33:02.809
write-what-where in order to exploit
sboot. And I used … I exploited the chunk
00:33:02.809 --> 00:33:08.570
splitting technique. So the first thing to
do was to fake a chunk header which I can
00:33:08.570 --> 00:33:13.629
control with some large size, so it will
get split, and then I had to figure out
00:33:13.629 --> 00:33:20.309
its address. And I can do this with the
first vulnerability, the relative read,
00:33:20.309 --> 00:33:24.159
and then the next step is to make sure
this chunk is actually selected when you
00:33:24.159 --> 00:33:30.159
call malloc. And then, it will try to give
you the bottom part of the buffer. So it
00:33:30.159 --> 00:33:35.119
will start from the chunk address and then
it will go all the way to the bottom,
00:33:35.119 --> 00:33:39.900
which is adding chunk size, and then it
will go back the size you wanted to
00:33:39.900 --> 00:33:43.460
allocate, right? And we want to control
this number and we can control this
00:33:43.460 --> 00:33:50.940
number. So if I just turn around this
equation, if I want to control address, I
00:33:50.940 --> 00:33:58.090
can just use this number as the chunk size
and then it will give me this address. So
00:33:58.090 --> 00:34:02.960
the actual details in my opinion are
boring. So you can find the exploit under
00:34:02.960 --> 00:34:10.780
this repository. It's public, so you can
just take an S3 and use it, and this is a
00:34:10.780 --> 00:34:19.949
demo. This is download mode, and this is
Hello World sboot exploit, so it works.
00:34:19.949 --> 00:34:25.460
OK, so, what if it's really dead? What if
this happened, right? What if also the
00:34:25.460 --> 00:34:29.949
boot partition is gone? So, obiously
something has to load. Has to talk with
00:34:29.949 --> 00:34:36.559
the eMMC and load sboot, right? So there's
also another piece of code which is called
00:34:36.559 --> 00:34:44.770
Exynos boot rom. And it is … it resides in
the main CPU. And what happens normally is
00:34:44.770 --> 00:34:49.760
that the Exynos boot ROM starts and then
it loads something which I call the "first
00:34:49.760 --> 00:34:53.040
bootloader", which is prepended
to sboot, and it is
00:34:53.040 --> 00:35:00.110
signed and it just verifies the signature
of sboot and then jumps into it. So you
00:35:00.110 --> 00:35:06.330
can just think about it as, it's together
with sboot. And then sboot loads the
00:35:06.330 --> 00:35:13.120
kernel. But the boot ROM has to load the
first bootloader and sboot from somewhere,
00:35:13.120 --> 00:35:18.910
so what does it try to do? So it first
starts with the eMMC. But if this fails,
00:35:18.910 --> 00:35:26.240
it goes to the external SD-card. So I just
took sboot and the first bootloader and
00:35:26.240 --> 00:35:31.550
dropped them onto an SD-card. But that
didn't work because sboot boots into, in
00:35:31.550 --> 00:35:36.860
this case, sboot boots into SD-card mode,
in which there's is no USB protocol, so
00:35:36.860 --> 00:35:42.011
you can't exploit it. And, as I said, it
is signed, so I can't patch it. But
00:35:42.011 --> 00:35:49.790
apparently some people over a forum, their
nicknames are AdamOutler, Rebellos, and
00:35:49.790 --> 00:35:54.740
Ralekdev. They found out that there is a
development board, called ODROID-X, which
00:35:54.740 --> 00:35:59.140
uses exactly the same CPU, so it's the
same boot ROM, which uses the same
00:35:59.140 --> 00:36:03.590
signature, but it uses a different first
bootloader, which doesn't do any signature
00:36:03.590 --> 00:36:10.250
checks at all. So if you take this first
bootloader and append to it a patched
00:36:10.250 --> 00:36:14.480
sboot, it will jump into this patched
sboot and then you can just exploit it and
00:36:14.480 --> 00:36:20.720
run your code. And this is the modified
boot process, so you start with Exynos
00:36:20.720 --> 00:36:26.950
boot ROM, you plug in an external SD-card,
the externel SD-card has ODROID-X first
00:36:26.950 --> 00:36:33.130
bootloader, which is signed, so the boot
ROM will jump into it and then the first
00:36:33.130 --> 00:36:38.990
bootloader will jump to the patched sboot
and then you can exploit it and run you
00:36:38.990 --> 00:36:45.260
shell code. And no hardware mode is
required at all. So if the boot partition
00:36:45.260 --> 00:36:50.770
is still intact, the phone loads sboot and
it is stored in your eMMC. But if it is
00:36:50.770 --> 00:36:55.790
corrupt, the phone uses the external SD-
card. And either way, I can load sboot.
00:36:55.790 --> 00:37:00.520
And then I can exploit a vulnerability to
gain code execution in sboot. And the next
00:37:00.520 --> 00:37:09.980
step is to access the eMMC boot ROM. And
as I said before, I need to trigger this
00:37:09.980 --> 00:37:18.520
interrupt #7 and send it … send this
argument somehow. So I just iterated over
00:37:18.520 --> 00:37:24.321
all the possible eMMC commands,
which is from 0 to 63, and I
00:37:24.321 --> 00:37:31.470
powered off the eMMC, powered it back on,
so the boot process gets started again.
00:37:31.470 --> 00:37:36.750
And then I quickly sent a command X with
this argument and I waited for some time
00:37:36.750 --> 00:37:43.070
for the boot process to finish. And then I
sent any command which is supported by the
00:37:43.070 --> 00:37:48.010
boot ROM recovery mode and I checked if I
got any response. And I said, ehhh, this
00:37:48.010 --> 00:37:54.220
is … maybe it's going to work, maybe not,
and then I tried command 0 and it failed,
00:37:54.220 --> 00:37:57.480
and I said, naah, it's never going to
work, and then command 1 worked.
00:37:57.480 --> 00:38:02.300
laughter So this was very exciting for me
because this is the first time, the eMMC
00:38:02.300 --> 00:38:08.730
actually responds. And up until then, on
the bricked device, I tried to send
00:38:08.730 --> 00:38:12.511
several commands to the eMMC and I never
saw a response. And this is the first time
00:38:12.511 --> 00:38:18.060
I actually saw a response from the eMMC
and this was very exciting. And the eMMC
00:38:18.060 --> 00:38:22.821
even has command 62, you know, this
backdoor mode, so let's fix it. Let's
00:38:22.821 --> 00:38:28.540
repair the eMMC. So, there are two
revisions of this faulty chip. The first
00:38:28.540 --> 00:38:35.980
revision uses a firmware 0xF1, which is
buggy, and then there were phones with
00:38:35.980 --> 00:38:42.120
firmware revision 0xF7 in which the bug
never occurred. So probably Samsung fixed
00:38:42.120 --> 00:38:47.770
the bug in later hardware revisions. So my
goal was to update the chip to firmware
00:38:47.770 --> 00:38:55.420
0xF7 and format the FTL metadata so
the corruption is gone. OK, so … what I
00:38:55.420 --> 00:39:00.780
did was to write a dump tool, a firmware
dump tool, which is a kernel module. And
00:39:00.780 --> 00:39:06.730
then I had to convince anybody over … the
Internet … to run my code which sends low-
00:39:06.730 --> 00:39:12.240
level eMMC commands to … on their own
device. laughter And thanks to @artesea,
00:39:12.240 --> 00:39:20.830
which was courage enough to try it, I got
a dump of firmware 0xF7 and it worked. And
00:39:20.830 --> 00:39:27.480
now I just had to write it to the eMMC
itself. So this is absolutely doable
00:39:27.480 --> 00:39:33.950
because I could've used the memory write
backdoor to write my own code and access
00:39:33.950 --> 00:39:39.240
the NAND flash chip and write a new
firmware. But then I found out something
00:39:39.240 --> 00:39:44.330
simpler. So there's another backdoor,
which is command 60, and it has two
00:39:44.330 --> 00:39:48.990
firmware upgrade modes for some
reason. So the former mode,
00:39:48.990 --> 00:39:56.950
which is 0xCBAD1160, supports FTL
metadata format. You can send an erase
00:39:56.950 --> 00:40:02.670
command and it will format all the FTL
metadata. And then you can write a new
00:40:02.670 --> 00:40:12.070
firmware and it will do everything for
you. So how do I fix a dead S3? I just get
00:40:12.070 --> 00:40:18.270
a dead S3, which should be … this is
important to note … the … many … there's
00:40:18.270 --> 00:40:24.420
different revisions of Galaxy S3. I'm
talking about GT-I9300, which is the
00:40:24.420 --> 00:40:30.710
international version. Boot to sboot,
either directly, if the boot partition is
00:40:30.710 --> 00:40:36.230
still intact, or by using an external SD-
card. Then exploit sboot to run your own
00:40:36.230 --> 00:40:43.720
code. From the shell code, reboot the eMMC
into boot ROM recovery mode and then use
00:40:43.720 --> 00:40:48.820
command 60 to format the FTL metadata and
flash the new firmware, 0xF7 firmware.
00:40:48.820 --> 00:40:53.290
Then reboot the eMMC so the firmware
loading … actually boots and then you can
00:40:53.290 --> 00:40:58.390
write sboot to the eMMC's boot partition.
And there is another step, which is … to
00:40:58.390 --> 00:41:06.760
profit. And this means, it is demo time!
So, I pray to the demo gods that it is
00:41:06.760 --> 00:41:17.030
going to happen, it is going to succeed.
So, yeah … This … OK, so I have a bricked
00:41:17.030 --> 00:41:22.130
device, I bricked it on purpose. This is
the device. If I try to turn it on---
00:41:22.130 --> 00:41:29.470
there's a battery inside---nothing
happens. It is bricked. If I try to get
00:41:29.470 --> 00:41:43.360
into download mode, nothing works. I have
this external SD card which does have
00:41:43.360 --> 00:41:53.320
sboot as I said before. And if I plug it
in, and I try to boot the device, it
00:41:53.320 --> 00:42:10.890
should boot into … Yeah, okay. So, it
boots into something and now I can use …
00:42:10.890 --> 00:42:22.341
Just go back to the … yeah. And now I can
plug it into the USB and sboot answers,
00:42:22.341 --> 00:42:30.870
and now I am going to run a shell code,
which fixes the eMMC. It’s retrying, it is
00:42:30.870 --> 00:42:35.700
okay. Shell code started. It rebooted the
eMMC into bootrom mode, and now it will
00:42:35.700 --> 00:42:43.080
write the new firmware. And it should take
a couple of seconds, so … hold tight, as
00:42:43.080 --> 00:42:53.630
it said… Okay, yeah, so the next thing is
going to be to reboot into the firmware
00:42:53.630 --> 00:43:02.610
and then change the boot partition size so
that there's actually a boot partition.
00:43:02.610 --> 00:43:10.770
Yeah, and now the shell command is done
and I can just use a different SD card
00:43:10.770 --> 00:43:16.211
which loads sboot normally and it goes
into SD card mode and in this SD card
00:43:16.211 --> 00:43:31.230
mode, it will write sboot to the boot
partition, so … Let me just … Yeah, okay.
00:43:31.230 --> 00:43:36.990
So this is SD card mode. I think you can't
see, but if I now remove this SD card,
00:43:36.990 --> 00:43:47.390
right? And just reboot the device, so …
the battery is outside and now it's … yeah
00:43:47.390 --> 00:43:52.560
… It should boot into … yeah! So, this is
sboot! So the device is fixed.
00:43:52.560 --> 00:44:06.900
applause
00:44:06.900 --> 00:44:16.970
Thank you! So, conclusion. A few
shoutouts, so … Rebellos, AdamOutler, and
00:44:16.970 --> 00:44:24.890
Ralekdev did all the Exynos U-Boot, first
bootloader, ODROID-X work, so … Thanks to
00:44:24.890 --> 00:44:31.610
them! I couldn't … if it weren't for them,
I couldn't boot bricked devices.
00:44:31.610 --> 00:44:39.190
Entropy512 was involved in the eMMC
research back in 2013 and bunnyxobs held a
00:44:39.190 --> 00:44:47.160
wonderful talk here at CCC some years ago.
And he talked about hacking Chinese SD
00:44:47.160 --> 00:44:51.020
cards and they mentioned my research, and
this motivated me to complete it because it
00:44:51.020 --> 00:44:59.660
was still in progress. This is the reason
for which I'm talking today, so … thanks!
00:44:59.660 --> 00:45:06.010
applause
00:45:06.010 --> 00:45:12.740
So, I can basically own Samsung
eMMCs, I can fix bricked S3 with just
00:45:12.740 --> 00:45:18.030
software, and, imagine, this is just a
use-case, because now you can do
00:45:18.030 --> 00:45:25.940
interesting stuff with your eMMC chip. And
what I think we should do next is to look
00:45:25.940 --> 00:45:32.040
at newer eMMCs which I suspect still has
this backdoor, because I tried some chip
00:45:32.040 --> 00:45:39.680
which I could get my hands on and it had
this backdoor, so … Maybe even the new
00:45:39.680 --> 00:45:47.450
ones also has this mode. And then there's
UFS, which is the bus which replaces eMMC
00:45:47.450 --> 00:45:55.970
and it is based on SCASI and Samsung also
produces UFS chips so it might be wanting
00:45:55.970 --> 00:46:03.460
to see if there's a similar backdoor. And
it's also interesting to look at different
00:46:03.460 --> 00:46:08.840
vendors of eMMCs and maybe one day write
an open-source alternative firmware for
00:46:08.840 --> 00:46:15.410
these devices. So this is question time.
You can find the code that I wrote to
00:46:15.410 --> 00:46:19.270
experiment with these devices over the
following links, and you can find the
00:46:19.270 --> 00:46:25.760
slides in the bottom link. It's already
public, so go ahead. And if you have any
00:46:25.760 --> 00:46:28.820
questions, this is the time, so … thanks!
00:46:28.820 --> 00:46:38.510
applause
00:46:38.510 --> 00:46:40.150
Herald: So thank you very much, Oran, for
00:46:40.150 --> 00:46:43.000
a really interesting talk. If you have
questions, there are two microphones in
00:46:43.000 --> 00:46:48.580
this aisle, and then two on the sides, and
first question from microphone #2.
00:46:48.580 --> 00:46:49.690
Microphone #2: It's pretty amazing what
00:46:49.690 --> 00:46:54.970
you did. Did you guys get any feedback
from Samsung on this?
00:46:54.970 --> 00:46:58.290
Oran: Yeah, so … I published my research
00:46:58.290 --> 00:47:08.100
back in 2012 … 2013, sorry, over forums
and I didn't use it from a security
00:47:08.100 --> 00:47:17.470
perspective. I wanted to fix S3. They
never responded or … they didn't contact
00:47:17.470 --> 00:47:24.950
me in any way. I didn't contact them about
the boot ROM recovery mode, because in my
00:47:24.950 --> 00:47:34.170
opinion it is not a security issue. And it
can be fixed. And regarding the sboot
00:47:34.170 --> 00:47:40.080
vulnerabilities, there is no … it's
already patched, so … No, the answer is:
00:47:40.080 --> 00:47:41.520
No.
00:47:41.520 --> 00:47:44.480
Microphone #2: So, the way I understand
it, this is the only way to fix some of
00:47:44.480 --> 00:47:46.490
the phones that are broken
out there, right?
00:47:46.490 --> 00:47:49.050
Oran: Yeah, I don't know any other way to
00:47:49.050 --> 00:47:50.260
do it.
00:47:50.260 --> 00:47:51.550
M#2: OK, thanks.
00:47:51.550 --> 00:47:53.570
Herald: Microphone #1.
00:47:53.570 --> 00:47:57.990
Microphone #1: After seeing a real-life
FTL, do you still use SSDs?
00:47:57.990 --> 00:47:59.070
Oran: Sorry?
00:47:59.070 --> 00:48:00.760
Microphone #1: After seeing a real-life
00:48:00.760 --> 00:48:05.100
FTL, do you still use SSDs or
other flash devices?
00:48:05.100 --> 00:48:09.180
Oran: Yeah, this is a good question … it's
00:48:09.180 --> 00:48:17.710
okay. And I don't … there's no
alternative, right? So … but we might
00:48:17.710 --> 00:48:22.440
make something, so …
00:48:22.440 --> 00:48:25.150
Herald: Mic number three.
00:48:25.150 --> 00:48:31.250
Microphone #3: Do you have any idea what
other devices have this model eMMC and
00:48:31.250 --> 00:48:37.580
support the same commands that let you
access the firmware? ’cause there is other
00:48:37.580 --> 00:48:40.500
devices that had bad eMMC.
00:48:40.500 --> 00:48:47.760
Oran: Ah, okay, so … Samsu… Galaxy S2 had
a similar bug and Kindle Fire, I think,
00:48:47.760 --> 00:48:53.440
one of their versions. And some of them
got patches by Samsung and it's usually
00:48:53.440 --> 00:48:58.450
was something like this, like: Patch the
internal memory everytime the device boots
00:48:58.450 --> 00:49:06.880
so the bug never happens. I think, in the
other devices, the bug was actually fixed.
00:49:06.880 --> 00:49:08.500
Microphone #3: But are you aware of any
00:49:08.500 --> 00:49:15.930
non-Samsung devices that have Samsung MMCs
in them that might be the same MMC?
00:49:15.930 --> 00:49:16.730
Oran: I'm sorry?
00:49:16.730 --> 00:49:17.840
Microphone #3: Are there other devices
00:49:17.840 --> 00:49:21.270
that aren't Samsung phones but still have
Samsung parts in them?
00:49:21.270 --> 00:49:23.300
Oran: Yeah, ah! So, there's not a lot of
00:49:23.300 --> 00:49:27.740
eMMC manufacturers and Samsung is a big
manufacturer, so … A lot of different
00:49:27.740 --> 00:49:35.750
phones and devices use Samsung eMMCs, so …
yes. It is relevant to non-Samsung devices.
00:49:35.750 --> 00:49:37.320
Herald: Number one.
00:49:37.320 --> 00:49:42.110
Microphone #1: Hey, thanks for your
amazing talk and research. Two questions:
00:49:42.110 --> 00:49:48.540
There's the Samsung Galaxy Note 2 that has
more or less the same bug, does your fix
00:49:48.540 --> 00:49:54.540
and your research also apply to that
device? And is there a way to a chip-off
00:49:54.540 --> 00:49:59.910
dump without erasing the FTL
and contents of the card?
00:49:59.910 --> 00:50:01.990
Oran: Yeah, so, this is a good question.
00:50:01.990 --> 00:50:07.090
The first question was … the S2
has the same bug, right?
00:50:07.090 --> 00:50:08.310
Microphone #1: The Note 2! The …
00:50:08.310 --> 00:50:09.470
Oran: Ah! The Note 2! Ah, okay. I don't
00:50:09.470 --> 00:50:13.260
know. I never had a Note 2, so.
00:50:13.260 --> 00:50:16.730
Microphone #1: I have one
that is bricked that way.
00:50:16.730 --> 00:50:18.630
Oran: But would be interesting to try.
00:50:18.630 --> 00:50:23.880
True! So, that's that. And regarding the
second question: My code actually formats
00:50:23.880 --> 00:50:29.710
all the FTL metadata which is not that
good because it erases all this
00:50:29.710 --> 00:50:38.190
information about how many times every
block was erased. A more proper fix would
00:50:38.190 --> 00:50:43.460
be to actually fix the corrupted metadata
but I haven't got to the point in which I
00:50:43.460 --> 00:50:50.500
can fully understand the inner workings of
the FTL. So, this is my current code but
00:50:50.500 --> 00:50:54.460
you are welcome to try to improve it.
00:50:54.460 --> 00:50:55.790
Microphone #1: Wonderful.
00:50:55.790 --> 00:50:57.680
Herald: Microphone number two.
00:50:57.680 --> 00:51:01.680
Microphone #2: I'd like to know what the
timeframe was from you working on the
00:51:01.680 --> 00:51:04.590
issue 'til you had the first fixed S3.
00:51:04.590 --> 00:51:12.640
Oran: Yeah, so, I obtained the firmware
back in 2013 and I had a working device
00:51:12.640 --> 00:51:24.040
and I didn't want to do … like … bad stuff
to it. So I stopped back in this year, and
00:51:24.040 --> 00:51:30.230
then last year, a friend of mine said that
he had a bricked S3 so I said, let's try
00:51:30.230 --> 00:51:36.770
to fix it. So I think if you, like,
accumulate the time, it's probably going
00:51:36.770 --> 00:51:43.660
to be, like, a timeframe which I worked,
actively worked on this, was something
00:51:43.660 --> 00:51:49.970
like a few months. Probably four or five
months. But it started back in … four
00:51:49.970 --> 00:51:57.010
years ago, and I finished it something
like a couple of months ago
00:51:57.010 --> 00:51:58.080
Microphone #2: Cool. Thanks!
00:51:58.080 --> 00:51:58.600
Herald: Number One.
00:51:58.600 --> 00:52:01.770
Microphone #1: Do … Do Samsung SD cards
00:52:01.770 --> 00:52:04.510
have the same undocumented commands?
00:52:04.510 --> 00:52:09.300
Oran: Yeah, I suspect, they do. Some of
them. I actually bought some Samsung SD
00:52:09.300 --> 00:52:15.690
cards and they had controllers made by
Silicon Motion but I read over the
00:52:15.690 --> 00:52:25.130
Internet that some specific cards, I think
it's Evo+ Plus have Samsung controllers
00:52:25.130 --> 00:52:35.440
which should have the same backdoor, so,
I'm trying to buy one but as soon as I
00:52:35.440 --> 00:52:38.700
find out, I will probably post about it.
00:52:38.700 --> 00:52:39.340
Microphone #1: Thank you.
00:52:39.340 --> 00:52:41.940
Herald: Number three.
00:52:41.940 --> 00:52:47.670
Microphone #3: OK, thanks for the great
talk. So, I'm using an S3 as my everyday
00:52:47.670 --> 00:52:56.450
phone, so what actually happened a few
months ago, it broke down but … so I still
00:52:56.450 --> 00:53:03.500
saw the Samsung bootloader, the sboot,
what it is called, and afterwards it got
00:53:03.500 --> 00:53:10.071
stuck at the bootscreen from the OS, so in
my case it was Cyanogenmod, but also, when
00:53:10.071 --> 00:53:14.060
I flashed on something else, like
LineageOS, or the default Samsung's
00:53:14.060 --> 00:53:19.180
firmware, it still got stuck. I really had
to re-flash everything and then it worked
00:53:19.180 --> 00:53:25.060
again. That somehow sounds really similar
to the bug you described, but in a way it
00:53:25.060 --> 00:53:30.140
also doesn't. Do you think
it's the same thing?
00:53:30.140 --> 00:53:33.500
Oran: So, if it's related, my guess would
00:53:33.500 --> 00:53:41.481
be that your device have this in-memory
patch which freezes the eMMC and when you
00:53:41.481 --> 00:53:49.700
used LineageOS or what it was before, this
infinite loop triggered at some point in
00:53:49.700 --> 00:53:55.130
the boot process so the device actually
froze before it got to boot Android. But
00:53:55.130 --> 00:53:59.840
then, when you flashed it, somehow, the
internal block mapping got changed and now
00:53:59.840 --> 00:54:08.500
it doesn't trigger this freezing. But if
your chip is VTU00M and its firmware is
00:54:08.500 --> 00:54:11.470
0xF1, then you definitely have the bug.
00:54:11.470 --> 00:54:14.140
Microphone #3: OK, thanks.
00:54:14.140 --> 00:54:15.790
Herald: Number One.
00:54:15.790 --> 00:54:19.470
Microphone #1: Hi! Thanks for the great
work. One question: You said, you upgraded
00:54:19.470 --> 00:54:24.490
the firmware of the eMMC with a newer
revision. Are these firmwares actually
00:54:24.490 --> 00:54:28.620
signed or can you flash anything
on the eMMC controller?
00:54:28.620 --> 00:54:31.700
Oran: You can flash anything … yeah. They
00:54:31.700 --> 00:54:39.240
have a simple heuristic which checks if
the stack address is … looks normal, but
00:54:39.240 --> 00:54:44.740
other than that, it boots every firmware
you give it. I think, in your eMMCs, which
00:54:44.740 --> 00:54:52.601
is eMMC 5.1, there's a mechanism of
flashing new firmwares and I think it
00:54:52.601 --> 00:54:59.781
should be signed but I don't have a newer
eMMC, so … I don't know about it, but
00:54:59.781 --> 00:55:00.691
yeah.
00:55:00.691 --> 00:55:02.300
Microphone #1: Thank you.
00:55:02.300 --> 00:55:06.930
Herald: So … I have one last question,
about the Samsung patch. You said that it
00:55:06.930 --> 00:55:11.960
basically goes into some sort of infinite
loop. But do you think they tried to some
00:55:11.960 --> 00:55:14.220
busy wait or they're waiting
for something to happen?
00:55:14.220 --> 00:55:18.520
Oran: No, I think they just want … they
00:55:18.520 --> 00:55:26.200
want the bug to never happen, so … Yeah, I
… my phone froze a lot of times and I
00:55:26.200 --> 00:55:30.190
waited like, I don't know, 30 minutes. And
the code in the Linux kernel doesn't do
00:55:30.190 --> 00:55:34.740
anything, and the code in the eMMC
firmware doesn't do anything, so my guess:
00:55:34.740 --> 00:55:37.800
It just waits forever.
00:55:37.800 --> 00:55:40.830
Herald: I see no more questions, so again,
a big round of applause to Oran for great
00:55:40.830 --> 00:55:42.136
work.
00:55:42.136 --> 00:55:46.500
applause
00:55:46.500 --> 00:55:51.310
34c3 outro
00:55:51.310 --> 00:56:08.000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!