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