"Binary Patching - Making the Switch" - Pete Rankin

we have Pete Rankin who will be giving a talk on binary patching making the switch and who is also the person who wrote the firmware for this year's about so the person that wrote that snake and Tetris game is standing up on stage right now so let's welcome Pete to the stage [Applause] Wow thank you welcome I know it's 4 o'clock but uh let's just get started Christmas 2017 I saw an ad for the Nintendo switch and I couldn't help but think I would buy that if only it was a phone and we do we ask this about a lot of different products I would get that if it could do blah but I don't think

this is the right way to look at that problem should the switch be a phone or should my phone be a switch we should not have to buy new devices in order to get access to new features and we should not have to beg companies to add features to our stuff they should already be there and we should have to borrow from a range of devices when we need to go on a plane like an e-reader or an mp3 player and when we do make our stuff work the way that we want it to we should not feel like we're stealing anything I think we should be builders we should be hackers and we should be

making devices do the things that they were never ever meant to do today's talk Oh

my tour today is on binary patching and I think that this is one of the very many tools that you can use to make your devices do the things that they were never meant to do and so I'll get stuck into it and not leave you I know it's four o'clock my name is Peter and at the moment I am working for a company called Penton that does a lot of great hardware stuff and I think a lot of my skills and my ideas have come from them and feel free to ask me questions afterwards but I'm a software developer and researcher so I'd like to think that I can write as much code as what I can reverse engineer

or understand but more importantly and I think this is the big part I'm big on retro Nintendo and gaming and emulators and I have very fond memories of long trips to places with my game boys and I hope that the nostalgia that maybe you feel with those Nokia phones brings back some of those memories of throwing your 3310 to the ground and being able to pick it up without a broken screen and yes many hours went into the firm of the badge but also their echo who did the actual badge design went through many prototypes and so kudos to him who actually came up with the nokia theme they gave me the groundwork to actually

build the firmware and also I'd like to say thank you to my partner Sarah who I love very much who supported me for the months that I spent on this for which I was not very pleasant all the time so it's about a 50 minute talk and I'm going to spend a few minutes going over the concept and then a bit of an introduction into binary patching where I talk about how I patched Android Bluetooth to fix an issue and then the talk kind of splits and goes off in a different direction because at that point I had learnt about Linux kernels and how to build them and I was looking for the next problem which is where I'll

go into trust zone interception so I hope there's something for everyone in this talk today so the concepts I saw that ad for the Nintendo switch and it looks great a console and a portable combined and with suite suite controllers they really are they've actually got little connectors at the bottom of them that work at 1.8 volts the screen is a good size good storage good processing power a great system but like many of you I have a phone why would I carry two devices and it has more power and more storage than the switch if only had buttons and this is a real problem so many devices are losing their buttons and I don't think

it'll be that long before devices have no buttons or and and no inputs all together and it's really sad because buttons are a great way to interact with products so I hacked I had this idea get just the controllers for the switch get my phone 3d design and print a case that supported it 3d CAD is very accessible and I didn't even need a 3d printer I could just send my design away and someone mailed me a piece of plastic that didn't fit the first time but to know less you know 3d printing is definitely accessible and the controllers they paired by bluetooth but it lagged it lags to the point where it was unusable you'd press a button it

would happen after about five seconds and then everything would happen so I looked around on forum after for him I tried to understand Bluetooth and it's complicated and it's hard and I don't understand all of it but if you just keep pursuing you can figure it out or you can find someone else you can help you or in this case someone else who had already figured it out open your Bluetooth default shared objects find this by pattern or replace it with this one or find this bike plan and replace it with this one and that's kind of where it gets started I have a binary patch that I want to apply so I can make my phone do the

things it was never meant to do and you don't even need a rooted or broken device to begin with if you have an Android device you can pull any binary off that phone that you want without rooting it you can use ADB and there is lots of Google tutorials about how to do that you don't need roots you don't need boot boot loader unlocked and once you've got those files you can open them up in a hex editor which is just basically word for binaries and you do a find and replace unless you can't find which is really devastating because then you're like well what do I do now but there's a better question to ask

yourself what exactly is the patch doing because we're talking about a network process something that does radio stuff is it making authentication completely disabled is it setting up a custom listening Bluetooth socket who knows so before you binary patch things try and understand it yourself first and so I went back to that forum where I found that patch and someone pointed me to this idea that it was on this SSR max latency value for Bluetooth and I can tell you now to this day I still don't fully comprehend what that feature does but Android source code is readily available and from that I was able to find the define that said it's the value 800 which is hex 320 and if you look at

