Bypassing Huawei's Fingerprint Authentication by Exploiting the TrustZone

besides DC would like to thank all of our sponsors and a special thank you to all of our speakers volunteers and organizers for making 2018 a success hello my name is Nick Stevens is it okay sorry so my name is Nick I'll be talking about Huawei's fingerprint on the vacation but mostly their trusted implementation if you don't know what trisomy is I'm going to go over all of that this talks mostly going to be about memory corruption bugs and how to exploit them in huawei products unless so about like a biometric bypass which you might expect for the title of the talk so the goal of this talk is to completely for find a chain of memory

corruption bugs in Huawei's trust in architecture to completely compromise the phone and then disable the fingerprint sensor so a little bit about myself before we talk really get started I play on the shelf for CTF team if you don't know what CTF is it stands for capture the flag it's a sort of simulated hacking exercise where teams compete against each other to break into each other's computers most of times involves like fake pieces of software so organizers will write up a bunch of fake code or about just fake like email servers or web servers and it's up to the players of the game to find bugs and then write exploits for those and typically our memory corruption bugs

we're clipped their bugs so it's mostly the application security auditing skills at play here so other things I've done is I worked on the cyber grant challenge so that was an automated CTF competition we put on my DARPA I've also published above research papers on topics like automated exploitation and automated bug finding and then I've also done some research on the trust so we're gonna talk today and I've also published papers on so general just played a lot of CTF which is one of the ways I was able to you know acquire the background necessary to do this kind of research and another thing is I actually worked clearly for Raytheon CSI as a vulnerability researcher so if after

this talk if you decide this is something that you would like to do as a job feel free to talk to me afterwards we're always hiring and this is the kind of thing I do every day so down to the actual park the goal is to completely compromise the huawei p9 and they have it actually right here I'll be demonstrating the exploit on later so we want to go from an untrusted app which is an Android sandbox selinux context which essentially is any app that you have on your phone that you download from the Play Store and you give no permissions to that's going to become an untrusted app so all the default apps on your

phone or the apps that you're downloading are all considered to be untrusted and they're put into a sandbox that limits what they can do so we're gonna go from that position and we're gonna completely compromise something known as the tea twee this stands for the trusted execution environment and this is actually sort of a more recent and non-traditional security layer that is actually seen a lot of Android phones now I'm gonna be talking more about exactly what that is and then once we're in this trust the most trusted layer of execution or the most trusted ring we're going to completely disable the fingerprint sensor which executes in this context so if you're unfamiliar with the trust zone it sort of divides

from add some new trust boundaries actually to the security architecture so if you've taken an OS class you might be familiar with you know the difference between user land and kernel that's sort of the most typical trust boundary and in this case and like on your desktop computer if you compromise your Linux kernel or your Windows kernel you've completely owned the machine you have all the permissions to do anything you want you can escalate your privileges arbitrarily but on a Android phone or on a phone running on an ARM chip you have the ability to enable something called the trust zone which is where like a shadow world which adds another layer of permission boundaries so you have

another kernel called the TOS and you have another set of trusted applications which all exist outside of the scope of the kernel so the T is the most privileged layer here and it has the permission to read anything within the Android world on the left the green side but the and rule does not permission to read anything in the blue world the tea world so just to break down with some examples of things you see these different permission levels and the most at the lowest level and userland you have things like chrome your browser you have all your applications then you have your kernel Android which resembles Linux with a couple of different lines added for like

networking permissions and then you have this tea with the trusted apps these don't have names you will be familiar with these applications but they do things like handle secure storage secure secure payment there's something called the trusted UI in huawei's case I don't actually know what that does I think that's something to do with the pin and then you also need another kernel to support these applications because they want to do things like that memory and perform i pc so you have all these different layers so to begin really or to to start exploiting a trust and a per take complete control of it we're gonna go through and individually compromise every single layers starting at usual

end so we're going to be exploiting bugs in some I'm always Android kernel which is Linux so there's actually a kernel module particulars I'll be exploiting then once we have root on the phone so that first stage in green that sort of like rooting an Android phone once we have root we're going to escalate into the tea so we're going to take over one of the trusted applications that we can find bugs in now once we've done that we still actually done a complete control over the tea so just to clarify while the tea has Google permission then the Android world the green world or the normal world we still need to get trusted kernel code execution to

