Return to Video

34C3 - eMMC hacking, or: how I fixed long-dead Galaxy S3 phones

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

https://media.ccc.de/c/34c3/34c3-8784-emmc_hacking_or_how_i_fixed_long-dead_galaxy_s3_phones

A journey on how to fix broken proprietary hardware by gaining code execution on it

How I hacked Sasmung eMMC chips: from an indication that they have a firmware - up until code execution ability on the chip itself, relevant to a countless number of devices. It all started when Samsung Galaxy S3 devices started dying due to a bug in their eMMC firmware. I will cover how I figured out there's a firmware inside the chip, how I obtained it, and my journey to gaining code execution on the chip itself — up until the point in which I could grab a bricked Galaxy S3, and fix it by software-only means.

oranav

https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8784.html

more » « less
Video Language:
English
Duration:
56:08

English subtitles

Revisions Compare revisions