this little bit of disassembly which you can get disassembled now on websites you don't even need a disassembler in your laptop and it will tell you that they're changing this 320 values 18 they are basically disabling the SSR max latency value so now that we know what it does we now need to find out where it is in our binary and for that you do need a disassembler but lucky for you as of I think a week or two ago deidre the NSA tool is available so feel free to let the NSA help you on your endeavors and so when you open up a binary like this in a disassembler there is lots and lots of

things to look at and it's very overwhelming the important thing to remember is that you would like to find something so you're looking for something that's unique something that's constant and in my case that for hex 320 value is the thing that I imagine would be unique but there was still like 1520 occurrences of it so you kind of have to iterate through it and apply a bit of understanding and then I found this spot that look like it might be right and that gave me the bike pan at the bottom which was the fine pattern for my binary and again using online tools you can take that pan disassemble it online change the value reassemble it and there

you are you have you created and ported your own binary patch it is that easy to make your devices do the things that they were never meant to do but this is kind of where some of the easy stuff starts to stop because unlike some of the earlier Android phones it is not as simple as pushing that binary back onto the phone and to kind of describe why that's the case I need to explain something about chain of trust so when you turn your phone on and you give it power there is a tiny bit of code that is baked into the chipset on your phone and it has the sole job and responsibility of verifying the

signature of the next part and I I apologize on these details are a little bit with you off you for those who do this all the time but the gist is that it verifies the next stage before executing it which then loads a primary bootloader on your Android devices and it's got a bit more space because it's not in the actual wires on your chip but again it just really verifies and loads the secondary bootloader and this this is where your phone kind of splits into two phones if you have an Android device you've got your Android with its Linux kernel and then you've got the secure world which handles all your DRM your keys your device encryption your

fingerprint scanner maybe even your facial recognition and it is this part of the boot chain that starts that and Android but for now let's focus on the Android part this is the Android bootloader that get flirted next if you've ever flashed a custom recovery or redid your phone or installed lineage or seijin mod you've used this tool to flash stuff onto your phone it's what fastboot talks to but it itself is not a Linux kernel so it loads the Linux kernel from the boot partition this is what actually does the DM Verity check on your Android system it checks that Android has not been modified and if all that is good we finally after all

that have got to the point where Android starts up your processors start and that's where our Bluetooth object that we want to patch exists and the important moral of this story is that it is verified if you change a bit in this boot chain your phone is a brick to varying degrees depending on how high up the chain you change that bit I've gotten close to this very very many times so how do people then install custom roms on their Android device well they boot load around lock and the the thing to remember about bootloader like unlocking is all you're doing is you're telling a boot to check nothing in the boot partition not the Linux

kernel not the round disk nothing boot will just get blindly loaded regardless of its state but at this point in time boot still has the code in it to check and verify the Android system so we still can't patch but that's when you can actually root your device and once you root your device this is what your phone security looks like someone who gets access to your phone can change your system petition and your boot petition and get access to anything on your device so just think about that next time you want a bootloader unlock now changing the system partition means that we're no longer eligible for updates but the routing community came up with

the solution to this a while ago and they called it system less routing and what it means is that they don't make any changes to the Android system partition they do it in the boot partition they make changes to the Linux kernel such that the Android system remains unchanged and changed and still able to receive updates so let's do that we start off with our own Linux driver that we can build for our Android and it gets to sit in the Linux kernel and from there you can see all the processes running in Android we can search those processes to find the Bluetooth one then we can search that Bluetooth process to find our shared objects as it exists in

memory and it's the same as what it is on disk for the most part and we can search that to find our bite pattern and patch it in memory from the kernel and that's pretty much it that is that is what system list means when they talk about system with root or system was patching so some useful tricks I know there's a bit of text on this slide the get user pages function is super cool from the Linux kernel you can ask for any page of any user mode process to be mapped into the kernel and with write Commission's so you can patch and change any byte in any user mo process without changing any permission on any of their

pages it's super cool and then the other thing is that you might want to read this other file system called proc Maps to find out where things are loaded in memory but if you're in the kernel you've got access to the structures and the data that's used to store that information and you can get at it directly so if you've managed to get as far as building your Linux kernel and your Linux kernel should be made available it is GPL I built my phone's Linux kernel on the windows subsystem Linux so it is totally doable you can get the source code for your phones and build it and once you've built it you get this image GZ to a DTV file and it