completely read out physical memory and modify anything at will so we're gonna need to find a bug in the trusted OS once we found a bug in the trusted app so each one of these stages is going to be a memory comforting bug that we exploit that I'm going to be going over how we topple each stage so before I get started on the actual bugs and how the trust zone architecture of Huawei works I am a sample here where I'm already assumed that I'm executing code on the device and this is really a fair sumption for an attacker so a more realistic shade might be getting code execution in the web browser like Chrome

people find bugs all the time in web browsers and then from there you would begin executing a payload which does this chain so this is all possible to do remotely as well you just need a couple more bugs in one of your user land applications so a little bit about who is making these trust zones so as I mentioned before the trust zone is actually an armed technology so it's something that comes on your your SOC your stocking on a chip but it's it is part of the arm spec but every single chip manufacturer isn't putting their own trust zone so some of the two manufactures that you have larger for Qualcomm which is for the most common in

the United States but Huawei has their own shoe manufacturer known as high silicon which is Chinese it's also mochi this is probably good time to mention what one way is if people aren't familiar Huawei is a Chinese phone manufacturer they also make networking gear I'm sorry I actually skipped over this part because I just been using it for so long but they're not actually very common in the United States because they've lot of difficulty getting into the US market because they're blocked by like Congress it's not easy for them to sell merchandise here but they're actually really common of course in China but also in Europe and other parts of South America so Huawei is this very

popular cheap device that you don't see in the US but they have all their own stuff to support this so while they use arm which is a you know the type of processor which almost all Android phones use they do they're not using Qualcomm technology although some of their phones do they're using their own in-house high silicon and another thing that makes the T interesting is that unlike the rest of Android which is sort of forced to be open source in some aspects the trust is not there's no obligation for a while way to publish the source code for any other trust owns this is all things you have to reverse engineer off the phone now luckily for

the first Sager bug they are forced to open source search their kernel modules so we can do source code auditing for the first stage but after that once we want to mix begin exploring the trusted apps and the trusted OS we're in reverse engineering so how does a normal Android app actually talk to the trust zone on huawei actually kind of a complicated song-and-dance it has we have to go through to to start sending messages to things like the secure storage trust lit now one of the reasons this is this we have this complicated outlook I'm gonna be going through each stage is that the trust lists themselves actually want to do permission checking but because of

the strange divide between the normal world and the secure world the Trust's themselves have no insight into the permissions of the normal world so all your you IDs and your SEO Linux labels those August and the Android kernel and the trust note has no idea that the system exists so we need a way of communicating that between the two worlds now to make matters more complicated the instruction that we use on arm to actually send up payloads and buffers and arguments and commands to the trust lists is a privilege instruction so are actually introduced this instruction called SMC so you should see in the middle bar I believe this stands for secure monitor call this is actually call that will

interrupt the trusted world and it will allow the trusted world to take out any arguments in a register and memory and begin passing those off the trust loads so to do this while we introduces our own kernel driver there's a number of bugs in there but the problem with the kernel driver is also it's not easy for the kernel driver to get the look up all this information about particular apps or at least one we found that there was an easy for them to look up information about particular apps making requests so they introduced this T connection daemon which will actually do the permission checking's for us so this is a user live component that's listening on a UNIX

domain socket T CD and it's going to be taking requests from our Android apps and it will be deciding Sandra Rapp is worthy and then serializing a credential structure sitting then off to the kernel driver and don't be the responsibility the kernel driver to send it off to all the trust 'lets that want to do permission checking themselves so our interrupts don't have direct permission to talk to the kernel driver so it can't just open dev you know TZ driver it has to talk to TC D and if t CD deems the app worthy and will open up the driver it's going to take that file descriptor and then once you send the file descriptor to or Android app using the

UNIX domain sockets so if you didn't know this is actually kind of a cool plastic thing you can actually send file descriptors over UNIX domain sockets so once GCD has open you know has that file descriptor it can wrap it up and pass it to our Android app and now Android have app has a new file descriptor in its process and it can use it to communicate to the kernel driver which is known as TC NS client and once we have that we can begin directly sending Lionel's to the driver and the independent one I out don't we said there's one this you know essentially called issue trust zone command the programmer will go off it will execute

