 Our next speaker is TeamStar. Personally, for me, I'm happy that I can announce this talk. I own an Apple device, but for me, the point of owning this Apple device is that it just works. I don't like to tinker with that specific device. So I'm very grateful that there are people who actually would like to tinker with Apple devices, such as TeamStar. So personally, I'm looking forward to learning all about downgrading iOS, how it worked in the past, how it works in the present, and what new will be in the presentation that TeamStar can teach us. So with that, I would like to ask all of you to give TeamStar a warm round of applause. Thanks. Oh, thank you very much. Yeah, I'm TeamStar, and I'm going to present you downgrading iOS from past to present. So the topics of this talk will be the iOS boot chain and how it chains through the versions. I'm going to talk about SHSH Blobs and AP Tickets, what those are. I'm going to talk about the past downgrade methods, real quick intro on IMG3 and IMG4 file format. Then I'm going to tell you what the baseband and sepoise problem is, which we encounter while downgrading. And at the end, there is something new for 64-bit devices. So this is the iOS boot chain. I'm going to see this picture a few times in this presentation. But basically, right here, we have two routes. We have the normal boot, and we have the DFU boot. The DFU is the device firmware upgrade, if you upgrade the device. So yeah, what you can see here is that the boot ROM first boots the first-stage boot loader. The first-stage boot loader boots the second-stage boot loader, which is iBoot and normal boot, or iBag if you go to Restoreout. If you go to normal boot route, then the kernel boots. And for 64-bit devices, this is new. The SAP OS boots, what that is, I'm going to talk a few slides. If you go to the DFU route, then the RAM is going to kernel as booted. This is much like a live system. And you use that for restoring. So yeah, let's talk a bit about iOS history. With the iPhone 2G, we had iPhone OS 1 and iPhone OS 2 and 3. And they were pre-signed. And downward was just possible. There was nothing stopping you from downgrading that. This changed a bit in iPhone 3G. Well, it didn't change in iPhone OS 2 and 3. It was basically the same. But it changed with iOS 4. On the iPhone 3G, Apple added software SHSH checks. And downward was still possible with a few hacks. So let's take a look at the boot chain of an iPhone 3G, iOS 4. I want to note real quick, I'm only talking about iPhones. But this also applies to iPads and iPods with the same hardware. So keep that in mind. So what you can see here that the boot components check each other. Like a first-stage bootloader checks the second-stage bootloader. Second-stage bootloader checks the kernel and the RAM disk and so on. But you can see here, they are missing one thing. The bootroom doesn't check the first-stage bootloader. It doesn't check ILB or IBSS. So if you want to go back to iOS 3, 201, you could just do it. The bootroom doesn't check, doesn't prevent that. So what are those SHSH blobs I'm talking about? Well, Apple introduced those to control what iOS version can be installed on your device. And those need to be requested from Apple while restoring. And an SHSH blob is basically a signed hash plus the asset of the device. So those makes them unique for every device. You can't just take one SHSH block from one device and try to use it with a different device. It won't work because the asset is different. So let's take a look at SHSH and IMG3 file format. So on the left image, you can see the grammar for an IMG3 file. Basically, we have some magic. We have some sizes. And we have a bunch of IMG3 tags. And those are actually interesting ones. And what those IMG3 tags can be, you can see on the right. This is a picture taken from the iPhone Wiki. And those files contain stuff like the iBoot version, what chip this firmware is to be used on. And you can also see SHSH. And the SHSH is basically an RSA encrypted SHA1 hash of the file. So this is how it looks like if you open up in a hex editor. You can see a bunch of IMG3 tags. And the one which I highlighted is the SHSH tag. So yeah, it's basically the RSA1 encrypted SHA1 hash. And below this SHSH blobs, what you can't really see here is the certificate, which contains Apple's public key, which you can use to verify that signature. So let's continue with the RSS3. With iPhone 3GS and the iPhone 4, things changed a bit. With iOS 3 to iOS 4, Apple had hardware-enforced SHSH checks. Those were new in those two devices. And starting with iOS 5, Apple introduced AP tickets. But what that is, we'll see later. So this is how the boot chain looks like on pre-IOS 5 on iPhone 4 and iPhone 3GS. And you can see the only difference here is that the boot ROM does verify the SHSH blobs. So that's actually the only difference. How do we downgrade this? Well, SHSH blob is just a signed hash of the firmware. So there's nothing which prevents us from a downgrade attack. What you would do is you save SHSH blobs while they're signed and there are a bunch of tools which can do that. For example, Tiny umbrella can do that, Cydia, iFate. And when Apple doesn't sign them anymore, you can just reply them. So what you would do is you hook your device up to iTunes. And when iTunes would ask the Apple server, you just man in the middle of traffic and send the blobs you saved. And iTunes would give it to the device. And the device would accept it. And you could downgrade. OK, so what are those AP tickets? AP tickets is as in one form as a container. It contains an e-sit, a board ID, chip ID, and the hashes of all the firmware files and anons. And it's obviously signed. So you can't tamper with that data. Those things are packed inside an IMG3 file and flashed along with the boot files. So this is how the bootchain looks like on all 32-bit devices on iOS 5 and later. What you can see here, the boot ROM still checks for the SHSH blobs. But if you go the ViewRound route, the IBSS checks now with the AP ticket instead of the single SHSH one. And what it actually does when it boots up IBSS, it would generate a nonce. And this is random. And what you need to do is you need to read out that nonce from the device. You need to request an AP ticket for that specific nonce. Then you could stitch that nonce to iBag. And then you could boot iBag. And then you do the same for iBag. So you would read out the nonce. You would stitch it to the RAMNISK and the kernel. And you can boot those. For the normal boot, the ILB and iBoot also checks the AP ticket. But they don't check the nonce. Well, this is because you can't really check the nonce. Because if you would generate the nonce randomly, then you would have to request a new ticket for every single boot. And since the devices in bootloader can't really do that, so nonce is ignored on normal boot. And this is fine. So this is how an AP ticket looks like if you decode it with ISN1. So in the left image, you can see it ISN1 decoded. The right image is a build manifest taken from an iPhone firmware file. So at the left, the first thing you can see is the E-set of the device this blobs belongs to. Then you have a bunch of hashes. And those actually correspond to the one you can see in the build manifest. So the one I highlighted there is the Apple logo hash. Then you can see the nonce, the iBoot version, and a bunch of other stuff. And at the very bottom, you have the signature. And below the signature is certificate, which you can use to verify the signature. So if you pack that inside an IMG3 file, there's nothing too special about it. This is how it looks like. You can see the identifier here is SCAB. You need to read that little endian. So that's basically just the AP ticket. And storing all those information about the device in one single file removes the need to have it in a bunch of files. So it just collects all in one place. So how do we download it? Well, we have Limerain. Limerain is a boot ROM exploit from Geohot. And it works up to the iPhone 4. It's patched to in the iPhone 4S, but up to the iPhone 4 works. And we can make the boot ROM anything we want. So what we could do is we could patch out the AP ticket checks and IBSS and iBag. And then we could boot IBSS, iBag, RAM disk and a kernel without any AP ticket. What we would do then is we would restore with the previously saved AP ticket. And since the nonce isn't checked on our boot, boot, we are good to go. So this is an image visualizing the downgrade using Limerain. First step, you point a boot ROM, then you send a patched IBSS, iBag, kernel, RAM disk and so on, simply restore. And then if you restore with the valid ticket, you can see that everything from there is valid if you go the normal boot route. So what about newer devices where we don't have Limerain? Well, first some background info. Thermal files are encrypted and the decryption is not possible anymore when the kernel has booted. This is disabled by hardware since the iPhone 4S. So before the iPhone 4S, you could actually decrypted with the iOS engine on the phone, but since the iPhone 4S, this is disabled by hardware and you can't use it anymore once the kernel has booted once. And yeah, so basically to get the keys, you need either iBoot or a boot ROM exploit. But luckily in the Jabra community, we have some people who have private iBoot exploits and we have people who have private hardware hacking techniques. And those people, they're able to get the phone keys and they're so kind to share them with us. You can find them on the iPhone wiki. So yeah, they're publicly available for many device and iOS combinations, not for all, but for a lot of them. Also we have K-loader by Winocm and what it could do, it could bootstrap a raw image from kernel mode. So what you could do then is something like jumping back to the bootloader, for example, by booting IBSS. So taking all these possibilities, we have Odysseys. Odysseys is a technique by Xerob. He uses a jailbreak. He uses a task to put zero on K-loader to bootstrap an IBSS. I personally call this KD view mode, kernel D view mode. It is similar to the point D view mode with Limerain where it would like accept anything which you would give it, which is booted. You can do the same if you bootstrap decrypted and patched IBSS. But the only difference is since in kernel the view mode, the kernel has booted once, the iOS engine is disabled. So this means you cannot decrypt firmer files anymore. So the solution to this problem is we simply built a custom firmer as sent the firmer files decrypted already. So yeah, we decrypt IBSS, I-Back, Ramless and kernel and to file system and just send it so the device doesn't need to decrypt them. And we can do that. So this is what it looks like if we're downgrading using Odysseys. The first thing you have here is the normal boot. You boot up the old ILB and in this case, old means before the downgrade and new means after the downgrade. BootRam verifies ILB, ILB verifies iBoot and so on to the kernel. Then you pawn the kernel, you jailbreak the kernel, you enable task for pit zero, then you run kloader and boot patched and decrypted IBSS. And this is what I call KDE view mode and this is because if your device booted IBSS, it behaves to the outside world like as if would be in KDE view mode. So the outside world couldn't tell if it's actually IBSS or KDE view mode or D view mode. So this is why I call this KDE view mode. What you would do then is boot a decrypted and patched iBag and decrypted and patched RAMness and kernel. Then you would simply run a normal restore but you would restore a valid AP ticket. And if you try to boot then, BootRam verifies ILB. In the AP ticket, the nonce is ignored so you're good to go and you could boot. So this really cool, but in this talk I haven't talked about the baseband. The baseband is a processor which handles communication like when you're trying to call someone and stuff like that. And the security of the baseband has improved too and the downgrade is not really possible. Also less people care about baseband at all since carriers start to unlock phones. So in the earlier days of iPhones, the reason why I would want to hack the baseband is because the carrier would sell a simlocked phone and you want to use the phone with a different carrier. So you would try to hack the baseband and get an unlock so you can use the phone with a different SIM card. But since carriers start to sell unlocked phones, don't really need that anymore. But from the earlier days, the common practice became not to update the baseband because security proved that too. What you would do is when you're upgrading the iOS, you would keep the old baseband. So you could still keep all the vulnerabilities and exploit it again. And when you direct the device, you could then exploit again the baseband and you could unlock your phone. And from those times, we know that many non-default iOS baseband combinations are working, combinations that weren't shipped. Some are not, but lots of them are working. So, yeah, we know that the new iOS and old baseband works, but the other way around works too if the gap isn't too big. So Odysseus uses this fact. It keeps the baseband with its signature and downgrading. Since the iPhone 4S, the baseband is stored on a file system. Before that, it's stored on some memory, but since 4S, it's on a file system. And this is why you need to patch the firmware for not updating the baseband. So what you would actually do, you would grab the old baseband from the phone, create a custom firmware where you put this old baseband in and you would flash the new, the custom firmware with the old baseband. So then we have Odysseus OTA. So Apple signs OTA blobs for iOS 6.1.3 for the iPhone 4S and for the iPad 2. And what exactly are those OTA blobs? Well, OTA means over the air. If you update your device, not using iTunes, but if you go to settings and update and just downloads the firmware and updates, and this is what we call an OTA update. And Apple signs 6.1.3 for these two devices because those were shipped initially with iOS 5. And for some reason, you can't just straight go from iOS 5 to iOS 9 or think you can't even go to iOS 8. So what you would need to do if those devices are still in iOS 5, you would need to upgrade first to 6.1.3 and from there you could go to iOS 9. And same applies for iOS 8.1 for some other devices. So the idea with Odysseus OTA is to use fresh OTA tickets. And you can also grab a baseband ticket since that's signed too. And this allows us to actually download the baseband because the only thing which was stopping us from downloading the baseband is the fact that it wasn't signed. But since it's signed here, we could just grab tickets and download it. This was discovered by Syrup and me around the same time. We're using different techniques like I'm patching the firmware bundles you use to generate the custom firmware. He added the command link parameter to iDeviceRestore where you pass a build manifest, but it's basically the same thing. So normal AP tickets and OTA tickets only differ by the RAM disk cache. And this also makes sense because if you're upgrading using iTunes, you want the upgrade process to be handled by iTunes. But if you're upgrading using the OTA method, you want your phone to do it on its own without iTunes. So we need to boot a different RAM disk. And the hash of the RAM disk doesn't really matter because we're booting that thing with K-loader anyway. So no nonces, no nothing is checked. So Odysseus is cool, but it also has some limitations. It only works for 32-bit devices and you need firmware keys because the device can't handle the decryption you need to decrypt it. You also need custom bundles, so know how to make the custom firmware. You need all these patches and those are not available for all device and iOS combinations. So what about 64-bit devices? Well, let's have first some background info with 64-bit devices. Apple switched to the IMG4 file format and we also have a new enemy, the secure enclave processor or short SAP. And SAP is used for TouchAD, it's used for file system encryption and some other things and it's definitely required for booting so you can't just decide to not boot it and use your phone, this won't work because you wouldn't be able to decrypt your file system. SAP has its own nonce inside the AP ticket and those need to match the one SAP generates when it boots. So also there are no known exploits for SAP, so for those who expected zero day for SAP to be dropped, I'm sorry, no exploits for SAP. So yeah, let's take a look at the IMG4 file format. IMG4 is an iOS and One formatted container, this is the IR encoded and what a signed IMG4 basically is, it's just the IM4P, this is the payload, this is like just a boot file, iBoot or something like that with an IM4M and IM4M is the manifest and the manifest is basically the AP ticket. And the interesting thing here is that every IMG4 file has its own copy of the manifest of the ticket. This eliminates the need for a ticket only file like we used to have with the IMG3 file format. And this is probably required for SAP because all bootloader files are flashed as some memory, except for SAP, SAP is the only thing which is stored on a file system and this is maybe why they made a single copy of the ticket to every file. So yeah, let's take a look at the IMG4 file format. You could see here on the left side, this is if you just simply AS and One decrypt a decode the file, you can see IMG4, IM4P and the tag of that file, this is SAPI, this is a SAPOS which is, yeah, displayed right here. Then you have the actual SAP, then you have the key bag and the key bag is actually an encrypted key which the device could decrypt and it could use that key to decrypt the firmware. So below that you have the IM4M, this is basically the manifest, but you can actually see the better on the right image. Right image is what IMG4Tool gives you if you just display the file, basically also the key bags and you can see there IM4M and I walk through all those things real quick. The BNCH is the APNONS which is inside the ticket. Then you have some device specific data, you have the ESID for which specific unique device this ticket can be used and the SNON is the SAPNONS and SRVN is the server NONS. It's basically NONS the server generates. So even if you request over and over again a ticket with the same parameters, you would still get a different ticket because the server NONS changes and as far as I know, the server NONS is not really used for anything. So below that you have a bunch of hashes from all the different files. Right here you can see the hash for the bad zero image. So this is how the bootchain looks like on 64 bit devices. If you go the normal boot route, the only thing which really changed there is starting with the bootrom. The AP ticket is changed, earlier this was the SHSH. And if you go the DFU route, not only the bootrom checks the AP ticket and generates an APNONS. So actually you need to request an APNONS from the bootrom and so on, but you also need to request a SAPNONS and put it inside your ticket. Yeah. So we've seen this all improved a lot, but can we still downgrade? And yes we can. So let's make a downgrade plan for 64 bit devices. Well, we know that the baseband and iOS mismatch works and what if this would work for SAP2? That would be cool, right? And also every IMG4 file contains its own copy of the AP ticket, but do they actually need to be the same? Well, let's continue with our plan here. What I did here is I made a little tool, iGetNONS. Basically all it does, it fetches the APNONS and the SAPNONS from the device in all the different modes. What I did then, I took my iPhone 5S, put it in DFU mode, connected it to computer and read out the nonces for AP and SAPNONS. What I did then is I requested a ticket for those two specific nonces for my device with TSS checker and stitched that ticket to IBSS and I booted IBSS. Then I again checked what nonces are generated and I've seen nonces doesn't change. So I again stitched that ticket to iBag and booted iBag and again I requested the nonces and again the nonces doesn't change. So this is definitely something we can work with. Yeah, we've seen we get the same nonces for DFU IBSS iBag and this also works if you go from iBoot to iBag and this is actually the route we're gonna go for downgrading. You see why in a few slides. And also notice that the SAPNONS is completely ignored in IBSS and iBag. It only matters when booting SAP, which kind of makes sense, I guess. So what happens if you could somehow predict or regenerate an APNONS? Well, this is where Prometheus comes in. Let's for a second assume we somehow can predict an APNONS. What we could do then is we would request now a ticket for a nonce which will be generated later. And once that isn't signed anymore, we can somehow make the device magically regenerate the nonce and use the ticket we saved before. So this brings us back to the old classic replay attack and we could boot up to the RAM list. So we can only boot up to the RAM list because there's still SAP. We can't do this for SAP and we need somehow to boot SAP. Well, what we can do here is we can just boot a possibly newer, but signed SAP. And since it's signed, we can request a valid ticket and we're also restoring the newer, but signed SAP and we're also doing the same for the baseband. So fix everything, right? This is how Prometheus looks like when booting the stuff. First, you boot to ILB, then iBoot. This is checked by the AP ticket on your device. If you hold down your home button while booting, you will get into recovery mode and it will stop there. Then we do some voodoo magic and make the device regenerate the APNONS, which we have saved the ticket for. Then we stitch that ticket to iBag and boot that. And again, the saved ticket stitched it to the RAM list and the kernel and boot that. And what we're doing here is we're booting not the shipped SAP, but the latest SAP, for example, with a valid ticket, which we just requested for the NONS that generated us and we boot that. Then we're doing a normal restore with the difference that we're restoring the AP ticket we saved. And we're restoring the newer SAP with a different AP ticket. And we can do that because every IMG4 file stores its own copy of the ticket. Yeah. Now, the only real question is, how do we predict the APNONS? Because if we can't predict the APNONS, we can't really use all this. Okay, let's take a look at the OTA update procedure. So when you take your phone, go to Settings, Update. What it would do, it would download all the boot files and store the RAM list in memory. It would set some boot arc and it would reboot. The RAM list is not encrypted, the boot files are. And you need an AP ticket to boot. So you can't really request an AP ticket while you're in recovery. This means you need to request a ticket before going to recovery. And we have a problem here. So there's something needed to be stored. So the AP, so the updater can predict what NONS will be generated on next boot. So we can request now an AP ticket and use it on the next reboot. So all we gotta do is find this something. Well, let's take a look in Envira. So in the big picture, you can see kernel cache from iOS 10, yeah, Apple was so kind to ship iOS 10 unencrypted. So we can just take a look here. And what we see here is com.apple.system.bootnons. And the only thing left is figuring out what all those values mean. And if you Google, you'll eventually end up on ionvrom.h on opensource.apple.com. And there you can see this G-O-F variables, this variable table. And so basically the elements here are first the string, then the type, then the permission, and the last thing is probably counter. So if we take a look at the kernel dump, we see 0x3 and 0x3 for the type and for the permission. And if we take a look at the type, it's a type string. And if we check the permission, it is permission kernel only, which is kind of bad, but it's nothing we couldn't change with the kernel patch. So patching this to permission user read would allow us to use the Envira tool to read and write this variable from user land. So yeah, how do we predict IP nons? So the generator is saved in Envira. Once you request from LockdownD and Nons. And you can do that by either requesting Nons with iTunes or the updater can request the Nons from LockdownD. And that generator is saved to Envira and consumed on the next reboot. So you can't really predict Nons twice. You can do this just once. So this is how such a generator looks like and it generates the following Nons on my iPhone 6. And yeah, since the permissions are kernel only, you need to patch the kernel to be able to read and write that. So this is kind of a demo, I guess. It's just an image, but still. This is my iPhone 6 running iOS 9.1. And what I did here is I first I requested a Nons from LockdownD. Then I run Envira-P to print all the variables. Then you can see we only have bootercs, debo2r's, autoboot and backlight level. Then running Nonsenabler, which patches the kernel. And if again I run Envira-P, you can see the comapples system bootnons magically appears and we can read it and we also can write it. So this is the only way. Well, the Nons is 20 bytes. And this means we have two to the power of 160 different possibilities. And this is just too many to brute force. The generator on the other hand is eight bytes. This is two to the power of 64 possibilities. But this is still too many, unless you're the NSA, there's even no point in trying. But I did all these calculations after I tried that. So let me show you my results. So I wrote the little script. Basically all it does is puts your device into recovery, sets the boot arc to false, so you always put in the recovery when you reboot. Then it reads out the Nons and reboots. Then again reads out the Nons and so on. And I let this run for, I don't know, two hours and it gave me like 2,000 Nonses. And if we take a look at the Nonses, they are on the right side. So I ordered them and you can see the first thing there is the Nons. Then in the second column, this is how often it was generated. And the last column is the percentage. So the one highlighted in blue is not actually the one generated most often, but it's my favorite one. That's why it's blue. And if you take a look and sum all this up, you can see that five Nonses are 20%. So we can definitely work with that. We also had some community test results. So I asked on Twitter, just take your phones and try this too. And I've seen multiple iPhone 5S generate the same Nons on iOS 9.3.2 and iOS 9.3.5. And this also works with multiple iPad Airs. And close versions. I haven't tried 32-bit devices. Maybe it works, maybe it doesn't. I have tried later devices like iPhone 6, 6S, and I don't know if someone tried an iPhone 7. But those don't generate collisions. Also the funny thing here is that I have seen collisions on iOS 9.3. I have seen collisions on iOS 10, 10.1, 10.2, but I haven't seen any collisions on iOS 9.1 and 9.0. So maybe that's something, some bug that Apple introduced on 9.3. I don't know. I haven't seen any collisions for iPhone 5S and 9.0. So it seems collisions are possible for some device, iOS combinations, and this can be used to downgrade without a jailbreak. So what you should do is run your own tests, figure out what nonce is generated the most, and get an AP ticket for that specific nonce. So downgrade scenario here would be, you upgrade to newer iOS, and figure out what nonce is generated the most often, and you need to do that because maybe it changes what nonce is generated. And yeah. So you would request an AP ticket with that specific nonce for an older iOS while it's still signed. When Apple releases a new iOS, the older one is signed for a certain amount of time, and you would need to do that while the older one is signed. And when the signing window closes, you make the device regenerate the same nonce you have the ticket for, and you could downgrade. You could even chain up different iOS versions like first downgrading from iOS 10 to 9 because 9.3.5 maybe generates a different nonce, and then you can use the tickets with the saved nonce there, make the device regenerate another nonce, which you have the ticket for, and you could go even further. I need to say at this point that it does work for downgrading iVoot, but the iOS 10 SEP is not compatible with iOS 9. So if you try to downgrade iOS 10 to iOS 9 by restoring an iOS 10 SEP to iOS 9, you don't get a working system, so don't do that. Well, this is cool, but Prometheus has lots of limitations, and it relies on the fact that the baseband, the SEP, and the iOS versions are not tied together, and checks for that can easily be added. Also, SEP and baseband are always the latest signed version, and they might not work with all the iOS version. This is the case for iOS 10 SEP with iOS 9. Also, the AP nonce must be predictable, and Apple can make our lives really hard here. They could, for example, add a salt in iVoot and change that in every different iVoot version, and since they're encrypted, there's no chance that you can get that salt. So it would kind of eliminate the downgrade without Jarex, so yeah, Apple can really do lots of things here. So for future downgrades, yeah, saving AP tickets is always a good idea. Even if you can't downgrade right now, maybe you can in future, and maybe there will be new bugs in futures or new techniques, and yeah, definitely save you AP tickets. So the tools I used here is TSS Checker. TSS Checker is a tool for requesting AP tickets from Apple with lots of customizations. You can manually specify the AP nonce, the set nonce you want the ticket for, if you want the basement ticket, if you don't want the basement ticket, and really lots of stuff, and I haven't seen any other tool which can do that. So TSS Checker is cool for that. Also, IMG4 tool, it is used for manipulating IMG4, IM4P and IM4M files. You can view those files, you can stitch IMG4 files, you can check the manifest and stuff like that. Also, Future Restore, this is the actual implementation of the Prometheus downgrade method. So what Future Restore allows you to do is to specify the ticket. You want to use the specify the set, you want to install and specify the basement you want to install, and all of these will be open sourced. TSS Checker is open sourced right now. IMG4 tool and Future Restore will be open sourced shortly after the stock, and yeah, at this point, I want to thank Nikias, who made Auto Tools Script for Building Future Restore. Future Restore is a really messy project which consists of TSS Checker, IMG4 tool, and I was IDYs restored, just all packed together and made some more work, so it was really complicated to make build files for that, and yeah, thank you. And now it's time for some Q&A. Thank you very much for the presentation. If there are any questions in the audience, we have four microphones at which you can line up, and then I will call you. If you need to leave the room now, that's okay, but please do so quietly and take some trash with you if you can. I think the first question was at the very back of the room. Yes, please. Thanks, so my question is a bit generic, but since you're in the scene, right? Why do jailbreak and other iOS hardware hackers never consider hacking as a hardware directly, or maybe they do? I think there are people who are doing hardware hacking. I know that some people are doing hardware hacking for getting the firmware keys, but I think most likely this is because hardware attacks are not really practical for the average user, so you can't tell a user, well, you need to open up the device, you need to wire those two pins, and then you have a jailbreak, so this is why I think mostly it's focused on software. All right, we're gonna take one question from the internet, please. Thank you. What is the point in downgrading a device? Well, I actually asked it myself a few times, but it seems like there are really lots of people who do want to downgrade for some reason. For example, if you use this technique to downgrade without a jailbreak, right now the latest signed version is iOS 10.2, and if you do all this voodoo magic, you could right now downgrade with that to iOS 10.1.1, and there is a jailbreak for that, so you could basically downgrade to get the jailbreak, but most likely you can't do this, so I don't know. Many people say newer versions are slower, so they downgrade for speed. I don't know, people just want downgrades. All right, we're gonna take a question from the front here. Yeah, I have a question about nonces here. As far as the studio found that there are some nonces that are much more frequent than others. Is that right? Yeah. And did you investigate why this could happen? Like did you find the algorithm which generates them somewhere in the firmware? I haven't really looked into that part. What I did is just basically tried. I figured out if you take lots of iPhone 5S on iOS 9.3 something, it would generate the same nonce across the devices, but I haven't really looked into it why they're doing that specific nonce. I didn't even expect this to work at all, so I was surprised. Why does it even work? Okay, thank you. All right, we're gonna take a question from the front, please. That was actually my question as well, but could I just get a picture of that nonce collision slide? That was fantastic. I think they're, yeah, I think they're even more on Reddit Post, which there's a guy who, I published them on my blog, and there's a guy on Reddit who put them all together in an even different statistic. I was thinking about taking that image to a presentation, but it's somewhere on Reddit which devices generate collisions and which don't. Okay, we're gonna take one more question from the internet, please. Thank you. Will it work on all 64-bit devices? Well, I guess. The only thing which would stop it from work on the iPhone 7 right now is that I haven't pulled the, well, what the iPhone 7 is doing with the baseband, they're changed the baseband, and I haven't pulled the IDY3 Store commits for handling the new baseband format. This is why it doesn't work right now on iPhone 7. I don't know what the new memory protection the iPhone 7 does if it stops it, if it doesn't stop it from patching. I don't know. It will probably work. Well, I assume it works with all 64-bit devices. It might even work with 32-bit devices, but I never tried. Okay, question from the back. Thanks for the talk. My question is more or less a dummy question. You showed us in the slides that this work for 935 and 933. And now you said by answering the previous question that this work with iOS 10. Maybe I misunderstand something. You mean that slide, right? Yes. Well, basically what the slide is saying that I had people with iPhone 5s on 932, 933, 944, 935, and they were trying to generate the nonce, and this was the same across all these devices, so generated the same. But the iPhone 5s also generates nonce collisions on iOS 10.0, 10.1, 10.2. There's a difference between 9 and 10 that they're just simply different ones, like five of these of iOS 9, and on iOS 10 it's just five different ones. Can I? Sorry, we're gonna take another question from the front. Thank you for the talk. Still about the repeated nonces, you already answered that you haven't looked into how they're generated, but is that code in the publicly reversible part? Like how hard would it be to figure out how they're generated? Well, if you boot the device and request a nonce from there, that would be a nonce generated from the bootloader, from iBoot or something, so you would probably need to dump iBoot and reverse it there, the random number generator. What I did is I took a look at the generator thing and I figured out it's just the little Indian encoding and if you hash that byte string, this is basically the nonce, so I focused on that, so you just take eight bytes, hash that and this is the nonce. This is also what TSS checker does when saving blobs, it would make random eight bytes, hash them, so we know we can use that specific generator if you write it to NVRAM, it would generate the same nonce, but I haven't really looked into how iBoot generates the random nonces. But iBoot, there are decrypted iBoot available for reversing, are there? I don't think that they are decrypted ones, I know there is a technique by Quirty where you could dump an iBoot from iOS 8 devices for 64 bit. For 32 bit, there are decrypted firmers, but I haven't really looked into that. On this I have focused on 64 bit. Thank you. Okay, one more question from the internet please. Thank you. Is it possible to get around the theft protection with downgrading a device? No, it is not because after your downgrade or restore in general, you need to activate the device and this is completely separated from the system, so you would need to get an activation record, this has nothing to do with downgrading and restoring, so now you cannot bypass theft protection. Question in the front. Yes, earlier you said that the baseband itself was used primarily for tying devices to a specific carrier and that for a while you could drive a different baseband and iOS combinations, but then, and you said that they were now tied together, what is actually inside the baseband? What is it being used for in modern science? Well, you have, as far as I understand, different some kind of chip and the baseband is the firmer for that specific chip and that handles the communication with the GSM and stuff like that, so if you wanna use LTE or if you call someone, then you're using that specific chip with that specific firmer attack to that and this baseband is the OS of the thing that handles telephone and stuff like that. And does it have storage? Could there be cryptographically relevant information in that particular section? Probably, there are some carrier information, I don't really know, but there's nothing really what the user would have access to anyhow. Okay, another question in the front, please. Hi, thank you for the talk. I wanted to ask you about if is there a way to get a K-loader for 64-bit devices? Honestly, I don't know. Okay. Another question from the internet. Have you ever break the device? If I ever break the device, no, I haven't. Any other questions? Now is your chance. Yes, please. You mentioned that it wasn't possible to downgrade from 10 to 9.5, but then you also had a slide on chaining those downgrades. Can you talk about that? So, these slides were made in the days where iOS 9 was still signed, so I wrongly assumed you can, but the really thing which is stopping you from downgrading iOS 10 to iOS 9 is that you cannot use iOS 10 ZEP on the iOS 9 firmware. You could finish up the restore, but at the very end of the restore, it would fail. At that point, it would have already written the bootloaders and iBoot, so you could boot up to recovery, but there's some stuff at the end which they restored and finished so you don't have a file system. I don't know if you have a file system, but you don't have a phone you could use. The bootloaders are there, but that's it. Another question in the front, please. This might be a dummy question as well, but after the downgrade, are still the user data on the phone maintained or are they wiped afterwards? This is a good question. This is actually a restore, so when you restore, you can wipe the whole data. There's also an option to upgrade where you don't actually erase the data partition. I have an option in Future Restore which sets the flag for IDYsRestore to not wipe the partition, but to the upgrade instead, so you could try downgrading and with that flag set so it would keep the data, but I don't know if it's a good idea to do that if it would mess stuff up. I haven't tried that, but maybe I could. Another question from the internet. Thank you. Can you save the set before updating and use it again after you downgraded to a previous version? No, you cannot because when the set, when restoring, you boot the RAM disk and then you also need to boot the SEP OS. So, and before you booted the SEP OS, you can't really start the downgrade. And the normal downgrade restores the file system and stuff and the SEP firmer actually handles the restore process for the SEP, so it would restore also the SEP and those nonsense need to match. So it's a completely separate restore process, so we can't do that. Question in the front, please. Why is the baseband so hard to exploit? I'm not saying the baseband is hard to exploit, but I have the feeling personally that not many people are looking into it because I wouldn't know what I would do with, like it's a lot of work just so we could downgrade. I'm not seeing why anyone would do that. In theory, you could exploit the baseband, you could try to downgrade that. What you also could do is you could patch the older iOS so it would understand the newer baseband API and get that somehow to work. It's definitely doable, but the easier way is just hope that it works. Thanks. Another question in the front, please. Is it, so what software handles writing the firmware to the SEP and things like that and would it be possible to patch that in the same way that you would patch the kernel to just not write the SEP so that you'd be able to do downgrades and things like that without having to write the newer SEP? I don't think you can do that just as easily maybe. You probably need to exploit the SEP firmware and to stop it from downgrading because SEP handles a lot of stuff like true random number generator and other things. So I think to not update the SEP, you would need to actually exploit the SEP, but I haven't really looked into the SEP, it's just what I assume. Any other final questions? All right, so when you go, please take some trash with you and please give another warm round of applause for Team Star.