might vary depending on what Android or what device you're doing this for but to flash it you actually need to put it into a boot image but there's a wonderful tool called Android image kitchen that you can use the pool part of boot image into the individual parts and the only one that we care about is the Linux kernel device tree the Lynx kernel and device tree and we can replace that file once extracted with our built one and then repack that boot image and flash it onto our phone using fastboot and it is that easy to unpack and pack a boot image for your phone and this is the cool thing you can do these kind of cool things so I

actually took it a step further after eyeing that driver and wrote my own Linux kernel input driver for the joy cons and I'd never done this before but there are lots of examples and I use the previous the Wii controller example from the Linux kernel to build mine and there are so many good emulators and now I'm pretty close to having my own phone as a switch which i think is pretty cool and if you're looking at doing this sort of stuff all my code is available so I've got my driver at the top which does the kernel to user mode patching the input driver and then someone else came across long this and actually built a

better one so you can use their driver which I would recommend over my code but now I'm kind of at this point where I can build Linux kernels from my phone and I can build drivers from my phone what should my next project be well it's kind of like I'm standing this high one if I could go there and so I turned my attention to trusts own the operating system on your phone that is running that you don't even know is there so to give you a bit of background your phone is basically broken into two worlds the normal world that has your Linux kernel and your Android operating system and the trust own kernel that handles your

DRM your keys all those security related features your fingerprint scanner so what if we wrote another driver and we load it into the Linux kernel again but we're below secure world we can't see it we can't interact with it but these processes so your YouTube has to talk to the trust 'let that is actually responsible for doing DRM decoding a video your fingerprint scanner has to talk to the trust that that's actually reading and verifying your fingerprint how does this communication happen and if you had this problem with computers and you had two computers and a wire running between them you'd want to see the messages right in the middle as I go across you'd want to sniff the traffic

and the driver for Qualcomm devices is called QC Kong and it does this problem it basically allows messages to be transferred from processors to trust lats and back and forth to facilitate this but if we're in the Linux kernel we're in the same playing field and we can make binary patches to that to see what's happening and Linux source code it's a big place but you can totally find things with very little experience myself a quick find I found the source file and better yet the first function in that source file was the function I want to hook intercept messages so it is it is not that hard to find things in the links kernel and there's plenty of resources

around you that can help you out if you if you're looking to solve these kind of problems but I probably should have said it was that simple because this is where you know things get a little bit harder so I want to hook a function in a kernel what are my options you can make source code changes so you can change the source code for their driver and rebuild it because it's the Linux kernel so if this is the function you want to intercept you write your own function nearby and you just make it call your function with the same args and you've basically done a hook in source code the only problem with this method is that

what if you don't get the source code to your kernel what if it's not released for until two three years after what happens if they don't release it at all Samsung has been notorious for this in the past what happens if bootloader and locking and loading up your own kernel changes the behavior of these things that you want to observe so sometimes source code changes are not always the best option we can look for function pointers that point to our function and change them so again we have the function we want to intercept and we have a table of function pointers that will call it we can write a function that takes exactly the same args and redirect it to it the

only problem is that in my case this doesn't exist so this is no good to me either the next one is to do inline hooks where you actually change the code at the beginning of a function so again we can write our own and we put a little jump so as soon as that function gets execution we send it somewhere else but we're putting code over existing code and at the start of the function is where some interesting things happen like how the stack gets set up how registers and variables get set up so we have to read do those things before we go to our function and we tend to write small code stubs to fix the stack to fix the

registers and then ultimately call our function so it's kind of like the assembly binary form of source code cooking but this ends up being very function and kernel and version specific because every time a compiler is run maybe it up put slightly different code may be making a one-line change can cause it to think of all sorts of optimizations so this becomes very specific and that's not very useful all the time so let's think about what calls this function something else obviously has to use it for a purpose so what if we wrote our own and redirected that call to ours and as it turns out this is exactly the case there is only one other

function call in the QC comm driver that cause the function that I want to hook so let's hook that instead the only problem with this though is that these functions are private the driver the QC comm driver does not make them expose you can't look them up with Cal Simms you can't do a this function name to function pointer lookup it doesn't work but again something has to call it something public has to call it and as it turns out the first thing that this other thing does QC comm unregister listen does is it calls the one that we want and functions are just bytes so we can disassemble them on the fly and find