an SMC to the trust let's and then the SMC is well it's going to actually go to the trusted core the trusted coercing in a dispatcher to a trust list and then the trust will begin making their own system calls to the trusted core as a need be like formatting memory and so forth so you have all these sort of different you know parameters being passed around and crossing across boundaries here so we're gonna begin getting through the bugs now so the very first step is targeting the trust zone driver so it turns out that on Huawei you can actually sort of authenticate to the trusted driver without a group having permissions to talk to any

particular trust little app and you can still send commands to something known as the global task so here I have a number of different things that the trusted driver is responsible for like logging in the app which have already kind of mentioned and proxying the calls but some mostly interesting about of this is that trust the trusted driver also has to handle the serialization of all these from parameters were going to send up so our trusses are going to be expecting different kinds of arguments in the forms of memory references and integers now that mortgages references are kind of interesting because the way we pass amount of data up to the trust zone is by actually just passing them literal

pages of information so we pass up these buffers I'm going to be going over why that is and it's too vulnerable here that we're going to exploit from an Android app to route the phone and take over the kernel driver now as I've already mentioned these two worlds and old and the secure world don't actually have a lot in common the only thing that they do have a common in one way they can they can sort of communicate with one each other using this from a shared language is through the physical addresses that they both know about so the trusted core has a one-to-one virtual address space it's map it's the physical address space so what this

means is that all the virtual addresses that the trusted course see the values of those addresses are the exact same values as their corresponding physical addresses now the your Linux kernel in the Android kernel and user land this is in the case the virtual addresses themselves are not the same value as the physical address page that they correspond to but the kernel doesn't permissions to look up what the physical address values are of those of those virtual pages so what the normal rule is going to do to pass up pages to the trusted core and it's going to find the memory reference and it's interested in so Sam user line app that wants to pass up a buffer to

the trust lit and what it's going to do is it's going to look up the physical page address of that buffer and it's going to pass that to the trusted core the trust of course going to say I know exactly what you're talking about I know physical addresses as well and then it's going to take that physical address it's gonna map it in to the destination trust its address space now this also becomes tricky because the destination trust loads this in their own address space as well with a SLR so just like your kernel and you usually the apps in the normal world your destination trust let's also are operating on virtual addresses that they

don't know the physical addresses for so you need this middleman the trusted core to take the physical addresses and convert them on both sides well excuse me the rhythm on one side the normal world kernel is going to handle converting them on its side before passing them to the trusted core so this introduces some issue in particular this means they actually have to handle converting the virtual dresses we pass in into physical addresses now the very first bug that we see is in this functionality now if we want to pass up a buffer to the trust lit what we need to do is actually register mappings with the kernel or with the trust own kernel

driver the way my way it's nice to handle this is they implement a version of a map so if you're unfamiliar with the map system : Linux essentially just allows you to allocate a new page or a number of pages in your process so your heap and your stack all under the hood are using M map so they'll MF in this new page using the file descriptor of the trusted driver and once they see that MF call occur they say ok I'm now aware of this page I'm gonna add it to my list of known trip memory pages and now what's it about this page will allow any userland apps to make requests referencing this page and they can they

can pass up an offset into this page of where they want the information to begin so as you can see if you've been looking at this code they're entering over this linked list and then they make it sure that the length that we're passing in is less than the actual page or less an actual obscure memory region that we registered with but then one thing that they don't check is they do share mem cruel adder plus client program memory if off said they never checked the member of offset so we can arbitrarily specify this now what this means is we can actually go completely out of bounds of the page that we allocated and we can

go point to another physical page now this will actually be interesting if this was just some page are usually in process because we just be specifying a page further down using a memory but it's actually using the kernel address that corresponds to the user land address and it's adding to that and then converting that to a physical page so this allows us to do is actually specify an arbitrary physical address and pass it up to the trusted core now one might see this can become an issue because if we could pass about an arbitrary physical address of the trusted core and the secure world has no idea about the different kinds of permissions in the

