[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:16.87,Default,,0000,0000,0000,,{\i1}34c3 intro{\i0}
Dialogue: 0,0:00:16.87,0:00:21.54,Default,,0000,0000,0000,,Herald: Right, so. Once again, good\Nmorning. Our next talk, next speaker
Dialogue: 0,0:00:21.54,0:00:26.91,Default,,0000,0000,0000,,today, this morning is an independant\Nsecurity researcher. He founded the Pasten
Dialogue: 0,0:00:26.91,0:00:31.16,Default,,0000,0000,0000,,CTF group, which some of you might have\Nheard of. And he has previously worked on
Dialogue: 0,0:00:31.16,0:00:35.74,Default,,0000,0000,0000,,OpeniBoot. Please give a big round of\Napplause to Oran Avraham.
Dialogue: 0,0:00:35.74,0:00:43.67,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:00:43.67,0:00:46.83,Default,,0000,0000,0000,,Oran: Can you hear me? OK. So I'm going to
Dialogue: 0,0:00:46.83,0:00:55.24,Default,,0000,0000,0000,,talk about how I hacked the eMMC chips or\Nhow we fixed dead Galaxy S3 devices.
Dialogue: 0,0:00:55.24,0:01:01.65,Default,,0000,0000,0000,,First, an introduction about myself or:\NWho am I? I'm Oran Avraham, 25 years old.
Dialogue: 0,0:01:01.65,0:01:06.56,Default,,0000,0000,0000,,I'm a security reasearcher based in\NIsreal. I'm currently working at a startup
Dialogue: 0,0:01:06.56,0:01:12.30,Default,,0000,0000,0000,,called Medigate. However this talk has no\Nconnection to my employer whatsoever. I
Dialogue: 0,0:01:12.30,0:01:17.98,Default,,0000,0000,0000,,previously worked on OpeniBoot which was\Nan open-source alternative bootloader for
Dialogue: 0,0:01:17.98,0:01:25.31,Default,,0000,0000,0000,,Apple iOS devices. We aimed to boot Linux\Non iPhone 3G, 3GS, and iPhone 4. We had
Dialogue: 0,0:01:25.31,0:01:34.45,Default,,0000,0000,0000,,some success. I also found vulnerabilities\Nin the early iPhone baseband, which were
Dialogue: 0,0:01:34.45,0:01:41.13,Default,,0000,0000,0000,,used to unlock and SIM free these devices\Nand I'm also a CTF player with the Pasten
Dialogue: 0,0:01:41.13,0:01:48.64,Default,,0000,0000,0000,,team. We're playing tonight, so good luck\Nfor us. This is my contact info, if you
Dialogue: 0,0:01:48.64,0:01:53.37,Default,,0000,0000,0000,,want to reach me, you can find on my\Nwebsite and there's also my twitter
Dialogue: 0,0:01:53.37,0:01:57.61,Default,,0000,0000,0000,,username. OK, so, an outline about this\Ntalk. I am going to start with an
Dialogue: 0,0:01:57.61,0:02:03.87,Default,,0000,0000,0000,,introduction about the story. How I got to\Nhack eMMC devices. Then, we'll talk about
Dialogue: 0,0:02:03.87,0:02:11.10,Default,,0000,0000,0000,,Samsung's eMMC patch, which they used for\NGalaxy S3 devices, then I will talk about
Dialogue: 0,0:02:11.10,0:02:20.63,Default,,0000,0000,0000,,how I obtained the firmware of those eMMC\Nchips and analysed it. We'll cover the bug
Dialogue: 0,0:02:20.63,0:02:25.85,Default,,0000,0000,0000,,itself, that was in Samsung Galaxy S3\Ndevices. And then, I'm going to talk about
Dialogue: 0,0:02:25.85,0:02:33.54,Default,,0000,0000,0000,,how do we resurrect bricked devices. So,\Nlet's start with the introduction. This
Dialogue: 0,0:02:33.54,0:02:38.96,Default,,0000,0000,0000,,phenomenon was called "Sudden Death\NSyndrome". This was the name that they
Dialogue: 0,0:02:38.96,0:02:46.47,Default,,0000,0000,0000,,gave it over forums, and it started in\N2012. Samsung Galaxy S3 devices just
Dialogue: 0,0:02:46.47,0:02:51.83,Default,,0000,0000,0000,,started dying with no apparent reason. You\Ncould use your phone and then one day it
Dialogue: 0,0:02:51.83,0:02:57.25,Default,,0000,0000,0000,,will get stuck and if you try to reboot\Nit, it won't boot anymore. The phone is
Dialogue: 0,0:02:57.25,0:03:02.13,Default,,0000,0000,0000,,basically a brick. And if you're lucky,\Nthe phone will boot into the bootloader so
Dialogue: 0,0:03:02.13,0:03:08.47,Default,,0000,0000,0000,,you'll see a loading screen, but it won't\Nboot Linux or Android. And if you're not
Dialogue: 0,0:03:08.47,0:03:14.23,Default,,0000,0000,0000,,lucky then it's just a brick. You can't\Nuse it, you cannot turn it on. If you plug
Dialogue: 0,0:03:14.23,0:03:19.99,Default,,0000,0000,0000,,in a USB cable, you'll see nothing. You\Ncannot even charge the battery because the
Dialogue: 0,0:03:19.99,0:03:26.51,Default,,0000,0000,0000,,actual charging\Nmechanism isn't powered on, so… yeah. And
Dialogue: 0,0:03:26.51,0:03:31.25,Default,,0000,0000,0000,,there were a lot of rants in forums. This\Nis an example: Somebody said, "this is
Dialogue: 0,0:03:31.25,0:03:36.59,Default,,0000,0000,0000,,happening to a lot of people. I hope,\NSamsung do something about this!" And,
Dialogue: 0,0:03:36.59,0:03:42.84,Default,,0000,0000,0000,,actually, they did, but it wasn't, like, a\Nproper fix, and we'll talk about it later.
Dialogue: 0,0:03:42.84,0:03:48.84,Default,,0000,0000,0000,,So, let's talk about how do you diagnose\Nsuch devices? So, this is a working S3.
Dialogue: 0,0:03:48.84,0:03:54.07,Default,,0000,0000,0000,,You can see the beautiful background and\Neverything is powered on. And this is a
Dialogue: 0,0:03:54.07,0:03:59.30,Default,,0000,0000,0000,,dead one. {\i1}laughter{\i0} Yeah, the screen is\Njust black, you cannot do anything.
Dialogue: 0,0:03:59.30,0:04:03.53,Default,,0000,0000,0000,,Actually, as I said before, if you're\Nlucky, you'll see this screen which is
Dialogue: 0,0:04:03.53,0:04:09.82,Default,,0000,0000,0000,,drawn by the bootloader, which is called\N"Samsung sboot" and it won't boot … this
Dialogue: 0,0:04:09.82,0:04:15.50,Default,,0000,0000,0000,,is the last screen you'll see. And if you\Npress a specific combination of keys, you
Dialogue: 0,0:04:15.50,0:04:18.37,Default,,0000,0000,0000,,will get this screen which is called\N"Download Mode", and we will talk about it
Dialogue: 0,0:04:18.37,0:04:26.64,Default,,0000,0000,0000,,later. So this is my understanding … this\Nis my current understanding on how S3
Dialogue: 0,0:04:26.64,0:04:33.16,Default,,0000,0000,0000,,works. So, this is a rough schematics;\Nthere's a lot of different peripherals
Dialogue: 0,0:04:33.16,0:04:40.18,Default,,0000,0000,0000,,that are not there, obviously. There's the\Nmain CPU, which is called "Samsung
Dialogue: 0,0:04:40.18,0:04:47.14,Default,,0000,0000,0000,,Exynos", it is an ARM-based CPU. And then\Nyou have the eMMC chip, which is a storage
Dialogue: 0,0:04:47.14,0:04:52.53,Default,,0000,0000,0000,,device. It is the standard storage device\Nfor phones. And there is some NAND flash
Dialogue: 0,0:04:52.53,0:04:58.13,Default,,0000,0000,0000,,inside of it. So, it is one package. And\Nif you inspect the silicon, you'll see a
Dialogue: 0,0:04:58.13,0:05:06.16,Default,,0000,0000,0000,,NAND flash chip- OK, so … then, Samsung\Ndropped a patch. And what happened is that
Dialogue: 0,0:05:06.16,0:05:14.34,Default,,0000,0000,0000,,they said to the press that they just\Nfixed this bug and since the Linux is GPL-
Dialogue: 0,0:05:14.34,0:05:19.86,Default,,0000,0000,0000,,licensed, they had to publish the source\Ncode. So, the patch was called "Soft-patch
Dialogue: 0,0:05:19.86,0:05:29.73,Default,,0000,0000,0000,,MoviNAND VTU00M eMMC failure" and it's …\Nthey modified the file responsible … the
Dialogue: 0,0:05:29.73,0:05:34.95,Default,,0000,0000,0000,,code responsible for communicating with\NeMMC devices. So in order to understand
Dialogue: 0,0:05:34.95,0:05:43.00,Default,,0000,0000,0000,,this patch, we have to talk about what is\NeMMC? So, what is eMMC basically? It's the
Dialogue: 0,0:05:43.00,0:05:49.40,Default,,0000,0000,0000,,de-facto standard storage for phones.\NActually, nowadays, high-end phones are
Dialogue: 0,0:05:49.40,0:05:57.47,Default,,0000,0000,0000,,starting to use UFS, which is the bus that\Nreplaces eMMC, but the majority of phones
Dialogue: 0,0:05:57.47,0:06:01.73,Default,,0000,0000,0000,,still use eMMC. And you\Ncan think about it as an
Dialogue: 0,0:06:01.73,0:06:06.99,Default,,0000,0000,0000,,SD-card in BGA form. It is a package that\Nyou can solder onto a PCB and it is
Dialogue: 0,0:06:06.99,0:06:15.59,Default,,0000,0000,0000,,basically an SD-card. It uses exactly the\Nsame bus. And as you can see, some company
Dialogue: 0,0:06:15.59,0:06:24.74,Default,,0000,0000,0000,,called HardKernel made a PCB which have an\NeMMC chip soldered onto it and you can …
Dialogue: 0,0:06:24.74,0:06:29.48,Default,,0000,0000,0000,,they made also an adapter which you can\Nplug and there's no logic to this adapter,
Dialogue: 0,0:06:29.48,0:06:37.13,Default,,0000,0000,0000,,it just turns the eMMC into an SD-card\Ndevice. And it works. So, eMMC is
Dialogue: 0,0:06:37.13,0:06:42.52,Default,,0000,0000,0000,,essentially a NAND flash chip with\Nconvenient bus, which is the same bus as
Dialogue: 0,0:06:42.52,0:06:49.51,Default,,0000,0000,0000,,SD-cards. So, for this reason, some people\Nalso called this an "internal SD-card", or
Dialogue: 0,0:06:49.51,0:06:55.28,Default,,0000,0000,0000,,something like that. And if I am going to\Nsay card later in my talk, I'm going to
Dialogue: 0,0:06:55.28,0:07:03.74,Default,,0000,0000,0000,,talk about the eMMC chip. So, when you\Ncommunicate with the eMMC bus, you send
Dialogue: 0,0:07:03.74,0:07:10.24,Default,,0000,0000,0000,,commands to the card and there are 64\Ncommands. And they are denoted from
Dialogue: 0,0:07:10.24,0:07:16.43,Default,,0000,0000,0000,,command 0 up to 63. For example, you have\Ncommand 17, which is READ_SINGLE_BLOCK,
Dialogue: 0,0:07:16.43,0:07:22.54,Default,,0000,0000,0000,,and command 24, which is WRITE_BLOCK, and\Neach command takes a single 32-bit
Dialogue: 0,0:07:22.54,0:07:29.43,Default,,0000,0000,0000,,argument. So you send a command, it has a\Nnumber, and an argument. And all the
Dialogue: 0,0:07:29.43,0:07:33.58,Default,,0000,0000,0000,,commands are categorised into classes. And\Nthere is one specific interesting class,
Dialogue: 0,0:07:33.58,0:07:37.81,Default,,0000,0000,0000,,which is class 8. Because if you look at\Nthe specific section, you'll see that
Dialogue: 0,0:07:37.81,0:07:44.24,Default,,0000,0000,0000,,command 60 up to 63 are reserved for the\Nmanufacturer. So if something interesting
Dialogue: 0,0:07:44.24,0:07:50.04,Default,,0000,0000,0000,,is going to happen, it will be probably\Nhappen with these commands. So let's go
Dialogue: 0,0:07:50.04,0:07:55.66,Default,,0000,0000,0000,,back to the patch. Samsung said, they\Nfixed the bug, right? So S3 devices
Dialogue: 0,0:07:55.66,0:08:04.85,Default,,0000,0000,0000,,shouldn't get bricked anymore. Let's … so,\Nthis patch actually, the first thing that
Dialogue: 0,0:08:04.85,0:08:10.57,Default,,0000,0000,0000,,… it compares the card's name to VTU00M,\Nwhich is the hardware revision of the
Dialogue: 0,0:08:10.57,0:08:15.67,Default,,0000,0000,0000,,faulty chip, and then they compare a\Nnumber to the value 0xF1, and this is
Dialogue: 0,0:08:15.67,0:08:21.92,Default,,0000,0000,0000,,actually the firmware version of this\Nchip. And then, they call a function which
Dialogue: 0,0:08:21.92,0:08:26.65,Default,,0000,0000,0000,,is called mmc_start_movi_smart, which\Nisn't that interesting, so I'm not going
Dialogue: 0,0:08:26.65,0:08:32.50,Default,,0000,0000,0000,,to talk about. And if all this comparisons\Nare true, then it will call
Dialogue: 0,0:08:32.50,0:08:35.42,Default,,0000,0000,0000,,mmc_start_movi_operation, which is the\Nmain logic
Dialogue: 0,0:08:35.42,0:08:44.49,Default,,0000,0000,0000,,responsible for fixing the chip. And the\Nthing to note about this patch is that it
Dialogue: 0,0:08:44.49,0:08:48.92,Default,,0000,0000,0000,,… this code runs everytime you boot the\Ndevice. So everytime the eMMC chip is
Dialogue: 0,0:08:48.92,0:08:55.62,Default,,0000,0000,0000,,powered on, this code runs. OK, so let's\Ntalk about mmc_start_movi_operation. So,
Dialogue: 0,0:08:55.62,0:09:02.19,Default,,0000,0000,0000,,this is … I edited the code for brevity,\Nit's not the exact same patch but this is
Dialogue: 0,0:09:02.19,0:09:07.98,Default,,0000,0000,0000,,basically the logic that they used. And\Nthis is very interesting. There is one
Dialogue: 0,0:09:07.98,0:09:16.74,Default,,0000,0000,0000,,strange thing about this function. This\Nmmc_movi_erase_cmd … erase is … an eMMC
Dialogue: 0,0:09:16.74,0:09:23.27,Default,,0000,0000,0000,,command which takes two arguments. It uses\Ntwo arguments because you precede it with
Dialogue: 0,0:09:23.27,0:09:28.50,Default,,0000,0000,0000,,a different command, so you can give it\Ntwo arguments. And the first arguments is
Dialogue: 0,0:09:28.50,0:09:33.95,Default,,0000,0000,0000,,this start block number to erase, and the\Nsecond one is the end block number to
Dialogue: 0,0:09:33.95,0:09:39.69,Default,,0000,0000,0000,,erase. And it erases all the blocks in-\Nbetween. So what should happen is that the
Dialogue: 0,0:09:39.69,0:09:46.98,Default,,0000,0000,0000,,first call to this function should erase\Nall the blocks starting with 40300 up to
Dialogue: 0,0:09:46.98,0:09:56.77,Default,,0000,0000,0000,,block number 4A03B510, right? This doesn't\Nmake any sense, and then the next call is
Dialogue: 0,0:09:56.77,0:10:02.28,Default,,0000,0000,0000,,the … the ranges overlap. And this was\Nvery strange. So my guess was that this is
Dialogue: 0,0:10:02.28,0:10:08.39,Default,,0000,0000,0000,,probably not an erase command. It is\Nprobably something else, somehow. And the
Dialogue: 0,0:10:08.39,0:10:13.01,Default,,0000,0000,0000,,next thing to note about this function is\Nthat you see the first two calls are
Dialogue: 0,0:10:13.01,0:10:19.81,Default,,0000,0000,0000,,mmc_movi_cmd, and the last calls are also\Nto the function mmc_movi_cmd. And
Dialogue: 0,0:10:19.81,0:10:25.13,Default,,0000,0000,0000,,mmc_movi_cmd is basically command 62,\Nwhich is a class-8-command. So it is
Dialogue: 0,0:10:25.13,0:10:34.09,Default,,0000,0000,0000,,reserved to the manufacturer. And my guess\Nwas that the first two calls basically
Dialogue: 0,0:10:34.09,0:10:39.59,Default,,0000,0000,0000,,enter some secret backdoor mode that\NSamsung hid inside the eMMC chip. And the
Dialogue: 0,0:10:39.59,0:10:46.36,Default,,0000,0000,0000,,last two calls leave this mode. So when\Nyou're in this mode, erase command doesn't
Dialogue: 0,0:10:46.36,0:10:52.84,Default,,0000,0000,0000,,do erase anymore. It does something else.\NAnd then, I saw that if you inspect the
Dialogue: 0,0:10:52.84,0:10:56.95,Default,,0000,0000,0000,,first argument, you'll see that the\Nnumbers are consecutive and they increment
Dialogue: 0,0:10:56.95,0:11:06.08,Default,,0000,0000,0000,,by four, except for the last number. All\Nthe first … the first five numbers are
Dialogue: 0,0:11:06.08,0:11:12.20,Default,,0000,0000,0000,,consecutive. And the next thing … so it\Nlooks something like memory addresses,
Dialogue: 0,0:11:12.20,0:11:18.06,Default,,0000,0000,0000,,right? And if you look at the second\Nargument, I noticed
Dialogue: 0,0:11:18.06,0:11:26.81,Default,,0000,0000,0000,,something very interesting. If I assumed\Nthis is memory data, then if you look at
Dialogue: 0,0:11:26.81,0:11:33.24,Default,,0000,0000,0000,,it like as little-endian numbers, you'll\Nsee 10B5, so it starts with 10B5. And I
Dialogue: 0,0:11:33.24,0:11:40.24,Default,,0000,0000,0000,,used to code a lot of ARM-assembly, and\N10B5 is PUSH in Thumb. And Thumb is an
Dialogue: 0,0:11:40.24,0:11:45.87,Default,,0000,0000,0000,,instruction set from the ARM\Nspecification. And functions in Thumb
Dialogue: 0,0:11:45.87,0:11:54.35,Default,,0000,0000,0000,,start with PUSH, right? So this is an eMMC\Nnext to a thumb. {\i1}laughter{\i0} And basically,
Dialogue: 0,0:11:54.35,0:11:58.87,Default,,0000,0000,0000,,this is my current understanding of how\NeMMC works. So you have this whole eMMC
Dialogue: 0,0:11:58.87,0:12:02.22,Default,,0000,0000,0000,,chip, but there is not only a NAND flash\Ninside it, there is also a
Dialogue: 0,0:12:02.22,0:12:06.84,Default,,0000,0000,0000,,microcontroller. And in Samsung's case,\Nthis is an ARM-based microcontroller which
Dialogue: 0,0:12:06.84,0:12:14.12,Default,,0000,0000,0000,,contains some firmware. So I thought this\Npatch might modify the internal memory of
Dialogue: 0,0:12:14.12,0:12:21.15,Default,,0000,0000,0000,,this chip somehow. So what I wanted to do\Nis to examine what this patch does. So I
Dialogue: 0,0:12:21.15,0:12:27.05,Default,,0000,0000,0000,,just took all this data that it writes and\Nput it into a binary file which I called
Dialogue: 0,0:12:27.05,0:12:35.24,Default,,0000,0000,0000,,patch.bin and this is, I just used IDA to\Nsee what is going on there and this is
Dialogue: 0,0:12:35.24,0:12:42.99,Default,,0000,0000,0000,,Samsung's patch. So … at the bottom, you\Ncan see the actual Thumb instructions but
Dialogue: 0,0:12:42.99,0:12:47.51,Default,,0000,0000,0000,,if you're not familiar with Thumb, you can\Nsee also a C-like pseudocode. And what
Dialogue: 0,0:12:47.51,0:12:52.42,Default,,0000,0000,0000,,they do is basically, they call a function\Nand if it returns zero, the chip will go
Dialogue: 0,0:12:52.42,0:12:57.59,Default,,0000,0000,0000,,into an infinite loop. And this is\Ninteresting, because later on, I
Dialogue: 0,0:12:57.59,0:13:03.81,Default,,0000,0000,0000,,understood that what was there before the\Npatch, it was just a call to this function
Dialogue: 0,0:13:03.81,0:13:09.20,Default,,0000,0000,0000,,and there wasn't this check. So they took\Na single call to a function and turned it
Dialogue: 0,0:13:09.20,0:13:15.47,Default,,0000,0000,0000,,into a call to the same function, but if\Nit returned zero, they just go into an
Dialogue: 0,0:13:15.47,0:13:20.90,Default,,0000,0000,0000,,infinite loop. So my thought was, this\Ncan't fix anything, right? {\i1}laughter{\i0}
Dialogue: 0,0:13:20.90,0:13:26.12,Default,,0000,0000,0000,,Because the chip is either going to do the\Nsame thing as before or it is going to go
Dialogue: 0,0:13:26.12,0:13:34.70,Default,,0000,0000,0000,,into an infinite loop. And then I read\Nsome threads over forums and I saw this
Dialogue: 0,0:13:34.70,0:13:40.06,Default,,0000,0000,0000,,thread. "Ultimate Galaxy S3 unusual\Nfreezing thread" And this is a quote from
Dialogue: 0,0:13:40.06,0:13:43.44,Default,,0000,0000,0000,,the actual thread, you can see that\N"Galaxy S3 is freezing with lockups,
Dialogue: 0,0:13:43.44,0:13:47.51,Default,,0000,0000,0000,,screen not responding … and ending with\Nunusual rebooting and bootlooping …
Dialogue: 0,0:13:47.51,0:13:51.75,Default,,0000,0000,0000,,Angry S3 users reporting this problem …\NAnd it keeps freezing every five minutes
Dialogue: 0,0:13:51.75,0:13:57.02,Default,,0000,0000,0000,,or 50+ freezes a day". This is insane,\Nright? This phone is not usable. I can't
Dialogue: 0,0:13:57.02,0:14:04.89,Default,,0000,0000,0000,,use it as my phone if it freezes every\Nfive minutes. And I had an S3 back then,
Dialogue: 0,0:14:04.89,0:14:12.61,Default,,0000,0000,0000,,and I noti… I started observing freezes in\Nmy phone as well. So the next step that I
Dialogue: 0,0:14:12.61,0:14:17.60,Default,,0000,0000,0000,,wanted to do is to obtain the eMMC\Nfirmware in order to understand how it
Dialogue: 0,0:14:17.60,0:14:23.32,Default,,0000,0000,0000,,works. So how do you get a firmware? The\Nfirst way to do it is to write … so I can
Dialogue: 0,0:14:23.32,0:14:29.17,Default,,0000,0000,0000,,write the eMMC's memory, right? So I can\Njust write code to random locations and
Dialogue: 0,0:14:29.17,0:14:37.26,Default,,0000,0000,0000,,hopefully it will get run somehow. And\Nthen, just write things to different
Dialogue: 0,0:14:37.26,0:14:43.38,Default,,0000,0000,0000,,addresses and do lucky guesses and maybe I\Nwill see something on the eMMC bus and
Dialogue: 0,0:14:43.38,0:14:50.31,Default,,0000,0000,0000,,then try to obtain the firmware. But it is\Nlike a shot in the dark. So the next thing
Dialogue: 0,0:14:50.31,0:14:55.65,Default,,0000,0000,0000,,I thought about doing is to fuzz different\Ncommands. Like use command 60, 61,
Dialogue: 0,0:14:55.65,0:15:02.09,Default,,0000,0000,0000,,different class-8-commands. But I didn't\Nwant to destroy my own eMMC, which was
Dialogue: 0,0:15:02.09,0:15:07.80,Default,,0000,0000,0000,,still working. So the last thing I thought\Nabout then is to look for clues. So how do
Dialogue: 0,0:15:07.80,0:15:13.95,Default,,0000,0000,0000,,you look for clues? I just googled these\Nnumbers that Samsung used to enter this
Dialogue: 0,0:15:13.95,0:15:18.85,Default,,0000,0000,0000,,backdoor mode. And I saw a different\Npatch. So this is a patch from a different
Dialogue: 0,0:15:18.85,0:15:23.66,Default,,0000,0000,0000,,device, and it is called "Patch the\Nfirmware of certain Samsung emmc parts to
Dialogue: 0,0:15:23.66,0:15:31.93,Default,,0000,0000,0000,,fix a bug" … ehhh {\i1}laughter{\i0} … and it used\Nthe same mode as before, so notice that
Dialogue: 0,0:15:31.93,0:15:41.76,Default,,0000,0000,0000,,they use arguments 0xEFAC62EC and then it\Nis 0x10210000. And this is important. So
Dialogue: 0,0:15:41.76,0:15:48.77,Default,,0000,0000,0000,,they use 0x10210000, right? And then they\Nwrite the value 0xFF to the address for
Dialogue: 0,0:15:48.77,0:15:55.70,Default,,0000,0000,0000,,the D9C. But then there was something else\Nafterwards. So if you continue to read
Dialogue: 0,0:15:55.70,0:16:01.94,Default,,0000,0000,0000,,this patch, you will se this thing. This\Nis a snippet which is enclosed by #ifed,
Dialogue: 0,0:16:01.94,0:16:08.81,Default,,0000,0000,0000,,which is called test_mmc_fw_patching, and\Nthey used the same emmc 62EC as before,
Dialogue: 0,0:16:08.81,0:16:18.51,Default,,0000,0000,0000,,but now they use the argument 10210002.\NAnd the next thing is that they … they use
Dialogue: 0,0:16:18.51,0:16:24.12,Default,,0000,0000,0000,,an erase command with the same addresses\Nas before, but then they do a read
Dialogue: 0,0:16:24.12,0:16:30.12,Default,,0000,0000,0000,,command, right? I was wondering … hm …\Nthis might be
Dialogue: 0,0:16:30.12,0:16:35.22,Default,,0000,0000,0000,,Samsung's way of reading the memory\Naddress of the … the memory of the eMMC
Dialogue: 0,0:16:35.22,0:16:39.71,Default,,0000,0000,0000,,chip. Because they use an erase command\Nwith the same address as before. The
Dialogue: 0,0:16:39.71,0:16:46.67,Default,,0000,0000,0000,,second argument is 4, which looks like a\Nsize, and then they read a DWORD from the
Dialogue: 0,0:16:46.67,0:16:52.08,Default,,0000,0000,0000,,eMMC. So I took this snippet of code and\Nmodified it into … what if I did into this
Dialogue: 0,0:16:52.08,0:16:57.65,Default,,0000,0000,0000,,snippet of code? Which basically just\Nloops over all the addresses in the
Dialogue: 0,0:16:57.65,0:17:04.51,Default,,0000,0000,0000,,address space. I just guessed how big the\Naddress space is. And I just read a single
Dialogue: 0,0:17:04.51,0:17:12.01,Default,,0000,0000,0000,,DWORD everytime and I dumped it into a\Nfile. And then, I got this thing, which
Dialogue: 0,0:17:12.01,0:17:20.60,Default,,0000,0000,0000,,looks like a firmware, right? So … the\Nnames aren't the names that you see, like,
Dialogue: 0,0:17:20.60,0:17:27.100,Default,,0000,0000,0000,,MMI, and hard_fault … these are all my\Nnames. What I saw was addresses, but this
Dialogue: 0,0:17:27.100,0:17:36.25,Default,,0000,0000,0000,,looks like a Thumb vector table. So I\Nunderstood that I basically got the
Dialogue: 0,0:17:36.25,0:17:42.54,Default,,0000,0000,0000,,firmware of my own chip. So the next step\Nwas to reverse the firmware in order to
Dialogue: 0,0:17:42.54,0:17:46.97,Default,,0000,0000,0000,,analyse what the bug is. So luckily for\Nme, the firmware contains Strings, so I
Dialogue: 0,0:17:46.97,0:17:51.80,Default,,0000,0000,0000,,can use them as part of my reverting\Nprocess. But unfortunately, it contained a
Dialogue: 0,0:17:51.80,0:18:00.99,Default,,0000,0000,0000,,String. A single String. And it was this\Nstring,. Which isn't very useful, if you
Dialogue: 0,0:18:00.99,0:18:08.48,Default,,0000,0000,0000,,are trying to reverse a firmware. And as\Nyou can see, this is a snippet of my
Dialogue: 0,0:18:08.48,0:18:17.50,Default,,0000,0000,0000,,reversing process. I used a lot of, like,\Nnames, flip_bit_in_somewhere, memory
Dialogue: 0,0:18:17.50,0:18:26.62,Default,,0000,0000,0000,,mapped I/O 1000 2 DWORDS … But, I\Nbasically understood the high-level logic
Dialogue: 0,0:18:26.62,0:18:32.24,Default,,0000,0000,0000,,of this code. And I got to the point in\Nwhich I can understand most of the
Dialogue: 0,0:18:32.24,0:18:37.74,Default,,0000,0000,0000,,firmware. So let's talk about debug.\NBefore we talk about debug, we have to
Dialogue: 0,0:18:37.74,0:18:45.70,Default,,0000,0000,0000,,talk about what is eMMC exactly. So let's\Ntalk about normal storage first. This is,
Dialogue: 0,0:18:45.70,0:18:51.40,Default,,0000,0000,0000,,like, hard-drives. You have two operations\Nwhich you can do. You have a read
Dialogue: 0,0:18:51.40,0:18:54.71,Default,,0000,0000,0000,,operation which reads data from the device\Nand then you have a write operation which
Dialogue: 0,0:18:54.71,0:19:01.14,Default,,0000,0000,0000,,writes data onto the device. This is\Npretty normal. Then you have NAND flash
Dialogue: 0,0:19:01.14,0:19:06.77,Default,,0000,0000,0000,,storage. So if you have NAND flash\Nstorage, you can do a read operation which
Dialogue: 0,0:19:06.77,0:19:13.50,Default,,0000,0000,0000,,still reads data, and this is as before,\Nbut write operation actually turns off
Dialogue: 0,0:19:13.50,0:19:17.79,Default,,0000,0000,0000,,bits. If a bit was already 0,\Nit won't turn into
Dialogue: 0,0:19:17.79,0:19:24.76,Default,,0000,0000,0000,,a 1. So this is basically applying a mask\Nto bits on the storage. And then you have
Dialogue: 0,0:19:24.76,0:19:30.99,Default,,0000,0000,0000,,an erase command, so you have to … you got to\Nhave same way for reversing this process.
Dialogue: 0,0:19:30.99,0:19:37.72,Default,,0000,0000,0000,,An erase operation erases a whole erase-\Nblock. It turns all this bits in the block
Dialogue: 0,0:19:37.72,0:19:48.33,Default,,0000,0000,0000,,all to 1s, but it's a slow operation. And\Nthere's another problem: Erase-blocks have
Dialogue: 0,0:19:48.33,0:19:53.70,Default,,0000,0000,0000,,a limited program/erase cycle. So if you\Nissue something like a 1000 or 10'000 or
Dialogue: 0,0:19:53.70,0:20:01.31,Default,,0000,0000,0000,,100'000 erases, the block will eventually\Ndie and is not usable anymore. So
Dialogue: 0,0:20:01.31,0:20:10.12,Default,,0000,0000,0000,,something have to … some software have to\Ndo this translation to take this (…?)
Dialogue: 0,0:20:10.12,0:20:18.00,Default,,0000,0000,0000,,storage and do an abstraction which will\Nshow it like normal storage. So, this is
Dialogue: 0,0:20:18.00,0:20:23.05,Default,,0000,0000,0000,,called an FTL---or Flash Translation\NLayer. This is common. And the FTL is
Dialogue: 0,0:20:23.05,0:20:28.38,Default,,0000,0000,0000,,responsible for many things but some\Nexamples are wear leveling, which is
Dialogue: 0,0:20:28.38,0:20:33.41,Default,,0000,0000,0000,,spreading out erases among different\Nblocks, so no single block gets erased a
Dialogue: 0,0:20:33.41,0:20:39.29,Default,,0000,0000,0000,,lot of times. And then it also does bad\Nblock management; if block already died,
Dialogue: 0,0:20:39.29,0:20:44.63,Default,,0000,0000,0000,,then it will remap it internally to a\Ndifferent block. It actually has spare
Dialogue: 0,0:20:44.63,0:20:50.81,Default,,0000,0000,0000,,blocks and then it … the firmware in\NSamsung's case is also responsible for the
Dialogue: 0,0:20:50.81,0:20:59.26,Default,,0000,0000,0000,,eMMC bus communication---or some of it. So\Nwhat is the bug exactly? So … when you do
Dialogue: 0,0:20:59.26,0:21:05.51,Default,,0000,0000,0000,,write operations on the device, the FTL\Nhas to save some metadata for itself,
Dialogue: 0,0:21:05.51,0:21:11.73,Default,,0000,0000,0000,,because it has to keep track on how many\Ntimes this block was erased and what is
Dialogue: 0,0:21:11.73,0:21:19.79,Default,,0000,0000,0000,,the internal mapping and so on. So it has\Nsome metadata that it saves for itself.
Dialogue: 0,0:21:19.79,0:21:27.52,Default,,0000,0000,0000,,And when you do write operations, it has\Nto modify this metadata. And the actual
Dialogue: 0,0:21:27.52,0:21:35.84,Default,,0000,0000,0000,,bug was a miscalculation in this code\Nwhich---not always, but sometimes---made
Dialogue: 0,0:21:35.84,0:21:42.00,Default,,0000,0000,0000,,the data corrupt. And once it happened---\Nit should only happen once---if the data
Dialogue: 0,0:21:42.00,0:21:48.95,Default,,0000,0000,0000,,got corrupted---and this is before\NSamsung's patch---everytime you try to
Dialogue: 0,0:21:48.95,0:21:56.05,Default,,0000,0000,0000,,power on the eMMC chip, the FTL will try\Nto parse this data, and it's corrupt, so
Dialogue: 0,0:21:56.05,0:22:01.07,Default,,0000,0000,0000,,it will raise a CPU exception. And the\Ndefault exception handler in Samsung's
Dialogue: 0,0:22:01.07,0:22:07.74,Default,,0000,0000,0000,,case is just an infinite loop. So\Nthe device … so … so you use the device
Dialogue: 0,0:22:07.74,0:22:14.75,Default,,0000,0000,0000,,and one day, the metadata gets corrupted\Nand then you try to turn it on and it
Dialogue: 0,0:22:14.75,0:22:19.14,Default,,0000,0000,0000,,tries to parse the metadata and it's\Ncorrupt, so it throws an exception and
Dialogue: 0,0:22:19.14,0:22:25.09,Default,,0000,0000,0000,,then the eMMC goes into an infinite loop\Nand you can't access it anymore. And the
Dialogue: 0,0:22:25.09,0:22:29.48,Default,,0000,0000,0000,,eMMC is basically, essentially, dead.\NBecause you send commands into it and
Dialogue: 0,0:22:29.48,0:22:33.22,Default,,0000,0000,0000,,nothing responds because the firmware is\Nthe one is dead, the software … that is
Dialogue: 0,0:22:33.22,0:22:37.76,Default,,0000,0000,0000,,responsible for answering eMMC commands.\NSo Samsung's patch was something about
Dialogue: 0,0:22:37.76,0:22:42.96,Default,,0000,0000,0000,,this. Something like this. Right before\Nthe metadata is about to get corrupted,
Dialogue: 0,0:22:42.96,0:22:50.74,Default,,0000,0000,0000,,halt the CPU. So, there's no bug, right?\NRight before the bug is about to happen,
Dialogue: 0,0:22:50.74,0:22:58.55,Default,,0000,0000,0000,,just halt the CPU so it never happens. And\Nthis then, like, sudden death syndrome
Dialogue: 0,0:22:58.55,0:23:06.20,Default,,0000,0000,0000,,into sudden freeze syndrome. So I wanted\Nto fix my own device. So, a quick recap: I
Dialogue: 0,0:23:06.20,0:23:11.82,Default,,0000,0000,0000,,got the eMMC firmware by analysing\NSamsung's patch. The firmware had the bug
Dialogue: 0,0:23:11.82,0:23:16.54,Default,,0000,0000,0000,,causing FTL corruption. Once it happened,\Nthe chip won't boot anymore and Samsung's
Dialogue: 0,0:23:16.54,0:23:22.94,Default,,0000,0000,0000,,patch was to avoid the bug happening at\Nall. So the next step is, obviously, to
Dialogue: 0,0:23:22.94,0:23:31.25,Default,,0000,0000,0000,,resurrect dead phones, right? … yeah,\Nwhat?! How do I … So the eMMC gets into a
Dialogue: 0,0:23:31.25,0:23:37.07,Default,,0000,0000,0000,,loop at boot. But what happens before it\Ngets into this loop? So I took a look at
Dialogue: 0,0:23:37.07,0:23:44.06,Default,,0000,0000,0000,,the firmware and I saw this memory layout.\NAs you can see at address 0, there's
Dialogue: 0,0:23:44.06,0:23:51.51,Default,,0000,0000,0000,,something that I called a "Boot ROM". And\Nit's a ROM, you can't write into it. And
Dialogue: 0,0:23:51.51,0:23:58.49,Default,,0000,0000,0000,,it is a code and what it does, it\Ninitialises the eMMC hardware and it loads
Dialogue: 0,0:23:58.49,0:24:04.69,Default,,0000,0000,0000,,the firmware from the NAND flash chip\Nitself. And this is strange, because if
Dialogue: 0,0:24:04.69,0:24:10.73,Default,,0000,0000,0000,,the boot ROM is already there, why don't …\Nwhy doesn't it already doing the things
Dialogue: 0,0:24:10.73,0:24:16.27,Default,,0000,0000,0000,,that the firmware is responsible to do? So\Nmy guess was that the firmware was too big
Dialogue: 0,0:24:16.27,0:24:21.56,Default,,0000,0000,0000,,to reside wherever the boot ROM resides,\Nso they had to, like, bootstrap it from
Dialogue: 0,0:24:21.56,0:24:26.37,Default,,0000,0000,0000,,the external NAND flash. And then it also\Nhas it's own machinery for eMMC commands,
Dialogue: 0,0:24:26.37,0:24:31.51,Default,,0000,0000,0000,,which is strange, because all it has to do\Nis just load its firmware. So my guess is
Dialogue: 0,0:24:31.51,0:24:36.11,Default,,0000,0000,0000,,that, during their\Nproduction process, the NAND flash is
Dialogue: 0,0:24:36.11,0:24:43.01,Default,,0000,0000,0000,,empty and there's no firmware. And then,\Nwhen Samsung produces these chips, they
Dialogue: 0,0:24:43.01,0:24:47.83,Default,,0000,0000,0000,,plug them in and there's no firmware, so\Nthe boot ROM goes into some kind of
Dialogue: 0,0:24:47.83,0:24:53.86,Default,,0000,0000,0000,,recovery mode and it exposes an eMMC bus\Nand from there you can write your new
Dialogue: 0,0:24:53.86,0:24:58.52,Default,,0000,0000,0000,,firmware. And the boot ROM is basically a\Nstripped-down firmware. There's no FTL,
Dialogue: 0,0:24:58.52,0:25:05.70,Default,,0000,0000,0000,,but it looks like the firmware itself. And\Nthis is my current understanding of how S3
Dialogue: 0,0:25:05.70,0:25:13.12,Default,,0000,0000,0000,,works. So inside the eMMC you have two\Nsilicon dies, and the first is an ARM chip
Dialogue: 0,0:25:13.12,0:25:17.19,Default,,0000,0000,0000,,which has a boot ROM, which loads the\Nfirmware from the external NAND flash and
Dialogue: 0,0:25:17.19,0:25:23.20,Default,,0000,0000,0000,,then boots it. So, if we could ever talk\Nto boot ROM, this might be interesting
Dialogue: 0,0:25:23.20,0:25:29.24,Default,,0000,0000,0000,,because we could maybe do something\Ninteresting. But the firmware loading
Dialogue: 0,0:25:29.24,0:25:33.73,Default,,0000,0000,0000,,actually succeeds because the firmware is\Nstill intact. The boot ROM will try to
Dialogue: 0,0:25:33.73,0:25:37.00,Default,,0000,0000,0000,,load the firmware, the firmware is still\Nthere and it will jump into it and the
Dialogue: 0,0:25:37.00,0:25:40.65,Default,,0000,0000,0000,,firmware executes and goes into infinite\Nloop so there is no chance of every
Dialogue: 0,0:25:40.65,0:25:46.95,Default,,0000,0000,0000,,talking to the boot ROM, right? Though,\Nactually, not. This is not correct,
Dialogue: 0,0:25:46.95,0:25:54.03,Default,,0000,0000,0000,,because on boot, there's this function at\Naddress 7DBC and a timer is being set for
Dialogue: 0,0:25:54.03,0:25:59.97,Default,,0000,0000,0000,,35ms and if during this time period, some\Ninterrupt fires, this is interrupt #7, I
Dialogue: 0,0:25:59.97,0:26:08.21,Default,,0000,0000,0000,,don't know what it is yet. They read a\Nvalue from a memory-mapped I/O address and
Dialogue: 0,0:26:08.21,0:26:16.21,Default,,0000,0000,0000,,they compare it to this constant magic.\NAnd if this comparison is true, firmware
Dialogue: 0,0:26:16.21,0:26:22.40,Default,,0000,0000,0000,,loading is skipped and it goes right into\Nthis recovery mode. And my guess is that …
Dialogue: 0,0:26:22.40,0:26:29.24,Default,,0000,0000,0000,,so this is a schematic of the boot process\Nand the right … the left column is the
Dialogue: 0,0:26:29.24,0:26:35.67,Default,,0000,0000,0000,,normal boot process and if we ever get to\Nthe right column, we will get into this
Dialogue: 0,0:26:35.67,0:26:42.26,Default,,0000,0000,0000,,recovery mode. So my guess is that this\Ninterrupt #7 corresponds to some eMMC
Dialogue: 0,0:26:42.26,0:26:49.27,Default,,0000,0000,0000,,command. And this value that they read\Nfrom memory-mapped I/O is probably the
Dialogue: 0,0:26:49.27,0:26:57.08,Default,,0000,0000,0000,,eMMC argument, because it is 32 bits. So\Nthat eMMCs get stuck on boot. So this is
Dialogue: 0,0:26:57.08,0:27:02.80,Default,,0000,0000,0000,,if the chip is already dead. However,\Nright before it gets stuck, there is a
Dialogue: 0,0:27:02.80,0:27:06.43,Default,,0000,0000,0000,,time window and during this time\Nwindow, if you somehow
Dialogue: 0,0:27:06.43,0:27:13.79,Default,,0000,0000,0000,,trigger this interrupt, the boot process\Nis aborted and it goes right into eMMC
Dialogue: 0,0:27:13.79,0:27:18.18,Default,,0000,0000,0000,,boot ROM recovery mode, which is\Ninteresting. But the phone is already
Dialogue: 0,0:27:18.18,0:27:25.08,Default,,0000,0000,0000,,dead. How do I even talk to the eMMC chip?\NSo I could've used the hardware mod, like,
Dialogue: 0,0:27:25.08,0:27:31.86,Default,,0000,0000,0000,,desolder the eMMC and send commands\Nexternally but … ehh … I wanted to, like,
Dialogue: 0,0:27:31.86,0:27:40.68,Default,,0000,0000,0000,,do something with software, because I\Ndon't know how to desolder BGA chips. So
Dialogue: 0,0:27:40.68,0:27:46.21,Default,,0000,0000,0000,,the next step is to talk to the eMMC by\Nsome kind of magic and then we'll access
Dialogue: 0,0:27:46.21,0:27:53.97,Default,,0000,0000,0000,,the eMMC boot ROM. And then, we can repair\Nit from this boot ROM recovery mode. So I
Dialogue: 0,0:27:53.97,0:27:58.18,Default,,0000,0000,0000,,said, if you're lucky, you get this\Nscreen. So this is the phone's bootloader.
Dialogue: 0,0:27:58.18,0:28:03.79,Default,,0000,0000,0000,,This is sboot. And it is saved on the eMMC\Nitself. So how do you get this? If the
Dialogue: 0,0:28:03.79,0:28:11.21,Default,,0000,0000,0000,,eMMC chip doesn't respond, how the main\NCPU gets to execute this bootloader? So,
Dialogue: 0,0:28:11.21,0:28:16.99,Default,,0000,0000,0000,,apparently, if you read Samsung's\Nspecification, you will see that the eMMC
Dialogue: 0,0:28:16.99,0:28:22.01,Default,,0000,0000,0000,,has two partitions and it's not a\Npartition in the filesystem-sense, it's a
Dialogue: 0,0:28:22.01,0:28:27.02,Default,,0000,0000,0000,,partition in the eMMC-sense. And there's a\Nboot partition and a user partition. And
Dialogue: 0,0:28:27.02,0:28:33.19,Default,,0000,0000,0000,,the boot partition holds sboot in\NSamsung's case, which is the bootloader
Dialogue: 0,0:28:33.19,0:28:39.93,Default,,0000,0000,0000,,for the main CPU. And the user partition\Nholds everything else. So it stores Linux
Dialogue: 0,0:28:39.93,0:28:49.50,Default,,0000,0000,0000,,and all the Android filesystem and all the\Napps etc. So the boot partition has its
Dialogue: 0,0:28:49.50,0:28:54.99,Default,,0000,0000,0000,,own FTL metadata and the user partition\Nalso has its own metadata. A friend of
Dialogue: 0,0:28:54.99,0:29:02.25,Default,,0000,0000,0000,,mine had a bricked S3 which does load\Nsboot. So he gets this screen. And … what
Dialogue: 0,0:29:02.25,0:29:07.47,Default,,0000,0000,0000,,I understood had happened is that only the\Nuser's … the user partition metadata got
Dialogue: 0,0:29:07.47,0:29:11.47,Default,,0000,0000,0000,,corrupted, so the boot partition is still\Nintact. And I suspect, this is a common
Dialogue: 0,0:29:11.47,0:29:15.49,Default,,0000,0000,0000,,scenario. When you write to your device,\Nyou usually don't try to write to the boot
Dialogue: 0,0:29:15.49,0:29:19.27,Default,,0000,0000,0000,,partition, you write to the user\Npartition. So if something is about to get
Dialogue: 0,0:29:19.27,0:29:25.24,Default,,0000,0000,0000,,corrupted, it probably will be in the user\Npartition. So this is how S3 breaks. The
Dialogue: 0,0:29:25.24,0:29:31.27,Default,,0000,0000,0000,,main CPU will power on and it will try to\Naccess the eMMC and asks: Give me sboot.
Dialogue: 0,0:29:31.27,0:29:41.60,Default,,0000,0000,0000,,And the eMMC parses the boot partition and\Nit will return sboot to the main
Dialogue: 0,0:29:41.60,0:29:47.21,Default,,0000,0000,0000,,CPU and then sboot will try to access the\Nuser partition in order to load Linux and
Dialogue: 0,0:29:47.21,0:29:52.98,Default,,0000,0000,0000,,then the eMMC tries to parse the user\Npartition metadata and it's corrupt, so it
Dialogue: 0,0:29:52.98,0:29:59.69,Default,,0000,0000,0000,,goes into a loop. So sboot actually has a\Ndevice firmware update mode, that is
Dialogue: 0,0:29:59.69,0:30:03.69,Default,,0000,0000,0000,,called "Download mode", and there is\Nprotocol of USB, the phone side is called
Dialogue: 0,0:30:03.69,0:30:08.13,Default,,0000,0000,0000,,Loke and the computer side is called Odin.\NI guess, this is a reference to the Norsk
Dialogue: 0,0:30:08.13,0:30:13.56,Default,,0000,0000,0000,,methology. And there's no way of sending\Nlow-level eMMC commands. So if you ever
Dialogue: 0,0:30:13.56,0:30:20.45,Default,,0000,0000,0000,,saw this screen, this is Odin software.\NIt's a software made by Samsung to talk to
Dialogue: 0,0:30:20.45,0:30:27.15,Default,,0000,0000,0000,,this protocol. And in this protocol, you\Ncan't send raw eMMC commands to the eMMC
Dialogue: 0,0:30:27.15,0:30:35.24,Default,,0000,0000,0000,,chip, so I need to send commands to the\Nchip, but the code isn't there in sboot.
Dialogue: 0,0:30:35.24,0:30:41.75,Default,,0000,0000,0000,,So, obviously, the thing that I'll have to do\Nis to exploit sboot, and run my own code.
Dialogue: 0,0:30:41.75,0:30:53.11,Default,,0000,0000,0000,,This is taken from USB PIT packets handler\Nfrom sboot. This is a C pseudocode that I
Dialogue: 0,0:30:53.11,0:31:00.36,Default,,0000,0000,0000,,wrote. So, you control this variable is\Ndumped and if it is 1, it will read
Dialogue: 0,0:31:00.36,0:31:05.35,Default,,0000,0000,0000,,something from the USB packet that you\Nsend to it and then it will give you a
Dialogue: 0,0:31:05.35,0:31:14.12,Default,,0000,0000,0000,,buffer and it will use this number that\Nyou gave it as an offset to this buffer
Dialogue: 0,0:31:14.12,0:31:21.48,Default,,0000,0000,0000,,but it doesn't do any boundary checks at\Nall. So this is an out-of-bounds read
Dialogue: 0,0:31:21.48,0:31:27.41,Default,,0000,0000,0000,,vulnerability. And the second case reads a\Nsize from the USB packet and then reads it
Dialogue: 0,0:31:27.41,0:31:35.25,Default,,0000,0000,0000,,into this USB buffer, which is constantly\Nallocated on the heap, it's of size 2000,
Dialogue: 0,0:31:35.25,0:31:40.01,Default,,0000,0000,0000,,but it doesn't do any boundary checks at\Nall either. So, this is a heap-overflow
Dialogue: 0,0:31:40.01,0:31:45.09,Default,,0000,0000,0000,,vulnerability, right? So eventually I\Nfound that this is not actually a 0-day.
Dialogue: 0,0:31:45.09,0:31:53.12,Default,,0000,0000,0000,,If you take, like an S8 or S7, this\Nvulnerability is fixed but for S3, which
Dialogue: 0,0:31:53.12,0:31:58.76,Default,,0000,0000,0000,,is end-of-life, these vulnerabilities are\Nstill there. So if you have an S3, you can
Dialogue: 0,0:31:58.76,0:32:08.10,Default,,0000,0000,0000,,use it … So, let's talk about Samsung's\Nsboot heap implementation. So if you
Dialogue: 0,0:32:08.10,0:32:15.64,Default,,0000,0000,0000,,wanted to allocate some size and the heap\Nchose to use a chunk which is larger than
Dialogue: 0,0:32:15.64,0:32:19.81,Default,,0000,0000,0000,,the size that you wanted to allocate, it\Nwill split it from the end. And you will
Dialogue: 0,0:32:19.81,0:32:22.77,Default,,0000,0000,0000,,see an illustration in a moment.\NAnd the thing to
Dialogue: 0,0:32:22.77,0:32:26.67,Default,,0000,0000,0000,,note about this heap implementation is\Nthat there is no security mitigations at
Dialogue: 0,0:32:26.67,0:32:36.89,Default,,0000,0000,0000,,all. It's very basic. So … let's say that\Nyou wanted to allocate 50 bytes and the
Dialogue: 0,0:32:36.89,0:32:41.77,Default,,0000,0000,0000,,chunk that it chose was 100 bytes, then it\Nwill give you this part, which is the
Dialogue: 0,0:32:41.77,0:32:48.56,Default,,0000,0000,0000,,bottom part of the buffer. And the buffer,\Nthe chunk header, has a size number … a
Dialogue: 0,0:32:48.56,0:32:57.20,Default,,0000,0000,0000,,size parameter and it will use this size\Nto go to the end. So I wanted to achieve
Dialogue: 0,0:32:57.20,0:33:02.81,Default,,0000,0000,0000,,write-what-where in order to exploit\Nsboot. And I used … I exploited the chunk
Dialogue: 0,0:33:02.81,0:33:08.57,Default,,0000,0000,0000,,splitting technique. So the first thing to\Ndo was to fake a chunk header which I can
Dialogue: 0,0:33:08.57,0:33:13.63,Default,,0000,0000,0000,,control with some large size, so it will\Nget split, and then I had to figure out
Dialogue: 0,0:33:13.63,0:33:20.31,Default,,0000,0000,0000,,its address. And I can do this with the\Nfirst vulnerability, the relative read,
Dialogue: 0,0:33:20.31,0:33:24.16,Default,,0000,0000,0000,,and then the next step is to make sure\Nthis chunk is actually selected when you
Dialogue: 0,0:33:24.16,0:33:30.16,Default,,0000,0000,0000,,call malloc. And then, it will try to give\Nyou the bottom part of the buffer. So it
Dialogue: 0,0:33:30.16,0:33:35.12,Default,,0000,0000,0000,,will start from the chunk address and then\Nit will go all the way to the bottom,
Dialogue: 0,0:33:35.12,0:33:39.90,Default,,0000,0000,0000,,which is adding chunk size, and then it\Nwill go back the size you wanted to
Dialogue: 0,0:33:39.90,0:33:43.46,Default,,0000,0000,0000,,allocate, right? And we want to control\Nthis number and we can control this
Dialogue: 0,0:33:43.46,0:33:50.94,Default,,0000,0000,0000,,number. So if I just turn around this\Nequation, if I want to control address, I
Dialogue: 0,0:33:50.94,0:33:58.09,Default,,0000,0000,0000,,can just use this number as the chunk size\Nand then it will give me this address. So
Dialogue: 0,0:33:58.09,0:34:02.96,Default,,0000,0000,0000,,the actual details in my opinion are\Nboring. So you can find the exploit under
Dialogue: 0,0:34:02.96,0:34:10.78,Default,,0000,0000,0000,,this repository. It's public, so you can\Njust take an S3 and use it, and this is a
Dialogue: 0,0:34:10.78,0:34:19.95,Default,,0000,0000,0000,,demo. This is download mode, and this is\NHello World sboot exploit, so it works.
Dialogue: 0,0:34:19.95,0:34:25.46,Default,,0000,0000,0000,,OK, so, what if it's really dead? What if\Nthis happened, right? What if also the
Dialogue: 0,0:34:25.46,0:34:29.95,Default,,0000,0000,0000,,boot partition is gone? So, obiously\Nsomething has to load. Has to talk with
Dialogue: 0,0:34:29.95,0:34:36.56,Default,,0000,0000,0000,,the eMMC and load sboot, right? So there's\Nalso another piece of code which is called
Dialogue: 0,0:34:36.56,0:34:44.77,Default,,0000,0000,0000,,Exynos boot rom. And it is … it resides in\Nthe main CPU. And what happens normally is
Dialogue: 0,0:34:44.77,0:34:49.76,Default,,0000,0000,0000,,that the Exynos boot ROM starts and then\Nit loads something which I call the "first
Dialogue: 0,0:34:49.76,0:34:53.04,Default,,0000,0000,0000,,bootloader", which is prepended\Nto sboot, and it is
Dialogue: 0,0:34:53.04,0:35:00.11,Default,,0000,0000,0000,,signed and it just verifies the signature\Nof sboot and then jumps into it. So you
Dialogue: 0,0:35:00.11,0:35:06.33,Default,,0000,0000,0000,,can just think about it as, it's together\Nwith sboot. And then sboot loads the
Dialogue: 0,0:35:06.33,0:35:13.12,Default,,0000,0000,0000,,kernel. But the boot ROM has to load the\Nfirst bootloader and sboot from somewhere,
Dialogue: 0,0:35:13.12,0:35:18.91,Default,,0000,0000,0000,,so what does it try to do? So it first\Nstarts with the eMMC. But if this fails,
Dialogue: 0,0:35:18.91,0:35:26.24,Default,,0000,0000,0000,,it goes to the external SD-card. So I just\Ntook sboot and the first bootloader and
Dialogue: 0,0:35:26.24,0:35:31.55,Default,,0000,0000,0000,,dropped them onto an SD-card. But that\Ndidn't work because sboot boots into, in
Dialogue: 0,0:35:31.55,0:35:36.86,Default,,0000,0000,0000,,this case, sboot boots into SD-card mode,\Nin which there's is no USB protocol, so
Dialogue: 0,0:35:36.86,0:35:42.01,Default,,0000,0000,0000,,you can't exploit it. And, as I said, it\Nis signed, so I can't patch it. But
Dialogue: 0,0:35:42.01,0:35:49.79,Default,,0000,0000,0000,,apparently some people over a forum, their\Nnicknames are AdamOutler, Rebellos, and
Dialogue: 0,0:35:49.79,0:35:54.74,Default,,0000,0000,0000,,Ralekdev. They found out that there is a\Ndevelopment board, called ODROID-X, which
Dialogue: 0,0:35:54.74,0:35:59.14,Default,,0000,0000,0000,,uses exactly the same CPU, so it's the\Nsame boot ROM, which uses the same
Dialogue: 0,0:35:59.14,0:36:03.59,Default,,0000,0000,0000,,signature, but it uses a different first\Nbootloader, which doesn't do any signature
Dialogue: 0,0:36:03.59,0:36:10.25,Default,,0000,0000,0000,,checks at all. So if you take this first\Nbootloader and append to it a patched
Dialogue: 0,0:36:10.25,0:36:14.48,Default,,0000,0000,0000,,sboot, it will jump into this patched\Nsboot and then you can just exploit it and
Dialogue: 0,0:36:14.48,0:36:20.72,Default,,0000,0000,0000,,run your code. And this is the modified\Nboot process, so you start with Exynos
Dialogue: 0,0:36:20.72,0:36:26.95,Default,,0000,0000,0000,,boot ROM, you plug in an external SD-card,\Nthe externel SD-card has ODROID-X first
Dialogue: 0,0:36:26.95,0:36:33.13,Default,,0000,0000,0000,,bootloader, which is signed, so the boot\NROM will jump into it and then the first
Dialogue: 0,0:36:33.13,0:36:38.99,Default,,0000,0000,0000,,bootloader will jump to the patched sboot\Nand then you can exploit it and run you
Dialogue: 0,0:36:38.99,0:36:45.26,Default,,0000,0000,0000,,shell code. And no hardware mode is\Nrequired at all. So if the boot partition
Dialogue: 0,0:36:45.26,0:36:50.77,Default,,0000,0000,0000,,is still intact, the phone loads sboot and\Nit is stored in your eMMC. But if it is
Dialogue: 0,0:36:50.77,0:36:55.79,Default,,0000,0000,0000,,corrupt, the phone uses the external SD-\Ncard. And either way, I can load sboot.
Dialogue: 0,0:36:55.79,0:37:00.52,Default,,0000,0000,0000,,And then I can exploit a vulnerability to\Ngain code execution in sboot. And the next
Dialogue: 0,0:37:00.52,0:37:09.98,Default,,0000,0000,0000,,step is to access the eMMC boot ROM. And\Nas I said before, I need to trigger this
Dialogue: 0,0:37:09.98,0:37:18.52,Default,,0000,0000,0000,,interrupt #7 and send it … send this\Nargument somehow. So I just iterated over
Dialogue: 0,0:37:18.52,0:37:24.32,Default,,0000,0000,0000,,all the possible eMMC commands,\Nwhich is from 0 to 63, and I
Dialogue: 0,0:37:24.32,0:37:31.47,Default,,0000,0000,0000,,powered off the eMMC, powered it back on,\Nso the boot process gets started again.
Dialogue: 0,0:37:31.47,0:37:36.75,Default,,0000,0000,0000,,And then I quickly sent a command X with\Nthis argument and I waited for some time
Dialogue: 0,0:37:36.75,0:37:43.07,Default,,0000,0000,0000,,for the boot process to finish. And then I\Nsent any command which is supported by the
Dialogue: 0,0:37:43.07,0:37:48.01,Default,,0000,0000,0000,,boot ROM recovery mode and I checked if I\Ngot any response. And I said, ehhh, this
Dialogue: 0,0:37:48.01,0:37:54.22,Default,,0000,0000,0000,,is … maybe it's going to work, maybe not,\Nand then I tried command 0 and it failed,
Dialogue: 0,0:37:54.22,0:37:57.48,Default,,0000,0000,0000,,and I said, naah, it's never going to\Nwork, and then command 1 worked.
Dialogue: 0,0:37:57.48,0:38:02.30,Default,,0000,0000,0000,,{\i1}laughter{\i0} So this was very exciting for me\Nbecause this is the first time, the eMMC
Dialogue: 0,0:38:02.30,0:38:08.73,Default,,0000,0000,0000,,actually responds. And up until then, on\Nthe bricked device, I tried to send
Dialogue: 0,0:38:08.73,0:38:12.51,Default,,0000,0000,0000,,several commands to the eMMC and I never\Nsaw a response. And this is the first time
Dialogue: 0,0:38:12.51,0:38:18.06,Default,,0000,0000,0000,,I actually saw a response from the eMMC\Nand this was very exciting. And the eMMC
Dialogue: 0,0:38:18.06,0:38:22.82,Default,,0000,0000,0000,,even has command 62, you know, this\Nbackdoor mode, so let's fix it. Let's
Dialogue: 0,0:38:22.82,0:38:28.54,Default,,0000,0000,0000,,repair the eMMC. So, there are two\Nrevisions of this faulty chip. The first
Dialogue: 0,0:38:28.54,0:38:35.98,Default,,0000,0000,0000,,revision uses a firmware 0xF1, which is\Nbuggy, and then there were phones with
Dialogue: 0,0:38:35.98,0:38:42.12,Default,,0000,0000,0000,,firmware revision 0xF7 in which the bug\Nnever occurred. So probably Samsung fixed
Dialogue: 0,0:38:42.12,0:38:47.77,Default,,0000,0000,0000,,the bug in later hardware revisions. So my\Ngoal was to update the chip to firmware
Dialogue: 0,0:38:47.77,0:38:55.42,Default,,0000,0000,0000,,0xF7 and format the FTL metadata so\Nthe corruption is gone. OK, so … what I
Dialogue: 0,0:38:55.42,0:39:00.78,Default,,0000,0000,0000,,did was to write a dump tool, a firmware\Ndump tool, which is a kernel module. And
Dialogue: 0,0:39:00.78,0:39:06.73,Default,,0000,0000,0000,,then I had to convince anybody over … the\NInternet … to run my code which sends low-
Dialogue: 0,0:39:06.73,0:39:12.24,Default,,0000,0000,0000,,level eMMC commands to … on their own\Ndevice. {\i1}laughter{\i0} And thanks to @artesea,
Dialogue: 0,0:39:12.24,0:39:20.83,Default,,0000,0000,0000,,which was courage enough to try it, I got\Na dump of firmware 0xF7 and it worked. And
Dialogue: 0,0:39:20.83,0:39:27.48,Default,,0000,0000,0000,,now I just had to write it to the eMMC\Nitself. So this is absolutely doable
Dialogue: 0,0:39:27.48,0:39:33.95,Default,,0000,0000,0000,,because I could've used the memory write\Nbackdoor to write my own code and access
Dialogue: 0,0:39:33.95,0:39:39.24,Default,,0000,0000,0000,,the NAND flash chip and write a new\Nfirmware. But then I found out something
Dialogue: 0,0:39:39.24,0:39:44.33,Default,,0000,0000,0000,,simpler. So there's another backdoor,\Nwhich is command 60, and it has two
Dialogue: 0,0:39:44.33,0:39:48.99,Default,,0000,0000,0000,,firmware upgrade modes for some\Nreason. So the former mode,
Dialogue: 0,0:39:48.99,0:39:56.95,Default,,0000,0000,0000,,which is 0xCBAD1160, supports FTL\Nmetadata format. You can send an erase
Dialogue: 0,0:39:56.95,0:40:02.67,Default,,0000,0000,0000,,command and it will format all the FTL\Nmetadata. And then you can write a new
Dialogue: 0,0:40:02.67,0:40:12.07,Default,,0000,0000,0000,,firmware and it will do everything for\Nyou. So how do I fix a dead S3? I just get
Dialogue: 0,0:40:12.07,0:40:18.27,Default,,0000,0000,0000,,a dead S3, which should be … this is\Nimportant to note … the … many … there's
Dialogue: 0,0:40:18.27,0:40:24.42,Default,,0000,0000,0000,,different revisions of Galaxy S3. I'm\Ntalking about GT-I9300, which is the
Dialogue: 0,0:40:24.42,0:40:30.71,Default,,0000,0000,0000,,international version. Boot to sboot,\Neither directly, if the boot partition is
Dialogue: 0,0:40:30.71,0:40:36.23,Default,,0000,0000,0000,,still intact, or by using an external SD-\Ncard. Then exploit sboot to run your own
Dialogue: 0,0:40:36.23,0:40:43.72,Default,,0000,0000,0000,,code. From the shell code, reboot the eMMC\Ninto boot ROM recovery mode and then use
Dialogue: 0,0:40:43.72,0:40:48.82,Default,,0000,0000,0000,,command 60 to format the FTL metadata and\Nflash the new firmware, 0xF7 firmware.
Dialogue: 0,0:40:48.82,0:40:53.29,Default,,0000,0000,0000,,Then reboot the eMMC so the firmware\Nloading … actually boots and then you can
Dialogue: 0,0:40:53.29,0:40:58.39,Default,,0000,0000,0000,,write sboot to the eMMC's boot partition.\NAnd there is another step, which is … to
Dialogue: 0,0:40:58.39,0:41:06.76,Default,,0000,0000,0000,,profit. And this means, it is demo time!\NSo, I pray to the demo gods that it is
Dialogue: 0,0:41:06.76,0:41:17.03,Default,,0000,0000,0000,,going to happen, it is going to succeed.\NSo, yeah … This … OK, so I have a bricked
Dialogue: 0,0:41:17.03,0:41:22.13,Default,,0000,0000,0000,,device, I bricked it on purpose. This is\Nthe device. If I try to turn it on---
Dialogue: 0,0:41:22.13,0:41:29.47,Default,,0000,0000,0000,,there's a battery inside---nothing\Nhappens. It is bricked. If I try to get
Dialogue: 0,0:41:29.47,0:41:43.36,Default,,0000,0000,0000,,into download mode, nothing works. I have\Nthis external SD card which does have
Dialogue: 0,0:41:43.36,0:41:53.32,Default,,0000,0000,0000,,sboot as I said before. And if I plug it\Nin, and I try to boot the device, it
Dialogue: 0,0:41:53.32,0:42:10.89,Default,,0000,0000,0000,,should boot into … Yeah, okay. So, it\Nboots into something and now I can use …
Dialogue: 0,0:42:10.89,0:42:22.34,Default,,0000,0000,0000,,Just go back to the … yeah. And now I can\Nplug it into the USB and sboot answers,
Dialogue: 0,0:42:22.34,0:42:30.87,Default,,0000,0000,0000,,and now I am going to run a shell code,\Nwhich fixes the eMMC. It’s retrying, it is
Dialogue: 0,0:42:30.87,0:42:35.70,Default,,0000,0000,0000,,okay. Shell code started. It rebooted the\NeMMC into bootrom mode, and now it will
Dialogue: 0,0:42:35.70,0:42:43.08,Default,,0000,0000,0000,,write the new firmware. And it should take\Na couple of seconds, so … hold tight, as
Dialogue: 0,0:42:43.08,0:42:53.63,Default,,0000,0000,0000,,it said… Okay, yeah, so the next thing is\Ngoing to be to reboot into the firmware
Dialogue: 0,0:42:53.63,0:43:02.61,Default,,0000,0000,0000,,and then change the boot partition size so\Nthat there's actually a boot partition.
Dialogue: 0,0:43:02.61,0:43:10.77,Default,,0000,0000,0000,,Yeah, and now the shell command is done\Nand I can just use a different SD card
Dialogue: 0,0:43:10.77,0:43:16.21,Default,,0000,0000,0000,,which loads sboot normally and it goes\Ninto SD card mode and in this SD card
Dialogue: 0,0:43:16.21,0:43:31.23,Default,,0000,0000,0000,,mode, it will write sboot to the boot\Npartition, so … Let me just … Yeah, okay.
Dialogue: 0,0:43:31.23,0:43:36.99,Default,,0000,0000,0000,,So this is SD card mode. I think you can't\Nsee, but if I now remove this SD card,
Dialogue: 0,0:43:36.99,0:43:47.39,Default,,0000,0000,0000,,right? And just reboot the device, so …\Nthe battery is outside and now it's … yeah
Dialogue: 0,0:43:47.39,0:43:52.56,Default,,0000,0000,0000,,… It should boot into … yeah! So, this is\Nsboot! So the device is fixed.
Dialogue: 0,0:43:52.56,0:44:06.90,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:44:06.90,0:44:16.97,Default,,0000,0000,0000,,Thank you! So, conclusion. A few\Nshoutouts, so … Rebellos, AdamOutler, and
Dialogue: 0,0:44:16.97,0:44:24.89,Default,,0000,0000,0000,,Ralekdev did all the Exynos U-Boot, first\Nbootloader, ODROID-X work, so … Thanks to
Dialogue: 0,0:44:24.89,0:44:31.61,Default,,0000,0000,0000,,them! I couldn't … if it weren't for them,\NI couldn't boot bricked devices.
Dialogue: 0,0:44:31.61,0:44:39.19,Default,,0000,0000,0000,,Entropy512 was involved in the eMMC\Nresearch back in 2013 and bunnyxobs held a
Dialogue: 0,0:44:39.19,0:44:47.16,Default,,0000,0000,0000,,wonderful talk here at CCC some years ago.\NAnd he talked about hacking Chinese SD
Dialogue: 0,0:44:47.16,0:44:51.02,Default,,0000,0000,0000,,cards and they mentioned my research, and\Nthis motivated me to complete it because it
Dialogue: 0,0:44:51.02,0:44:59.66,Default,,0000,0000,0000,,was still in progress. This is the reason\Nfor which I'm talking today, so … thanks!
Dialogue: 0,0:44:59.66,0:45:06.01,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:45:06.01,0:45:12.74,Default,,0000,0000,0000,,So, I can basically own Samsung\NeMMCs, I can fix bricked S3 with just
Dialogue: 0,0:45:12.74,0:45:18.03,Default,,0000,0000,0000,,software, and, imagine, this is just a\Nuse-case, because now you can do
Dialogue: 0,0:45:18.03,0:45:25.94,Default,,0000,0000,0000,,interesting stuff with your eMMC chip. And\Nwhat I think we should do next is to look
Dialogue: 0,0:45:25.94,0:45:32.04,Default,,0000,0000,0000,,at newer eMMCs which I suspect still has\Nthis backdoor, because I tried some chip
Dialogue: 0,0:45:32.04,0:45:39.68,Default,,0000,0000,0000,,which I could get my hands on and it had\Nthis backdoor, so … Maybe even the new
Dialogue: 0,0:45:39.68,0:45:47.45,Default,,0000,0000,0000,,ones also has this mode. And then there's\NUFS, which is the bus which replaces eMMC
Dialogue: 0,0:45:47.45,0:45:55.97,Default,,0000,0000,0000,,and it is based on SCASI and Samsung also\Nproduces UFS chips so it might be wanting
Dialogue: 0,0:45:55.97,0:46:03.46,Default,,0000,0000,0000,,to see if there's a similar backdoor. And\Nit's also interesting to look at different
Dialogue: 0,0:46:03.46,0:46:08.84,Default,,0000,0000,0000,,vendors of eMMCs and maybe one day write\Nan open-source alternative firmware for
Dialogue: 0,0:46:08.84,0:46:15.41,Default,,0000,0000,0000,,these devices. So this is question time.\NYou can find the code that I wrote to
Dialogue: 0,0:46:15.41,0:46:19.27,Default,,0000,0000,0000,,experiment with these devices over the\Nfollowing links, and you can find the
Dialogue: 0,0:46:19.27,0:46:25.76,Default,,0000,0000,0000,,slides in the bottom link. It's already\Npublic, so go ahead. And if you have any
Dialogue: 0,0:46:25.76,0:46:28.82,Default,,0000,0000,0000,,questions, this is the time, so … thanks!
Dialogue: 0,0:46:28.82,0:46:38.51,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:46:38.51,0:46:40.15,Default,,0000,0000,0000,,Herald: So thank you very much, Oran, for
Dialogue: 0,0:46:40.15,0:46:43.00,Default,,0000,0000,0000,,a really interesting talk. If you have\Nquestions, there are two microphones in
Dialogue: 0,0:46:43.00,0:46:48.58,Default,,0000,0000,0000,,this aisle, and then two on the sides, and\Nfirst question from microphone #2.
Dialogue: 0,0:46:48.58,0:46:49.69,Default,,0000,0000,0000,,Microphone #2: It's pretty amazing what
Dialogue: 0,0:46:49.69,0:46:54.97,Default,,0000,0000,0000,,you did. Did you guys get any feedback\Nfrom Samsung on this?
Dialogue: 0,0:46:54.97,0:46:58.29,Default,,0000,0000,0000,,Oran: Yeah, so … I published my research
Dialogue: 0,0:46:58.29,0:47:08.10,Default,,0000,0000,0000,,back in 2012 … 2013, sorry, over forums\Nand I didn't use it from a security
Dialogue: 0,0:47:08.10,0:47:17.47,Default,,0000,0000,0000,,perspective. I wanted to fix S3. They\Nnever responded or … they didn't contact
Dialogue: 0,0:47:17.47,0:47:24.95,Default,,0000,0000,0000,,me in any way. I didn't contact them about\Nthe boot ROM recovery mode, because in my
Dialogue: 0,0:47:24.95,0:47:34.17,Default,,0000,0000,0000,,opinion it is not a security issue. And it\Ncan be fixed. And regarding the sboot
Dialogue: 0,0:47:34.17,0:47:40.08,Default,,0000,0000,0000,,vulnerabilities, there is no … it's\Nalready patched, so … No, the answer is:
Dialogue: 0,0:47:40.08,0:47:41.52,Default,,0000,0000,0000,,No.
Dialogue: 0,0:47:41.52,0:47:44.48,Default,,0000,0000,0000,,Microphone #2: So, the way I understand\Nit, this is the only way to fix some of
Dialogue: 0,0:47:44.48,0:47:46.49,Default,,0000,0000,0000,,the phones that are broken\Nout there, right?
Dialogue: 0,0:47:46.49,0:47:49.05,Default,,0000,0000,0000,,Oran: Yeah, I don't know any other way to
Dialogue: 0,0:47:49.05,0:47:50.26,Default,,0000,0000,0000,,do it.
Dialogue: 0,0:47:50.26,0:47:51.55,Default,,0000,0000,0000,,M#2: OK, thanks.
Dialogue: 0,0:47:51.55,0:47:53.57,Default,,0000,0000,0000,,Herald: Microphone #1.
Dialogue: 0,0:47:53.57,0:47:57.99,Default,,0000,0000,0000,,Microphone #1: After seeing a real-life\NFTL, do you still use SSDs?
Dialogue: 0,0:47:57.99,0:47:59.07,Default,,0000,0000,0000,,Oran: Sorry?
Dialogue: 0,0:47:59.07,0:48:00.76,Default,,0000,0000,0000,,Microphone #1: After seeing a real-life
Dialogue: 0,0:48:00.76,0:48:05.10,Default,,0000,0000,0000,,FTL, do you still use SSDs or\Nother flash devices?
Dialogue: 0,0:48:05.10,0:48:09.18,Default,,0000,0000,0000,,Oran: Yeah, this is a good question … it's
Dialogue: 0,0:48:09.18,0:48:17.71,Default,,0000,0000,0000,,okay. And I don't … there's no\Nalternative, right? So … but we might
Dialogue: 0,0:48:17.71,0:48:22.44,Default,,0000,0000,0000,,make something, so …
Dialogue: 0,0:48:22.44,0:48:25.15,Default,,0000,0000,0000,,Herald: Mic number three.
Dialogue: 0,0:48:25.15,0:48:31.25,Default,,0000,0000,0000,,Microphone #3: Do you have any idea what\Nother devices have this model eMMC and
Dialogue: 0,0:48:31.25,0:48:37.58,Default,,0000,0000,0000,,support the same commands that let you\Naccess the firmware? ’cause there is other
Dialogue: 0,0:48:37.58,0:48:40.50,Default,,0000,0000,0000,,devices that had bad eMMC.
Dialogue: 0,0:48:40.50,0:48:47.76,Default,,0000,0000,0000,,Oran: Ah, okay, so … Samsu… Galaxy S2 had\Na similar bug and Kindle Fire, I think,
Dialogue: 0,0:48:47.76,0:48:53.44,Default,,0000,0000,0000,,one of their versions. And some of them\Ngot patches by Samsung and it's usually
Dialogue: 0,0:48:53.44,0:48:58.45,Default,,0000,0000,0000,,was something like this, like: Patch the\Ninternal memory everytime the device boots
Dialogue: 0,0:48:58.45,0:49:06.88,Default,,0000,0000,0000,,so the bug never happens. I think, in the\Nother devices, the bug was actually fixed.
Dialogue: 0,0:49:06.88,0:49:08.50,Default,,0000,0000,0000,,Microphone #3: But are you aware of any
Dialogue: 0,0:49:08.50,0:49:15.93,Default,,0000,0000,0000,,non-Samsung devices that have Samsung MMCs\Nin them that might be the same MMC?
Dialogue: 0,0:49:15.93,0:49:16.73,Default,,0000,0000,0000,,Oran: I'm sorry?
Dialogue: 0,0:49:16.73,0:49:17.84,Default,,0000,0000,0000,,Microphone #3: Are there other devices
Dialogue: 0,0:49:17.84,0:49:21.27,Default,,0000,0000,0000,,that aren't Samsung phones but still have\NSamsung parts in them?
Dialogue: 0,0:49:21.27,0:49:23.30,Default,,0000,0000,0000,,Oran: Yeah, ah! So, there's not a lot of
Dialogue: 0,0:49:23.30,0:49:27.74,Default,,0000,0000,0000,,eMMC manufacturers and Samsung is a big\Nmanufacturer, so … A lot of different
Dialogue: 0,0:49:27.74,0:49:35.75,Default,,0000,0000,0000,,phones and devices use Samsung eMMCs, so …\Nyes. It is relevant to non-Samsung devices.
Dialogue: 0,0:49:35.75,0:49:37.32,Default,,0000,0000,0000,,Herald: Number one.
Dialogue: 0,0:49:37.32,0:49:42.11,Default,,0000,0000,0000,,Microphone #1: Hey, thanks for your\Namazing talk and research. Two questions:
Dialogue: 0,0:49:42.11,0:49:48.54,Default,,0000,0000,0000,,There's the Samsung Galaxy Note 2 that has\Nmore or less the same bug, does your fix
Dialogue: 0,0:49:48.54,0:49:54.54,Default,,0000,0000,0000,,and your research also apply to that\Ndevice? And is there a way to a chip-off
Dialogue: 0,0:49:54.54,0:49:59.91,Default,,0000,0000,0000,,dump without erasing the FTL\Nand contents of the card?
Dialogue: 0,0:49:59.91,0:50:01.99,Default,,0000,0000,0000,,Oran: Yeah, so, this is a good question.
Dialogue: 0,0:50:01.99,0:50:07.09,Default,,0000,0000,0000,,The first question was … the S2\Nhas the same bug, right?
Dialogue: 0,0:50:07.09,0:50:08.31,Default,,0000,0000,0000,,Microphone #1: The Note 2! The …
Dialogue: 0,0:50:08.31,0:50:09.47,Default,,0000,0000,0000,,Oran: Ah! The Note 2! Ah, okay. I don't
Dialogue: 0,0:50:09.47,0:50:13.26,Default,,0000,0000,0000,,know. I never had a Note 2, so.
Dialogue: 0,0:50:13.26,0:50:16.73,Default,,0000,0000,0000,,Microphone #1: I have one\Nthat is bricked that way.
Dialogue: 0,0:50:16.73,0:50:18.63,Default,,0000,0000,0000,,Oran: But would be interesting to try.
Dialogue: 0,0:50:18.63,0:50:23.88,Default,,0000,0000,0000,,True! So, that's that. And regarding the\Nsecond question: My code actually formats
Dialogue: 0,0:50:23.88,0:50:29.71,Default,,0000,0000,0000,,all the FTL metadata which is not that\Ngood because it erases all this
Dialogue: 0,0:50:29.71,0:50:38.19,Default,,0000,0000,0000,,information about how many times every\Nblock was erased. A more proper fix would
Dialogue: 0,0:50:38.19,0:50:43.46,Default,,0000,0000,0000,,be to actually fix the corrupted metadata\Nbut I haven't got to the point in which I
Dialogue: 0,0:50:43.46,0:50:50.50,Default,,0000,0000,0000,,can fully understand the inner workings of\Nthe FTL. So, this is my current code but
Dialogue: 0,0:50:50.50,0:50:54.46,Default,,0000,0000,0000,,you are welcome to try to improve it.
Dialogue: 0,0:50:54.46,0:50:55.79,Default,,0000,0000,0000,,Microphone #1: Wonderful.
Dialogue: 0,0:50:55.79,0:50:57.68,Default,,0000,0000,0000,,Herald: Microphone number two.
Dialogue: 0,0:50:57.68,0:51:01.68,Default,,0000,0000,0000,,Microphone #2: I'd like to know what the\Ntimeframe was from you working on the
Dialogue: 0,0:51:01.68,0:51:04.59,Default,,0000,0000,0000,,issue 'til you had the first fixed S3.
Dialogue: 0,0:51:04.59,0:51:12.64,Default,,0000,0000,0000,,Oran: Yeah, so, I obtained the firmware\Nback in 2013 and I had a working device
Dialogue: 0,0:51:12.64,0:51:24.04,Default,,0000,0000,0000,,and I didn't want to do … like … bad stuff\Nto it. So I stopped back in this year, and
Dialogue: 0,0:51:24.04,0:51:30.23,Default,,0000,0000,0000,,then last year, a friend of mine said that\Nhe had a bricked S3 so I said, let's try
Dialogue: 0,0:51:30.23,0:51:36.77,Default,,0000,0000,0000,,to fix it. So I think if you, like,\Naccumulate the time, it's probably going
Dialogue: 0,0:51:36.77,0:51:43.66,Default,,0000,0000,0000,,to be, like, a timeframe which I worked,\Nactively worked on this, was something
Dialogue: 0,0:51:43.66,0:51:49.97,Default,,0000,0000,0000,,like a few months. Probably four or five\Nmonths. But it started back in … four
Dialogue: 0,0:51:49.97,0:51:57.01,Default,,0000,0000,0000,,years ago, and I finished it something\Nlike a couple of months ago
Dialogue: 0,0:51:57.01,0:51:58.08,Default,,0000,0000,0000,,Microphone #2: Cool. Thanks!
Dialogue: 0,0:51:58.08,0:51:58.60,Default,,0000,0000,0000,,Herald: Number One.
Dialogue: 0,0:51:58.60,0:52:01.77,Default,,0000,0000,0000,,Microphone #1: Do … Do Samsung SD cards
Dialogue: 0,0:52:01.77,0:52:04.51,Default,,0000,0000,0000,,have the same undocumented commands?
Dialogue: 0,0:52:04.51,0:52:09.30,Default,,0000,0000,0000,,Oran: Yeah, I suspect, they do. Some of\Nthem. I actually bought some Samsung SD
Dialogue: 0,0:52:09.30,0:52:15.69,Default,,0000,0000,0000,,cards and they had controllers made by\NSilicon Motion but I read over the
Dialogue: 0,0:52:15.69,0:52:25.13,Default,,0000,0000,0000,,Internet that some specific cards, I think\Nit's Evo+ Plus have Samsung controllers
Dialogue: 0,0:52:25.13,0:52:35.44,Default,,0000,0000,0000,,which should have the same backdoor, so,\NI'm trying to buy one but as soon as I
Dialogue: 0,0:52:35.44,0:52:38.70,Default,,0000,0000,0000,,find out, I will probably post about it.
Dialogue: 0,0:52:38.70,0:52:39.34,Default,,0000,0000,0000,,Microphone #1: Thank you.
Dialogue: 0,0:52:39.34,0:52:41.94,Default,,0000,0000,0000,,Herald: Number three.
Dialogue: 0,0:52:41.94,0:52:47.67,Default,,0000,0000,0000,,Microphone #3: OK, thanks for the great\Ntalk. So, I'm using an S3 as my everyday
Dialogue: 0,0:52:47.67,0:52:56.45,Default,,0000,0000,0000,,phone, so what actually happened a few\Nmonths ago, it broke down but … so I still
Dialogue: 0,0:52:56.45,0:53:03.50,Default,,0000,0000,0000,,saw the Samsung bootloader, the sboot,\Nwhat it is called, and afterwards it got
Dialogue: 0,0:53:03.50,0:53:10.07,Default,,0000,0000,0000,,stuck at the bootscreen from the OS, so in\Nmy case it was Cyanogenmod, but also, when
Dialogue: 0,0:53:10.07,0:53:14.06,Default,,0000,0000,0000,,I flashed on something else, like\NLineageOS, or the default Samsung's
Dialogue: 0,0:53:14.06,0:53:19.18,Default,,0000,0000,0000,,firmware, it still got stuck. I really had\Nto re-flash everything and then it worked
Dialogue: 0,0:53:19.18,0:53:25.06,Default,,0000,0000,0000,,again. That somehow sounds really similar\Nto the bug you described, but in a way it
Dialogue: 0,0:53:25.06,0:53:30.14,Default,,0000,0000,0000,,also doesn't. Do you think\Nit's the same thing?
Dialogue: 0,0:53:30.14,0:53:33.50,Default,,0000,0000,0000,,Oran: So, if it's related, my guess would
Dialogue: 0,0:53:33.50,0:53:41.48,Default,,0000,0000,0000,,be that your device have this in-memory\Npatch which freezes the eMMC and when you
Dialogue: 0,0:53:41.48,0:53:49.70,Default,,0000,0000,0000,,used LineageOS or what it was before, this\Ninfinite loop triggered at some point in
Dialogue: 0,0:53:49.70,0:53:55.13,Default,,0000,0000,0000,,the boot process so the device actually\Nfroze before it got to boot Android. But
Dialogue: 0,0:53:55.13,0:53:59.84,Default,,0000,0000,0000,,then, when you flashed it, somehow, the\Ninternal block mapping got changed and now
Dialogue: 0,0:53:59.84,0:54:08.50,Default,,0000,0000,0000,,it doesn't trigger this freezing. But if\Nyour chip is VTU00M and its firmware is
Dialogue: 0,0:54:08.50,0:54:11.47,Default,,0000,0000,0000,,0xF1, then you definitely have the bug.
Dialogue: 0,0:54:11.47,0:54:14.14,Default,,0000,0000,0000,,Microphone #3: OK, thanks.
Dialogue: 0,0:54:14.14,0:54:15.79,Default,,0000,0000,0000,,Herald: Number One.
Dialogue: 0,0:54:15.79,0:54:19.47,Default,,0000,0000,0000,,Microphone #1: Hi! Thanks for the great\Nwork. One question: You said, you upgraded
Dialogue: 0,0:54:19.47,0:54:24.49,Default,,0000,0000,0000,,the firmware of the eMMC with a newer\Nrevision. Are these firmwares actually
Dialogue: 0,0:54:24.49,0:54:28.62,Default,,0000,0000,0000,,signed or can you flash anything\Non the eMMC controller?
Dialogue: 0,0:54:28.62,0:54:31.70,Default,,0000,0000,0000,,Oran: You can flash anything … yeah. They
Dialogue: 0,0:54:31.70,0:54:39.24,Default,,0000,0000,0000,,have a simple heuristic which checks if\Nthe stack address is … looks normal, but
Dialogue: 0,0:54:39.24,0:54:44.74,Default,,0000,0000,0000,,other than that, it boots every firmware\Nyou give it. I think, in your eMMCs, which
Dialogue: 0,0:54:44.74,0:54:52.60,Default,,0000,0000,0000,,is eMMC 5.1, there's a mechanism of\Nflashing new firmwares and I think it
Dialogue: 0,0:54:52.60,0:54:59.78,Default,,0000,0000,0000,,should be signed but I don't have a newer\NeMMC, so … I don't know about it, but
Dialogue: 0,0:54:59.78,0:55:00.69,Default,,0000,0000,0000,,yeah.
Dialogue: 0,0:55:00.69,0:55:02.30,Default,,0000,0000,0000,,Microphone #1: Thank you.
Dialogue: 0,0:55:02.30,0:55:06.93,Default,,0000,0000,0000,,Herald: So … I have one last question,\Nabout the Samsung patch. You said that it
Dialogue: 0,0:55:06.93,0:55:11.96,Default,,0000,0000,0000,,basically goes into some sort of infinite\Nloop. But do you think they tried to some
Dialogue: 0,0:55:11.96,0:55:14.22,Default,,0000,0000,0000,,busy wait or they're waiting\Nfor something to happen?
Dialogue: 0,0:55:14.22,0:55:18.52,Default,,0000,0000,0000,,Oran: No, I think they just want … they
Dialogue: 0,0:55:18.52,0:55:26.20,Default,,0000,0000,0000,,want the bug to never happen, so … Yeah, I\N… my phone froze a lot of times and I
Dialogue: 0,0:55:26.20,0:55:30.19,Default,,0000,0000,0000,,waited like, I don't know, 30 minutes. And\Nthe code in the Linux kernel doesn't do
Dialogue: 0,0:55:30.19,0:55:34.74,Default,,0000,0000,0000,,anything, and the code in the eMMC\Nfirmware doesn't do anything, so my guess:
Dialogue: 0,0:55:34.74,0:55:37.80,Default,,0000,0000,0000,,It just waits forever.
Dialogue: 0,0:55:37.80,0:55:40.83,Default,,0000,0000,0000,,Herald: I see no more questions, so again,\Na big round of applause to Oran for great
Dialogue: 0,0:55:40.83,0:55:42.14,Default,,0000,0000,0000,,work.
Dialogue: 0,0:55:42.14,0:55:46.50,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:55:46.50,0:55:51.31,Default,,0000,0000,0000,,{\i1}34c3 outro{\i0}
Dialogue: 0,0:55:51.31,0:56:08.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2018. Join, and help us!