1
00:00:00,000 --> 00:00:16,869
34c3 intro
2
00:00:16,869 --> 00:00:21,539
Herald: Right, so. Once again, good
morning. Our next talk, next speaker
3
00:00:21,539 --> 00:00:26,910
today, this morning is an independant
security researcher. He founded the Pasten
4
00:00:26,910 --> 00:00:31,160
CTF group, which some of you might have
heard of. And he has previously worked on
5
00:00:31,160 --> 00:00:35,740
OpeniBoot. Please give a big round of
applause to Oran Avraham.
6
00:00:35,740 --> 00:00:43,670
applause
7
00:00:43,670 --> 00:00:46,830
Oran: Can you hear me? OK. So I'm going to
8
00:00:46,830 --> 00:00:55,240
talk about how I hacked the eMMC chips or
how we fixed dead Galaxy S3 devices.
9
00:00:55,240 --> 00:01:01,649
First, an introduction about myself or:
Who am I? I'm Oran Avraham, 25 years old.
10
00:01:01,649 --> 00:01:06,560
I'm a security reasearcher based in
Isreal. I'm currently working at a startup
11
00:01:06,560 --> 00:01:12,299
called Medigate. However this talk has no
connection to my employer whatsoever. I
12
00:01:12,299 --> 00:01:17,979
previously worked on OpeniBoot which was
an open-source alternative bootloader for
13
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
14
00:01:25,309 --> 00:01:34,449
some success. I also found vulnerabilities
in the early iPhone baseband, which were
15
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
16
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
17
00:01:48,640 --> 00:01:53,369
want to reach me, you can find on my
website and there's also my twitter
18
00:01:53,369 --> 00:01:57,609
username. OK, so, an outline about this
talk. I am going to start with an
19
00:01:57,609 --> 00:02:03,869
introduction about the story. How I got to
hack eMMC devices. Then, we'll talk about
20
00:02:03,869 --> 00:02:11,100
Samsung's eMMC patch, which they used for
Galaxy S3 devices, then I will talk about
21
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
22
00:02:20,630 --> 00:02:25,850
itself, that was in Samsung Galaxy S3
devices. And then, I'm going to talk about
23
00:02:25,850 --> 00:02:33,540
how do we resurrect bricked devices. So,
let's start with the introduction. This
24
00:02:33,540 --> 00:02:38,960
phenomenon was called "Sudden Death
Syndrome". This was the name that they
25
00:02:38,960 --> 00:02:46,471
gave it over forums, and it started in
2012. Samsung Galaxy S3 devices just
26
00:02:46,471 --> 00:02:51,830
started dying with no apparent reason. You
could use your phone and then one day it
27
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
28
00:02:57,250 --> 00:03:02,130
basically a brick. And if you're lucky,
the phone will boot into the bootloader so
29
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
30
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
31
00:03:14,230 --> 00:03:19,990
in a USB cable, you'll see nothing. You
cannot even charge the battery because the
32
00:03:19,990 --> 00:03:26,510
actual charging
mechanism isn't powered on, so… yeah. And
33
00:03:26,510 --> 00:03:31,250
there were a lot of rants in forums. This
is an example: Somebody said, "this is
34
00:03:31,250 --> 00:03:36,590
happening to a lot of people. I hope,
Samsung do something about this!" And,
35
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.
36
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.
37
00:03:48,840 --> 00:03:54,070
You can see the beautiful background and
everything is powered on. And this is a
38
00:03:54,070 --> 00:03:59,300
dead one. laughter Yeah, the screen is
just black, you cannot do anything.
39
00:03:59,300 --> 00:04:03,530
Actually, as I said before, if you're
lucky, you'll see this screen which is
40
00:04:03,530 --> 00:04:09,820
drawn by the bootloader, which is called
"Samsung sboot" and it won't boot … this
41
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
42
00:04:15,500 --> 00:04:18,370
will get this screen which is called
"Download Mode", and we will talk about it
43
00:04:18,370 --> 00:04:26,640
later. So this is my understanding … this
is my current understanding on how S3
44
00:04:26,640 --> 00:04:33,160
works. So, this is a rough schematics;
there's a lot of different peripherals
45
00:04:33,160 --> 00:04:40,180
that are not there, obviously. There's the
main CPU, which is called "Samsung
46
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
47
00:04:47,140 --> 00:04:52,530
device. It is the standard storage device
for phones. And there is some NAND flash
48
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
49
00:04:58,130 --> 00:05:06,160
NAND flash chip- OK, so … then, Samsung
dropped a patch. And what happened is that
50
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-
51
00:05:14,340 --> 00:05:19,860
licensed, they had to publish the source
code. So, the patch was called "Soft-patch
52
00:05:19,860 --> 00:05:29,730
MoviNAND VTU00M eMMC failure" and it's …
they modified the file responsible … the
53
00:05:29,730 --> 00:05:34,950
code responsible for communicating with
eMMC devices. So in order to understand
54
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
55
00:05:43,000 --> 00:05:49,400
de-facto standard storage for phones.
Actually, nowadays, high-end phones are
56
00:05:49,400 --> 00:05:57,470
starting to use UFS, which is the bus that
replaces eMMC, but the majority of phones
57
00:05:57,470 --> 00:06:01,730
still use eMMC. And you
can think about it as an
58
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
59
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
60
00:06:15,590 --> 00:06:24,741
called HardKernel made a PCB which have an
eMMC chip soldered onto it and you can …
61
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,
62
00:06:29,480 --> 00:06:37,129
it just turns the eMMC into an SD-card
device. And it works. So, eMMC is
63
00:06:37,129 --> 00:06:42,520
essentially a NAND flash chip with
convenient bus, which is the same bus as
64
00:06:42,520 --> 00:06:49,510
SD-cards. So, for this reason, some people
also called this an "internal SD-card", or
65
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
66
00:06:55,280 --> 00:07:03,740
talk about the eMMC chip. So, when you
communicate with the eMMC bus, you send
67
00:07:03,740 --> 00:07:10,240
commands to the card and there are 64
commands. And they are denoted from
68
00:07:10,240 --> 00:07:16,430
command 0 up to 63. For example, you have
command 17, which is READ_SINGLE_BLOCK,
69
00:07:16,430 --> 00:07:22,540
and command 24, which is WRITE_BLOCK, and
each command takes a single 32-bit
70
00:07:22,540 --> 00:07:29,430
argument. So you send a command, it has a
number, and an argument. And all the
71
00:07:29,430 --> 00:07:33,580
commands are categorised into classes. And
there is one specific interesting class,
72
00:07:33,580 --> 00:07:37,810
which is class 8. Because if you look at
the specific section, you'll see that
73
00:07:37,810 --> 00:07:44,240
command 60 up to 63 are reserved for the
manufacturer. So if something interesting
74
00:07:44,240 --> 00:07:50,040
is going to happen, it will be probably
happen with these commands. So let's go
75
00:07:50,040 --> 00:07:55,660
back to the patch. Samsung said, they
fixed the bug, right? So S3 devices
76
00:07:55,660 --> 00:08:04,850
shouldn't get bricked anymore. Let's … so,
this patch actually, the first thing that
77
00:08:04,850 --> 00:08:10,570
… it compares the card's name to VTU00M,
which is the hardware revision of the
78
00:08:10,570 --> 00:08:15,669
faulty chip, and then they compare a
number to the value 0xF1, and this is
79
00:08:15,669 --> 00:08:21,920
actually the firmware version of this
chip. And then, they call a function which
80
00:08:21,920 --> 00:08:26,650
is called mmc_start_movi_smart, which
isn't that interesting, so I'm not going
81
00:08:26,650 --> 00:08:32,499
to talk about. And if all this comparisons
are true, then it will call
82
00:08:32,499 --> 00:08:35,419
mmc_start_movi_operation, which is the
main logic
83
00:08:35,419 --> 00:08:44,489
responsible for fixing the chip. And the
thing to note about this patch is that it
84
00:08:44,489 --> 00:08:48,920
… this code runs everytime you boot the
device. So everytime the eMMC chip is
85
00:08:48,920 --> 00:08:55,619
powered on, this code runs. OK, so let's
talk about mmc_start_movi_operation. So,
86
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
87
00:09:02,189 --> 00:09:07,980
basically the logic that they used. And
this is very interesting. There is one
88
00:09:07,980 --> 00:09:16,740
strange thing about this function. This
mmc_movi_erase_cmd … erase is … an eMMC
89
00:09:16,740 --> 00:09:23,269
command which takes two arguments. It uses
two arguments because you precede it with
90
00:09:23,269 --> 00:09:28,499
a different command, so you can give it
two arguments. And the first arguments is
91
00:09:28,499 --> 00:09:33,949
this start block number to erase, and the
second one is the end block number to
92
00:09:33,949 --> 00:09:39,689
erase. And it erases all the blocks in-
between. So what should happen is that the
93
00:09:39,689 --> 00:09:46,980
first call to this function should erase
all the blocks starting with 40300 up to
94
00:09:46,980 --> 00:09:56,769
block number 4A03B510, right? This doesn't
make any sense, and then the next call is
95
00:09:56,769 --> 00:10:02,279
the … the ranges overlap. And this was
very strange. So my guess was that this is
96
00:10:02,279 --> 00:10:08,390
probably not an erase command. It is
probably something else, somehow. And the
97
00:10:08,390 --> 00:10:13,009
next thing to note about this function is
that you see the first two calls are
98
00:10:13,009 --> 00:10:19,809
mmc_movi_cmd, and the last calls are also
to the function mmc_movi_cmd. And
99
00:10:19,809 --> 00:10:25,129
mmc_movi_cmd is basically command 62,
which is a class-8-command. So it is
100
00:10:25,129 --> 00:10:34,089
reserved to the manufacturer. And my guess
was that the first two calls basically
101
00:10:34,089 --> 00:10:39,589
enter some secret backdoor mode that
Samsung hid inside the eMMC chip. And the
102
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
103
00:10:46,360 --> 00:10:52,839
do erase anymore. It does something else.
And then, I saw that if you inspect the
104
00:10:52,839 --> 00:10:56,949
first argument, you'll see that the
numbers are consecutive and they increment
105
00:10:56,949 --> 00:11:06,079
by four, except for the last number. All
the first … the first five numbers are
106
00:11:06,079 --> 00:11:12,199
consecutive. And the next thing … so it
looks something like memory addresses,
107
00:11:12,199 --> 00:11:18,060
right? And if you look at the second
argument, I noticed
108
00:11:18,060 --> 00:11:26,809
something very interesting. If I assumed
this is memory data, then if you look at
109
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
110
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
111
00:11:40,240 --> 00:11:45,869
instruction set from the ARM
specification. And functions in Thumb
112
00:11:45,869 --> 00:11:54,350
start with PUSH, right? So this is an eMMC
next to a thumb. laughter And basically,
113
00:11:54,350 --> 00:11:58,869
this is my current understanding of how
eMMC works. So you have this whole eMMC
114
00:11:58,869 --> 00:12:02,220
chip, but there is not only a NAND flash
inside it, there is also a
115
00:12:02,220 --> 00:12:06,839
microcontroller. And in Samsung's case,
this is an ARM-based microcontroller which
116
00:12:06,839 --> 00:12:14,119
contains some firmware. So I thought this
patch might modify the internal memory of
117
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
118
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
119
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
120
00:12:35,240 --> 00:12:42,990
Samsung's patch. So … at the bottom, you
can see the actual Thumb instructions but
121
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
122
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
123
00:12:52,420 --> 00:12:57,589
into an infinite loop. And this is
interesting, because later on, I
124
00:12:57,589 --> 00:13:03,809
understood that what was there before the
patch, it was just a call to this function
125
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
126
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
127
00:13:15,469 --> 00:13:20,899
infinite loop. So my thought was, this
can't fix anything, right? laughter
128
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
129
00:13:26,119 --> 00:13:34,699
into an infinite loop. And then I read
some threads over forums and I saw this
130
00:13:34,699 --> 00:13:40,059
thread. "Ultimate Galaxy S3 unusual
freezing thread" And this is a quote from
131
00:13:40,059 --> 00:13:43,439
the actual thread, you can see that
"Galaxy S3 is freezing with lockups,
132
00:13:43,439 --> 00:13:47,509
screen not responding … and ending with
unusual rebooting and bootlooping …
133
00:13:47,509 --> 00:13:51,749
Angry S3 users reporting this problem …
And it keeps freezing every five minutes
134
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
135
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,
136
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
137
00:14:12,610 --> 00:14:17,599
wanted to do is to obtain the eMMC
firmware in order to understand how it
138
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
139
00:14:23,319 --> 00:14:29,170
write the eMMC's memory, right? So I can
just write code to random locations and
140
00:14:29,170 --> 00:14:37,259
hopefully it will get run somehow. And
then, just write things to different
141
00:14:37,259 --> 00:14:43,380
addresses and do lucky guesses and maybe I
will see something on the eMMC bus and
142
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
143
00:14:50,309 --> 00:14:55,649
I thought about doing is to fuzz different
commands. Like use command 60, 61,
144
00:14:55,649 --> 00:15:02,089
different class-8-commands. But I didn't
want to destroy my own eMMC, which was
145
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
146
00:15:07,800 --> 00:15:13,949
you look for clues? I just googled these
numbers that Samsung used to enter this
147
00:15:13,949 --> 00:15:18,850
backdoor mode. And I saw a different
patch. So this is a patch from a different
148
00:15:18,850 --> 00:15:23,660
device, and it is called "Patch the
firmware of certain Samsung emmc parts to
149
00:15:23,660 --> 00:15:31,929
fix a bug" … ehhh laughter … and it used
the same mode as before, so notice that
150
00:15:31,929 --> 00:15:41,761
they use arguments 0xEFAC62EC and then it
is 0x10210000. And this is important. So
151
00:15:41,761 --> 00:15:48,769
they use 0x10210000, right? And then they
write the value 0xFF to the address for
152
00:15:48,769 --> 00:15:55,699
the D9C. But then there was something else
afterwards. So if you continue to read
153
00:15:55,699 --> 00:16:01,939
this patch, you will se this thing. This
is a snippet which is enclosed by #ifed,
154
00:16:01,939 --> 00:16:08,809
which is called test_mmc_fw_patching, and
they used the same emmc 62EC as before,
155
00:16:08,809 --> 00:16:18,511
but now they use the argument 10210002.
And the next thing is that they … they use
156
00:16:18,511 --> 00:16:24,120
an erase command with the same addresses
as before, but then they do a read
157
00:16:24,120 --> 00:16:30,119
command, right? I was wondering … hm …
this might be
158
00:16:30,119 --> 00:16:35,219
Samsung's way of reading the memory
address of the … the memory of the eMMC
159
00:16:35,219 --> 00:16:39,709
chip. Because they use an erase command
with the same address as before. The
160
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
161
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
162
00:16:52,079 --> 00:16:57,649
snippet of code? Which basically just
loops over all the addresses in the
163
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
164
00:17:04,510 --> 00:17:12,009
DWORD everytime and I dumped it into a
file. And then, I got this thing, which
165
00:17:12,009 --> 00:17:20,599
looks like a firmware, right? So … the
names aren't the names that you see, like,
166
00:17:20,599 --> 00:17:27,999
MMI, and hard_fault … these are all my
names. What I saw was addresses, but this
167
00:17:27,999 --> 00:17:36,250
looks like a Thumb vector table. So I
understood that I basically got the
168
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
169
00:17:42,539 --> 00:17:46,970
analyse what the bug is. So luckily for
me, the firmware contains Strings, so I
170
00:17:46,970 --> 00:17:51,800
can use them as part of my reverting
process. But unfortunately, it contained a
171
00:17:51,800 --> 00:18:00,990
String. A single String. And it was this
string,. Which isn't very useful, if you
172
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
173
00:18:08,480 --> 00:18:17,500
reversing process. I used a lot of, like,
names, flip_bit_in_somewhere, memory
174
00:18:17,500 --> 00:18:26,619
mapped I/O 1000 2 DWORDS … But, I
basically understood the high-level logic
175
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
176
00:18:32,240 --> 00:18:37,740
firmware. So let's talk about debug.
Before we talk about debug, we have to
177
00:18:37,740 --> 00:18:45,700
talk about what is eMMC exactly. So let's
talk about normal storage first. This is,
178
00:18:45,700 --> 00:18:51,401
like, hard-drives. You have two operations
which you can do. You have a read
179
00:18:51,401 --> 00:18:54,710
operation which reads data from the device
and then you have a write operation which
180
00:18:54,710 --> 00:19:01,140
writes data onto the device. This is
pretty normal. Then you have NAND flash
181
00:19:01,140 --> 00:19:06,770
storage. So if you have NAND flash
storage, you can do a read operation which
182
00:19:06,770 --> 00:19:13,500
still reads data, and this is as before,
but write operation actually turns off
183
00:19:13,500 --> 00:19:17,789
bits. If a bit was already 0,
it won't turn into
184
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
185
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.
186
00:19:30,990 --> 00:19:37,720
An erase operation erases a whole erase-
block. It turns all this bits in the block
187
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
188
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
189
00:19:53,700 --> 00:20:01,309
100'000 erases, the block will eventually
die and is not usable anymore. So
190
00:20:01,309 --> 00:20:10,120
something have to … some software have to
do this translation to take this (…?)
191
00:20:10,120 --> 00:20:18,000
storage and do an abstraction which will
show it like normal storage. So, this is
192
00:20:18,000 --> 00:20:23,049
called an FTL---or Flash Translation
Layer. This is common. And the FTL is
193
00:20:23,049 --> 00:20:28,380
responsible for many things but some
examples are wear leveling, which is
194
00:20:28,380 --> 00:20:33,410
spreading out erases among different
blocks, so no single block gets erased a
195
00:20:33,410 --> 00:20:39,290
lot of times. And then it also does bad
block management; if block already died,
196
00:20:39,290 --> 00:20:44,630
then it will remap it internally to a
different block. It actually has spare
197
00:20:44,630 --> 00:20:50,809
blocks and then it … the firmware in
Samsung's case is also responsible for the
198
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
199
00:20:59,259 --> 00:21:05,509
write operations on the device, the FTL
has to save some metadata for itself,
200
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
201
00:21:11,730 --> 00:21:19,789
the internal mapping and so on. So it has
some metadata that it saves for itself.
202
00:21:19,789 --> 00:21:27,520
And when you do write operations, it has
to modify this metadata. And the actual
203
00:21:27,520 --> 00:21:35,840
bug was a miscalculation in this code
which---not always, but sometimes---made
204
00:21:35,840 --> 00:21:42,000
the data corrupt. And once it happened---
it should only happen once---if the data
205
00:21:42,000 --> 00:21:48,950
got corrupted---and this is before
Samsung's patch---everytime you try to
206
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
207
00:21:56,049 --> 00:22:01,070
it will raise a CPU exception. And the
default exception handler in Samsung's
208
00:22:01,070 --> 00:22:07,739
case is just an infinite loop. So
the device … so … so you use the device
209
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
210
00:22:14,750 --> 00:22:19,139
tries to parse the metadata and it's
corrupt, so it throws an exception and
211
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
212
00:22:25,090 --> 00:22:29,479
eMMC is basically, essentially, dead.
Because you send commands into it and
213
00:22:29,479 --> 00:22:33,220
nothing responds because the firmware is
the one is dead, the software … that is
214
00:22:33,220 --> 00:22:37,760
responsible for answering eMMC commands.
So Samsung's patch was something about
215
00:22:37,760 --> 00:22:42,960
this. Something like this. Right before
the metadata is about to get corrupted,
216
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,
217
00:22:50,739 --> 00:22:58,549
just halt the CPU so it never happens. And
this then, like, sudden death syndrome
218
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
219
00:23:06,201 --> 00:23:11,820
got the eMMC firmware by analysing
Samsung's patch. The firmware had the bug
220
00:23:11,820 --> 00:23:16,540
causing FTL corruption. Once it happened,
the chip won't boot anymore and Samsung's
221
00:23:16,540 --> 00:23:22,940
patch was to avoid the bug happening at
all. So the next step is, obviously, to
222
00:23:22,940 --> 00:23:31,250
resurrect dead phones, right? … yeah,
what?! How do I … So the eMMC gets into a
223
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
224
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
225
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
226
00:23:51,510 --> 00:23:58,489
it is a code and what it does, it
initialises the eMMC hardware and it loads
227
00:23:58,489 --> 00:24:04,690
the firmware from the NAND flash chip
itself. And this is strange, because if
228
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
229
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
230
00:24:16,269 --> 00:24:21,559
to reside wherever the boot ROM resides,
so they had to, like, bootstrap it from
231
00:24:21,559 --> 00:24:26,370
the external NAND flash. And then it also
has it's own machinery for eMMC commands,
232
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
233
00:24:31,510 --> 00:24:36,110
that, during their
production process, the NAND flash is
234
00:24:36,110 --> 00:24:43,010
empty and there's no firmware. And then,
when Samsung produces these chips, they
235
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
236
00:24:47,830 --> 00:24:53,860
recovery mode and it exposes an eMMC bus
and from there you can write your new
237
00:24:53,860 --> 00:24:58,519
firmware. And the boot ROM is basically a
stripped-down firmware. There's no FTL,
238
00:24:58,519 --> 00:25:05,700
but it looks like the firmware itself. And
this is my current understanding of how S3
239
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
240
00:25:13,120 --> 00:25:17,190
which has a boot ROM, which loads the
firmware from the external NAND flash and
241
00:25:17,190 --> 00:25:23,200
then boots it. So, if we could ever talk
to boot ROM, this might be interesting
242
00:25:23,200 --> 00:25:29,240
because we could maybe do something
interesting. But the firmware loading
243
00:25:29,240 --> 00:25:33,730
actually succeeds because the firmware is
still intact. The boot ROM will try to
244
00:25:33,730 --> 00:25:37,000
load the firmware, the firmware is still
there and it will jump into it and the
245
00:25:37,000 --> 00:25:40,649
firmware executes and goes into infinite
loop so there is no chance of every
246
00:25:40,649 --> 00:25:46,950
talking to the boot ROM, right? Though,
actually, not. This is not correct,
247
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
248
00:25:54,029 --> 00:25:59,970
35ms and if during this time period, some
interrupt fires, this is interrupt #7, I
249
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
250
00:26:08,210 --> 00:26:16,211
they compare it to this constant magic.
And if this comparison is true, firmware
251
00:26:16,211 --> 00:26:22,399
loading is skipped and it goes right into
this recovery mode. And my guess is that …
252
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
253
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
254
00:26:35,669 --> 00:26:42,259
recovery mode. So my guess is that this
interrupt #7 corresponds to some eMMC
255
00:26:42,259 --> 00:26:49,269
command. And this value that they read
from memory-mapped I/O is probably the
256
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
257
00:26:57,080 --> 00:27:02,800
if the chip is already dead. However,
right before it gets stuck, there is a
258
00:27:02,800 --> 00:27:06,430
time window and during this time
window, if you somehow
259
00:27:06,430 --> 00:27:13,789
trigger this interrupt, the boot process
is aborted and it goes right into eMMC
260
00:27:13,789 --> 00:27:18,179
boot ROM recovery mode, which is
interesting. But the phone is already
261
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,
262
00:27:25,080 --> 00:27:31,860
desolder the eMMC and send commands
externally but … ehh … I wanted to, like,
263
00:27:31,860 --> 00:27:40,680
do something with software, because I
don't know how to desolder BGA chips. So
264
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
265
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
266
00:27:53,970 --> 00:27:58,179
said, if you're lucky, you get this
screen. So this is the phone's bootloader.
267
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
268
00:28:03,790 --> 00:28:11,210
eMMC chip doesn't respond, how the main
CPU gets to execute this bootloader? So,
269
00:28:11,210 --> 00:28:16,990
apparently, if you read Samsung's
specification, you will see that the eMMC
270
00:28:16,990 --> 00:28:22,010
has two partitions and it's not a
partition in the filesystem-sense, it's a
271
00:28:22,010 --> 00:28:27,019
partition in the eMMC-sense. And there's a
boot partition and a user partition. And
272
00:28:27,019 --> 00:28:33,189
the boot partition holds sboot in
Samsung's case, which is the bootloader
273
00:28:33,189 --> 00:28:39,930
for the main CPU. And the user partition
holds everything else. So it stores Linux
274
00:28:39,930 --> 00:28:49,499
and all the Android filesystem and all the
apps etc. So the boot partition has its
275
00:28:49,499 --> 00:28:54,990
own FTL metadata and the user partition
also has its own metadata. A friend of
276
00:28:54,990 --> 00:29:02,250
mine had a bricked S3 which does load
sboot. So he gets this screen. And … what
277
00:29:02,250 --> 00:29:07,470
I understood had happened is that only the
user's … the user partition metadata got
278
00:29:07,470 --> 00:29:11,470
corrupted, so the boot partition is still
intact. And I suspect, this is a common
279
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
280
00:29:15,490 --> 00:29:19,269
partition, you write to the user
partition. So if something is about to get
281
00:29:19,269 --> 00:29:25,240
corrupted, it probably will be in the user
partition. So this is how S3 breaks. The
282
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.
283
00:29:31,270 --> 00:29:41,600
And the eMMC parses the boot partition and
it will return sboot to the main
284
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
285
00:29:47,210 --> 00:29:52,980
then the eMMC tries to parse the user
partition metadata and it's corrupt, so it
286
00:29:52,980 --> 00:29:59,690
goes into a loop. So sboot actually has a
device firmware update mode, that is
287
00:29:59,690 --> 00:30:03,689
called "Download mode", and there is
protocol of USB, the phone side is called
288
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
289
00:30:08,129 --> 00:30:13,559
methology. And there's no way of sending
low-level eMMC commands. So if you ever
290
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
291
00:30:20,450 --> 00:30:27,149
this protocol. And in this protocol, you
can't send raw eMMC commands to the eMMC
292
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.
293
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.
294
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
295
00:30:53,110 --> 00:31:00,360
wrote. So, you control this variable is
dumped and if it is 1, it will read
296
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
297
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
298
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
299
00:31:21,480 --> 00:31:27,409
vulnerability. And the second case reads a
size from the USB packet and then reads it
300
00:31:27,409 --> 00:31:35,249
into this USB buffer, which is constantly
allocated on the heap, it's of size 2000,
301
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
302
00:31:40,010 --> 00:31:45,090
vulnerability, right? So eventually I
found that this is not actually a 0-day.
303
00:31:45,090 --> 00:31:53,119
If you take, like an S8 or S7, this
vulnerability is fixed but for S3, which
304
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
305
00:31:58,759 --> 00:32:08,100
use it … So, let's talk about Samsung's
sboot heap implementation. So if you
306
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
307
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
308
00:32:19,810 --> 00:32:22,770
see an illustration in a moment.
And the thing to
309
00:32:22,770 --> 00:32:26,670
note about this heap implementation is
that there is no security mitigations at
310
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
311
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
312
00:32:41,769 --> 00:32:48,559
bottom part of the buffer. And the buffer,
the chunk header, has a size number … a
313
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
314
00:32:57,199 --> 00:33:02,809
write-what-where in order to exploit
sboot. And I used … I exploited the chunk
315
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
316
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
317
00:33:13,629 --> 00:33:20,309
its address. And I can do this with the
first vulnerability, the relative read,
318
00:33:20,309 --> 00:33:24,159
and then the next step is to make sure
this chunk is actually selected when you
319
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
320
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,
321
00:33:35,119 --> 00:33:39,900
which is adding chunk size, and then it
will go back the size you wanted to
322
00:33:39,900 --> 00:33:43,460
allocate, right? And we want to control
this number and we can control this
323
00:33:43,460 --> 00:33:50,940
number. So if I just turn around this
equation, if I want to control address, I
324
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
325
00:33:58,090 --> 00:34:02,960
the actual details in my opinion are
boring. So you can find the exploit under
326
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
327
00:34:10,780 --> 00:34:19,949
demo. This is download mode, and this is
Hello World sboot exploit, so it works.
328
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
329
00:34:25,460 --> 00:34:29,949
boot partition is gone? So, obiously
something has to load. Has to talk with
330
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
331
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
332
00:34:44,770 --> 00:34:49,760
that the Exynos boot ROM starts and then
it loads something which I call the "first
333
00:34:49,760 --> 00:34:53,040
bootloader", which is prepended
to sboot, and it is
334
00:34:53,040 --> 00:35:00,110
signed and it just verifies the signature
of sboot and then jumps into it. So you
335
00:35:00,110 --> 00:35:06,330
can just think about it as, it's together
with sboot. And then sboot loads the
336
00:35:06,330 --> 00:35:13,120
kernel. But the boot ROM has to load the
first bootloader and sboot from somewhere,
337
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,
338
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
339
00:35:26,240 --> 00:35:31,550
dropped them onto an SD-card. But that
didn't work because sboot boots into, in
340
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
341
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
342
00:35:42,011 --> 00:35:49,790
apparently some people over a forum, their
nicknames are AdamOutler, Rebellos, and
343
00:35:49,790 --> 00:35:54,740
Ralekdev. They found out that there is a
development board, called ODROID-X, which
344
00:35:54,740 --> 00:35:59,140
uses exactly the same CPU, so it's the
same boot ROM, which uses the same
345
00:35:59,140 --> 00:36:03,590
signature, but it uses a different first
bootloader, which doesn't do any signature
346
00:36:03,590 --> 00:36:10,250
checks at all. So if you take this first
bootloader and append to it a patched
347
00:36:10,250 --> 00:36:14,480
sboot, it will jump into this patched
sboot and then you can just exploit it and
348
00:36:14,480 --> 00:36:20,720
run your code. And this is the modified
boot process, so you start with Exynos
349
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
350
00:36:26,950 --> 00:36:33,130
bootloader, which is signed, so the boot
ROM will jump into it and then the first
351
00:36:33,130 --> 00:36:38,990
bootloader will jump to the patched sboot
and then you can exploit it and run you
352
00:36:38,990 --> 00:36:45,260
shell code. And no hardware mode is
required at all. So if the boot partition
353
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
354
00:36:50,770 --> 00:36:55,790
corrupt, the phone uses the external SD-
card. And either way, I can load sboot.
355
00:36:55,790 --> 00:37:00,520
And then I can exploit a vulnerability to
gain code execution in sboot. And the next
356
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
357
00:37:09,980 --> 00:37:18,520
interrupt #7 and send it … send this
argument somehow. So I just iterated over
358
00:37:18,520 --> 00:37:24,321
all the possible eMMC commands,
which is from 0 to 63, and I
359
00:37:24,321 --> 00:37:31,470
powered off the eMMC, powered it back on,
so the boot process gets started again.
360
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
361
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
362
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
363
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,
364
00:37:54,220 --> 00:37:57,480
and I said, naah, it's never going to
work, and then command 1 worked.
365
00:37:57,480 --> 00:38:02,300
laughter So this was very exciting for me
because this is the first time, the eMMC
366
00:38:02,300 --> 00:38:08,730
actually responds. And up until then, on
the bricked device, I tried to send
367
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
368
00:38:12,511 --> 00:38:18,060
I actually saw a response from the eMMC
and this was very exciting. And the eMMC
369
00:38:18,060 --> 00:38:22,821
even has command 62, you know, this
backdoor mode, so let's fix it. Let's
370
00:38:22,821 --> 00:38:28,540
repair the eMMC. So, there are two
revisions of this faulty chip. The first
371
00:38:28,540 --> 00:38:35,980
revision uses a firmware 0xF1, which is
buggy, and then there were phones with
372
00:38:35,980 --> 00:38:42,120
firmware revision 0xF7 in which the bug
never occurred. So probably Samsung fixed
373
00:38:42,120 --> 00:38:47,770
the bug in later hardware revisions. So my
goal was to update the chip to firmware
374
00:38:47,770 --> 00:38:55,420
0xF7 and format the FTL metadata so
the corruption is gone. OK, so … what I
375
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
376
00:39:00,780 --> 00:39:06,730
then I had to convince anybody over … the
Internet … to run my code which sends low-
377
00:39:06,730 --> 00:39:12,240
level eMMC commands to … on their own
device. laughter And thanks to @artesea,
378
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
379
00:39:20,830 --> 00:39:27,480
now I just had to write it to the eMMC
itself. So this is absolutely doable
380
00:39:27,480 --> 00:39:33,950
because I could've used the memory write
backdoor to write my own code and access
381
00:39:33,950 --> 00:39:39,240
the NAND flash chip and write a new
firmware. But then I found out something
382
00:39:39,240 --> 00:39:44,330
simpler. So there's another backdoor,
which is command 60, and it has two
383
00:39:44,330 --> 00:39:48,990
firmware upgrade modes for some
reason. So the former mode,
384
00:39:48,990 --> 00:39:56,950
which is 0xCBAD1160, supports FTL
metadata format. You can send an erase
385
00:39:56,950 --> 00:40:02,670
command and it will format all the FTL
metadata. And then you can write a new
386
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
387
00:40:12,070 --> 00:40:18,270
a dead S3, which should be … this is
important to note … the … many … there's
388
00:40:18,270 --> 00:40:24,420
different revisions of Galaxy S3. I'm
talking about GT-I9300, which is the
389
00:40:24,420 --> 00:40:30,710
international version. Boot to sboot,
either directly, if the boot partition is
390
00:40:30,710 --> 00:40:36,230
still intact, or by using an external SD-
card. Then exploit sboot to run your own
391
00:40:36,230 --> 00:40:43,720
code. From the shell code, reboot the eMMC
into boot ROM recovery mode and then use
392
00:40:43,720 --> 00:40:48,820
command 60 to format the FTL metadata and
flash the new firmware, 0xF7 firmware.
393
00:40:48,820 --> 00:40:53,290
Then reboot the eMMC so the firmware
loading … actually boots and then you can
394
00:40:53,290 --> 00:40:58,390
write sboot to the eMMC's boot partition.
And there is another step, which is … to
395
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
396
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
397
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---
398
00:41:22,130 --> 00:41:29,470
there's a battery inside---nothing
happens. It is bricked. If I try to get
399
00:41:29,470 --> 00:41:43,360
into download mode, nothing works. I have
this external SD card which does have
400
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
401
00:41:53,320 --> 00:42:10,890
should boot into … Yeah, okay. So, it
boots into something and now I can use …
402
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,
403
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
404
00:42:30,870 --> 00:42:35,700
okay. Shell code started. It rebooted the
eMMC into bootrom mode, and now it will
405
00:42:35,700 --> 00:42:43,080
write the new firmware. And it should take
a couple of seconds, so … hold tight, as
406
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
407
00:42:53,630 --> 00:43:02,610
and then change the boot partition size so
that there's actually a boot partition.
408
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
409
00:43:10,770 --> 00:43:16,211
which loads sboot normally and it goes
into SD card mode and in this SD card
410
00:43:16,211 --> 00:43:31,230
mode, it will write sboot to the boot
partition, so … Let me just … Yeah, okay.
411
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,
412
00:43:36,990 --> 00:43:47,390
right? And just reboot the device, so …
the battery is outside and now it's … yeah
413
00:43:47,390 --> 00:43:52,560
… It should boot into … yeah! So, this is
sboot! So the device is fixed.
414
00:43:52,560 --> 00:44:06,900
applause
415
00:44:06,900 --> 00:44:16,970
Thank you! So, conclusion. A few
shoutouts, so … Rebellos, AdamOutler, and
416
00:44:16,970 --> 00:44:24,890
Ralekdev did all the Exynos U-Boot, first
bootloader, ODROID-X work, so … Thanks to
417
00:44:24,890 --> 00:44:31,610
them! I couldn't … if it weren't for them,
I couldn't boot bricked devices.
418
00:44:31,610 --> 00:44:39,190
Entropy512 was involved in the eMMC
research back in 2013 and bunnyxobs held a
419
00:44:39,190 --> 00:44:47,160
wonderful talk here at CCC some years ago.
And he talked about hacking Chinese SD
420
00:44:47,160 --> 00:44:51,020
cards and they mentioned my research, and
this motivated me to complete it because it
421
00:44:51,020 --> 00:44:59,660
was still in progress. This is the reason
for which I'm talking today, so … thanks!
422
00:44:59,660 --> 00:45:06,010
applause
423
00:45:06,010 --> 00:45:12,740
So, I can basically own Samsung
eMMCs, I can fix bricked S3 with just
424
00:45:12,740 --> 00:45:18,030
software, and, imagine, this is just a
use-case, because now you can do
425
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
426
00:45:25,940 --> 00:45:32,040
at newer eMMCs which I suspect still has
this backdoor, because I tried some chip
427
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
428
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
429
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
430
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
431
00:46:03,460 --> 00:46:08,840
vendors of eMMCs and maybe one day write
an open-source alternative firmware for
432
00:46:08,840 --> 00:46:15,410
these devices. So this is question time.
You can find the code that I wrote to
433
00:46:15,410 --> 00:46:19,270
experiment with these devices over the
following links, and you can find the
434
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
435
00:46:25,760 --> 00:46:28,820
questions, this is the time, so … thanks!
436
00:46:28,820 --> 00:46:38,510
applause
437
00:46:38,510 --> 00:46:40,150
Herald: So thank you very much, Oran, for
438
00:46:40,150 --> 00:46:43,000
a really interesting talk. If you have
questions, there are two microphones in
439
00:46:43,000 --> 00:46:48,580
this aisle, and then two on the sides, and
first question from microphone #2.
440
00:46:48,580 --> 00:46:49,690
Microphone #2: It's pretty amazing what
441
00:46:49,690 --> 00:46:54,970
you did. Did you guys get any feedback
from Samsung on this?
442
00:46:54,970 --> 00:46:58,290
Oran: Yeah, so … I published my research
443
00:46:58,290 --> 00:47:08,100
back in 2012 … 2013, sorry, over forums
and I didn't use it from a security
444
00:47:08,100 --> 00:47:17,470
perspective. I wanted to fix S3. They
never responded or … they didn't contact
445
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
446
00:47:24,950 --> 00:47:34,170
opinion it is not a security issue. And it
can be fixed. And regarding the sboot
447
00:47:34,170 --> 00:47:40,080
vulnerabilities, there is no … it's
already patched, so … No, the answer is:
448
00:47:40,080 --> 00:47:41,520
No.
449
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
450
00:47:44,480 --> 00:47:46,490
the phones that are broken
out there, right?
451
00:47:46,490 --> 00:47:49,050
Oran: Yeah, I don't know any other way to
452
00:47:49,050 --> 00:47:50,260
do it.
453
00:47:50,260 --> 00:47:51,550
M#2: OK, thanks.
454
00:47:51,550 --> 00:47:53,570
Herald: Microphone #1.
455
00:47:53,570 --> 00:47:57,990
Microphone #1: After seeing a real-life
FTL, do you still use SSDs?
456
00:47:57,990 --> 00:47:59,070
Oran: Sorry?
457
00:47:59,070 --> 00:48:00,760
Microphone #1: After seeing a real-life
458
00:48:00,760 --> 00:48:05,100
FTL, do you still use SSDs or
other flash devices?
459
00:48:05,100 --> 00:48:09,180
Oran: Yeah, this is a good question … it's
460
00:48:09,180 --> 00:48:17,710
okay. And I don't … there's no
alternative, right? So … but we might
461
00:48:17,710 --> 00:48:22,440
make something, so …
462
00:48:22,440 --> 00:48:25,150
Herald: Mic number three.
463
00:48:25,150 --> 00:48:31,250
Microphone #3: Do you have any idea what
other devices have this model eMMC and
464
00:48:31,250 --> 00:48:37,580
support the same commands that let you
access the firmware? ’cause there is other
465
00:48:37,580 --> 00:48:40,500
devices that had bad eMMC.
466
00:48:40,500 --> 00:48:47,760
Oran: Ah, okay, so … Samsu… Galaxy S2 had
a similar bug and Kindle Fire, I think,
467
00:48:47,760 --> 00:48:53,440
one of their versions. And some of them
got patches by Samsung and it's usually
468
00:48:53,440 --> 00:48:58,450
was something like this, like: Patch the
internal memory everytime the device boots
469
00:48:58,450 --> 00:49:06,880
so the bug never happens. I think, in the
other devices, the bug was actually fixed.
470
00:49:06,880 --> 00:49:08,500
Microphone #3: But are you aware of any
471
00:49:08,500 --> 00:49:15,930
non-Samsung devices that have Samsung MMCs
in them that might be the same MMC?
472
00:49:15,930 --> 00:49:16,730
Oran: I'm sorry?
473
00:49:16,730 --> 00:49:17,840
Microphone #3: Are there other devices
474
00:49:17,840 --> 00:49:21,270
that aren't Samsung phones but still have
Samsung parts in them?
475
00:49:21,270 --> 00:49:23,300
Oran: Yeah, ah! So, there's not a lot of
476
00:49:23,300 --> 00:49:27,740
eMMC manufacturers and Samsung is a big
manufacturer, so … A lot of different
477
00:49:27,740 --> 00:49:35,750
phones and devices use Samsung eMMCs, so …
yes. It is relevant to non-Samsung devices.
478
00:49:35,750 --> 00:49:37,320
Herald: Number one.
479
00:49:37,320 --> 00:49:42,110
Microphone #1: Hey, thanks for your
amazing talk and research. Two questions:
480
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
481
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
482
00:49:54,540 --> 00:49:59,910
dump without erasing the FTL
and contents of the card?
483
00:49:59,910 --> 00:50:01,990
Oran: Yeah, so, this is a good question.
484
00:50:01,990 --> 00:50:07,090
The first question was … the S2
has the same bug, right?
485
00:50:07,090 --> 00:50:08,310
Microphone #1: The Note 2! The …
486
00:50:08,310 --> 00:50:09,470
Oran: Ah! The Note 2! Ah, okay. I don't
487
00:50:09,470 --> 00:50:13,260
know. I never had a Note 2, so.
488
00:50:13,260 --> 00:50:16,730
Microphone #1: I have one
that is bricked that way.
489
00:50:16,730 --> 00:50:18,630
Oran: But would be interesting to try.
490
00:50:18,630 --> 00:50:23,880
True! So, that's that. And regarding the
second question: My code actually formats
491
00:50:23,880 --> 00:50:29,710
all the FTL metadata which is not that
good because it erases all this
492
00:50:29,710 --> 00:50:38,190
information about how many times every
block was erased. A more proper fix would
493
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
494
00:50:43,460 --> 00:50:50,500
can fully understand the inner workings of
the FTL. So, this is my current code but
495
00:50:50,500 --> 00:50:54,460
you are welcome to try to improve it.
496
00:50:54,460 --> 00:50:55,790
Microphone #1: Wonderful.
497
00:50:55,790 --> 00:50:57,680
Herald: Microphone number two.
498
00:50:57,680 --> 00:51:01,680
Microphone #2: I'd like to know what the
timeframe was from you working on the
499
00:51:01,680 --> 00:51:04,590
issue 'til you had the first fixed S3.
500
00:51:04,590 --> 00:51:12,640
Oran: Yeah, so, I obtained the firmware
back in 2013 and I had a working device
501
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
502
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
503
00:51:30,230 --> 00:51:36,770
to fix it. So I think if you, like,
accumulate the time, it's probably going
504
00:51:36,770 --> 00:51:43,660
to be, like, a timeframe which I worked,
actively worked on this, was something
505
00:51:43,660 --> 00:51:49,970
like a few months. Probably four or five
months. But it started back in … four
506
00:51:49,970 --> 00:51:57,010
years ago, and I finished it something
like a couple of months ago
507
00:51:57,010 --> 00:51:58,080
Microphone #2: Cool. Thanks!
508
00:51:58,080 --> 00:51:58,600
Herald: Number One.
509
00:51:58,600 --> 00:52:01,770
Microphone #1: Do … Do Samsung SD cards
510
00:52:01,770 --> 00:52:04,510
have the same undocumented commands?
511
00:52:04,510 --> 00:52:09,300
Oran: Yeah, I suspect, they do. Some of
them. I actually bought some Samsung SD
512
00:52:09,300 --> 00:52:15,690
cards and they had controllers made by
Silicon Motion but I read over the
513
00:52:15,690 --> 00:52:25,130
Internet that some specific cards, I think
it's Evo+ Plus have Samsung controllers
514
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
515
00:52:35,440 --> 00:52:38,700
find out, I will probably post about it.
516
00:52:38,700 --> 00:52:39,340
Microphone #1: Thank you.
517
00:52:39,340 --> 00:52:41,940
Herald: Number three.
518
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
519
00:52:47,670 --> 00:52:56,450
phone, so what actually happened a few
months ago, it broke down but … so I still
520
00:52:56,450 --> 00:53:03,500
saw the Samsung bootloader, the sboot,
what it is called, and afterwards it got
521
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
522
00:53:10,071 --> 00:53:14,060
I flashed on something else, like
LineageOS, or the default Samsung's
523
00:53:14,060 --> 00:53:19,180
firmware, it still got stuck. I really had
to re-flash everything and then it worked
524
00:53:19,180 --> 00:53:25,060
again. That somehow sounds really similar
to the bug you described, but in a way it
525
00:53:25,060 --> 00:53:30,140
also doesn't. Do you think
it's the same thing?
526
00:53:30,140 --> 00:53:33,500
Oran: So, if it's related, my guess would
527
00:53:33,500 --> 00:53:41,481
be that your device have this in-memory
patch which freezes the eMMC and when you
528
00:53:41,481 --> 00:53:49,700
used LineageOS or what it was before, this
infinite loop triggered at some point in
529
00:53:49,700 --> 00:53:55,130
the boot process so the device actually
froze before it got to boot Android. But
530
00:53:55,130 --> 00:53:59,840
then, when you flashed it, somehow, the
internal block mapping got changed and now
531
00:53:59,840 --> 00:54:08,500
it doesn't trigger this freezing. But if
your chip is VTU00M and its firmware is
532
00:54:08,500 --> 00:54:11,470
0xF1, then you definitely have the bug.
533
00:54:11,470 --> 00:54:14,140
Microphone #3: OK, thanks.
534
00:54:14,140 --> 00:54:15,790
Herald: Number One.
535
00:54:15,790 --> 00:54:19,470
Microphone #1: Hi! Thanks for the great
work. One question: You said, you upgraded
536
00:54:19,470 --> 00:54:24,490
the firmware of the eMMC with a newer
revision. Are these firmwares actually
537
00:54:24,490 --> 00:54:28,620
signed or can you flash anything
on the eMMC controller?
538
00:54:28,620 --> 00:54:31,700
Oran: You can flash anything … yeah. They
539
00:54:31,700 --> 00:54:39,240
have a simple heuristic which checks if
the stack address is … looks normal, but
540
00:54:39,240 --> 00:54:44,740
other than that, it boots every firmware
you give it. I think, in your eMMCs, which
541
00:54:44,740 --> 00:54:52,601
is eMMC 5.1, there's a mechanism of
flashing new firmwares and I think it
542
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
543
00:54:59,781 --> 00:55:00,691
yeah.
544
00:55:00,691 --> 00:55:02,300
Microphone #1: Thank you.
545
00:55:02,300 --> 00:55:06,930
Herald: So … I have one last question,
about the Samsung patch. You said that it
546
00:55:06,930 --> 00:55:11,960
basically goes into some sort of infinite
loop. But do you think they tried to some
547
00:55:11,960 --> 00:55:14,220
busy wait or they're waiting
for something to happen?
548
00:55:14,220 --> 00:55:18,520
Oran: No, I think they just want … they
549
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
550
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
551
00:55:30,190 --> 00:55:34,740
anything, and the code in the eMMC
firmware doesn't do anything, so my guess:
552
00:55:34,740 --> 00:55:37,800
It just waits forever.
553
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
554
00:55:40,830 --> 00:55:42,136
work.
555
00:55:42,136 --> 00:55:46,500
applause
556
00:55:46,500 --> 00:55:51,310
34c3 outro
557
00:55:51,310 --> 00:56:08,000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!