normal world the trusted core might be getting writing to a physical page that belongs to the kernel and not to user lands so we can essentially use like a confused deputy attack where the trusted core has more permissions in the kernel itself but still wants to maintain Commission boundaries of another world unfortunately there's no way to do that so it can right through a physical page it doesn't belong to the app were just making the request so this allows us to essentially in some ways get an arbitrary write into the kernel now we need functionality in the trust and that will write to the physical Patriot ass up and I'll show that later but another thing we need in

kernel exploitation is a leak so as I mentioned before they have their own mmm who mutation so if you've ever done kernel and external auditing before little driver on earthing particular you'll know they have this structure where they implemented a number of different operations such as open and I octal and they can also automate and map if you're unfamiliar with this this is just a mechanism where the driver could essentially override a bunch of operations and implement their own versions of things like our alpha land end map so as you can see they move under there you mentioned a couple of times and now all this does is get a number of pages register is that list like I talked

about and then it will map the virtual address that we've requested to the pages that got with get free pages now this is kind of tricky because a lot of the M map system is actually already handled by Linux proper or the kernel itself and the mmm that we implement only has the ability to do a couple of different things pretty much only handle residual data that occurs because of the mm so Linux is going to be choosing the address that it wants the user and process the places page at and typically it also allocates memory already so while way is completely just throwing it away so as you can see though we will add this thing to the linked list now

this gets really interesting when they want to unmapped something so something that a naive kernel driver developer might not know about is that while you could implement a map you can't implement the inverse operation mud map so you can't actually implement operation that will mud map that area or completely get rid of the area in your address space or clean it up so to handle this they actually implemented a new I octal handler called TC NS client I octal shared memory release and what this does is it completely just unlinks a shared memory from the linked list now that might seem okay because it will unlink it from the linked list and free the physical pages associated with it

but since this isn't going through mud map what actually occurs is you have this issue where the the underlying or the virtual the virtual address doesn't actually correspond to the physical pages which were just freed so what this introduces is actually a dangling page in our username process so what will occur is we'll have a virtual address resilient process which was never cleaned up because we're going through my octal and not mud map and we'll have that virtual address pointing to a physical page so our page table will never actually be cleaned up and point to musical page at the kernel considers free and this causes all sorts of issues the colonel thinks this page is free but

our Uslan process can still actually read and write to that page so this is a number of consequences so if another process for example once not have mapped something and needs a physical page from the colonel the Chrome's gonna say oh I have a free page right here it's going to give you the exact same page to the user land process that our user loan process has or the crude oil also use a physical page to allocate colonel data structures which are incredibly sensitive if you've been over a colonel data structure as a user lamb process you've also kind of owned the colonel so this dangling bug is the number of repercussions we can actually use it to

get a leak by spraying and so therefore colonel opera are using operations that allocate colonel data structures so with these two primitives what we're going to want to do is get code execution obviously now the way we're going to get code execution and this is just one way of doing this if you're familiar with Linux kernel expectation there's hundreds of ways to do this and maybe even better ways I chose to actually just overwrite the file operations pointer of a file so the way files work in Linux is you have a file descriptor which I'm trimmin even more familiar with but this file descriptor is just an integer it's very opaque so this actually correlates to a kernel

structure which is the final kernel structure which has every all the metadata associated with that file so just as the permissions of the file it's offset but it also has this function pointed table which is used to override the operations that we do on that file so people who are familiar with Linux may also know that one of the great things about it is that a final scripture can represent many different kinds of objects can represent like just a file on disk you can represent a network socket represent a kernel driver the way all this is handled is by using this function pointer table to override the functionalities different operations so in this example we have a legitimate

table the ext4 table which is a file format on linux and that corresponds to all these legitimate operations now we want to point that final operation support your table into userland where we can control the use that table and extra points different Rob gadgets Rob is if you're unfamiliar is a technique used to bypass something known as n X where we can't actually introduce code into the kernel or P X N and we use it essentially be able to recycle the functionality that's in the code in the kernel to carry out our wishes so in this case we can overwrite the functionality of the Rob I octal to instead store the very first argument into the address of the second

argument and then returns this is an arbitrary right gadget or we can find a rope gadget that will read out from the very first argument the value that address and then return that as a value so now if we wanted to do element or read we can call L seek with our file descriptor that corresponds to the file structure that we overrode and we give to L seek as the first argument the address of the kernel value we want our the kernel address we want to read from and then L seek will return the value that it read has its return value so we use our return value as the contents of the week so to actually redirect the ops