the instructions that are for our call and then we can work backwards to figure out where that addresses and so now we can mine private functions from public ones and so now you can find all the other API is dynamically in the links kernel that weren't there before and you're going to get a lot of crashes I'm surprised my phone actually still works after this point because changing bytes there is so much more to it but to show you the problems that I encountered my colonel for my phone is compiled to be read only there's a flag at compile time called config debug read-only data and with that enabled the kernel code is read-only and that's where the driver

that I want to patch is so we can't change it so what if I recompiled my kernel without this flag well the problem with that is that then everything can catch my my kernel so malware that gets on to your phone can actually rootkit your device and we don't want that but this is kind of roughly what it looks like after it after this is done so that there is literally only read write there was no readwrite access for any part of the kernel but I thought about like what replies these protections and it turns out mark read-only data are ro is what gets call to apply these up in these protections and inside of it are two

functions create mapping light and their job is to take the kernel and change it from readwrite X to read-only X but these are private functions inside a public function and so we can actually line those addresses so we take the mark read-only data disassembly and we find what we think is that creep mapping light and we do the same technique and we get the address and we call it and we get a crash but it turns out that compilers are very smart and they like to optimize code as much as possible and so instead of this call being crack mapping lights it ended up being the function for layers deeper in the code and it literally just inline them and

this bothered me for weeks and I got to the point where I was struggling and I call on the help of a friend a friend of mine called Brad who came over and we kind of worked this problem together you don't have to be an expert yourself you can always reach out to others to help you when you get stuck and so with this on a read on the colonel you can make it read right patch and read only and this works for all Android kernels that I think it works for all Android kernels with the exception of Samsung that protects those permissions using a hypervisor using its Knox but just remember this all I'm

doing is changing a flag in the kernel the kernel is on your boot image and if you've bootloader unlocked what stops some other piece of malware going in and flipping that bit there and turning read/write/execute back on or adding code to your kernel these are the risks that you take when you bootloader unlock your phone so now we're back at the problem where we actually want to hook we want to intercept messages and the problem is I'm still getting crashes because where this function is the qce SCM call is actually located too far away from my driver in address space so I actually need to do an absolute call in order to be able to reach it but

backwards compatibility is your friend because that is SCM arm v8 call that's just checking whether you've got a 32-bit or 64-bit phone which means that one of those code paths is never used on your device and we can use this to our advantage when we want to hook so we're going to take the disassembly of that function that we found we found the call to get architecture to check whether it's a 32-bit or a 64-bit phone it's then going to split whether it is the 32-bit or 64-bit phone it's going to call the actual function that will send the message in the data across to secure world and trustzone which leaves these bytes here completely

unused and because we've got this ability to change the channel to read/write X we can use them so we're going to set up a very small call stub inside that we're going to have the absolute address of our function where we're going to intercept all calls to we're going to load it into a register and call that address and then we're going to branch back to the original function and at this point we're set up a hook stub a way to basically go from a relative address call to an absolute address call to redirect flow of execution to anywhere in the kernel and in this case we're redirecting it to our driver so we can see what's going on and

then to turn it on we'll just patch that call to jump into our stub and we have now seen every single request for a trust zone for secure world for trust let's for loading for unloading of trust let's all of that stuff we can now see our function will always get called first and with that capability you can do all sorts of kind of crazy stuff you could build your own firewall for trust let's so you could say I don't want to load wide vine so when I see loads for Widevine DRM I'm just going to drop them you can then see malicious activity you can use it for protocol analysis to kind of understand how you talk to trust

let's in order to create better fuzzing rigs and so with the ability to intercept I thought how great would it be if I could treat a trust 'let like a Linux driver and to do this I need to be able to get access to some extra information the trust zone does not tell you what's loaded it does not tell you what trust lets have been loaded but the QC comm driver it keeps a list so let's find that list in the driver which again it's private we can't see it but some function has to use it that's public it turns out QC compro does a lot of initialization and so we can mind that function for the address of that

structure that contains the list of all the things that are loaded and so we've got our probe function and one of the first thing it does is it loads up the page address who where that structure is and then it adds to that address the offset in that page and it's a arm arm 64 does this with two instructions and this is a problem because you can't guarantee the compiler is going to put them next to each other there could be all sorts of stuff in between but we can do this easier we don't have to find that add that offset if we know some magic values in that structure we can search for those in the

page and it's very similar to the way that in the Android Bluetooth case I looked for the magic value of 320 in the disassembly so we're going to look for the two version numbers in that structure located next to each other because I can know ahead of her time what the version is and when I find that spot I also know the shape of the structure because I've got the Linux source code and I can subtract its offset to get the address of that structure in memory and this is really cool at this point because that structure has all the state for everything happening between android and secure world and so from this we can now

