 Hello everyone. Thank you very much for having me. Yesterday we were going to be talking about physical attacks against smartphones. So the crux of this talk is that I was seeing a huge number of different conference talks about extremely complex attacks against smartphones due to the high measures of security that are placed on them from the boot level all the way up to the high level OS. Despite this, there are still times when very simple techniques can be used to bypass the security on smartphones and escalate privileges or get unauthorised access in ways that you would consider very simple in a general sense. So we're going to be doing two 20-minute case studies for this. The first one is going to be gaining root access on a smartphone with no bootloader unlocking capability. This is where the manufacturer removes the ability to unlock the bootloader and root it by itself. And the second is going to be gaining code execution in the bootloader of a Samsung smartphone in order to bypass secure boot and execute your own kernel and do other malicious things. So case study one, rooting on a locked bootloader. Essentially I bought a brand new phone and wanted to root my old one so that I could use it for app tech testing and that sort of thing. Install mode certificates, ad reader, et cetera. However, on this particular device, the manufacturer had gone into the code of the bootloader and removed the checks to allow you to access the USB interface. This meant that I would never be able to get into the fast boot mode and unlock a bootloader, add root access and that sort of thing. OEMs very rarely do this and they usually just add restrictions onto the bootloader that requires them to you to sign up with their services in order to do this properly. The target device was a smartphone from a Chinese OEM released in 2019 that used an OEM developed for Android which had its own security features and other tweaks to it that were going to be the target of this particular project. So while I say that it didn't have bootloader and locking capabilities in the traditional sense, what it did have was a special engineering app that permitted bootloader and locking. This used a signature stored in a partition on the device which was inaccessible to standard users but could then be used as an engineering app with special permissions and written into it. And then when the device rebooted it would give other engineering level access. It was not publicly available though there were some leaks online and required an approved user account which was a long-winded process I didn't want to go through. So when bootloader and locking isn't available it's obvious that you're going to need some kind of exploit in order to escalate privilege to root. And with no direct access to the bootloader USB interface which is my standard approach for attacking a device like this a vulnerability was needed in the Android fork itself. I didn't think I'd find anything in Android that would be particularly actionable in this sense and I thought the changes that I'd made to it would be probably the area where I'd find the most critical vulnerabilities I could use. What I found was the Android fork contained a high number of custom system and root level applications which could be potentially exploited in different ways. So the Android fork had a service running as a root at all times that was called by the system level applications for the facilitation of cloud upload and archiving of app data so we would take all the data from the users protected application called and off partitions package it all together and upload it to the cloud where it could be downloaded again if needed. Brief analysis of this binary found that it had an immediate command injection vulnerability where if you had a file within the file system with back ticks in the name you could execute commands within it. What would happen is you would upload this file and then download it again and as it was restoring the file it would then execute whatever command was in the back ticks so very basic. Unfortunately for me Android also employs SE Linux which is an extremely strong security measure to cordon off different components of the operating system even if they are all running as root. This meant that even though I had root access superficially I only had access to the app data sections of the device rather than having the access to other components I wanted to modify. I found that pretty much every instance of a command injection I could find on the device had a similar issue so I'd have to find another way of getting escalated privileges. Most vulnerabilities that are limited by SE Linux context could probably be bypassed with a kernel exploit however a kernel exploit is a very complex thing to do and not something you want to be doing for a very basic simple project you're just doing in your spare time. As the boot loader was locked down and the OS exploits were out of the question I decided to go for my next specification which would be recovery mode on the device. Recovery mode on an Android device traditionally is a very simple menu which you use the volume buttons and the power button in order to navigate through it. I found that on this Android 4 they'd actually updated this to include Wi-Fi access access to more parts of external storage and a few other options as well as having the touchscreen enabled which I found was due to the fact that they'd taken their Android kernel and dumped it into the recovery partition meaning that if I'd gain access to it I'd have access to all the same hardware components the traditional Android operating system was. I wanted to find an update image for the entire operating system of the device so that I could extract recovery and then find a simple vulnerability. Unfortunately downloading the updated the update files for this device found that they never updated the recovery partition meaning that I couldn't find it within the operating system. That meant that I would have to work out any vulnerabilities blind and just guess and just try things until something worked. So yeah, with no recovery image to reverse engineer I just tried very basic attacks of again with. As the menu option included the option to load in these encrypted zip files the OTA update images I decided to attempt those first. So as I found a command injection of vulnerability in the high-level operating system I thought I would probably find one in the recovery image as well. So I took a legitimate encrypted update file for the device and renamed it to contain Bactics and Sleep 30000. What happened is if I had successfully executed this command the phone would be spending a few hours trying to update itself with never succeeding. Yes, and this did indeed cause the update process to hang demonstrating that I'd found yet another command injection of vulnerability in the device. I disclosed all the command injection of vulnerability sites found to the OEM who very very swiftly remediated them and updated new versions of the software. But as the recovery mode command injection was very likely to be running as root and have no restrictions on it this would be a good basis for me to then gain further root access to Android. So I started with root cause analysis just so I could get out of the way and found that it was a SHA-1SUM check for some logging that was checking data on the SHA-1SUM of the update file which was then just executing the Bactics because there was a sprintf into an exec command so very basic. As there was a command injection of vulnerability in the file name this could probably be used to update a more complex script. So if I wrote a more complex script a base 64 encoded it and piped it into a system bin SH a shell script could then be loaded to this more complex from the file system and executed so this script here literally just cats from the user data partition a much more complex script that can be used. Unfortunately the file system used by Android's user data does not support all special characters for instance the pipe character I would need to perform as exploit so I would have to find a way around this. Luckily I found that they had modified the recovery image to also support which is rare on Android and usually when you put in the XT4 SD card into an Android device it says unsupported file system and then tries to format it. Luckily for me it didn't do that so I could just load my more complex update file onto that and execute it. So I wanted to get a more concrete shell on the device so I would have a look around and also work out what was going on in a more accessible manner. So what I did was I run the IT command and run it into the user data partition so that if I wanted to reboot the phone I would then find it was running ID root or ID system or what was going on. I also wanted to see if I could disable SE Linux to bypass all of the context that were there and found that that also worked and then I also wanted to enable ADB on the device so I had a root shell into recovery which also worked quite well. So root access and recovery mode is great but you've then got a phone that's in a very not very fairly fleshed out mode I can't access any apps from there I can't modify my files in any real way and I can't usually access the internet Bluetooth or anything like that. What I wanted to do was find a way to switch from recovery to Android without ever having to reboot the device and go to the bootloader because as soon as I do that I would lose my shell on the device because there was no persistence in an attack like this. My first pull of call was to try to use Kexec now Kexec is a kernel component which allows you to load a new Linux kernel onto a Linux device and then execute that essentially switching from one Linux kernel to another. If I could do that that would be a very quick way for me to switch to the Android kernel and everything else but unfortunately even compiling the module from scratch was blocked because it was using some deny listed module components so I decided to try to do something that was in the user space rather than in the kernel itself. Luckily there was Ptrace as a system call allowing one process to observe and control another for debugging purposes. Typically this is for things like logging and tracking and debugging on things that are running on the operating system and doing things like the Strace command within Linux. It can even modify memory that is right denied in the standard processes which means you can modify running code even if they are not meant to be able to do that in the particular elf that you're working with. What I wanted to do was use Ptrace to essentially latch on to the init process and restart that but in the Android context. So init is always process ID one which means that it has some special privileges within Linux and also it has a lot of control over the rest of the system. What I wanted to do was use the execute command which executes a command within one process that uses the same process ID to run more commands that would then get me to switch out init. Luckily for me if I did this I could execute init but never have to return back to it. I could just keep things going as one long process switching from one data to the other. This could be very tribly done with a bit of assembly code so just moving in the parameters and then executing the service call. Switch route is what's used during the boot process usually to switch from the init ramfs so the ramdisk which contains some of the lower level stuff for mounting the more complex file systems into the new one. It's a very common feature on Linux based devices and what I intended to do was switch from one init ramfs to the Android init ramfs which would then load into the system operating system. This could be very easily done if I just mounted a new ramdisk and then loaded the data in and then hopefully I could then switch it instead if I needed. So the process for init usually looks like you have the init process that starts as one then it sets up SE Linux and then it does init second stage which has all the hardware set up and everything and that's where the process sits most of the time. Essentially what I wanted to do was inject in a switch route command into init which would then start the whole process again killing the old recovery process and introducing a new one that was running Android. There are a few caveats with this however because the ones really intended to switch from one init ramfs to another and you're meant to reboot to get into other systems like this. So a core component of switch route is the remounting of mounted folders however most of the mounted folders that occur in Android at this point are shared. This means they're handled in slightly different ways than how you expect when it comes to things like moving the mounts to different places. However this could be tribly resolved by using a small shell strip that went through all the mounts found out if they were shared and made them private instead and private means Also I found that init binary was checking proc command line within the file system for whether the image required SE Linux to be enabled and if it did and it found it was disabled it would enable SE Linux forcibly re-enabling it even though I disabled it. Luckily for me ptrace allows you to override system calls so I modified the read system call whenever it touched the proc command line file to override the check for enforcing SE Linux with one that allowed it to be permissive which was nice and easy. I also found that this caused a lot of kernel panics because init also does all the system hardware services setup. This includes things like saying go out of the wife interface bluetooth etc but the recovery operator side of the things had already done this so doing this again caused the kernel to not really know what to do. What I did was in the same way as I did with proc command line just make it return empty files whenever it tried to access these .rc files. I did this to modify them within the file system which would cause the device to not be able to work in a non-rooted manner. I also found that when I tried to unlock my phone after getting through this entire process and getting it to boot that I could no longer use my pin because all of the security services were still running in the recovery context. Luckily for me I could just kill all these processes and let it restart them again right as I was starting this whole process up. While this was pretty much a read only file, by re-rooting the device I'd lose all of this root access. What I could do was still override some read only files. The system partition which stores a lot of the system data is a read only file system. It uses dm verity to make sure it's got appropriate signatures working throughout the file system. However if you use the mount-bind command you can override the files there temporarily with your own meaning that if I wanted to modify for instance frameworks which had root detection in and things like that I just need to do that temporarily and it would work without damaging the device in any way. I'm going to do a quick demo of this boot process now before I move on to the next one. Hopefully this won't go to the next one. Brilliant, sorry guys. As you can see I've just pressed my little commander and now it's running through the init process. It's running through the files recovery which was running the screen at that point and starts the Android process booting up. Then starting the full Android operating system and giving me root access. I also found the trend off the phone when I started this I needed to reboot the screen otherwise I couldn't use the touchscreen. I have a telnet root backdoor into the device. Thank you. I observed something quite interesting after this. I was quite happy to have root access but I realised that during the debugging process I'd kept a busybox telnet server within the recovery context of the device. When I'd remounted the new init RAM FS I'd found that the old recovery one was still sitting in memory and accessible. So there was a telnet service running in a file system that Android had no idea about. Switch root had deleted all the files within this file system because it was stored in RAM but just using busybox I could repopulate all the tools and it gave me this secret little section of the device which Android could have access to. Because it was hidden from Android I could do a lot of interesting things accessing the hardware and stuff but I could also access the rest of Android itself without Android knowing that I was there. So by seeding or shrooting into the directory proc1root which was the root file system that the init process is using recovery could access the Android root file system as root without Android knowing about it which was fantastic. What I decided to do was expand this out however and add a whole Debian root file system to it. So I had a lot of debugging and testing tools that I could also use to continue to compromise the device in further ways. So in conclusion root access to this method was very consistent. I left the thing running with the init parasite ptrace tool attached to it for days at a time without any crashes. They would just keep running and running and running and no problem whatsoever. I also found that just by rebooting the device I had no effect and it could operate normally going back to a standard way. And I also found that the biggest benefit for this whole project was having ptrace there so if you're compiling a kernel do remove that if you need to. Now we've gone to the second case study which is a bit more technical and a bit more exciting because we're not going for a device that I wanted to root for my own purposes but I just wanted to exploit in some way. So external space devices have had a significant amount of research done on them on this stage and at Black Hat we've focused on the download mode of the bootloader so this is a high level protocol used by Samsung to write and read files in different ways and debug the device and unbreak it in many ways. Because it all focused on the high level download protocol I decided to start a project to try and manipulate the low level USB stack that was in use to see if I could find a vulnerability that was as actionable as what had already been found. For this I found the cheapest Samsung device I could that was still a decent Samsung Galaxy A04S which was actually quite a decent phone after I bought it. It was released in August 2022 and used an Exynos 850 chip set and I knew that it would be quite an interesting target because it had a lot of the security features like NOX in place that more expensive, more modern or more higher end Samsung devices do. So the secondary bootloader which is what I was going for with this project is called S-boot in Samsung and it facilitates a few things. It facilitates standard boot from the primary bootloader and it facilitates download mode which is the protocol we're just talking about. On my device it also had fast boot mode which is the standard Android administration's bootloader tool and upload mode which is what's usually found when you hit an unrecoverable error in some way. All of this was encompassed in a single firmware binary called sboot.bin but because of this I thought all three USB protocols so download, fast boot and USB would probably be using the core USB stack underneath and it would have broken all of those in one go. So when I'm talking about the core USB stack I'm talking about USB control transfers. So control transfers are used to send and receive like debugging information, or not debugging information, configuration information about the device. Sometimes it's used for more complex things for instance iPhone and DFU modes also use control transfers but generally there's a very standardised approach for these and they use standard parameters which are BM request type, B request, so what I really wanted to do was just fuzz it and find an actual exploit just by running a very basic fuzz it. Now control transfers are mostly extremely stateless. They do their own thing, you read and write data and at a very high level there's just not much else you need to do. With this you can just randomise all the parameters and send a randomised buffer size with randomised data in it and see what happens. So as you can see there my very complex fuzz it way better than AFL of rand, rand, rand, rand for every parameter. As you can see on the right when I was running this you'll see the minus nine errors which are Lib USB errors which is where the device has gone I don't know what the hell to do with this. All the ones without the minus is where data has been transferred back and forth so very simple to keep track of. However during my initial fuzzing attempts I was sending purely random data and it caused the device to reboot into a failure mode that I couldn't recover from. Every time I tried to reboot it said the same thing an error has been done but it occurred updating the device software and I thought I'd now got a brick on my hands. This occurred when the OXF6 value was sent as the B request parameter which was very interesting because I didn't know why that would be because it's not a standard commander or anything like it. However I found it was recoverable and back to a working device by using the download mode tool so I used the command line tool in Heimdall which is an open source tool for manipulating download mode that's accessible on GitHub and as soon as I tried to do anything with that tool the device decided it was working again so clearly it just didn't like my tool. So I kept fuzzing and fuzzing and fuzzing for about half an hour and found that the device would crash and reboot after a certain set of transfers. Luckily I had a seed in this fuzzing so I knew exactly what could be done and I could just run the hole on target fuzz again and see what happened. What I did was essentially remove transfers in the sequence to see which ones were actually causing the crash in the first place and essentially got that down to two control transfers over about 10,000 which was nice. The first transfer was a malformed get descriptor request so in that instance it's got get and it was sending data instead of receiving it and the second was a valid get descriptor request which was causing the crash. Now get descriptor is a core component of the USB stack and it's control transfers that retrieves descriptors about the device. These are configuration data which includes things like strings about who manufactured the device ID's and also what the device does which is very nice. In these descriptors the first byte of the data is always going to be the size of the buffer itself so you can see B length is 18 which is the size and if you can overwrite this you can then make your memory access push into the linked list next to it which is where the other descriptors are stored usually. So what's interesting is most USB stacks don't check the control transfer direction. They're usually protected by how their own USB hardware works so they have send and receive functions so for instance in this case this is the STM32 USB D stack where if you send it a get device descriptor request it will explicitly send a control send data request to its own hardware meaning that it can't receive data back from it. However in this instance I could send data to it meaning that I had full control overwriting data in memory which was very nice. So what I did was I tried to overwrite that first byte just by sending data to the same memory that was there however this was ineffective and it did change the byte however it didn't alter the size of the data received. Luckily for me there was just a buffer overflow there anyway so I was quite happy. Because of this the data next to the buffer could be overwritten but I didn't know what there was there yet but I could just try and guess. So by sending a large buffer that caused the device to crash I knew that I had a traditional buffer overflow hitting something so I decided to do a binary check until I found a data size that didn't cause the device to crash. Then I made that size one byte larger and saw if it crashed and then if it did crash changed the value of that last byte incrementing by one until I found a value that didn't crash. Essentially it was brute forcing my way up via JSON memory until I found fully working memory that I could then manipulate if I wanted. What was excellent about this was next to it was a link list to other descriptors which would then be overwritten themselves and this had two key benefits to me. Number one this could be used for a cold boot attack. So for instance if I had someone's something phone and rebooted it the memory wouldn't be cleared at that time and I could dump the entirety of memory at EL1 so all of the external RAM and then get their secrets out of it something they'd been typing, anything that was stored in RAM at that time. The second thing I could do was write to all of that data as well including to the boot loader. So the first thing I did was when I dumped the memory of the device so I knew the memory layout of the boot loader itself so I could then manipulate it later. So I found that all of the pointers I was looking at were between OXF9 and 6.0s and OXF8 and 6.0s. So I made a memory dump of a bit of data right before that just to see if I could find the code of the boot loader itself right next to the RAM which is what I expected. Luckily for me the boot loader could start at OXF8 and 5.0s which meant that I could then dump it and just use it in GEDA if I need it to. What I really wanted to do was get code execution so I could then modify the functionality of the device to simply bypass the cure boot and get a bit more access to things, modify the kernel etc. But I found that they'd actually implemented depth on the device so data execution prevention meaning that I couldn't overwrite the code in the boot loader in RAM because the memory management unit had disabled this. When I tried this it caused the device to hang because it hit a hardware error and it was configured well. And trying, however, I found that attempting to execute code outside of the code that had been allocated for the boot loader was possible. So if I just dumped a bunch of code just outside of what had been mapped already I could execute code from anywhere at the same exception level as the boot loader itself. So with this I could patch in new functions if I wanted to and when I'm writing even exploits of boot loaders I like doing this in C. And just by using the GCC static no-lib flags and using object copy you can create a raw memory of any functions you're writing as long as you're not using standard libraries. So you would have to re-implement mem copy but you've still got a lot of ease overwriting ARM assembly all day. And because I could write these into directly into memory if I wanted to then write into the stack to point to them that would be very easy as well but I had another idea instead. So fast boot mode was used to the basis of this exploit because I just really like fast boot mode but also because it uses string based commands for all of its functions you'll find on boot loaders using fast boot is there will be a table of strings for the commands themselves and then point us to specific functions. And this is usually stored in writable RAM regardless of where it is because they're loaded in via other functions and by modifying this table it would allow me to have easy code execution without modifying the stack that I need to do other complex things. I found that fast boot in this instance wasn't really used in administration at home you had two commands which were get fire because it was easier. So the table usually looks like this so you have an address pointing to the string so reboot and then address point into the function itself. This would mean that if there were any really complex things like stack canaries in place where I could still bypass them very easily they wouldn't be a problem at this point because I was actually going to see someone loading an address itself and execute them. Because I had code execution it meant that secure boot bypass would be possible. So I could then modify the kernel without hopefully tripping knocks and add malicious code into someone's phone when it was booting and do other interesting things. However I found that none of the USB base modes so fast boot download etc had the capability of just booting the phone itself which would be a good way to hook into for this particular attack. What I would have to do was call into the boot functionality that was already there for the standard boot mode so I found that this crashed the phone itself which meant that I would actually have to implement boot functionality in a boot loader myself. So there are two options for the re-implementing the boot process. The first was to copy the entirety of working memory from the boot loader and put it somewhere where I could modify as I wanted to or just re-implement the boot functionality from scratch calling in functions that I needed to to things like set up the hardware, set up the site. That is the point because all I was doing. So functions in the boot loader could tribly be called by absolute addresses in C so in C you can literally say I want to call a function at this address and it will load it in and branch them and it can give it parameters and that is why I wanted to do so that I could just load in and check things that didn't work right etc or say change parameters or just remove functionality I didn't need for instance if the boot loader had already executed certain hardware set up I wouldn't y byddwyd yn ymlaen i am gyfrifiad i yn ôl y byddwydstei yr yma. Felly y ffordd eu gymryd ymlaen i'r newydd yn cael eu bod yn gweithio unrhyw rhaid o'i byddwyd dros y dybogwch yn ystod y gwaith yn cyfeirio, roedd y ffyrdd ymlaen i'r boedau, yn cael cefnogi, dwi'n gweithio'n job i'r cyr Polfod FxF 0700. Byd hallai'r bood pwy o gw feddwl i'ch gwir ymarfer o wahanol, gallw'r hyn yw'rhewchberg sydd i gynnal â gynnal y ffyrdd yma. Rhywbeth i wahanol i dda i'r gyda'r hyn yn gwneud y bydd hwnnw i'r bwc pwysig hynMCol yn gwneud y presbytion yn gwneud y gondig gweld yn yn gwinell. Mae'n rhoi gwneud yn tre middomeg'i booth yma, felly mae'r prysg bwysig yn eich bwysig. Maen nhw, o救 pwysig hyn, yma wrth gwrs wrth glwg. Felly sy'n rhoi'r boblodeau i'r bhwysig Eеляu Sialer Holderwyr yw ni'nouldwch y clin-dodi yn achos o erd i. Pan mae'r Mu yn gymoedd oeddaeth gyda'r cyntaf i bod ni'n rhaid i ychydigol. Rwy'n gwybod dda'r cyntaf i'n gallu amddangos a unigodd y Cymru a bach at bullywنتau cymaint o bobl ym Yngyrch Cymbr Sfiad, ymgyrch Cymbr Cymbr fel chi wedi'u annigodd ac yn ystod yn cael eu gwirioneddiaeth. Am wnaeth i adnodd ybryd o fyfiol fel ni'n fcyniau i ddweud yn dechrau'r cyntaf i ddweud is being around that the device was freezing after the kernel re-initialized the MMU. A key component of the kernel is it reinitializes a lot of the hardware registers that the bootloader has already done because they're not necessarily anymore. And so as soon as it was re-initializing the MMU with its own rear-arrangement of the memory, so setting up things like the kernel memory protection and things, it was causing the rest of the device to hang. And the reason for that was most likely going to be that the bootloader itself ac mae'n gwiswch yn ymgyrch yn ymlaen, mae'n ddweud bod yn gweithio'r ddweud yn y cwmwysgol. Mae'r Android boolod yn ystod y cyd-drygu'r gweithio arall. Mae'r Android yw'r start-up, mae'r interrupt yn ymgyrch, ac mae'r USB yn ymgyrch, ac yn ymgyrch arall, mae'n gwybod i'r adeiladau ar A-B, ac mae'n gwybod i'r Android yr adeiladau. Mae'r S-boolod yn ymgyrch i'r Arthos, ac mae'n ddweud yn ymgyrch yn ymgeisio'r ddweud, a ddweud i ddaethol cyhoedd yn ymddorol combiwnol veggies. Dydedwch yn ymddorol, maen nhw'n mynd i'r ffordd ar yr hyn ac ymddorol yn gyllidol. Pas ddod wrth gennych eich cyflym o grampau sy'n fynd, rydyn ni'n ddweud am yr lleol lle mae'n rhoi ei ddweud am dyfodol i'r hefyd yn cyffredinol, ac mae'n hynny roedd yn cerdd. Oherwydd mae'r gyfan y floseg, trafodau'r cyffredinol e'n credu eu papill i'r hefyd, Mae gennym i eu gweld i'r hollun, ac mae'n gweithio'r rydyn ni'n cwmein henderfyn ar y rai. Felly, ti'n wneud am 3 rhai ar gyfer y dyfodol, ond mae'n rhaid i gweithio'r gweithio, mae'n fynd i'r gweithio'r gweithio, mae'n allan o'r troleu'r dyfodol, i'r bobl yn gweithio, ac mae'n gweithio'r cyffredin o gyhoedd SBC, ond mae'n gweithio'r ffasbydd, ac mae'n gweithio'r gweithio'r gweithio. Llwyddo gyfaint eich hanffras, o'r cwmaint ydw'r newid gyda gennym, ac erddw i ddim drafod yma eich sut yng Nghaerdydd, ond ond nid o'r ddiolch yn Gwenllian papurau. A dwi'n cael cymaint ar gyfer y solutio cyllid yma oedd gwylio, ac nid o'r llwyddo gyda'r llwyddo ac yn oaf. Felly, y llwyddo gyhoeddol, ym nid o'r llwyddo gyfaint, ddweud yr llwyddo cyff fynd i gael i'r llwyddo, something that's very timing or security critical and also recovering from the exception wouldn't be required because we were trying to access the canal which would then resettle off the exception registers and things so I could literally just dump the canal bootstrapping code into that hopefully and get where I want it to be. So VBAR EL1 which was the table that you just saw in the last slide is a register that points to a table in memory which includes sequences of different exceptions which are stored in 128 byte chunks so every 128 bytes is a different exception type. I didn't really want to work out which exception was what so what I ended up doing was doing a knob sled throughout the entirety of the exception table into my bootstrapping code at the end of memory which would then execute it. So even with the canal booting like this and it did work it's got further down the line Android was still failing to start reverting to a special recovery mode that was telling me that the file system manager was failing. The error message that I saw was suggested that it was due to the user data partition not being decrypted so on most Android devices now user data is encrypted and using hardware key which needs to be set up during boot to make sure that you can access your files. What this implied to me is that I'd messed up somewhere and that the key storage or something else was not being enabled properly or had been broken in some manner by my bootstrapping. So analysing the logs prior to boot found that there were multiple hardware initialisations I'd missed or ignored because I was being quite lazy with this project and this was due to the fact that they'd already been initialised by fastboot that required them for other purposes. This included things like reading data and setting other things up but essentially I was running the same functions twice for setting up the TE etc. By looking at the logs I could see the error messages for instance key storage in it failed and T-gris register handler rat minus one meaning I'd have to do something to bypass this. So both of these particular functions were enabled by a very very large and complex function that would take a long time to modify or bring back from scratch however I did end up doing that by fully re-implementing it but checking for every if statement throughout the function for different self hardware initialisations and ignoring the code paths that I didn't think it would hit. However with these errors removed the phone could then complete booting to Android. So I'm going to do another demo now hopefully. So here's the phone in fastboot mode and you'll see it very quickly go into the boot screen before switching back so that screen you just saw was the one that happens when you just hold the power button on a tunnel on the phone but as part of the boot process it required it. It then shows the secured by knock screen which I'm not quite sure is true anymore at this point in the process. You'll see a flicker occasionally in the screen where the kernel is rewriting that secured by knock screen and then you'll see that disappear. Now at this point I was very excited because this was meaning that we'd bypassed all of the hard issues or the other issues I'd had in this process and we're now getting to the point where I was executing my custom modified kernel which I'll be peaking and poking into through this process. So in a second we'll see the home screen and we'll know that my modified kernel was executing which I was very happy with. So there's a lot of things that can be done with kernel code execution. You can disable security features and things like that but you have to be very careful because Samsung do put a lot of effort into making sure that there are checks in place that if you do too many scary things, knocks will blow a fuse and permanently the device will say it can't be secured in the same manner because someone's been messing with it but very easily I could modify the kernel proc version just to show you what happened in the strings. Now I did modify this further to remove things like SE Linux checks so regardless of whether it had SE Linux in place but I thought just a demonstrative picture of the version being modified was a good start for this. So some final notes on this case study. Because the exploit can now be triggered using an exception it would be much easier for me to re-implement it in the download mode which is much more common on Samsung devices which would mean that the exploit would be much more far reaching if I implemented it on a more expensive device. And while code execution was possible as I just said there was still a risk of triggering knocks however I didn't manage to do that during my analysis of this device. So in conclusion of the two case studies we've discussed today, the initial vulnerability was disclosed to, sorry we're doing the disclosure first, I'll get my slides mixed up, the initial vulnerability was disclosed to Samsung in December 2022 and they provided constant updates on progress and patched the finding within three months across all their devices which was extremely impressive considering the complexity of debugging this kind of thing. So the target device that I had after recording my demos for Defcon was updated and I found it to no longer be vulnerable to the descriptive right vulnerability meaning code execution but in this manner was no longer possible. I'll be releasing the tools for this on my github but you'll be able to find the link to my Twitter where I'll announce this in the slides which you'll find on the Defcon media server. So now conclusion. So most devices regardless of how much effort people put into protecting them will still have exploitable vulnerabilities that can be exploited simply despite their resources and even with basic vulnerabilities the effort required sometimes to go from a proof of concept to a full exploit is really rewarding. For instance you saw that there was two very basic vulnerabilities in both of those case studies. We then took a certain amount of effort to actually make into a complete attack chain and last of all even on targets which had a huge amount of research put on them there will still be a factor no one else has tried so you should try it first. Thank you very much. I think we have time for questions and there's a microphone at the back of the room. I'm also happy for people to just shout at me or I'll be outside in the hallway after this talk so whatever works for everyone.