34c3 intro Herald: Right, so. Once again, good morning. Our next talk, next speaker today, this morning is an independant security researcher. He founded the Pasten CTF group, which some of you might have heard of. And he has previously worked on OpeniBoot. Please give a big round of applause to Oran Avraham. applause Oran: Can you hear me? OK. So I'm going to talk about how I hacked the eMMC chips or how we fixed dead Galaxy S3 devices. First, an introduction about myself or: Who am I? I'm Oran Avraham, 25 years old. I'm a security reasearcher based in Isreal. I'm currently working at a startup called Medigate. However this talk has no connection to my employer whatsoever. I previously worked on OpeniBoot which was an open-source alternative bootloader for Apple iOS devices. We aimed to boot Linux on iPhone 3G, 3GS, and iPhone 4. We had some success. I also found vulnerabilities in the early iPhone baseband, which were used to unlock and SIM free these devices and I'm also a CTF player with the Pasten team. We're playing tonight, so good luck for us. This is my contact info, if you want to reach me, you can find on my website and there's also my twitter username. OK, so, an outline about this talk. I am going to start with an introduction about the story. How I got to hack eMMC devices. Then, we'll talk about Samsung's eMMC patch, which they used for Galaxy S3 devices, then I will talk about how I obtained the firmware of those eMMC chips and analysed it. We'll cover the bug itself, that was in Samsung Galaxy S3 devices. And then, I'm going to talk about how do we resurrect bricked devices. So, let's start with the introduction. This phenomenon was called "Sudden Death Syndrome". This was the name that they gave it over forums, and it started in 2012. Samsung Galaxy S3 devices just started dying with no apparent reason. You could use your phone and then one day it will get stuck and if you try to reboot it, it won't boot anymore. The phone is basically a brick. And if you're lucky, the phone will boot into the bootloader so you'll see a loading screen, but it won't boot Linux or Android. And if you're not lucky then it's just a brick. You can't use it, you cannot turn it on. If you plug in a USB cable, you'll see nothing. You cannot even charge the battery because the actual charging mechanism isn't powered on, so… yeah. And there were a lot of rants in forums. This is an example: Somebody said, "this is happening to a lot of people. I hope, Samsung do something about this!" And, actually, they did, but it wasn't, like, a proper fix, and we'll talk about it later. So, let's talk about how do you diagnose such devices? So, this is a working S3. You can see the beautiful background and everything is powered on. And this is a dead one. laughter Yeah, the screen is just black, you cannot do anything. Actually, as I said before, if you're lucky, you'll see this screen which is drawn by the bootloader, which is called "Samsung sboot" and it won't boot … this is the last screen you'll see. And if you press a specific combination of keys, you will get this screen which is called "Download Mode", and we will talk about it later. So this is my understanding … this is my current understanding on how S3 works. So, this is a rough schematics; there's a lot of different peripherals that are not there, obviously. There's the main CPU, which is called "Samsung Exynos", it is an ARM-based CPU. And then you have the eMMC chip, which is a storage device. It is the standard storage device for phones. And there is some NAND flash inside of it. So, it is one package. And if you inspect the silicon, you'll see a NAND flash chip- OK, so … then, Samsung dropped a patch. And what happened is that they said to the press that they just fixed this bug and since the Linux is GPL- licensed, they had to publish the source code. So, the patch was called "Soft-patch MoviNAND VTU00M eMMC failure" and it's … they modified the file responsible … the code responsible for communicating with eMMC devices. So in order to understand this patch, we have to talk about what is eMMC? So, what is eMMC basically? It's the de-facto standard storage for phones. Actually, nowadays, high-end phones are starting to use UFS, which is the bus that replaces eMMC, but the majority of phones still use eMMC. And you can think about it as an SD-card in BGA form. It is a package that you can solder onto a PCB and it is basically an SD-card. It uses exactly the same bus. And as you can see, some company called HardKernel made a PCB which have an eMMC chip soldered onto it and you can … they made also an adapter which you can plug and there's no logic to this adapter, it just turns the eMMC into an SD-card device. And it works. So, eMMC is essentially a NAND flash chip with convenient bus, which is the same bus as SD-cards. So, for this reason, some people also called this an "internal SD-card", or something like that. And if I am going to say card later in my talk, I'm going to talk about the eMMC chip. So, when you communicate with the eMMC bus, you send commands to the card and there are 64 commands. And they are denoted from command 0 up to 63. For example, you have command 17, which is READ_SINGLE_BLOCK, and command 24, which is WRITE_BLOCK, and each command takes a single 32-bit argument. So you send a command, it has a number, and an argument. And all the commands are categorised into classes. And there is one specific interesting class, which is class 8. Because if you look at the specific section, you'll see that command 60 up to 63 are reserved for the manufacturer. So if something interesting is going to happen, it will be probably happen with these commands. So let's go back to the patch. Samsung said, they fixed the bug, right? So S3 devices shouldn't get bricked anymore. Let's … so, this patch actually, the first thing that … it compares the card's name to VTU00M, which is the hardware revision of the faulty chip, and then they compare a number to the value 0xF1, and this is actually the firmware version of this chip. And then, they call a function which is called mmc_start_movi_smart, which isn't that interesting, so I'm not going to talk about. And if all this comparisons are true, then it will call mmc_start_movi_operation, which is the main logic responsible for fixing the chip. And the thing to note about this patch is that it … this code runs everytime you boot the device. So everytime the eMMC chip is powered on, this code runs. OK, so let's talk about mmc_start_movi_operation. So, this is … I edited the code for brevity, it's not the exact same patch but this is basically the logic that they used. And this is very interesting. There is one strange thing about this function. This mmc_movi_erase_cmd … erase is … an eMMC command which takes two arguments. It uses two arguments because you precede it with a different command, so you can give it two arguments. And the first arguments is this start block number to erase, and the second one is the end block number to erase. And it erases all the blocks in- between. So what should happen is that the first call to this function should erase all the blocks starting with 40300 up to block number 4A03B510, right? This doesn't make any sense, and then the next call is the … the ranges overlap. And this was very strange. So my guess was that this is probably not an erase command. It is probably something else, somehow. And the next thing to note about this function is that you see the first two calls are mmc_movi_cmd, and the last calls are also to the function mmc_movi_cmd. And mmc_movi_cmd is basically command 62, which is a class-8-command. So it is reserved to the manufacturer. And my guess was that the first two calls basically enter some secret backdoor mode that Samsung hid inside the eMMC chip. And the last two calls leave this mode. So when you're in this mode, erase command doesn't do erase anymore. It does something else. And then, I saw that if you inspect the first argument, you'll see that the numbers are consecutive and they increment by four, except for the last number. All the first … the first five numbers are consecutive. And the next thing … so it looks something like memory addresses, right? And if you look at the second argument, I noticed something very interesting. If I assumed this is memory data, then if you look at it like as little-endian numbers, you'll see 10B5, so it starts with 10B5. And I used to code a lot of ARM-assembly, and 10B5 is PUSH in Thumb. And Thumb is an instruction set from the ARM specification. And functions in Thumb start with PUSH, right? So this is an eMMC next to a thumb. laughter And basically, this is my current understanding of how eMMC works. So you have this whole eMMC chip, but there is not only a NAND flash inside it, there is also a microcontroller. And in Samsung's case, this is an ARM-based microcontroller which contains some firmware. So I thought this patch might modify the internal memory of this chip somehow. So what I wanted to do is to examine what this patch does. So I just took all this data that it writes and put it into a binary file which I called patch.bin and this is, I just used IDA to see what is going on there and this is Samsung's patch. So … at the bottom, you can see the actual Thumb instructions but if you're not familiar with Thumb, you can see also a C-like pseudocode. And what they do is basically, they call a function and if it returns zero, the chip will go into an infinite loop. And this is interesting, because later on, I understood that what was there before the patch, it was just a call to this function and there wasn't this check. So they took a single call to a function and turned it into a call to the same function, but if it returned zero, they just go into an infinite loop. So my thought was, this can't fix anything, right? laughter Because the chip is either going to do the same thing as before or it is going to go into an infinite loop. And then I read some threads over forums and I saw this thread. "Ultimate Galaxy S3 unusual freezing thread" And this is a quote from the actual thread, you can see that "Galaxy S3 is freezing with lockups, screen not responding … and ending with unusual rebooting and bootlooping … Angry S3 users reporting this problem … And it keeps freezing every five minutes or 50+ freezes a day". This is insane, right? This phone is not usable. I can't use it as my phone if it freezes every five minutes. And I had an S3 back then, and I noti… I started observing freezes in my phone as well. So the next step that I wanted to do is to obtain the eMMC firmware in order to understand how it works. So how do you get a firmware? The first way to do it is to write … so I can write the eMMC's memory, right? So I can just write code to random locations and hopefully it will get run somehow. And then, just write things to different addresses and do lucky guesses and maybe I will see something on the eMMC bus and then try to obtain the firmware. But it is like a shot in the dark. So the next thing I thought about doing is to fuzz different commands. Like use command 60, 61, different class-8-commands. But I didn't want to destroy my own eMMC, which was still working. So the last thing I thought about then is to look for clues. So how do you look for clues? I just googled these numbers that Samsung used to enter this backdoor mode. And I saw a different patch. So this is a patch from a different device, and it is called "Patch the firmware of certain Samsung emmc parts to fix a bug" … ehhh laughter … and it used the same mode as before, so notice that they use arguments 0xEFAC62EC and then it is 0x10210000. And this is important. So they use 0x10210000, right? And then they write the value 0xFF to the address for the D9C. But then there was something else afterwards. So if you continue to read this patch, you will se this thing. This is a snippet which is enclosed by #ifed, which is called test_mmc_fw_patching, and they used the same emmc 62EC as before, but now they use the argument 10210002. And the next thing is that they … they use an erase command with the same addresses as before, but then they do a read command, right? I was wondering … hm … this might be Samsung's way of reading the memory address of the … the memory of the eMMC chip. Because they use an erase command with the same address as before. The second argument is 4, which looks like a size, and then they read a DWORD from the eMMC. So I took this snippet of code and modified it into … what if I did into this snippet of code? Which basically just loops over all the addresses in the address space. I just guessed how big the address space is. And I just read a single DWORD everytime and I dumped it into a file. And then, I got this thing, which looks like a firmware, right? So … the names aren't the names that you see, like, MMI, and hard_fault … these are all my names. What I saw was addresses, but this looks like a Thumb vector table. So I understood that I basically got the firmware of my own chip. So the next step was to reverse the firmware in order to analyse what the bug is. So luckily for me, the firmware contains Strings, so I can use them as part of my reverting process. But unfortunately, it contained a String. A single String. And it was this string,. Which isn't very useful, if you are trying to reverse a firmware. And as you can see, this is a snippet of my reversing process. I used a lot of, like, names, flip_bit_in_somewhere, memory mapped I/O 1000 2 DWORDS … But, I basically understood the high-level logic of this code. And I got to the point in which I can understand most of the firmware. So let's talk about debug. Before we talk about debug, we have to talk about what is eMMC exactly. So let's talk about normal storage first. This is, like, hard-drives. You have two operations which you can do. You have a read operation which reads data from the device and then you have a write operation which writes data onto the device. This is pretty normal. Then you have NAND flash storage. So if you have NAND flash storage, you can do a read operation which still reads data, and this is as before, but write operation actually turns off bits. If a bit was already 0, it won't turn into a 1. So this is basically applying a mask to bits on the storage. And then you have an erase command, so you have to … you got to have same way for reversing this process. An erase operation erases a whole erase- block. It turns all this bits in the block all to 1s, but it's a slow operation. And there's another problem: Erase-blocks have a limited program/erase cycle. So if you issue something like a 1000 or 10'000 or 100'000 erases, the block will eventually die and is not usable anymore. So something have to … some software have to do this translation to take this (…?) storage and do an abstraction which will show it like normal storage. So, this is called an FTL---or Flash Translation Layer. This is common. And the FTL is responsible for many things but some examples are wear leveling, which is spreading out erases among different blocks, so no single block gets erased a lot of times. And then it also does bad block management; if block already died, then it will remap it internally to a different block. It actually has spare blocks and then it … the firmware in Samsung's case is also responsible for the eMMC bus communication---or some of it. So what is the bug exactly? So … when you do write operations on the device, the FTL has to save some metadata for itself, because it has to keep track on how many times this block was erased and what is the internal mapping and so on. So it has some metadata that it saves for itself. And when you do write operations, it has to modify this metadata. And the actual bug was a miscalculation in this code which---not always, but sometimes---made the data corrupt. And once it happened--- it should only happen once---if the data got corrupted---and this is before Samsung's patch---everytime you try to power on the eMMC chip, the FTL will try to parse this data, and it's corrupt, so it will raise a CPU exception. And the default exception handler in Samsung's case is just an infinite loop. So the device … so … so you use the device and one day, the metadata gets corrupted and then you try to turn it on and it tries to parse the metadata and it's corrupt, so it throws an exception and then the eMMC goes into an infinite loop and you can't access it anymore. And the eMMC is basically, essentially, dead. Because you send commands into it and nothing responds because the firmware is the one is dead, the software … that is responsible for answering eMMC commands. So Samsung's patch was something about this. Something like this. Right before the metadata is about to get corrupted, halt the CPU. So, there's no bug, right? Right before the bug is about to happen, just halt the CPU so it never happens. And this then, like, sudden death syndrome into sudden freeze syndrome. So I wanted to fix my own device. So, a quick recap: I got the eMMC firmware by analysing Samsung's patch. The firmware had the bug causing FTL corruption. Once it happened, the chip won't boot anymore and Samsung's patch was to avoid the bug happening at all. So the next step is, obviously, to resurrect dead phones, right? … yeah, what?! How do I … So the eMMC gets into a loop at boot. But what happens before it gets into this loop? So I took a look at the firmware and I saw this memory layout. As you can see at address 0, there's something that I called a "Boot ROM". And it's a ROM, you can't write into it. And it is a code and what it does, it initialises the eMMC hardware and it loads the firmware from the NAND flash chip itself. And this is strange, because if the boot ROM is already there, why don't … why doesn't it already doing the things that the firmware is responsible to do? So my guess was that the firmware was too big to reside wherever the boot ROM resides, so they had to, like, bootstrap it from the external NAND flash. And then it also has it's own machinery for eMMC commands, which is strange, because all it has to do is just load its firmware. So my guess is that, during their production process, the NAND flash is empty and there's no firmware. And then, when Samsung produces these chips, they plug them in and there's no firmware, so the boot ROM goes into some kind of recovery mode and it exposes an eMMC bus and from there you can write your new firmware. And the boot ROM is basically a stripped-down firmware. There's no FTL, but it looks like the firmware itself. And this is my current understanding of how S3 works. So inside the eMMC you have two silicon dies, and the first is an ARM chip which has a boot ROM, which loads the firmware from the external NAND flash and then boots it. So, if we could ever talk to boot ROM, this might be interesting because we could maybe do something interesting. But the firmware loading actually succeeds because the firmware is still intact. The boot ROM will try to load the firmware, the firmware is still there and it will jump into it and the firmware executes and goes into infinite loop so there is no chance of every talking to the boot ROM, right? Though, actually, not. This is not correct, because on boot, there's this function at address 7DBC and a timer is being set for 35ms and if during this time period, some interrupt fires, this is interrupt #7, I don't know what it is yet. They read a value from a memory-mapped I/O address and they compare it to this constant magic. And if this comparison is true, firmware loading is skipped and it goes right into this recovery mode. And my guess is that … so this is a schematic of the boot process and the right … the left column is the normal boot process and if we ever get to the right column, we will get into this recovery mode. So my guess is that this interrupt #7 corresponds to some eMMC command. And this value that they read from memory-mapped I/O is probably the eMMC argument, because it is 32 bits. So that eMMCs get stuck on boot. So this is if the chip is already dead. However, right before it gets stuck, there is a time window and during this time window, if you somehow trigger this interrupt, the boot process is aborted and it goes right into eMMC boot ROM recovery mode, which is interesting. But the phone is already dead. How do I even talk to the eMMC chip? So I could've used the hardware mod, like, desolder the eMMC and send commands externally but … ehh … I wanted to, like, do something with software, because I don't know how to desolder BGA chips. So the next step is to talk to the eMMC by some kind of magic and then we'll access the eMMC boot ROM. And then, we can repair it from this boot ROM recovery mode. So I said, if you're lucky, you get this screen. So this is the phone's bootloader. This is sboot. And it is saved on the eMMC itself. So how do you get this? If the eMMC chip doesn't respond, how the main CPU gets to execute this bootloader? So, apparently, if you read Samsung's specification, you will see that the eMMC has two partitions and it's not a partition in the filesystem-sense, it's a partition in the eMMC-sense. And there's a boot partition and a user partition. And the boot partition holds sboot in Samsung's case, which is the bootloader for the main CPU. And the user partition holds everything else. So it stores Linux and all the Android filesystem and all the apps etc. So the boot partition has its own FTL metadata and the user partition also has its own metadata. A friend of mine had a bricked S3 which does load sboot. So he gets this screen. And … what I understood had happened is that only the user's … the user partition metadata got corrupted, so the boot partition is still intact. And I suspect, this is a common scenario. When you write to your device, you usually don't try to write to the boot partition, you write to the user partition. So if something is about to get corrupted, it probably will be in the user partition. So this is how S3 breaks. The main CPU will power on and it will try to access the eMMC and asks: Give me sboot. And the eMMC parses the boot partition and it will return sboot to the main CPU and then sboot will try to access the user partition in order to load Linux and then the eMMC tries to parse the user partition metadata and it's corrupt, so it goes into a loop. So sboot actually has a device firmware update mode, that is called "Download mode", and there is protocol of USB, the phone side is called Loke and the computer side is called Odin. I guess, this is a reference to the Norsk methology. And there's no way of sending low-level eMMC commands. So if you ever saw this screen, this is Odin software. It's a software made by Samsung to talk to this protocol. And in this protocol, you can't send raw eMMC commands to the eMMC chip, so I need to send commands to the chip, but the code isn't there in sboot. So, obviously, the thing that I'll have to do is to exploit sboot, and run my own code. This is taken from USB PIT packets handler from sboot. This is a C pseudocode that I wrote. So, you control this variable is dumped and if it is 1, it will read something from the USB packet that you send to it and then it will give you a buffer and it will use this number that you gave it as an offset to this buffer but it doesn't do any boundary checks at all. So this is an out-of-bounds read vulnerability. And the second case reads a size from the USB packet and then reads it into this USB buffer, which is constantly allocated on the heap, it's of size 2000, but it doesn't do any boundary checks at all either. So, this is a heap-overflow vulnerability, right? So eventually I found that this is not actually a 0-day. If you take, like an S8 or S7, this vulnerability is fixed but for S3, which is end-of-life, these vulnerabilities are still there. So if you have an S3, you can use it … So, let's talk about Samsung's sboot heap implementation. So if you wanted to allocate some size and the heap chose to use a chunk which is larger than the size that you wanted to allocate, it will split it from the end. And you will see an illustration in a moment. And the thing to note about this heap implementation is that there is no security mitigations at all. It's very basic. So … let's say that you wanted to allocate 50 bytes and the chunk that it chose was 100 bytes, then it will give you this part, which is the bottom part of the buffer. And the buffer, the chunk header, has a size number … a size parameter and it will use this size to go to the end. So I wanted to achieve write-what-where in order to exploit sboot. And I used … I exploited the chunk splitting technique. So the first thing to do was to fake a chunk header which I can control with some large size, so it will get split, and then I had to figure out its address. And I can do this with the first vulnerability, the relative read, and then the next step is to make sure this chunk is actually selected when you call malloc. And then, it will try to give you the bottom part of the buffer. So it will start from the chunk address and then it will go all the way to the bottom, which is adding chunk size, and then it will go back the size you wanted to allocate, right? And we want to control this number and we can control this number. So if I just turn around this equation, if I want to control address, I can just use this number as the chunk size and then it will give me this address. So the actual details in my opinion are boring. So you can find the exploit under this repository. It's public, so you can just take an S3 and use it, and this is a demo. This is download mode, and this is Hello World sboot exploit, so it works. OK, so, what if it's really dead? What if this happened, right? What if also the boot partition is gone? So, obiously something has to load. Has to talk with the eMMC and load sboot, right? So there's also another piece of code which is called Exynos boot rom. And it is … it resides in the main CPU. And what happens normally is that the Exynos boot ROM starts and then it loads something which I call the "first bootloader", which is prepended to sboot, and it is signed and it just verifies the signature of sboot and then jumps into it. So you can just think about it as, it's together with sboot. And then sboot loads the kernel. But the boot ROM has to load the first bootloader and sboot from somewhere, so what does it try to do? So it first starts with the eMMC. But if this fails, it goes to the external SD-card. So I just took sboot and the first bootloader and dropped them onto an SD-card. But that didn't work because sboot boots into, in this case, sboot boots into SD-card mode, in which there's is no USB protocol, so you can't exploit it. And, as I said, it is signed, so I can't patch it. But apparently some people over a forum, their nicknames are AdamOutler, Rebellos, and Ralekdev. They found out that there is a development board, called ODROID-X, which uses exactly the same CPU, so it's the same boot ROM, which uses the same signature, but it uses a different first bootloader, which doesn't do any signature checks at all. So if you take this first bootloader and append to it a patched sboot, it will jump into this patched sboot and then you can just exploit it and run your code. And this is the modified boot process, so you start with Exynos boot ROM, you plug in an external SD-card, the externel SD-card has ODROID-X first bootloader, which is signed, so the boot ROM will jump into it and then the first bootloader will jump to the patched sboot and then you can exploit it and run you shell code. And no hardware mode is required at all. So if the boot partition is still intact, the phone loads sboot and it is stored in your eMMC. But if it is corrupt, the phone uses the external SD- card. And either way, I can load sboot. And then I can exploit a vulnerability to gain code execution in sboot. And the next step is to access the eMMC boot ROM. And as I said before, I need to trigger this interrupt #7 and send it … send this argument somehow. So I just iterated over all the possible eMMC commands, which is from 0 to 63, and I powered off the eMMC, powered it back on, so the boot process gets started again. And then I quickly sent a command X with this argument and I waited for some time for the boot process to finish. And then I sent any command which is supported by the boot ROM recovery mode and I checked if I got any response. And I said, ehhh, this is … maybe it's going to work, maybe not, and then I tried command 0 and it failed, and I said, naah, it's never going to work, and then command 1 worked. laughter So this was very exciting for me because this is the first time, the eMMC actually responds. And up until then, on the bricked device, I tried to send several commands to the eMMC and I never saw a response. And this is the first time I actually saw a response from the eMMC and this was very exciting. And the eMMC even has command 62, you know, this backdoor mode, so let's fix it. Let's repair the eMMC. So, there are two revisions of this faulty chip. The first revision uses a firmware 0xF1, which is buggy, and then there were phones with firmware revision 0xF7 in which the bug never occurred. So probably Samsung fixed the bug in later hardware revisions. So my goal was to update the chip to firmware 0xF7 and format the FTL metadata so the corruption is gone. OK, so … what I did was to write a dump tool, a firmware dump tool, which is a kernel module. And then I had to convince anybody over … the Internet … to run my code which sends low- level eMMC commands to … on their own device. laughter And thanks to @artesea, which was courage enough to try it, I got a dump of firmware 0xF7 and it worked. And now I just had to write it to the eMMC itself. So this is absolutely doable because I could've used the memory write backdoor to write my own code and access the NAND flash chip and write a new firmware. But then I found out something simpler. So there's another backdoor, which is command 60, and it has two firmware upgrade modes for some reason. So the former mode, which is 0xCBAD1160, supports FTL metadata format. You can send an erase command and it will format all the FTL metadata. And then you can write a new firmware and it will do everything for you. So how do I fix a dead S3? I just get a dead S3, which should be … this is important to note … the … many … there's different revisions of Galaxy S3. I'm talking about GT-I9300, which is the international version. Boot to sboot, either directly, if the boot partition is still intact, or by using an external SD- card. Then exploit sboot to run your own code. From the shell code, reboot the eMMC into boot ROM recovery mode and then use command 60 to format the FTL metadata and flash the new firmware, 0xF7 firmware. Then reboot the eMMC so the firmware loading … actually boots and then you can write sboot to the eMMC's boot partition. And there is another step, which is … to profit. And this means, it is demo time! So, I pray to the demo gods that it is going to happen, it is going to succeed. So, yeah … This … OK, so I have a bricked device, I bricked it on purpose. This is the device. If I try to turn it on--- there's a battery inside---nothing happens. It is bricked. If I try to get into download mode, nothing works. I have this external SD card which does have sboot as I said before. And if I plug it in, and I try to boot the device, it should boot into … Yeah, okay. So, it boots into something and now I can use … Just go back to the … yeah. And now I can plug it into the USB and sboot answers, and now I am going to run a shell code, which fixes the eMMC. It’s retrying, it is okay. Shell code started. It rebooted the eMMC into bootrom mode, and now it will write the new firmware. And it should take a couple of seconds, so … hold tight, as it said… Okay, yeah, so the next thing is going to be to reboot into the firmware and then change the boot partition size so that there's actually a boot partition. Yeah, and now the shell command is done and I can just use a different SD card which loads sboot normally and it goes into SD card mode and in this SD card mode, it will write sboot to the boot partition, so … Let me just … Yeah, okay. So this is SD card mode. I think you can't see, but if I now remove this SD card, right? And just reboot the device, so … the battery is outside and now it's … yeah … It should boot into … yeah! So, this is sboot! So the device is fixed. applause Thank you! So, conclusion. A few shoutouts, so … Rebellos, AdamOutler, and Ralekdev did all the Exynos U-Boot, first bootloader, ODROID-X work, so … Thanks to them! I couldn't … if it weren't for them, I couldn't boot bricked devices. Entropy512 was involved in the eMMC research back in 2013 and bunnyxobs held a wonderful talk here at CCC some years ago. And he talked about hacking Chinese SD cards and they mentioned my research, and this motivated me to complete it because it was still in progress. This is the reason for which I'm talking today, so … thanks! applause So, I can basically own Samsung eMMCs, I can fix bricked S3 with just software, and, imagine, this is just a use-case, because now you can do interesting stuff with your eMMC chip. And what I think we should do next is to look at newer eMMCs which I suspect still has this backdoor, because I tried some chip which I could get my hands on and it had this backdoor, so … Maybe even the new ones also has this mode. And then there's UFS, which is the bus which replaces eMMC and it is based on SCASI and Samsung also produces UFS chips so it might be wanting to see if there's a similar backdoor. And it's also interesting to look at different vendors of eMMCs and maybe one day write an open-source alternative firmware for these devices. So this is question time. You can find the code that I wrote to experiment with these devices over the following links, and you can find the slides in the bottom link. It's already public, so go ahead. And if you have any questions, this is the time, so … thanks! applause Herald: So thank you very much, Oran, for a really interesting talk. If you have questions, there are two microphones in this aisle, and then two on the sides, and first question from microphone #2. Microphone #2: It's pretty amazing what you did. Did you guys get any feedback from Samsung on this? Oran: Yeah, so … I published my research back in 2012 … 2013, sorry, over forums and I didn't use it from a security perspective. I wanted to fix S3. They never responded or … they didn't contact me in any way. I didn't contact them about the boot ROM recovery mode, because in my opinion it is not a security issue. And it can be fixed. And regarding the sboot vulnerabilities, there is no … it's already patched, so … No, the answer is: No. Microphone #2: So, the way I understand it, this is the only way to fix some of the phones that are broken out there, right? Oran: Yeah, I don't know any other way to do it. M#2: OK, thanks. Herald: Microphone #1. Microphone #1: After seeing a real-life FTL, do you still use SSDs? Oran: Sorry? Microphone #1: After seeing a real-life FTL, do you still use SSDs or other flash devices? Oran: Yeah, this is a good question … it's okay. And I don't … there's no alternative, right? So … but we might make something, so … Herald: Mic number three. Microphone #3: Do you have any idea what other devices have this model eMMC and support the same commands that let you access the firmware? ’cause there is other devices that had bad eMMC. Oran: Ah, okay, so … Samsu… Galaxy S2 had a similar bug and Kindle Fire, I think, one of their versions. And some of them got patches by Samsung and it's usually was something like this, like: Patch the internal memory everytime the device boots so the bug never happens. I think, in the other devices, the bug was actually fixed. Microphone #3: But are you aware of any non-Samsung devices that have Samsung MMCs in them that might be the same MMC? Oran: I'm sorry? Microphone #3: Are there other devices that aren't Samsung phones but still have Samsung parts in them? Oran: Yeah, ah! So, there's not a lot of eMMC manufacturers and Samsung is a big manufacturer, so … A lot of different phones and devices use Samsung eMMCs, so … yes. It is relevant to non-Samsung devices. Herald: Number one. Microphone #1: Hey, thanks for your amazing talk and research. Two questions: There's the Samsung Galaxy Note 2 that has more or less the same bug, does your fix and your research also apply to that device? And is there a way to a chip-off dump without erasing the FTL and contents of the card? Oran: Yeah, so, this is a good question. The first question was … the S2 has the same bug, right? Microphone #1: The Note 2! The … Oran: Ah! The Note 2! Ah, okay. I don't know. I never had a Note 2, so. Microphone #1: I have one that is bricked that way. Oran: But would be interesting to try. True! So, that's that. And regarding the second question: My code actually formats all the FTL metadata which is not that good because it erases all this information about how many times every block was erased. A more proper fix would be to actually fix the corrupted metadata but I haven't got to the point in which I can fully understand the inner workings of the FTL. So, this is my current code but you are welcome to try to improve it. Microphone #1: Wonderful. Herald: Microphone number two. Microphone #2: I'd like to know what the timeframe was from you working on the issue 'til you had the first fixed S3. Oran: Yeah, so, I obtained the firmware back in 2013 and I had a working device and I didn't want to do … like … bad stuff to it. So I stopped back in this year, and then last year, a friend of mine said that he had a bricked S3 so I said, let's try to fix it. So I think if you, like, accumulate the time, it's probably going to be, like, a timeframe which I worked, actively worked on this, was something like a few months. Probably four or five months. But it started back in … four years ago, and I finished it something like a couple of months ago Microphone #2: Cool. Thanks! Herald: Number One. Microphone #1: Do … Do Samsung SD cards have the same undocumented commands? Oran: Yeah, I suspect, they do. Some of them. I actually bought some Samsung SD cards and they had controllers made by Silicon Motion but I read over the Internet that some specific cards, I think it's Evo+ Plus have Samsung controllers which should have the same backdoor, so, I'm trying to buy one but as soon as I find out, I will probably post about it. Microphone #1: Thank you. Herald: Number three. Microphone #3: OK, thanks for the great talk. So, I'm using an S3 as my everyday phone, so what actually happened a few months ago, it broke down but … so I still saw the Samsung bootloader, the sboot, what it is called, and afterwards it got stuck at the bootscreen from the OS, so in my case it was Cyanogenmod, but also, when I flashed on something else, like LineageOS, or the default Samsung's firmware, it still got stuck. I really had to re-flash everything and then it worked again. That somehow sounds really similar to the bug you described, but in a way it also doesn't. Do you think it's the same thing? Oran: So, if it's related, my guess would be that your device have this in-memory patch which freezes the eMMC and when you used LineageOS or what it was before, this infinite loop triggered at some point in the boot process so the device actually froze before it got to boot Android. But then, when you flashed it, somehow, the internal block mapping got changed and now it doesn't trigger this freezing. But if your chip is VTU00M and its firmware is 0xF1, then you definitely have the bug. Microphone #3: OK, thanks. Herald: Number One. Microphone #1: Hi! Thanks for the great work. One question: You said, you upgraded the firmware of the eMMC with a newer revision. Are these firmwares actually signed or can you flash anything on the eMMC controller? Oran: You can flash anything … yeah. They have a simple heuristic which checks if the stack address is … looks normal, but other than that, it boots every firmware you give it. I think, in your eMMCs, which is eMMC 5.1, there's a mechanism of flashing new firmwares and I think it should be signed but I don't have a newer eMMC, so … I don't know about it, but yeah. Microphone #1: Thank you. Herald: So … I have one last question, about the Samsung patch. You said that it basically goes into some sort of infinite loop. But do you think they tried to some busy wait or they're waiting for something to happen? Oran: No, I think they just want … they want the bug to never happen, so … Yeah, I … my phone froze a lot of times and I waited like, I don't know, 30 minutes. And the code in the Linux kernel doesn't do anything, and the code in the eMMC firmware doesn't do anything, so my guess: It just waits forever. Herald: I see no more questions, so again, a big round of applause to Oran for great work. applause 34c3 outro subtitles created by c3subtitles.de in the year 2018. Join, and help us!