 And now, I want to introduce our first speaker and the topic he's talking about. IOS, Kernel Exploitation Archaeology. A kernel exploit from late 2013, early 2014 will be digged out and analyzed proper archaeology. All the digging and analysis is done by ArchBee here to my left on the stage and give him a big round of applause and the stage is yours. Thanks, thanks for the introduction. Okay, first of all, thank you all for being here. As the person that did the introduction told you this is going to be an archaeology talk, so I apologize in advance if it's not that interesting to you. So we'll talk about a bit older stuff rather than new things. Okay, so a few things about myself. Actually, I think from all these things the most important are the frag papers, right? So yeah, let's ignore all the other stuff. Okay, so what I'm going to talk about? I'm going to talk about the Evasion 7 kernel exploit. Now, Evasion 7 was a jailbreak. It was released by the evaders on the 22nd of December 2013. It supported iOS 7 to iOS 7.1 beta 3. That's not the 7.1 stable release, right? So that's the beta. And it supported all devices at that time including the iPhone 5s, which was the first 64-bit device except the Apple TV. So I decided to reverse engineer the kernel exploit of the jailbreak to focus just on that because I was really interested not so much in the bug itself, which was, as we will see, not very complicated, but I was really interested to understand the exploitation techniques that the evaders used. So I started reversing it and understanding it, and at some point I just said I'm just going to do a re-implementation of the kernel exploit. So this talk is basically my notes on this whole process, and of course it's not a jailbreak walkthrough, right? And I'm going to specifically focus on the various problems I encountered during this task and how I overcome them. And hopefully it's going to give you some helpful takeaways if you do iOS kernel research nowadays. Okay, so the general outline is I'm going to say a few things about Evasion 7 to set up the stage, and then I'm going to explain the kernel bug itself, and then I'm going to talk in length about my debugging setup, and I think that's a very important step that usually phone or embedded talks, exploitation talks, don't analyze that much, and I think it's a really important part because usually having a working debugging setup is basically maybe half the job of doing a reliable exploit. Then I'm going to talk about my re-implementation of the exploit, and hopefully at the end we're going to have some things to take away, or maybe not we'll say. Okay, so the Evasion 7 jailbreak was released about four years ago, and that's the archaeology in the title, that's ancient history, right? And if you were following the jailbreak community, you might remember this huge drama around this jailbreak. Initially with Jehoot, and if he was planning or not to release it before the evaders, and who he was planning to sell it to, and some leaked discussion that he had with someone that he was offering money to buy, and Jehoot, his jailbreak was supposedly using some of the bugs the evaders were using, so this huge drama. And then after the Evasion 7 jailbreak released, like maybe a few hours ago, people realized that if your phone had a Chinese locale, then the jailbreak was installing a piracy app. So that was basically a third-party app that was taking you to an app store, not operated by Apple but by TIG, that had some pirated versions of the real applications on the app store. And of course that also created a huge drama in this practice. Okay, so a lot of things were said about that jailbreak at that time and about the TIG piracy app store, but what I really set apart was this tweet, and the really important thing that I liked about this tweet is that it doesn't really make sense. So he says that we have to decide to remotely disable the default installation of TIG in China for further investigations on the piracy. So that whole thing doesn't make sense. So you mean you didn't know what was happening, you didn't bundle it with the jailbreak, are you going to disable it for new installations, and then what does remotely mean exactly? So what about the people that already had the piracy app? How are you going to disable that? Is that what remotely refers to? So that's an excellent tweet, I think. Okay, so at some point after the Evasion 7 jailbreak was released, Jeho did a write-up on the user-land part of it. So he analyzed how the user-land part worked and he stopped at the point of gaining root. And basically he mentioned in his write-up that the Evasion 7 untether binary, which was basically what was doing the kernel exploit, was obfuscated. And as we will see, this was indeed the case. And as far as I know, that's the first jailbreak that used the deliberate obfuscation. I don't know the reason. I assume it's partly to hide the piracy app store that was bundled with it and maybe partly to hide the kernel bug. But I'm not sure about the reason. Now Posix Ninja, who found, as far as I know, the kernel bug, did a write-up on the kernel bug. It's on the iPhone wiki and he basically describes the bug and he stops at the point where he gets a crash log from ZDB. So he doesn't say anything about how to exploit it. Okay, so after all these things happened, I decided to reverse engineer the untether binary and understand the exploitation techniques. And I was really interested to reverse engineer the obfuscation that the evaders were using. It seemed like an interesting challenge. But as I also mentioned earlier, I was really interested to understand the exploitation techniques that they were using. That was more important for me at the time. Okay, so the jailbreak was released December 2013 and I started doing that around February 2014. And I did that while having an actual day job, right? So I was spending at most two days per week on that. So what was my setup? I had an iPhone 4 and if you know about iPhone 4s, a bootrom bug called Lime Rain which basically allows you to load arbitrary kernels, unsigned kernels on the device and run them. And that basically means that you can very easily set up kernel debugging. So initially I had an iPhone 4 device with iOS 7.0.6. I want to remind you that iPhone 4 is ARM32, right? I also had an iPhone 5s with the same version of iOS. And I had that in order to verify all my findings and all my tests to redo my tests on an ARM 64 device. And as I told you, the iPhone 5s at that time was the only ARM 64 device actually I think on the market. I don't think there was another consumer device with ARM 64 at that time. So that's the exact version of version 7 I was analyzing. And of course it does, GDB, LLDB. Now the laws in this slide, they don't actually refer to something funny. They actually mean something very painful and that caused a lot of sleepless nights. But I'll get on to that. OK, a few things about the obfuscation. Not all of the functions of the untether binary were obfuscated, but some of the important ones were. And those were the ones that were triggering the bug and they were actually doing heap manipulation and all the other important things. Now I have been told, I haven't checked that, but I have been told that later versions remove the obfuscation. But I'm not sure about that. I haven't verified it. And I already had my implementation done at that point, so I wasn't that interested to look at that. So as I mentioned, the kernel bug that the version 7 untether binary was based on was found by posix ninja. And basically as far as he says on that iPhone wiki page, he used that six line bus script fuzzer to find it. So as you can see, he basically creates device nodes and with controlled arguments here, like minor and major numbers. Now in order to get to the point to create device nodes, you basically need to be outside of the application sandbox that exists on iOS and you also need root privileges. And that's what I refer to as the user land part of the version 7 binary and I'm not going to cover that at all. So I'm going to start my analysis from the point on that we have escaped the sandbox, we have obtained root and now we go to exploit the kernel bug. Now that's code from that version of the XNU kernel that had the bug. Now this ptsd open function is called every time user land code opens a devptmx device. And then this ptmxgetioctl function is called. Now the important thing here is that dev here is completely user controlled and then it's passed to this ptmxgetioctl function with no checks at all. And then this ptmxgetioctl function uses this to index an array without any checks. So basically the bugs and valid indexing bug, right? So since you can control that, you can put here whatever. I have here the ptmxioctl struct that... Okay, this array here is... So this state struct here is global to the kernel and this piece ioctl list array here is on the kernel heap. And it is an array of ptmxioctl structs. And that's the ptmxioctl struct. And the important thing here is that I'm going to refer to again and again during the talk is that it has a pointer to a tty struct as the first element of the structure. Okay, so we control the index to the array. So what can we do with that? So here, as you can see, the ptmxgetioctl function returns whatever it indexes, right? So as you can see here, it assigns it to this pti variable and then does all kinds of interesting things. So pti is controllable, tp is controllable here as well after this dereference here to some controllable value. And I mean, in other code paths of the kernel, this is called again. So there are a lot of things to consider when you know the bug and then you try to think how to exploit it. Okay, one important thing here that I wanted to mention is that this function here, ptmxgetioctl, also does the allocation of this struct here, of this tty struct here. And that's important because I'm going to use it further on. Okay, another important thing is that you basically, this bug, what allows you to do is you can control the size of this array here. So by... Can you see that? Okay, so by repeatedly opening the devptmxdevice, you can grow this array. And you can grow it as you see here by this grow vector. That's 16, but it doesn't matter. What matters is that the size of this array in bytes is controllable by you, the person who is trying to exploit this bug. Now, for example, these are nodes from my exploit, so if I did one allocation, if I did one open of this devptmxdevice, then this array was going into caloc64. If I was doing 17, it was going to caloc128. If I was doing 33 opens here, it was going to caloc192 and so on and so forth. So I could decide in which caloc zone I could place the array. If you don't know caloc zones, there are basically... You can think them as containers. You can think caloc zones as containers for heap objects on the kernel heap. All of them can be of different type, but all of them are of the same size, right? So caloc64 can have different structures of size 64 bytes, but all of them are size 64 bytes. Okay, so I started debugging the untether binary in userland. That's how I started. Initially, I was using GDB, and I found out that nothing worked with GDB. At that point, Apple was starting to move from GDB to LLDB. Maybe that was the reason GDB wasn't tested at all. When I say nothing worked, I mean that I was placing breakpoints and they weren't hitting, and I was trying like stepping and it was continuing execution and stuff like that. Sometimes I couldn't even attach to the binary. So then I moved to LLDB, to an LLDB setup with debug server, and things were much better. Now, while I was experimenting still from just with userland debugging, my iPhone 4 device went into a recovery loop and I wasn't able to get out of it. So I was forced to do a clean restore of the device. The problem was that at that time, only iOS 7.1 was signed by Apple. So I couldn't install a version of iOS that had the kernel that had the bug that I was interested to look at. But on the other hand, I couldn't not restore my device because that was the only device I had at the point that I could do kernel debugging with. So I upgraded my device to 7.1. As I just told you, 7.1 didn't have a vulnerable kernel to this bug. So what I wanted to do was basically to boot an iOS 7.1 device with a 7.0.6 kernel. And in order to do that, I could use the LimeRain bug that allowed me to boot arbitrary kernels. And the utility to do that was RedSnow, right? The problem was that RedSnow only supported up to iOS 6. And it didn't have support for iOS 7. So I left all the other things I was doing and I started reversing RedSnow to understand how it worked. RedSnow, if you don't know, it was back then and still is closed source, right? So I started reversing that to understand how it worked in order to support, for me, to hotpad, to patch it, to binary patch it to add support for iOS 7. And I spent, like, I don't know, maybe a month on that. And then I realized that it wasn't leading me anywhere. I couldn't understand a lot of things about how RedSnow was implemented. So I stopped doing that. And at that point, I found OpenSnow, which was an effort by Winocm to reimplement RedSnow as open source. So it seemed to have support for iOS 7, and that was good. I tested that and it was working. Now, my problem was that I couldn't have an arbitrary length of boot args. Boot args are the arguments that you pass to the kernel when it boots. And they are really important in iOS because by passing certain boot args to the kernel, you can disable signing checks, you can enable kernel debugging, so it's really important to be able to pass arbitrary length boot args. And iOS 7.1 was using up to 39 characters, so that was the reason OpenSnow couldn't support more. So what I ended up doing was I patched iBack, which is basically the loader of the kernel that passes boot args to the kernel when it boots. And basically, I changed the pointer to the boot args to some other place that had much more space. So at that point, I was able to pass arbitrary length boot args to my kernel. So where we are at last? So I had an iPhone 4 device with iOS 7.1, and I was using OpenSnow to boot the 7.0.6 kernel that had the bug that I was interested to exploit. Now, one side note here is that as I was doing that and I was trying to add to OpenSnow all the patches to the kernel, to enable kernel debugging, I was reversing the evasion7 binary as well. Now, the evasion7 binary was trying also to, after it exploited the kernel, it was patching it to enable kernel debugging. So I was just copying their patches, right, and adding them to OpenSnow. But I realized at some point that they missed some check-off for the debug enabled variable, and KDP wasn't really working. So the session was established, and it seemed like it was working, but if you try to actually use the kernel debugging setup or to do actual, like, to attach this debugger to the kernel and do whatever, like, place a breakpoint or step, then KDP just froze. So I added another patch that was required on that. Okay, so kernel debugging at last, but that's not really what happened, because, you know, breakpoints didn't always work. So you were placing a breakpoint and it wasn't hitting when execution was reaching there. And you were trying to step instructions, and the execution just continued. So you were stepping one instruction, and it was just like you were typing continue. And if you were taking too long to type an LLDB command and KDP froze, and then you had to restart your device, reestablish the kernel debugging session, and start from zero. And if you issue commands too fast, then KDP froze again. It was amazing. It was a great time. And now I did similar stuff with IOS 6, and I distinctly remember that it was much easier and kernel debugging worked much better. And I mean, the issue that comes to everyone's mind that does that is do Apple engineers really use KDP for debugging the IOS kernel or do they use something else? Okay, so now I could debug the evasion-several-tender binary both from the user, from the user land side and from the kernel side. And that was good because I was analyzing at runtime, and at the same time I was reversing it in NIDA. So the obfuscation, I could do it much faster since I was taking hits from runtime. So at that point things started moving fast, and I quickly found that it was abusing the DTY structure to obtain read-write access to physical memory. I mean, that was interesting to me, but I was expecting something else. I was expecting something like what they did in IOS in the evasion-6 jailbreak that they did a lot of heap manipulation, and that's my interest, actually, heap consolidation. So at that point I decided to stop reversing it and re-implement the exploit the way that I wanted to do it. So obviously that wasn't work from scratch. It was from everything that I just stood up to that point. And what I really wanted to use was the VMAP copy structures technique by doubt and mind, and I'm going to explain that in the following slides how it works. Okay, so at that point I had a clear understanding of the bug of what it was, and I had a general idea about how to exploit it. I mean, if you've done that, you know, then it takes a lot of pen and paper, like ideas you develop on paper, then you go test them, and they don't work, and then you design them again, and then again, and then you fail, and you despair, and then you suddenly have an idea and you spend like, I don't know, like two nights, testing things, and they don't work, and then you despair again, and add no zoom. But eventually you get somewhere. So let's talk about exploitation now. Now, a few things to refresh your memory about the bug. So as I said, it was a valid indexing bug. This PCIO CTL list array was on the heap, and I could control in weak color zone it can go. I can grow it, but once I grow it, I cannot string it back. Now, that's code from that PTMX GitIO CTL function. So basically what it does, it allocates a new PTMX iOS CTL structure, and then it uses the index that you provide, that you control to store the address on the array. Now, this allocation here, this struct here, goes into caloc88, and that's useful for the next parts. Okay, a few things about the technique I wanted to use, about the exploitation technique I wanted to use. So it's the VM map copy technique. It was proposed by Dowd and Madd, and basically they were spraying the heap with these structs here, the VM map copy structs, and assuming you have like some way to corrupt this struct that you have sprayed on the heap, if you can override this Kdata element here, then basically what you have is a leak of kernel memory, other adjacent like next to the Kdata, whatever is below or above the Kdata pointer, or arbitrary if you put whatever address you want in there. By overwriting the caloc size element here, and then freeing the struct on the heap, you put it on a wrong zone, and basically when you allocate it back, since you put it on a different size zone, you can have a heap overflow. So that's a general overview of this technique. You corrupt this struct and you get exploitation primitives. Okay, so what was the idea I had at that point? The idea was to use this piece IocityListIndex bug to corrupt this Kdata pointer here and to have a relative leak of kernel heap memory, and that would be my first step towards exploiting the bug. Of course, the end goal is to have arbitrary redraw it, right? And of course it was just a fuzzy idea at that point and you know that's always the goal, but when you study the bug and you see the different code paths and how the things you affect are used, then you have some maybe not completely concrete things in your mind, but you know that interesting things can happen, so that's what I had at that point. Okay, so let's talk about the exploitation stages now. So at stage one, I sprayed the kernel heap with VVMap copy structs and I decided to work on the Kalloc 256 zone, and the reason for that was completely arbitrary was because of all the kernel debugging I have done up to this point of this untether binary, I saw that this Kalloc zone was not really used that much, either by the kernel or by whatever the exploit was doing, so that's good because it means that you as an exploiter can have much better control over the kernel heap if there aren't other things placing allocations on the zone you work. So I decided to use the Kalloc 256 zone. I avoided, of course, Kalloc 384 because the TTOI structure going there, and that would really mess up my heap arrangements. So the first let me actually okay so what I wanted to do was to do this, so initially you spray the heap with VMap copy structs and you control both their size and their contents, the contents don't matter at this point, so it just their size matters, so I spray with 256 bytes VMap copy structs and then I free every other second one and I create this kind of pattern like VMap copy and a free slot and VMap copy and a free slot and then I grow the PSIO CTL list array to 256 bytes and then it goes into one of these free slots here. Now the code for doing that looks something like that, so what this basically does is since it creates this VMap copy struct so if you see here the out-of-line Mac messages as basically these VMap copy structs and their size is 256, their buffer doesn't matter at this point and you just send them like Mac send message and then after I have sprayed with them, then you free every second one here with this loop here, so in order to make free slots you just receive this Mac out-of-line messages that correspond to the VMap copy structs and after you've created the holes you basically grow the array to 256 bytes how do you do that as I mentioned earlier you open the devptmx device a number of times how many times like a specific number of times that I mentioned earlier that I have noticed grows it to 256 bytes so that's the array you have at that first stage okay so the second stage is done on the Kallok 88 zone so I spray again with VMap copy structs and this time I make them 88 bytes to go to the Kallok 88 zone and then I create again holes and then I trigger the bug in valid index value and remember that when you trigger the bug a ptmx ioctl struct is allocated and this goes to Kallok 88 but because on Kallok 88 I have created this pattern of used free it goes into one of the free slots so now I have a ptmx ioctl struct into one of my free slots I don't know where that is but I know that it falls into the pattern right so I trigger the bug and remember that basically you control this index right so since I control the index I point it to the K data element of the VMap copy struct that I know is below the free slot that I went into I don't know the address I can put an address there but I know the relative distance in bytes because I created the pattern the hip pattern so it looks like that so that's my first stage free VMap copy and this is the same pattern on the Kallok 88 zone when you trigger the bug this structure is allocated it goes into one of the free slots and then the bug itself which is what we see here is remember you control the index so this is the new allocation that went here and then it goes and stores this address where the index tells it to store to store it but remember that this is controlled we control that so what I do I point this here to the neighboring VMap copy struct at the K data field so in this K data field here of the VMap copy struct I have now this address so that's that's how the hip looks like I have here the code it's very similar to the first stage you spray with VMap copy structs of size 88, max and right and then you receive every second one you create the holes on the 88 zone and then you trigger the bug here right this invalid Psyndex number here is basically what points relatively to here right so I have now the address of this ptmxioctl struct which is an address on the caloc88 zone I have it on the K data field of this VMap copy struct here so what I do I can simply receive this message and in its content I can see the address of that slot on the caloc88 zone so that's the code to do that I can simply receive all the messages and that's my address okay so at this point what I only have is this address here I have the address of this hip slot so at that point I started looking at other code paths that this invalid index what other variables this invalid index was influencing and I found the code path that was actually giving me a right but in order to reach that I needed to survive several dereferences and what I only knew was just the caloc88 address right nothing else so I will now walk you through everything that gave me this right so I clean up the caloc256 zone and I spray it again with vmap copy structs and create holes exactly like the previous step the first stage again next to the psioctl list array I have a vmap copy struct but at this time I in all the vmap copy structs I put a payload of this fake ptmx iocctl address I have and remember that the first element of the ptmx iocctl struct is a pointer to a tty struct and I can use the leaked address I have for this pointer that I don't know I didn't know where to point it to so the next step was to clean up the caloc88 zone and spray it again and again I spray it with vmap copy structs but at this time at the payload I can put now the fake tty struct that the ptmx iocctl struct is pointing to the problem at that point was that the tty struct was 256 bytes and caloc88 the slots are only 88 bytes so I couldn't just with the elements just with the first 88 byte elements I couldn't get to the path that was giving the right so I needed to find some other way to host my fake tty struct so remember that I couldn't work on any other caloc zone or anywhere else because what I only knew was the address of that caloc88 zone I had nothing else to build on so at that point I started doing a much more complicated heap arrangement so instead of spraying just one thing I was spraying I was trying to create a pattern of a pattern of two controlled things now I couldn't use vmap copy structs because the vmap copy struct has a header right so it would mess up my fake tty struct so by reading Ionic's kernel heap exploitation slides I realized that I could spray the heap with XML properties of length 88 from that apple jpeg driver and I could I could place as a second control object after the vmap copy struct these XML properties which are completely controlled in content and I could host the second part of the tty struct there, I mean it's still not 256 bytes but what it gives me is the ability to survive all the references to reach the right that I was interested in okay so a few things about the tty struct that's what I wanted to create on the calo kth zone right so that's the tty struct that the ptmx iostl struct is pointing to now what basically I wanted to do here is I wanted to point the final thing was to use this clist struct to control this element here c underscore cs as the start of the ring buffer for the tty to give me an arbitrary right to give me a controlled right I started playing a bit to use it to do arbitrary right but I found that I wasn't able to do it because at later states some other parts of the tty struct were needed that I wasn't able to control so I only had two 88 slots to host my fake tty struct so that wasn't stable I was only using that to do a relative right so we'll see the code later on let's go to the heap layout so that's the third states again remember I spread the calo 256 zone with vmap copy structs freeze just to place my psioctl list array next to vmap copy struct remember that I control the contents of vmap copy so I placed in the buffer of vmap copy this ptm xioctl address that I know and I point the invalid index that I control to this ptm xioctl this address that I put here and what is this address is that leaked address that I got in the previous states which points to the calo kt8 zone and what's the arrangement of that calo kt8 zone is as I told you a vmap copy followed by an xml properties vmap copy xml properties and all these fake tty structs all these are the same I just explained here how it looks like so this points to the kdata element here and the rest of it holds the rest of the all this is basically the fake the buffer of the vmap copy and then following the xml contents of this heap allocation and where do I this c underscore cs pointer that I told you that I wanted to control where do I point it I point it relatively, again I don't know any addresses but I can point it relatively since I created this heap arrangement I can point it relatively to the size or the calo size of the vmap copy struct and why do I need this because I want to use the vmap copy technique by mark and dot that I mentioned earlier so that's the end goal so what's the code looks like that's the spray of 256 we have seen that a lot of times then we have the freeze wait no that's not the freeze so that's the allocations of the 256 that's I don't have the freeze here because they don't matter because we have seen them before so what I have here is the spray of the calo kt8 zone and the important thing here is that what I wanted to show you is that at every step I took two allocations one is the vmap copy struct here with the mark send message and the second part is the xml properties which are sprayed on the heap when you open the device driver, the apple jpeg driver and what are the contents of that xml properties they're basically that fake the second part of the fake tty struct that you have the control c underscore cs pointer that will give me the relative write so if you see here I have this function set up fake tty that basically creates the structs since I don't have to type all the time and we are at second stage here and basically what you can see here is the creation of the fake tty struct so that's the different elements of the fake tty as we saw it from the code and that's the write offset I pointed to the ktata field of the neighboring vmap copy struct so again that's how it looks like in the heap so after that after we have arranged this way we trigger again the invalid index array bug but at this time on a slave ptmx device I was only doing that on a master ptmx device but in order to reach that right code path that I mentioned you need to do it on a slave ptmx device so that's what happens here and then you simply write to the corresponding descriptor and it just dereferences the c underscore xcs that you controlled and it writes to whatever you want to write and what do I want to write? I want to write a new size for the vmap copy struct for the caloc size field of the neighboring vmap copy struct so I can use the doubt and math technique so putting everything together so at that point I have a controlled corruption of a vmap copy struct and I can use the primitives to get arbitrary an arbitrary leak so I can leak for example the kslr slide and I can do a heap overflow again these are how you can use the primitives that mark and doubt gave us now I also know my location on the kernel heap and remember that's basically we found that on the first two stages and we use only that where that ptmxioctl struct was stored on the kernel heap that's the only thing we knew that address in order to successfully build on it in order to reach a much more useful primitive and the interesting thing here is that everything up to this point is that only you haven't injected any code you haven't done anything at all that you could be caught somehow by a kernel self-protection mechanism or these kind of things everything is that only so once you reach that point how do you get PC control so since you can use doubts and maths technique you can basically do a heap overflow so you can again do an over-arrangement you can place iokit objects next to vmap copy where you can overflow from and you can corrupt iokit objects and from there you can have also you can do an arbitrary read so you can by the arbitrary read you can read the vtable of the iokit objects so you know the kslr slide and you can corrupt it in order to get out and of course getting to a whole jablik from that point is out of the scope of this talk but it's not that hard actually from that point on okay so after doing all that how close was that exploit to the to the real evasion 7 kernel exploit I'd say it was pretty far off but I mean it wasn't my point to recreate it like completely but it was my point to to play with the heap and to try to do complex heap arrangements and to see how much I understand the the ios kernel heap that was the point of this whole exercise for me okay so some lessons learned so the real surprising thing for me at that point was that I couldn't believe that Apple does kernel debugging by KDP it was very flaky it was very unstable as I told you if you type commands too fast it froze, if you type commands very slow it had like a wordstock timer and it froze I think it had a wordstock timer or something like that and I couldn't believe that Apple engineers were using this interface to do kernel debugging so it was it was really hard to do anything on the kernel side of iDevices but of course I don't really mean that you shouldn't mess with these things these devices are really interesting and it's really becoming harder to hack them but I think it's much more fun and I think the only take away maybe is that you shouldn't report bugs to Apple at all and if you need street cred you should just report to them that's always good and this is getting very esoteric there are not a lot of information and Apple keeps changing stuff and everything is closed source all the important parts are closed source and I really think people that work on that should set nodes as much as possible these are some of the people I was talking to while doing all these and basically that's all of the material I have and I'm open to any questions we might have Thank you ArcP for the talk so we have prepared microphones 1, 2, 3 and 4 in the room and we have a signal angel I think when you have questions you can give me a hand sign but I think we start with microphone 2 here in the front and please ask questions and no comments there's time after the talk. Go ahead. Thanks for an awesome talk. I have a question about Heapspray was your Heapspray really stable if it is not successful did it crush the device? I haven't mentioned it here but it was pretty stable I think because I did a lot of tests for that because it was really interesting for me to know it was maybe something like 90% so 9 out of 10 times it worked but if it didn't work yeah it crushed the kernel and crushed the device and did you try to return HIP into some kind of initial state to start your exploit from scratch? yeah that's true I haven't included that but you're right so the initial step on every spray that I mentioned here was to spray a lot of objects of the specific size you were targeting in order to get basically a new page of the catalog zone so even if as I told you the catalog wasn't that busy there were still allocations going on it so if you did a lot of initial spraying I'm sure that when the allocations that mattered to you were made on a new page that wasn't too much noise from other allocations from the kernel so yeah you're right I haven't included that but yeah that happened thanks then microphone one please also thank you for your awesome talk again my question was nowadays it's way harder to use VM copy I think Apple truly replicated it it's not possible anymore due to security do you see hope in reconstructing some function that does the same or is it totally dead now oh you mean the VM app copy technique yes no I think it's completely dead now alright and I recently saw on the IOS logs vulnerabilities that again vulnerability in Apple do you think have you looked into it or well the Apple JPEG driver is one of the four I think IOS drivers that you can reach from the container sandbox right so that means it's very very fast by everyone Apple included and very audited so I'm not saying that there aren't many there aren't things there like interesting findings but if there are they're not going to live much longer I think thank you thanks for your question and now from the signal angel question from the internet yes I have a question from the internet how long did this research take you you said two weeks in the beginning but from begin to end how many hours about because you also said it was during work no no it didn't take two weeks no it took like maybe close to three months so two months and something like that so I spent as I mentioned I spent like a complete month I think maybe three weeks maybe not a complete month just on reversing red snow and trying to get red snow to play with IOS 7 so I wouldn't count this month in the exploit part of it right so if you're interested just in the kernel exploit part I would say something like maybe seven weeks something like that but just with two two maybe three days per week right not complete weeks okay then microphone one please congratulations your talk it was really interesting I liked it a lot and my question is if the technique you use it to supply the bug it works in free BSTD or in other BSTD as well oh no no I mean the VMAP copystack doesn't exist anywhere else except the XNU kernel but I think the interesting takeaway is that you can do complex heap arrangements if you understand the kernel heap allocator right so this process I described by creating holes and maybe controlling two allocations in order to host fake structures that you are able then to use to get exploitation primitives then that's applicable everywhere right thank you okay then we go to microphone two again please so I saw one sentence just not report or just don't report the bugs I would like to understand your thinking behind because I think this is really important for companies to know the bugs that they made and yeah make the products better and this is really beneficial for researcher because for example April they pay a lot of money for the bugs okay yeah I don't have much to say on that I mean apart from if all the bugs are fixed and you won't be able to do this kind of work and it's not fun I don't have anything else to say on that sorry I I don't have anything else no comment okay signal Angel do we have another question from the internet okay then please a big round of applause for our speaker