table we find this functionality and the trustzone kernel that anyone can execute and this is a very basic command where essentially we can ask if our trust lit is loaded so another thing I haven't mentioned yet is that all the trusts are identified by a UUID so while there aren't that many trusts let's eat rustle it goes by a UUID which is i think it's a 32 bytes value might be 16 bytes I'm not sure I forget but it uses this to individually identify the different trust let's so we can query essentially if we need to load a trust little work for us it's already loaded and the way this works is we pass up a buffer to our

trust own kernel and we say this buffer points to UID string can you make sure it doesn't exist in the currently list of loaded you IDs once it does that check so we can kind of see it here it takes per m so size and then takes so this makes it looks like it like it's actually 16 bytes so it loads the value on the UID onto the stack it is call this function trust it needs loading and then depending on if it needs loading so it does the alerting if it doesn't exist and we put that to the eight and then it will write that boolean value into the very first part of that buffer so now you can see if we

have a physical page specified we can essentially write a boolean true or false to any physical page in memory now because we're gonna be pointing this at a random piece of kernel data which isn't going to have memory contents we control because we're going to be pointing to something we want to overwrite that's something we already have control of this is always always return true because we're gonna be pointing at something like an F off staple is just say this F ops table is a UUID which doesn't get sportin correspond to anything I know about I'm gonna say yes you need to load whatever your UID value this corresponds to so this essentially allows us to write a

32-bit one to anywhere in memory so to take advantage of this we're gonna find an F ops table so we use our mud map leak to find the address of F ops table and then or a kernel a file structure which points to an F ops table and then we're gonna overwrite that value slowly with our boolean so what we can do is we can start pointing slowly point this ext4 file operations tables is the legitimate value by issuing the write a number of times we can essentially shrink it by sliding this one over and issuing multiple writes to get this into an address which corresponds to userland so as you can see after about three

different writes we give this to a very small address which will exist in a user land process and not into the kernel and now in our own process we can and map this region and we can control file operations table pointer and we have code execution in the kernel now I hope you're not bored by how pedantic this talk is because it's about to get a lot more member kupshur bugs this is only the first step so we now have root so have Hameroff table and we have the reading right like I mentioned so we can actually with this we can overwrite the credential structure inside the kernel and essentially change all of our UI DS

which correspond to our apps UI DS to zero and that makes us root so once we do that we were actually able to completely control all the permission checking that I mentioned before that occurs in the the kernel driver so when we were just a normal user LANAP in fact we were just an attacker app we didn't have the ability to talk to arbitrary trust votes we were only able to talk to this one small piece of functionality which essentially queried if a you idea was was loaded and we got fairly lucky that allowed us to do a write but there weren't a lot of bugs in that attack surface besides what I mentioned which

isn't really a bug it's just a bug in the actual page serialization so now that we are route you can Forge our identity to the trusted core and we can become any app we want in his eyes so we can talk to any trust lit now in this case to find a bug I decided to target a secure file storage but this application does is it allows you to transparently encrypt files on disk so Huawei has an app called files it's just a basic file manager and I'm sure many people people will be familiar with on their phone but they have a feature known as the safe and it allows you to put in the pin and

that pin will be used to encrypt any files you put into the safe now the decides implement this in trust so so theoretically if an attacker reads your phone they would be unable to access any files that you encrypted using the safe so this seems pretty cool the curl'd is no idea what the key is it should definitions I didn't look in to if there was any week but of course if there are bugs in the Heinicke application an attacker can take control that highest ACT are the secure storage trust which does the encryption and knows that keys they can completely around all this and reveal of those files but for us all we're really interested in in is getting

a foothold inside the secure world so that we can then attack the trusted kernel and then find the average corresponds to the fingerprint so we're going to be targeting in this trust lit type to debug which I'm if you don't know what type confusion is it will become pretty clear in a second how this is a problem so what's for the curl driver all we have to do is send the SMC which has our attack of our attacker payload in it and begin exploring this Trussell in now a little more about the serialization of the kernel arguments so there's a lot of bugs with this functionality and if you're auditing any surface I definitely recommend looking at the any sorts of