set up our own calls to unload a trust let we can also load a trusted in memory and the way that trusts let's get loaded into secure world is using this thing called ion an ion is a Linux device driver sorry a Linux driver that's responsible for allocating large chunks of memory and it can align it can allocate those chunks of memory physically one after the other in physical memory and this is important because the only thing that's common between normal world and secure world is physical addresses and so with the eye on handle that we can get because we've got that structure we can allocate memory that will work perfectly for trust zone and then we can put our own trust lit

image in memory into that buffer and send the advisee khalad rs.2 trust zone and if it loads we get back and identify our a 32b identifier and so what I'm going to do now is going to kind of show you this driver that I wrote to do this which I call danger zone so I'm going to just quickly cut over to Rory

No oh wow this is gonna be fun all right so I've just plugged my phone in and I can connect to my phone using ADB and I can go to route where I've got permissions to see load and unload Linux drivers so there's my joke on drivers as they load in memory but now we want to actually load our dangerzone driver

I knew I knew someone was gonna say that let's see if I can do this who this he's using the big screen like this is great that'd be better I'll leave it like this because in a second you'll see why okay cool so dangerous

Oh trust me not to spell stuff properly in a live demo you know cool oh yeah so the drive is loaded so at the moment we are now intercepting Qualcomm calls so what can I do for you today well it turns out that if I just bring up my rock K Maciej I can see a log in my device and my function hook at the moment just basically logs our system calls so if I turn off my phone and then I try and run my finger over the fingerprint scanner you'll see a whole bunch of messages swimming by as it tries to talk to the fingerprint trust 'let insecure lot on my phone and I can

see the application in Android and its process ID and I can see the trust that that is talking to and I can see all the messages that they're sending between them now this might obviously not work if it's encrypted because then these might be encrypted buffers but you can see it which means you can dissect it so you can analyze it and then you can reverse-engineer it and fuzz it and potentially exploit it but you might also want as part of this stability to low trust let's so first my driver which is comes up under dev dezzy you can see the list of loaded trusts let's and we can actually load them as well and so

for this I'm going to use Silvio as an example because as it turns out you can load trustless under whatever name you like so I'm going to send Silvio to the danger zone

so all your trust lets or at least a lot of them are located under vendor firmware Widevine is like Google's DRM encryption trust let

there we are we've just floated a truss let that easy just like a driver and you can load any trust lit but what's interesting is that if I try to load Widevine under a different name now it would fail so trust zone is keeping some kind of list of trusts lots that are loaded and because I've loaded this one as sylvio applications my phone that now want Widevine kind of she load it so I've actually dust my phone from being able to do DRM at the moment so maybe what we can do is we can unload silver we'll get Silvio out of the danger zone

and it's back to the way it was and if we look at look at prop Kane message they can see the one above there which is our juicy comm app shutdown command so we can even see our loads and unload because we're hooked so high up in the kernel okay and so with that that kind of concludes my talk and all my code is available on my get lab page including the danger zone driver that's my twitter handle but if you want to contact me I would recommend emailing me if you have questions because I'm not I'm not a very competent Twitter user yet but yes if there are any questions I'm happy to answer I can't actually see anyone and

see what is coming up to give me a hand do we have Mike runners just up the front

okay I'll repeat the question

okay so the question is do trust let's need signing before they'll be allowed to be loaded by the trusting and my understanding is that yes the trust zone itself checks the signatures of trust that's before they're loaded however I think depending on the implementation and the version and the age of your phone the whether it actually has a white list and a black list of bad trust 'lets that have been proven to be vulnerable can vary so depending on your device you might have a signed trust that with a vulnerability that can actually still be loaded so yes they do need to be signed in order to be loaded although maybe this might help people

fuzz that and actually see if there's any issues in that area any more questions so I'm just wondering can this technique be used to extract device encryption keys that are used for like full device encryption etc okay can this be used to extract device encryption keys so for those who aren't aware device encryption keys are very very special values that are kept secure and locked down inside the secured world they're the things that are back all your encryption including your full disk encryption on your Android devices for example in theory they should not be made available to anywhere outside their trust let let alone anywhere in the normal world in the Linux kernel but phones are built by

a wide variety of manufacturers and I would not be surprised if you know someone conducting research in this space actually found some terrible phone that leaked a device key so the answer is no it shouldn't be possible but people in general including myself are terrible programmers any more questions

so let's think pate for a great talk [Applause]