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:56:07,401 *34c3 outro*