serialization you see there's always lots of bugs in it so in this case as I mentioned before we have the ability to specify memory references or integers now the way this is handled is your trust zone kernel is going to actually pass up this tag TT and its operation pointer or pointer to the structure which can handle up to four different parameters now because we have the ability to pass some integers or memory references a simple type checking system needs to be in place now this is actually pretty easy but they do is they have as you can see they have the structure on the right it has space for exactly four and then they have an

integer which specifies the type of every single one of those parameters so if we have a memory reference type and our very first parameter the most significant byte upper am types will be one if we have a integer type in our second parameter the second most significant byte will be 0 for example so all this type information is stored into this and its operation structure and now it's the responsibility of the trust lid to check the types before it begins acting on them so if you have buffer argument confused with an integer argument that can be pretty bad because it means that any address that we put into a an integer can be any value can

be confused as an address and this means to cause havoc so now getting into the actual parameters checking is it turns out that not all trust let's actually check these so I guess there was some kind of miscommunication between the Trussell developers and the kernel driver developers and they didn't know the system worked now our secure storage trust lit actually influenced a long different functionality that you expect to see in linux it has a read and write call also has an open which returns a opaque handle just a blend external it has an L seek now we have is an interesting bug as you can see right here where we take the parameter values out of the

structure but no check has ever performed before treating them actually it has a buffer in a size so we can specify an A and B instead of a buffer and a size and this allows us to specify any address in the trust let's address space that is a pretty big problem sorry guys it's a pretty big problem because if you can imagine a Lynx kernel which doesn't check the buffer argument and never make sure that the buffer argument that you're passing up to read or to write actually poison the user lid and not the kernel you just initiate the same situation where you can arbitrarily read data into the kernels memory space so with this primitive we can actually

get both a leak and a right inside the trust lid so we can use writes to read values out and we can use read to write values in so what we're going to do is we're going to write to a fake secured file and we're going to write the value into that file that we want to actually do the memory right on and then we want to write that value into the memory heat of the trust lid we're going to read from that file and the value that is read out will be written to an arbitrary address inside the trust lit and that won't get us going execution and I'll show you how so the one issue here is

all that we have arbitrary right we still need to point to an arbitrary payload of code this be kind of tricky because there's lots of different paid for missions going on we don't have really any insight into the trust let's this isn't like a standard elf binary so we don't actually know what it looks like in memory so this was a lot of painful experimentation on my part but it turns out that the address space of a trust that kind of looks like this so at the lower addresses we have the text section which is all of our code then we have the BSS which is like our global and then interestingly enough we have

the kernel mapped and of course the transyl's came right to this kernel but it's mapped into the same virtual address space as the trust lit just like how the list kernels happen to the same virtual address space as usual in apps it's sort of mapped in the middle of its address to actually address see zero zero zero zero zero zero zero and then above that kernel we actually have old the past two memory references that are remap into the Trussell address space so when I pass in a buffer to a trust let with it actually is occurring as it takes the trusted work takes a physical page and it adds a new page table entry

to the trust lit and is saying your buffer arguments are actually this really high address and everything at this page and at this address is readable writable and executable so what this means that as soon as we overwrite a function pointer inside of our or BSS we can pass in a shellcode as one of the parameters to our trust lit and that will just be waiting for us to execute so this gives us sort of a nice primitive where we can pass in our in our first argument as the file descriptor value or second argument as the address that we want to write to and then our third argument it can actually be just an address of our shellcode that

we can jump to so by overwriting one of the function pointers inside T malloc so their implementation of malloc uses a function pointer table they handle different classes of size objects I this is just a coincidence of their implementation it's just circumstances I just took advantage of that to to get code execution so I hate something that instead now calls my shellcode instead of calling the allocation function and we get code execution now there's actually one small problem still the trust notes I actually have a SLR so if you're familiar with a SLR the stands for address space layout randomization this is a fairly old technology used to make an attackers life more difficult by

allocating sort of code in the stack and piece of data and random addresses so if you do smash the stack and you get code execution you don't know where to point or hijack PC value tube because you don't know where anything is in memory so if the address space layout is completely random it makes it attacker site more difficult because although we might be able to overwrite a function pointer we don't know where to point that to because we don't know where a shellcode is or in this case we don't actually know where the function pointer is so we don't know where it right to it so here's the actual code inside Huawei which generates a random value and then

