 Right, so once again. Good morning our next talk our next speaker today this morning is an independent security researcher He founded the past and CTF group, which some of you might know her I've heard of and he has previously worked on open I boot please give a big round of applause to oan of Raham Thank you Can you hear me? Okay? So I'm going to talk about how I hacked emmc chips Or how he fixed that galaxy s3 devices First an introduction about myself. Where am I? I am one of Raham 25 years old security researcher based in Israel Mike I'm currently walking at a startup called the medigate. However, this talk has no connection to my employer whatsoever I previously worked on open I boot which it was an open source alternative bootloader for apple iOS devices We aimed to boot linux on iPhone 3g 3gs and iPhone 4 We had some success. I also found vulnerabilities in The early iPhone Basebands which were used to unlock Seem free these devices and I'm also a CTF player with the past and team We're playing tonight. So good luck to us This is my contact info if you if you want to reach me You can find it on my website and then there's also my Twitter username Okay, so an outline about this talk I'm going to start with an introduction about the story how I got to hack emmc devices Then we'll talk about Samsung's emmc patch which they used for galaxy s3 devices and Then I will talk about how I obtained such firmware and the few more of these emmc chips and Analyzed it We'll cover the bug itself that was in Samsung galaxy s3 devices And then I'm going to talk about how do we resurrect the devices like bricked devices? So let's start with the introduction This phenomenon was called a sudden death syndrome This is what the name that they gave it over forums and it started in 2012 Samsung galaxy s3 devices Just started dying with no apparent reason you you could use your phone and then one day It will get stuck and if you try to reboot it it won't boot anymore The phone is basically a brick And if you're lucky the phone will boot into the boot loader So you will see a loading screen, but it won't boot Linux or Android and If you're not lucky, then it's just a brick. You can't you can't use it You can turn it on if you plug in a USB cable. You'll see nothing You can't even charge the battery because the actual charging Mechanism isn't powered on so yeah And there were a lot of friends in forums So this is an example somebody said this is happening to a lot of people I hope Samsung do something about this and Actually, they they did But it wasn't like a proper fix and we'll talk about it later So let's talk about how do you diagnose such devices? So this is a walk in s3. You can see the beautiful background and Everything is powered on and this is a dead one Yeah, the screen is just black. You can't do anything Actually, as I said before if you're lucky, you'll see this screen which is Drawn by the boot loader, which is called Samsung gas boot And it won't but you this is the last screen you'll see and if you press a specific combination of keys, you'll get this screen, which is called download mode and we'll talk about it later So this is my Understanding this is my current understanding on how s3 walks So this is a rough schematic. It's there's a lot of different peripherals that aren't there but We obviously There's the main CPU which is called Samsung Exynos. It's an ARM based CPU and then you have the EMMC chip, which is a storage device It's the standard storage device for phones And there's some NAND flash inside of it. So it's a it's one package and If you if you inspect the silicone, you'll see an NAND flash chip Okay, so Then Samsung dropped the patch and what happened is that they said to their press that they just fixed this this bug and Since the Linux is a gpr licensed. They had to publish the source code So the patch was called soft patch moving on the VTU double zero M EMMC failure and it's it's they they modified the file responsible the code responsible for Communicating with EMMC devices. So in order to understand this patch, we have to talk about what is EMMC and So what is the EMMC basically? So it's it's that de facto some standard storage for phones actually nowadays high-end phones are starting to use UFS, which is the bus that replaces EMMC but the majority of phones still use EMMC and it's If you can think about it as SD card in BGA form So it's it's a package that you can solder onto a PCB and it's basically an SD card It's it uses the exactly the same bus And as you can see some company called hard canal made and a PCB which have an EMMC chip soldered onto it and you can they made also an adapter Which you can plug and there's no logic to this adapter. It just turns the EMMC into an SD card device And it works so EMMC is essentially an end flash chip with convenient bus, which is the same bus as SD cards So for this reason some people also call this an internal SD card or something like that and if I'm going to say card Later in my talk I'm going to talk about the EMMC chip So When you when you communicate with the EMMC bus There you you send commands to the to the code And there are 64 commands and they are denoted from command zero up to 63 And for example, you have a command 17 which is read single block and command 24 Which is right blocks and each command takes a single 32-bit argument So you'd send a command it has a number and an argument and all the commands are categorized into classes And there's one specific interesting class which is class 8 because if you look at the specification you'll see that Command 60 up to 63 are reserved for the manufacturer. So If something interesting is going to happen, it will probably happen with these commands So let's go back to the patch. So Samsung said they fixed the bug, right? So S3 devices shouldn't get bricked anymore and Let's so this patch actually The first thing does it it's come it compares the cards name to VTU double zero M Which is the hardware revision of the faulty chip and then they compare a number to the value F1 And this is actually the firmware version of the of this chip And then they call a function which is called MMC start movie smart Which isn't that interesting so I'm not going to talk about and if all these comparisons are true Then it will call MMC start movie operation, which is the main logic responsible for fixing the chip and the thing to know to note about this patch is that It this code runs every time you put the device so every time the emmc chip is powered on this code runs Okay, so let's talk about MMC start movie operation. So this is I edited the code for brevity It's not the the exact same patch, but this is basically the logic that they use And this is very interesting. There's one strange thing about this function there's MMC movie erase command and erase is Is an MMC command which? takes two arguments It uses two arguments because you proceed it with a different command so you can give it Two arguments and the first argument is the start block number to erase and the second argument is the end block number to Erase and it erases all the blocks in between So what should happen is that the first? Call to this function should erase all the blocks starting with forty three hundred up to block number 403 b5 10 right this doesn't make any sense and then the the next call is That they had like the the range is overlapped and this was very strange So my guess was that this is probably not an erase command It is probably something else somehow and the next thing to to note about this function is that you see The first two calls are MMC movie CMD and the last two calls are also to the function MMC movie CMD and MMC movie CMD is basically command 62 which is a class 8 command so it's reserved for to the manufacturer and my guess was that The first two calls Basically enter some secret backdoor mode that some some song hid inside the MFC chip and the last two calls leave this mode So when you're in this mode erase command doesn't do erase anymore. It does something else And then I saw that if you inspect the first argument you'll see that the numbers are consecutive on the increment by four except for the last number, but All the all the first the first five numbers are consecutive and The next thing so it looks something like memory addresses, right? And If you if you look at the second argument, I Noticed something very interesting If I assumed this is memory data Then if you look at it like as as little and the numbers you'll see 10 be 5 so it starts with 10 be 5 and I used to code a lot of arm assembly and 10 be 5 is push in thumb and thumb is an instruction set from the arm specification and Functions in thumb start with push, right? So this is an emcee next to a thumb and Basically, this is my current understanding of our emcee works So you have this all emcee chip, but there's not only an nand flash inside of it There's also a microcontroller and in Samsung's case. This is an ARM based microcontroller which contains some firmware so I thought this patch might Modify the internal memory of this chip some somehow So what they wanted to do is to examine what what this patch does so I just took all these data that it writes and Put it into a binary file, which I called patch dot bin and this is I just used Ida to To see what what is going on there and this is Samsung's patch So at the bottom you can see the actual thumb instructions But if you're not familiar with thumb, you can see also a C like pseudo code and What they do is basically they call a function and if it returns zero the chip will go in into an infinite loop And this is interesting because later on I understood that What was there before this patch? It just it was just a call to this function and there wasn't this check so they took a single call to a function and turned it into a Call to the same function, but if it returned zero Just they just go into an infinite loop. So my thought was This can't fix anything, right? Because the chip is either going to do the same thing as before or it's going to go into an infinite loop and then I Read some threads of our forms and I saw this thread ultimate galaxy S3 unusual freezing thread And this is a quote from the actual thread You can see that galaxy S3 is freezing with lockup screen not responding ending up with an usual rebooting and boot looping and Angry S3 users reporting this problem and it keeps freezing every five minutes or 50 plus freezes a day This is insane, right? This phone is not usable. I can't use it as my phone if it's a if it's freezes every five minutes and I had an S3 back then and I know I started observing freezes in my phone as well So the next step that I wanted to do is to obtain the emm emmc fumer in order to understand how it works So how do you get a fumer? The first way to do it is to write so I can I can write the emmc's memory Right, so I can just write code to random locations and hopefully it will get run some somehow and then just write things to different addresses and Do lucky guesses and maybe I will see something on the emmc bus and then try to to obtain the fumer But this is like a shot in the dark So the next thing I thought about doing is to fast different comments like use a command 60 61 different class 8 commands But they didn't want to destroy my own emmc Which was still working So the the last thing I thought about doing is to look for clues So how do you look for clues? I just googled these these numbers that Samsung used to enter this backdoor mode And I saw a different patch So this is a patch from a different device and it's called a patch the fumer of certain Samsung emmc parts to fix a bug And it uses the same the same mode as before So notice that they they use arguments effac 62 ec and then it's 10 21 and four zeros and this is Important so they use 10 21 four zeros right and then they write The value ff to the address for the d9c But then there was something else afterwards So if you continue to read this patch, you'll see this thing this this is a snippet Which isn't closed by if death, which is called test emmc fumer patching and they use the same if a 62 ec as before but now they use the the argument 10 21 002 and The next thing is that they they use an erase command with the same address as before but then they they do a read command, right and I Was wondering hmm This might be Samsung's way of reading the memory address of the memory of the emmc chip Because they use an erase command with the same address as before The second argument is for which looks like an like a size and then they read a D word from from the emmc So I took this snippet of code and modified into modified it into this snippet of code Which is basically just loops over all the addresses in the address space. I I just guessed How big the address space is and I just read the view a single D word every time and dumped it into a file And I think I got this thing Which looks like a fumer, right? so the names aren't the names that you see like our NMI and hard fault These are my names what what I saw was addresses, but this looks like a thumb vector table so I understood that I basically got the fumer of my own chip So the next step was to reverse the fumer in order to analyze what the bug is So luckily for me the fumer contains strings so I can use them as part of my reversing process But actually it contained a string A single string and it was this string Which isn't very useful if you're trying to reverse a fumer And as you can see this is a snippet of my reversing process I used a lot of like names flip bit in somewhere and Memory map tile thousand 2d words or but I basically understood the the high-level logic of this code and I got to the point which I can in which I can understand most of the fumer So let's talk about debug Before we talk about the bug we have to talk about how what is what is emmc exactly? So let's talk about normal storage First this is like hard drives You have two operations which you can do you have a read operation which reads data from the device And then you have a write operation which really writes data into the onto the device right this is pretty normal Then you have a non flash storage. So if you have a non flash storage you can Do a read operation which still reads data and this is as before but write operation actually turns off bits If a bit was already zero it won't turn it into into a one So this is basically applying a mask To bits on on the storage and then you have an erase command So you have to you got to have some some way of reversing this process An erase operation erases a whole erase block it Turns it all the bits in this block into into one into ones But it is a slow operation and There's another problem Erase blocks have a limited program erase cycle So if you issue something like a thousandth or maybe a tensa thousandth or hundred thousandth erases the block will eventually die And then it's not usable anymore so something you have to some software have to do this translation right to take this occurred storage and Do an abstraction which will show it Like normal storage. So this is called an FTL or flash translation layer this is common and the FTL is responsible for many things but some examples are Well-leveling which is spreading out erases among different blocks. So no single block gets erased a lot of times And then it also does bed block management if block already died Then it will remap it internally to to a different block it actually have spare blocks and then It the firmware in Samsung's case is also responsible for the EMMC bus communication or some of it So what is the bug exactly so When you do write operations on the device the FTL has to save some metadata for itself Because it has to keep track on with how many times this block was erased and What is the internal mapping is and so on so it has some metadata that it saves for itself and When you do write operation write operations it has to modify this metadata and the actual bug was a miscalculation in this Code which not always but sometimes made the data corrupt and Once it happened it should only happen once if the data got corrupted This is before Samsung's patch Every time you try to power on the EMMC chip The FTL will try to pass this data and it's corrupt. So it will raise a CPU exception And the default exception handler in Samsung's case is just an infinite loop So the device so the device you use it the device and one day the metadata get gets corrupted and then you try to turn it on and It tries to pass the metadata and it's it's corrupt so it throws an exception and then the EMMC goes into an infinite loop and You can't access it anymore And the EMMC is basically essentially dead because you send commands into it and nothing responds because the firmware is the one is The software that is responsible for answering EMMC commands. So Samsung's patch was something about this something like this Right before the metadata is about to get corrupted how to the CPU. So there's no bug, right? Right before the bug is about to happen just how the CPU So it never happens And this turned like sudden death syndrome into sudden freeze syndrome So I wanted to fix my own device So a quick recap we got I got the EMMC firmware by analyzing Samsung's patch The firmware had a bug causing FTL corruption Once it happened the chip won't boot anymore and Samsung's patch was to avoid the bug happening at all So the next step is obviously to resurrect dead phones, right? Yeah, what? How do I So the EMMC gets into a loop at boot But what happens before it gets into this loop? So I took a look at the firmware and I saw This memory layout as you can see at address zero does Something that I called a boot ROM and it's it's a ROM you can't write into it Yeah and it is a code and What it does it initializes the EMMC hardware and it loads the firmware from the NAND flash chip itself And this is strange because if the boot ROM is already there Why don't why why doesn't it already doing that the things that the firmware is responsible to do So my guess was that the firmware was too too big to reside wherever the boot ROM resides So they had to like bootstrap it from the external NAND flash and then it also has its own machinery for EMMC comments Which is strange because all it has to do is just load the firmware, right? So my guess is that during the production process The NAND flash is empty and there's no firmware and then when Samsung produces this This chips They plug them in and there's no firmware. So the boot ROM goes into some kind of recovery mode and it exposes an emmc bus and from there you can write your new firmware and The boot ROM is basically a stripped-down firmware. There's no FTL, but it looks like the the firmware itself And this is my my current understanding about how S3 works. So inside the emmc you have two silicon dies The first is an arm chip which has a boot ROM which loads the firmware from the external NAND flash and then boots it So if we could ever talk to the boot ROM this might be interesting because we could maybe some do something interesting But the firmware loading actually succeeds because because the firmware is still intact The boot ROM will try to load the firmware. The firmware is still there and it will jump into it and the firmware Executes and goes into an infinite loop. So there's no chance of ever talking talking to the boot ROM, right? though actually not this is not correct because On boot and there's this function at address 7 dbc and a timer is being set for 35 milliseconds and if during this time period some interrupt fires, this is interrupt number seven I don't know what it is yet They read a value from a memory mapped IO address and they compare it to this constant magic And if this comparison is true Firmware loading is skipped and it goes right into this recovery mode and my guess is that so this is a schematic of the boot process and The right that the left column is the normal boot process And if we ever get to the right column that we will we will get into this recovery mode So my guess is that this interrupt number seven corresponds to some emmc command and this Value that they read from memory mapped IO is probably the emmc argument because it's 32 bits so Dead emmc is get stuck on boot. So this is if the chip is already dead However, right before it gets stuck. There's a time window and during this time window if you somehow trigger this interrupt the boot process is Aborted and it goes right into emmc boot ROM recovery mode, which is interesting But the phone is already dead. How do I even talk to the emmc chip? So I could have used the hardware mode like the soldier the emmc and send commands externally, but I wanted to like do something with software because I don't know how to disolder the GI chips So the next step is to talk to the emmc by some kind of magic and then we'll access the emmc boot ROM And then we can repair it from this boot ROM recovery mode So I said if you're lucky you'll get this screen. So this is the phone's boot loader This is S boot and it is saved on the emmc chip itself So how do you get this if the emmc chip doesn't respond? How the phone all the main CPU gets to execute this boot loader? So apparently if you read Samsung specification You'll see that the their emmc has two partitions and it's it's not a partition in the file system sense It's a partition in the emmc sense And there's a boot partition and a user partition and the boot partition holds S boot in Samsung's case Which is the boot loader for the the main CPU and the user partition holds everything else so it it stores Linux and All the Android File system and all the apps and etc So the boot partition has its own FTL metadata and the user partition also has its own metadata a friend of mine had a brick S3 which does load S boot so it gets this screen and It's what what I understood that happened is that only the users but the user partition meta data got corrupted So the boot partition is still intact and I suspect this is a common scenario because When you write to your device you usually don't try to the boot partition you write to the user partition So if something is about to get corrupted it probably will be in the user partition So this is how S3 breaks The main CPU will power on and try it will try to access the emmc and ask give me S boot and the emmc passes the boot partition And It will Return S boot to the main CPU and then S boot will try to access the user partition in order to load Linux and Then the emmc tries to pass the user partition metadata and it's corrupt. So it goes into a loop So S boot actually has a device firmware upgrade mode that is called download mode And there's a protocol of a USB the phone side is called lucky and the computer side is called Odin I guess this is a reference to the most mythology And there's no way of sending low-level emmc commands. So if you ever saw this screen, this is Odin software It's a software made by Samsung to talk with this protocol and in this protocol you can't send But raw emmc commands to the emmc chip. So I need to Send Comments to the chip, but the code isn't there in S boot. So obviously the thing that I have to do is to exploit S boot, right? And run my own my own code So this is this is taken from USB pit packets handler from S boot This is a C pseudo code that I wrote so you control this variable is dump and If it's one it will read something from the USB packet that you sent to it And then it will give you an a buffer and it will use this Number that you gave it as an offset to this buffer, but it doesn't do any boundary checks at all so This is our out of bounds read vulnerability, right? And then the second case reads a size from the USB packet and then it reads it into this buffer Which is constantly allocated on the heap. It's a it's of size are two thousand But it doesn't do any boundary checks at all either so this is a hip overflow vulnerability, right? So eventually I found out this is not actually a zero-day If you take like an s8 or a 7 these two vulnerabilities are fixed but For s3 which is end-of-life These vulnerabilities are still there. So if you have an s3 you can use it So let's talk about some some the S boot heap implementation So if you wanted to allocate some size and The heap chose to to use a chunk which is larger than the size that you wanted to allocate It will split it from the end and we'll see an illustration in a moment And the thing to note about this heap implementation is that there's no security mitigations at all It's very basic so let's say that you wanted to allocate 50 bytes and The chunk that it chose was a hundred bytes then it will give you this part which is the bottom part of the buffer and the buffer that the chunk header has a size number a size Parameter and it will use this size to go to the end So I wanted to achieve right what were in order to exploit S boot and I I use I exploited this chunk splitting technique So the first thing to do was to fake a chunk header which I can control with some large size So it will get split and then I had to figure out its address and I can do this with the first vulnerability the relative read and Then the next step is to make sure this chunk is actually selected when you call malloc And then it will try to give you the bottom part of the buffer So it will start from the chunk address and then it will go all the way to the bottom which is Adding chunk size and then it will go back the size you wanted to allocate, right? And we want to control this number and we can control this number. So if I just Turn around this equation If I want to control address I can just use this number as The chunk size and then it will give me this address So the actual details in my opinion are boring so you can find exploit under this repository It's public so you can just take an s3 and use it And this is a demo This is download mode and this is hello world as boot exploit, right? So it works Okay, so what if it's really dead what if this happened right what if also the boot partition is gone So obviously something has to load has to talk with the emmc and load as boot, right? so there's also Another piece of code which is called Exynos boot room and it it is it resides in the in the main CPU and What happens normally is that the Exynos boot room starts and then it loads something which I call the first boot loader Which is Prepended to sboot and is signed and it just verifies the signature of sboot and then Jumps into it. So just you can just think about it like It's together with that with sboot and then sboot loads the kernel But the boot room has to load the first boot loader and some and sboot from somewhere So what does it try to do? So it first starts with the emmc, but if this fails it goes to the external SD card So I just took sboot and the first boot loader and Drop them onto an SD card, but this that didn't work because Sboot boots into in this case the Sboot puts into SD card mode in which there's no USB protocol So you can't exploit it and as I said it it is signed so I can't patch it But apparently some people over a Forum they The nicknames are Adam out there were bellows and rock dev They found out that there's a development board called odroid x which uses exactly the same CPU So it's the same boot room which uses the same signature, but it uses a different first boot loader Which doesn't do any signature checks at all so if you to if you take this first boot loader and Append it Append to it a patch test boot It will jump into this patch test boot and then you can just exploit it and run your code And this is the modified boot process. So you start with x in a boot room you plug in an external SD card the external SD card has Odroid x first boot loader which is signed so the boot room will jump into it and then the first boot loader will Jump to the patch test boot and then you can exploit it and run your shell code and no hardware mode is required required at all So if the boot partition is still intact the phone loads as boot and it's stored on your emmc But if it is corrupt the phone uses the external SD card and either way I can load as boot And then I can exploit a vulnerability to gain code execution and as boot and the next Step is to access the emmc boot room and As I said before I I Need to trigger this interrupt number seven and send it send down this argument somehow So I just iterated over all the possible emmc commands Which is from zero to 63 and I powered off the emmc powered it back down so the boot process some gets started again And then I quickly sent command x with this argument and I waited some time for the boot process to finish And then I sent any command which is supported by the boot room recovery mode And I checked if I got any response and I said that this is how Maybe it's going to work. Maybe not and then I tried command zero and it failed and I said yeah It's never going to walk and then command one walked So this was very exciting for me because this is the first time the emmc actually responds and Up until then on my on the brick device. I tried to Send several comments to the emmc and I never saw a response And this is the first time I actually saw a response back from the emmc This was very exciting and the emmc boot room even has command 62 and all this back door mode So let's fix it right let's repair the emmc So there are two revisions of this faulty chip the first revision uses a firmware f1 which is buggy And then there were phones with firmware revision f7 in which the bug never occured So probably some song fix the bugs fix the bug in later hardware revisions So my goal was to update the chip to firmware f7 and format the FTL metadata. So the corruption is gone Okay, so what I did was to write a dump tool a few more dump tool Which is a kernel module and then I had to convince anybody over The internet to run my code which sends low-level emmc commands to on their own device and Thanks to Artezia, which was courage enough to Try it I got a dump of firmware f7 and it worked And I would just had to write it to the emmc itself So this is absolutely doable because I could have used the memory write back door To write my own code and access the NAND flash chip And write a new firmware, but then I found out something simpler So there's another back door which is command 60 And it has two firmware upgrade modes for some reason So the the former mode which is CB AD 1160 Supports FTL metadata format you can send an erase command and it will format all the FTL metadata And then you can write a new firmware and it will do everything for you so How do I fix a dead S3? Just I just just get the dead S3 Which should be this is important to note that there are many There's different revisions of galaxy S3. I'm talking about a GTI 9 300 which is the international version Boot to S boot either directly If the boot partition is still intact or by using an external SD card Then exploit S boot to run your own code From the shell code reboot the emmc into boot from recovery mode And then use command 60 to format the FTL metadata and flash the new firmware F7 firmware Then we put the emmc so the female loading actually so the firmware boots and then you can write S boot to the emmc's boot partition and There's another step which is to profit And this means it's demo time So I pray to the demo gods that it it's going to happen. It's going to succeed So yeah Okay So I have a brick device. I break it on purpose This is the device if I try to turn it on this does battery inside Nothing happens. It's bricked If I try to get into download mode nothing nothing works And I have this external SD card which is which does have As Boot as I said before If I plug it in And I try to boot device Should boot into Yeah, okay, so it boots into something and now I can use Just go back to the and I can I can plug it into the USB and As boot answers And now I'm going to Run a shell code which fixes the emmc Yeah, it's retrying. It's okay. Yeah, she'll got started It's rebooted the emcee to boot from out and now it will write the new firmware And it should take a couple of seconds. So Hold tight as it said Okay Yeah, so the next thing it's going to do it's to reboot into the firmware and then Change the boot partition size. So there's actually a boot partition yeah, and now the shellcon is done and I can just use a Different SD card which Loads S boot normally and it goes into SD card mode and in this SD card mode it will write S boot to the boot partition so Just Yeah, okay. So this is SD card mode. I think you can't see but if I now remove this SD card, right? And just reboot the device. So the battery is outside. I know it's Yeah It should boot into yeah, so this is S boot. So the device is fixed. Thank you so Conclusion a Few shout outs. So rebella, Saddam Outler and Radek Dev did all the Exynos U boot first bootloader or droid X walk. So Thanks to them. I couldn't I if it weren't for them. I couldn't boot brick devices Entropy 512 was involved in the emcee research back in 2013 And Banyan Exobs held a wonderful talk here at CCC some years ago And they talked about hacking Chinese SD cards and they mentioned my research and this motivated me to complete it because it was still in progress So this was this is the reason which for which I'm talking today. So thanks So I can basically own Samsung emcees I can fix Brick test tree with just software And in my opinion, this is just a use case because now you can do interesting stuff with your emcee chip and What I think we should do next is to look at newer emcees Which I suspect still has this back door because I tried some some chip which I could get my hands on and it had this back door so Maybe even the new ones also has this mode and Then there's a UFS, which is the bus which replaces emcee and it is based on SCSI and Samsung also produces UFS chips, so it might be wanting to see if there's a similar back door and It's also interesting to look at different vendors of emcees and maybe one day write It's an open-source alternative firmware for these devices So this is question time You can find the code that I wrote to experiment with these devices over the following links and you can find the slides in the bottom link It's already public so go ahead and if you have any questions, this is the time so thanks So thank you very much all on for a really interesting talk if you have questions There are two microphones in this aisle and then two on the sides and first question from microphone number two Yeah, hi, okay, really amazing what you did Do you have any feedback or contact with Samsung about this? Yeah, so I published my research back in 2012 2013 sorry Over forums and I I didn't use it from a security perspective. I wanted to fix S3 They never Responded or they didn't contact me in any way. I Didn't contact them about the bootrom Recovery mode because in my opinion, it's it's not a security issue And it can be fixed it can be fixed and Regarding the S boot vulnerabilities does know it's already it's already patched. So No, then says no So the way I understand is this is the only way to actually fix some of the phones that are broken out there, right? Yeah, I don't know any other way to do it. Okay. Yeah, thanks microphone number one After seeing a real-life FTL do you still use SSDs? Sorry after seeing the code of a real-life FTL You still use SSDs or flash device. Yeah, this is a good good question it's okay and I don't There's no alternative, right? So But we might make something so yeah number three do you have any Do you have any idea what other devices have this model emm see and and like support the same Commands that let you access the firmware Ah, there's other devices that have had bad MMC Okay. Yeah, so the Some Galaxy S2 had a similar bug and Kindle fire I think one of their versions and some of them got Pitches by Samsung and it's usually was something like this like patched them internal memory every time the device boots So the bug never happens. I think in the other Devices the bug was actually fixed But are you aware of any non Samsung devices that have Samsung MMCs in them that might be the same? MMC I'm sorry. Are there other devices that aren't Samsung phones. Oh, yeah. Yeah, still have Samsung parts in them Yeah, so there's not a lot of emm see manufacturers and Samsung is a big manufacturer So a lot of different phones on devices use Samsung emm sees. So yes, it's irrelevant to non Samsung devices Number one hi, thanks for your amazing talk and research Two questions There's the Samsung galaxy note 2 that has More or less the same bug. That's your fix and your research also apply to that device and Is there a way to do a chip of thumb? Without erasing the FTL and the contents of the card Yeah, so this is a good question. So the first the first question was That's as to has the same bug, right? The note to I don't know. I never had a note Oh, so okay. I have one that is bricked that way. Okay Interesting to try. Yeah, true. Let's talk and Regarding the second question. So my code actually formats all the FTL metadata, which is Not that good because it erases all this information about how many times every block was erased a More proper fix would be to actually fix the corrupted metadata, but I haven't got to the point in which I can Fully understand the inner walkings of the FTL So this is my current code, but you're welcome to try to improve it Wonderful I'd like to know what the time frame was from you starting to work on the issue till you had the first fixed s3 Yeah, so I I obtained the firmware back in 2013 And I had the walking device and I didn't want to do like I'm bad stuff to it. So I Stopped back in this year and then Last year a friend of mine said that he has a brick test tree. So I said, let's try to fix it So I think if you like accumulate the time, it's probably going to be like time frame which I walked which I Actively walked on this was something like a few months probably four or five months But it started back in like for four years ago and And I finished it something like a couple of months ago. So Thanks number one Do my am do Samsung SD cards have the same undocumented commands. Yeah, I suspect they do some of them I actually bought some Samsung SD cards and they had Controllers made by Silicon motion, but they read over the internet that some specific cards I think it's a evil plus evil plus Have Samsung controllers, which should have the same vector. So I'm trying to Buy one But as soon as I find out I will probably Thank you number three Hi, thanks for the great talk So I'm still using an S3 as my everyday phone So what actually happened a few months ago is they broke down But so I still saw the Samsung bootloader that's put what he described and Afterwards it got stuck at the boot screen from the OS so in my case It was a notch mod, but also when I flashed on something else lineage OS or the default something's from where it still got stuck So really had to reflash everything and then it worked again That somehow sounds really similar to the buck you described, but in a way it also it doesn't so yeah Do you think it's the same thing? So if it's related my guess would be that Your device have this in-memory patch which freezes the MMC and When you used lineage OS or what it was before This infinite loop triggered at some point in the boot process So the device actually froze before it got to the to boot Android But then when you refreshed it Somehow the internal block mapping got changed and now it doesn't trigger this freezing but If your chip is a VTUW0M and its firmware is F1 then you definitely have the bug Okay, thanks. Yeah Number one Hi, thanks for the great work One question you said you upgraded the firmware of the MMC with a newer revision Are these filmers actually signed or can you flash anything on the AMC controller? You can flash anything Yeah, they have a simple heuristic which checks if the stock address is It looks normal, but other than that it just puts every film you'll give it So I think I think in newer newer emmcs, which is a emmc 5.1. There's a mechanism of Flashing new filmers and I think it should be signed, but I don't have a newer emmc So I Don't know about about it, but yeah, thank you So I have one last question About the Samsung patch. You said that it basically goes into some sort of infinite loop But do you think they might have tried to do some busy wait or they waiting for something to happen? No, I think they just Did you just want they want the bug to never happen? So Yes, I my phone froze a lot of times and I waited like I don't know 30 minutes And the code in the Linux channel doesn't do anything and the code in the emmc a few more doesn't do anything So my guess is just waits forever Yeah, so I see no questions. So again big round of applause to all on for great work