uses this to map in trust lit now they have this they do this thing where they actually only implement one byte of entropy here so that makes it fairly easy to practice implementation of a SLR because it means there's only 256 different places that the trust Allah could be loaded so you can imagine a number of ways that you could they attack this the Trust's also are constantly it's a very robust systems to trustless as soon as they crash or immediately reloads that have the same address so you could very easily just try to exploit this 256 times with different addresses and eventually we would make the correct guess and we would know the address of the function

pointer but the problem gets even worse because all the information is actually just revealed in log files so strangely enough information about the trusted world is leaked to the normal world via the file system so it completely defeats this you know mechanism this security mitigation because if we can just crash it once and will log out the address that the trust was loaded to and we don't need to make guess 256 times which would be trivial we see the guests once fail and they guess again because we know the address so this gets this code execution into the trust live now we have trusted execution and we're on to the final summation I'm sure everyone's

at the edge of their seats right now is getting very exciting but we have the trust of kernel which implements all these different mechanisms inside the inside of the trust of the world that the trust widths themselves used to operate normally like apps so they can map and marine like I've said before they provide IPC do everything you'd expect a curl has to do for an application of function so this trusted core has written one big one err ability that you might suspect that's used executing system calls or issuing system call set trusted core and that is that there is absolutely no employer Tannen's nation whatsoever so if you imagine a linux kernel that never

Santas any in the pointers you pass in that'd be a giant issue if you aren't familiar with this the linux kernel has to go through any pointers so oftentimes in user land we need to specify some kind of buffer arguments or some kind of structure that the kernel operate on such as like a stat buffer to say we want the kernel to tell us how big a file is we need to pass in a buffer which says all the information about the file you have right into this buffer now an attacker might think why don't I point this buffer into the kernels address space and have the kernel write to itself this is a giant class of bugs

and kill a long time ago this is all is handled because the kernel is able to check and very easily differentiate between you land addresses and kernel and addresses and this security boundary or this check this doesn't actually exist in the Huawei trust zone kernel so if I pass them an address even if it doesn't belong to my trustless address space the trusted core has no idea who this belongs to de souza belongs to user language may not be the case in and will just right there so this allows us to very easily take over the trusted core now strangely enough the trusted core actually has hundreds of system calls so we defined a sequence of system calls

that give us an arbitrary right we don't actually need to reverse-engineer the entire thing and determine what exactly system poles are you doing now a little bit about the environment or that we're attacking there is noise Solara so we know exactly where the kernel is mapped inside the trusted world I guess it'll be called Kay SOR which is another thing where the kernel has an interest space layout randomization applying to it there is pxn the stands will page execute never if you're familiar with x86 the same thing is called SMA P or SMAP which is supervisor mode SMAP supervisor mode execution prevention so this means that our kernel will not execute code that exists in userland

there is no pan which is for page access than ever so the kernel can access Uslan memory arbitrarily if you do have had it makes your life more difficult we have to go through a gate whenever you want to access something in user land so our return pieces of code are typically going to go through this gate so if you're able to crop the pointer inside the kernel and pointed into user land it's going the kernel is going to panic instead of actually trusting your reference so the other thing which is interesting is there's no DEP data execution prevention also known as like right X or X or any region which is writable should not also be executable

this is not enforced so the cruel heap is actually executable in this case and there's also like I mentioned hundreds of system calls in fact there's about 300 and some of our behind permission checks and there I have no idea why a kernel which supports nine different hard-coded applications or like nine or six hard-coded applications needs to support so many different system calls it might an something to do with wha wage is stealing this kernel from somebody else I don't know would not surprise me but they have hundreds of system calls so it was a lot of things that we can attack and find functionality in so this is the most pedantic slide so I apologize but

there's nothing which actually just writes our first argument the second argument or vice versa or the first argument so it be CREB one step system call which just says I have this value I want to write to this address or and it would perform it but said we need to go through this and this sort of dance and find number different system calls that once we combine them get us our rhetoric out execution so all these bugs in fact the fruits for have to do with the actual pointer assassination problem of course there are other little more legitimate bugs inside the kernel so there is an integer overflow which we can use to read arbitrary addresses I'm

not going to go over this right now because I'm about ten minutes left but if the sides will be online so you can check out later but essentially we're able to combine all these small gadgets of functionality and make it into a rubber tree right and we can essentially allocate a buffer inside of our trusted core kernel user arbitrary right to write the shellcode contents through that buffer and then overwrite a function pointer inside of our trusted core they gain count execution now we've completely owned the phone now but there's still another issue which is I actually have no idea where the fingerprint authentication stuff is now if you take the trust zone like image

bundle which is flashing to the phone and you take it apart so they have a custom format which is pretty easy to reverse inside of this disk you only get out a number of different elf files which are your trust lets you have something called the key mister which handles crypto services you have your sex storage you have something known as a gatekeeper but there's nothing in there which looks like fingerprint checking and everything there's also pretty small your biggest files 105k fingerprint recognition logic which sort of can finally tell the fingerprint resembles an other image should be pretty complex I would think and larger than 100k so how do we find this so I

think this is fingerprint DS actually a default Android service I could be wrong but I think this is oxygen all Android phones are just open source but the handle different vendors implementations of fingerprint recognition services the vendor has to map in a shared object file into that which takes care of all the functionality that this binary will call out to to do the finger projects so if you look at the memory maps to figure for D you find this thing interesting which says live FPC tack share now attacks in some trusted agent something an FPGA of details like fingerprint something I don't know what the C's are but this looks interesting to me so I

checked it out and of course what we see here is something that resembles huawei's trust zone api so mall way implements their own API known as teak to implement with their or to interact with eric trust and architecture so as you can see we have this really suspicious-looking string system bid UUID datsuk and then that's passed into an open session call now if you look at this dot SEC it's just as data if you run file on it and like other trusts let's it's not gonna say it's an elf it's gonna say it's actually stronger blob of data so this says to me is an encrypted trust lid now why did Huawei feel the need to encrypt

this trust and not others I'll lead that up to the audience to figure out why they might want to do some shady like that it could be a security reason it could be something else but they didn't they do feel the need to encrypt whatever covers in that trust lit so to actually get to this we're gonna have to do is leverage our trusted core code execution to leak out the college's of this trust lei and this is a lot of leaking of encrypted data is done so on iphone if they want to leak the kernel cache what they can do is they can wait till it's loaded use a bug from it alters the system that's been

disclosed and then they can leak out the contents of the decrypted memory because this needs to be decrypted for it to run so once our fingerprint logic is working and then you know we can check this physically by just making sure that we can authenticate is with fingerprint we know that code must be decrypted somewhere in memory and with a trusted core we have access to all the physical memory on the device so we can do we can crawl all of our physical memory and looking for armed instructions and whenever we find our instruction we can dump the memory around it and look for references to just literal strings like fingerprint and fingerprint deed there's

a pretty naive approach but it happened to work once I was able to do that I actually could dump out an entire unstriped elf file so what this means that they al final actually had complete symbols and was very easy to reverse engineer and I essentially found a function called identify image which happened to correspond to the recognized fingerprint functionality and from there we can essentially get this - since you always return true we patched that in and now fingerprint checking works that's actually end of my talk I hope everyone enjoyed it now I have a more interesting demo here we've actually demonstrate unlocking the phone using the exploit with my nose so one second so hopefully everyone can see

this I know it's pretty far away so I just started the phone so I actually have to unlock it with a pin but now I can lock the phone all right and now if I want to use my fingerprint to unlock it see I think it's this one maybe it's this one okay so I can use my finger to unlock the phone who everyone saw that I can't just arbitrarily use other body parts yet or other fingers but if I run my exploit so I just have it as an app on the phone it's not 100% reliable it's not okay it didn't work this time but okay so it's now pwned the trust zone so now I should be able to use my

nose all right all right

all right that's essentially the end of my talk I have room in here for Q&A I don't know if this conference does it but if anyone has any questions feel free to ask otherwise I'll be right here after the talk I want to talk to me and one more thing I do work for Raytheon CSI and if you want time that interesting or if you think this is kind of work you would like to do this is sort of what I do for a job yeah I look for memory corruption bugs and I'm going to exploit them so if you would like to do this as a full-time job is completely possible just talk to me

and yeah we're retiring so I'll be around for the talk thanks everybody