1 00:00:03,970 --> 00:00:16,730 *35C3 preroll music* 2 00:00:16,730 --> 00:00:22,010 Herald-Angel: All right, let's start with our next talk in the security track of the 3 00:00:22,010 --> 00:00:27,239 chaos communication congress. The talk is called jailbreaking iOS from past to 4 00:00:27,239 --> 00:00:34,954 present. Done by tihmstar. He spoke at the 32nd C3 already and researched on several 5 00:00:34,954 --> 00:00:40,470 jailbreaks like the Phoenix or the jelbrekTime for the Apple Watch and he's 6 00:00:40,470 --> 00:00:44,800 gonna talk about the history of jailbreaks. He's going to familiarize you 7 00:00:44,800 --> 00:00:52,020 with the terminology of jailbreaking and about exploit mitigations and how you can 8 00:00:52,020 --> 00:00:55,910 circumvent these mitigations. Please welcome him with a huge round of applause. 9 00:00:55,910 --> 00:01:02,620 *Applause* 10 00:01:02,620 --> 00:01:08,800 tihmstar: Thank you very much. So hello room, I'm tihmstar, and as already said I 11 00:01:08,800 --> 00:01:13,910 want to talk about jailbreaking iOS from past to present and the topics I'm going 12 00:01:13,910 --> 00:01:19,800 to cover "what is jailbreaking?". I will give an overview in general. I'm going to 13 00:01:19,800 --> 00:01:25,600 introduce you to how jailbreak started, how they got into the phone at first and 14 00:01:25,600 --> 00:01:30,950 how all of these progressed. I'll introduce you to the terminology which is 15 00:01:30,950 --> 00:01:37,460 "tethered", "untethered", "semi-tethered", "semi-untethered" jailbreaks. Stuff you 16 00:01:37,460 --> 00:01:41,400 probably heard but some of you don't know what that means. I'm gonna talk a bit 17 00:01:41,400 --> 00:01:46,250 about hardware mitigations which were introduced by Apple which is KPP, KTRR and 18 00:01:46,250 --> 00:01:52,799 a little bit about PAC. I'm going to talk about the general goals of... About the 19 00:01:52,799 --> 00:01:57,790 technical goals of jailbreaking and the kernel patches and what you want to do 20 00:01:57,790 --> 00:02:02,698 with those and brief overview how jailbreaking could look like in the future. 21 00:02:02,698 --> 00:02:10,769 So who am I? I'm tihmstar. I got my first iPod touch with iOS 5.1 and since 22 00:02:10,769 --> 00:02:15,740 then I pretty much played with jailbreaks and then I got really interested into that 23 00:02:15,740 --> 00:02:19,440 and started doing my own research. I eventually started doing my own 24 00:02:19,440 --> 00:02:23,510 jailbreaks. I kinda started with downgrading – so I've been here two years 25 00:02:23,510 --> 00:02:28,840 ago with my presentation "iOS Downgrading: From past to present". I kept hacking 26 00:02:28,840 --> 00:02:33,530 since then. So back then I kind of talked about the projects I made and related to 27 00:02:33,530 --> 00:02:38,610 downgrading which was tsschecker, futurerestore, img4tool, you probably have 28 00:02:38,610 --> 00:02:42,520 heard of that. And since then I was working on several jailbreaking tools 29 00:02:42,520 --> 00:02:49,690 ranging from iOS 8.4.1 to 10.3.3, among those 32bit jailbreaks, untethered 30 00:02:49,690 --> 00:02:54,510 jailbreaks, remote jailbreaks like jailbreak.me and the jailbreak for the 31 00:02:54,510 --> 00:03:02,200 Apple Watch. So, what is this jailbreaking I am talking about? Basically, the goal is 32 00:03:02,200 --> 00:03:08,620 to get control over a device you own. You want to escape the sandbox which the apps 33 00:03:08,620 --> 00:03:14,440 are put in. You want to elevate the privileges to root and eventually to 34 00:03:14,440 --> 00:03:20,030 kernel, you want to disable code signing because all applications on iOS are code- 35 00:03:20,030 --> 00:03:24,090 signed and you cannot run unsigned binaries. You pretty much want to disable 36 00:03:24,090 --> 00:03:29,959 that to run unsigned binaries. And the most popular about people on jailbreak is 37 00:03:29,959 --> 00:03:35,620 to install tweaks! And also a lot of people install a jailbreak or jailbreak 38 00:03:35,620 --> 00:03:39,241 their devices for doing security analysis. For example if you want to pentest your 39 00:03:39,241 --> 00:03:44,980 application and see how an attack goes foot – you want to debug that stuff and 40 00:03:44,980 --> 00:03:51,120 you want to have a jailbroken phone for that. So what are these tweaks? Tweaks are 41 00:03:51,120 --> 00:03:55,830 usually modifications of built-in userspace programs, for example one of the 42 00:03:55,830 --> 00:03:59,739 programs is springboard. Springboard is what you see if you turn on your phone. 43 00:03:59,739 --> 00:04:04,790 This is where all the icons are at. And usually you can install tweaks to, I don't 44 00:04:04,790 --> 00:04:10,680 know, modify the look, the behavior or add functionality, just this customization, 45 00:04:10,680 --> 00:04:17,880 this is how it started with jailbreaking. What is usually bundled when you install a 46 00:04:17,880 --> 00:04:23,720 jailbreak is Cydia. So you install dpkg and apt which is the Debian package 47 00:04:23,720 --> 00:04:31,630 manager and you also get Cydia which is a user-friendly graphical user interface for 48 00:04:31,630 --> 00:04:38,280 the decentralized or centralized package installer system. I'm saying centralized 49 00:04:38,280 --> 00:04:42,250 because it is pretty much all in one spot, you just open the app and you can get all 50 00:04:42,250 --> 00:04:47,250 your tweaks and it's also decentralized because you can just add up your own repo, 51 00:04:47,250 --> 00:04:54,200 you can make your own repo, you can add other repos and you're not kinda tied to 52 00:04:54,200 --> 00:04:58,460 one spot where you get the tweaks from, like from the App Store you can only download 53 00:04:58,460 --> 00:05:02,266 from the App Store. But with Cydia you can pretty much download from everywhere. 54 00:05:02,266 --> 00:05:09,210 You're probably familiar with Debian and it's pretty much the same. So this talk is 55 00:05:09,210 --> 00:05:15,610 pretty much structured around this tweet: the "Ages of jailbreaking". So as you can 56 00:05:15,610 --> 00:05:20,490 see we get the Golden Age, the BootRom, the Industrial Age and The Post- 57 00:05:20,490 --> 00:05:25,160 Apocalyptic age. And I kind of agree with that. So this is why I decided to 58 00:05:25,160 --> 00:05:29,530 structure my talk around that and walk you through the different ages of 59 00:05:29,530 --> 00:05:35,350 jailbreaking. So starting with the first iPhone OS jailbreak – then it was actually 60 00:05:35,350 --> 00:05:42,490 called iPhone OS not iOS – it was not the BootROM yet. So the first was a buffer 61 00:05:42,490 --> 00:05:49,560 overflow and the iPhone's libTitt library. And this is an image parsing library. 62 00:05:49,560 --> 00:05:54,930 It was exploited through Safari and used as an entry point to get code execution. 63 00:05:54,930 --> 00:06:00,900 It was the first time that non-Apple software was run on an iPhone and people installed 64 00:06:00,900 --> 00:06:06,850 applications like Installer or AppTapp which were stores similar to Cydia back 65 00:06:06,850 --> 00:06:11,590 then and those were used to install apps or games because for the first iPhone OS 66 00:06:11,590 --> 00:06:16,650 there was no way to install applications anyhow, as the App Store got introduced 67 00:06:16,650 --> 00:06:24,490 with iOS 2. So then, going to the Golden Age, the attention kind of shifted to the 68 00:06:24,490 --> 00:06:29,949 BootROM; people started looking at the boot process and they found this device 69 00:06:29,949 --> 00:06:39,120 firmware upgrade mode which is a part of ROM. So the most famous BootROM exploit 70 00:06:39,120 --> 00:06:45,120 was limera1n by geohot. It was a bug in hardware and it was unpatchable with 71 00:06:45,120 --> 00:06:52,650 software. So this bug was used to jailbreak devices up to the iPhone 4. 72 00:06:52,650 --> 00:06:56,669 There were also several other jailbreaks – we didn't rely on that one – but this one, 73 00:06:56,669 --> 00:07:00,375 once discovered, you can use it over and over again and there's no way to patch 74 00:07:00,375 --> 00:07:06,690 that. So this was later patched in a new hardware revision which is the iPhone 4s. 75 00:07:06,690 --> 00:07:09,830 So with that BootROM bug – 76 00:07:09,830 --> 00:07:15,930 This is how kind of tethered jailbreaks became a thing. So limera1n exploits a bug 77 00:07:15,930 --> 00:07:24,340 in DFU mode which allows you to load unsigned software through USB. However 78 00:07:24,340 --> 00:07:29,729 when you reboot the device a computer was required to re-exploit and again load your 79 00:07:29,729 --> 00:07:36,380 unsigned code. And then load the bootloaders, load the patched kernel and 80 00:07:36,380 --> 00:07:40,350 thus the jailbreak was kind of tethered to the computer because whenever you shut 81 00:07:40,350 --> 00:07:46,160 down you need to be back at a computer to boot your phone up. So historically a 82 00:07:46,160 --> 00:07:51,520 tethered jailbroken phone does not boot without a computer at all. And the reason 83 00:07:51,520 --> 00:07:57,990 for that is because the jailbreaks would modify the kernel and the bootloaders on 84 00:07:57,990 --> 00:08:04,120 the file system for performance reasons, so when you do the actual tether boot you 85 00:08:04,120 --> 00:08:09,229 would need to upload a very tiny payload via USB which then in turn would load 86 00:08:09,229 --> 00:08:14,380 everything else from the file system itself. But this results in a broken chain 87 00:08:14,380 --> 00:08:18,780 of trust. When the normal boot process runs and the bootloader checks the 88 00:08:18,780 --> 00:08:23,340 signature of the first-stage bootloader that would be invalid so the bootloader 89 00:08:23,340 --> 00:08:29,340 would refuse to boot that and it would end up in DFU mode so basically a phone won't 90 00:08:29,340 --> 00:08:36,349 boot. Sometime around then, the idea for semi-tethered jailbreak came up and the 91 00:08:36,349 --> 00:08:40,479 idea behind that is very simple: just don't break the chain of trust for 92 00:08:40,479 --> 00:08:47,149 tethered jailbreaks. So, what you would do differently is you do not modify the 93 00:08:47,149 --> 00:08:52,220 kernel on the file system, don't touch the bootloaders at all and then when you 94 00:08:52,220 --> 00:08:56,230 would boot tethered, you would need to upload all the bootloaders like the first 95 00:08:56,230 --> 00:09:00,790 stage bootloader, then the second stage bootloader which is iBoot and then the 96 00:09:00,790 --> 00:09:05,550 kernel via USB to boot into jailbroken mode. However when you reboot you could 97 00:09:05,550 --> 00:09:10,550 boot all those components from the file system so you could actually boot your 98 00:09:10,550 --> 00:09:17,149 phone into non-jailbroken mode. If you don't install any tweaks or modifications 99 00:09:17,149 --> 00:09:22,020 which modify critical system components because if you tamper with, for example, 100 00:09:22,020 --> 00:09:25,210 the signature of the mount binary the system obviously cannot boot 101 00:09:25,210 --> 00:09:28,810 in non-jailbroken mode. 102 00:09:28,810 --> 00:09:35,910 So, this is kind of the Golden age. So let's continue with the Industrial age. 103 00:09:35,910 --> 00:09:43,829 So with the release of the iPhone 4s and iOS 5, Apple fixed the 104 00:09:43,829 --> 00:09:49,689 BootROM bug and essentially killed limera1n. They also introduced APTickets 105 00:09:49,689 --> 00:09:55,660 and nonces to bootloaders, which I'm just mentioning because it's kind of a 106 00:09:55,660 --> 00:10:00,980 throwback for downgrading: before that you can have a phone if you update to the 107 00:10:00,980 --> 00:10:05,529 latest firmware and before you save your SHSH blobs you could just downgrade and 108 00:10:05,529 --> 00:10:09,279 then jailbreak again which wasn't a big deal but with that they also added 109 00:10:09,279 --> 00:10:13,809 downgrade protection so jailbreaking became harder. If you wanted to know more 110 00:10:13,809 --> 00:10:20,009 about how the boot process works, what SHSH blobs are, what APTickets are, you 111 00:10:20,009 --> 00:10:24,040 should check out my talk from two years ago, I go in-depth on how all of that 112 00:10:24,040 --> 00:10:30,470 works. So, I'm skipping that for this talk. So the binaries the phone boots are 113 00:10:30,470 --> 00:10:35,829 encrypted so the bootloaders are encrypted and until recently the kernel used to be 114 00:10:35,829 --> 00:10:41,749 encrypted as well. And the key encryption key is fused into the devices and it is 115 00:10:41,749 --> 00:10:46,329 impossible to get through hardware attacks. At least there's no public case 116 00:10:46,329 --> 00:10:53,100 where somebody actually got that recovered at keys so it's probably impossible, 117 00:10:53,100 --> 00:11:01,059 nobody has done it yet. So old boot files are decrypted at boot by the previous 118 00:11:01,059 --> 00:11:09,610 bootloader. And before the iPhone 4s you could actually just talk to the hardware 119 00:11:09,610 --> 00:11:15,079 iOS engine as soon as you got kernel-level code execution. But with the iPhone 4s 120 00:11:15,079 --> 00:11:19,471 they introduced a feature where before the kernel would boot they would shut off the 121 00:11:19,471 --> 00:11:25,870 iOS engine by hardware, so there is no way to decrypt bootloader files anymore so 122 00:11:25,870 --> 00:11:33,019 easily unless you got code execution in the bootloader itself. So decrypting 123 00:11:33,019 --> 00:11:38,720 bootloaders is a struggle from now on. So I think kind of because of that the 124 00:11:38,720 --> 00:11:44,810 attention shifted to userland and from now the jailbreaks kind of had to be 125 00:11:44,810 --> 00:11:50,569 untethered. So untethered here means that if you jailbreak your device, you turn it 126 00:11:50,569 --> 00:11:55,820 off, you boot it again, then the device is still jailbroken, and this is usually 127 00:11:55,820 --> 00:12:01,089 achieved through re-exploitation at some point in the boot process. So you can't 128 00:12:01,089 --> 00:12:05,529 just patch the kernel on file system because that would invalidate signatures, 129 00:12:05,529 --> 00:12:09,939 so instead you would, I don't know, add some configuration files to some demons 130 00:12:09,939 --> 00:12:16,079 which would trigger bugs and then exploit. So jailbreaks then chained many bugs 131 00:12:16,079 --> 00:12:21,249 together, sometimes six or more bugs to get initial code execution, kernel code 132 00:12:21,249 --> 00:12:28,078 execution and persistence. This somewhat changed when Apple introduced free 133 00:12:28,078 --> 00:12:33,759 developer accounts around the time they released iOS 9. So these developer 134 00:12:33,759 --> 00:12:38,949 accounts allow everybody who has an Apple ID to get a valid signing certificate for 135 00:12:38,949 --> 00:12:44,970 seven days for free. So you can actually create an XCode project and run your app 136 00:12:44,970 --> 00:12:49,939 on your physical device. Before that that was not possible, so the only way to run 137 00:12:49,939 --> 00:12:56,400 your own code on your device was to buy a paid developer account which is 100$ per 138 00:12:56,400 --> 00:13:03,149 year if you a buy personal developer account. But now you can just get that for 139 00:13:03,149 --> 00:13:07,670 free. And after seven days the certificate expires, but you can just, for free, 140 00:13:07,670 --> 00:13:12,040 request another one and keep doing that. Which is totally enough if you develop 141 00:13:12,040 --> 00:13:18,540 apps. So this kind of led to semi- untethered jailbreaks because initial code 142 00:13:18,540 --> 00:13:21,737 execution was not an issue anymore. Anybody could just get that free 143 00:13:21,737 --> 00:13:28,564 certificate, sign apps and run some kind of code that was sandboxed. So jailbreak 144 00:13:28,564 --> 00:13:36,350 focus shifted to more powerful kernel bugs which were reachable from sandbox. So we 145 00:13:36,350 --> 00:13:40,809 had jailbreaks using just one single bug or maybe just two bugs and the jailbreaks 146 00:13:40,809 --> 00:13:46,629 then were distributed as an IPA, which is an installable app people would download, 147 00:13:46,629 --> 00:13:53,489 sign themselves, put on the phone and just run the app. So semi-untethered means 148 00:13:53,489 --> 00:13:59,639 you can reboot into non-jailbroken mode, however you can get to jailbroken mode 149 00:13:59,639 --> 00:14:06,370 easily by just pressing an app. And over the years Apple stepped up its game 150 00:14:06,370 --> 00:14:13,829 constantly. So with iOS 5 they introduced ASLR address space layer randomisation, 151 00:14:13,829 --> 00:14:21,310 with iOS 6 they added kernel ASLR, with the introduction of the iPhone 5, as they 152 00:14:21,310 --> 00:14:27,949 added 64bit CPUs, which isn't really a security mitigation, it just changed a bit 153 00:14:27,949 --> 00:14:37,629 how you would exploit. So the real deal started to come with iOS 9, where they 154 00:14:37,629 --> 00:14:42,689 first introduced Kernel Patch Protection, an attempt to make the kernel immutable 155 00:14:42,689 --> 00:14:50,109 and not patchable. And they stepped up that with the iPhone 7 where they introduced 156 00:14:50,109 --> 00:14:57,551 Kernel Text Readonly Region, also known as KTRR. So with iOS 11 they removed 32bit 157 00:14:57,551 --> 00:15:03,459 libraries, which I think has very little to no impact on exploitation; it's mainly 158 00:15:03,459 --> 00:15:09,699 in the list because up to that point Cydia was compiled as a 32bit binary and that 159 00:15:09,699 --> 00:15:17,720 stopped working, that's why that had to be recompiled for 64bit, which took someone 160 00:15:17,720 --> 00:15:26,040 to do until you could get a working Cydia on 64bits iOS 11. So with the iPhone Xs 161 00:15:26,040 --> 00:15:30,989 which came out just recently they introduced Pointer Authentication Codes, 162 00:15:30,989 --> 00:15:35,386 and I'm gonna go more in detail into these hardware mitigations in the next few 163 00:15:35,386 --> 00:15:42,079 slides. So let's start with Kernel Patch Protection. So when people say KPP, they 164 00:15:42,079 --> 00:15:47,519 usually refer to what Apple calls watchtower. So watchtower, as the name 165 00:15:47,519 --> 00:15:53,769 suggests, watches over the kernel and panics when modifications are detected, 166 00:15:53,769 --> 00:15:58,859 and it prevents the kernel from being patched. At least that's the idea of it. 167 00:15:58,859 --> 00:16:03,069 It doesn't really prevent it because it's broken but when they engineered it, it 168 00:16:03,069 --> 00:16:08,689 should prevent you from patching the kernel. So how does it work? Watchtower is 169 00:16:08,689 --> 00:16:13,301 a piece of software which runs in EL3 which is the ARM exception level 3. 170 00:16:13,301 --> 00:16:18,709 So exception levels are kind of privilege separations while 3 is the highest and 0 171 00:16:18,709 --> 00:16:24,519 is the lowest. And you can kind of trigger an exception to call handler code in 172 00:16:24,519 --> 00:16:31,459 higher levels. So the idea of watchtowers that recurring events which is FPU usage 173 00:16:31,459 --> 00:16:35,720 trigger Watchtower inspection of the kernel, and you cannot really turn it off 174 00:16:35,720 --> 00:16:41,819 because you do need the FPU. So if you picture how it looks like, we have the 175 00:16:41,819 --> 00:16:46,919 Watchtower to the left (which totally looks like a lighthouse) and the 176 00:16:46,919 --> 00:16:51,149 applications at the right. So in the middle, in EL1, we have the kernel and 177 00:16:51,149 --> 00:17:00,720 recent studies revealed that this is exactly how the XNU kernel looks like. So 178 00:17:00,720 --> 00:17:06,060 how can we be worse? An event occurs from time to time which is from using userland 179 00:17:06,060 --> 00:17:11,110 application, for example JavaScript makes heavy use of floating points, and the 180 00:17:11,110 --> 00:17:15,929 event would then go to the kernel and the kernel would then trigger Watchtower as it 181 00:17:15,929 --> 00:17:24,049 tries to enable the FPU. Watchtower would scan the kernel and then if everything is 182 00:17:24,049 --> 00:17:28,710 fine it would transition execution back into the kernel which then in turn would 183 00:17:28,710 --> 00:17:36,009 transition back into userspace which can then use the FPU. However with a modified 184 00:17:36,009 --> 00:17:41,974 kernel, when Watchtower scans the kernel and detects modification, it would just 185 00:17:41,974 --> 00:17:48,940 panic. So the idea is that the kernel is forced to call Watchtower because the FPU 186 00:17:48,940 --> 00:17:54,130 is blocked otherwise. But the problem at the same time is that the kernel is in 187 00:17:54,130 --> 00:18:00,480 control before it calls watchtower. And this thing was fully defeated by qwerty in 188 00:18:00,480 --> 00:18:09,720 yalu102. So how qwerty's KPP bypass works: The idea is: you copy the kernel in memory 189 00:18:09,720 --> 00:18:15,860 and you mody the copied kernel. Then you would modify the page tables to use the 190 00:18:15,860 --> 00:18:23,981 patched kernel. And whenever the FPU triggers a Watchtower inspection, before 191 00:18:23,981 --> 00:18:29,539 actually calling Watchtower you would switch back to the unmodified kernel and 192 00:18:29,539 --> 00:18:34,059 then let it run, let it check the unmodified kernel when that returns you 193 00:18:34,059 --> 00:18:39,909 would go back to the modified kernel. So this one it looks like: we copy the kernel 194 00:18:39,909 --> 00:18:47,130 in memory, we patch the modified copy, we switch the page tables to actually use the 195 00:18:47,130 --> 00:18:53,669 modified copy and when we have the FPU event it would just switch the page tables 196 00:18:53,669 --> 00:19:00,190 back, forward the call to Watchtower, make then watch tower scan the unmodified 197 00:19:00,190 --> 00:19:08,490 kernel and after the scan we would just return to the patched kernel. So the 198 00:19:08,490 --> 00:19:13,820 problem here is: Time of check – Time of Use, the classical TOCTOU. And this works 199 00:19:13,820 --> 00:19:20,370 on the iPhone 5s, the iPhone 6 and the iPhone 6s and it's not really patchable. 200 00:19:20,370 --> 00:19:27,130 However, with the iPhone 7, Apple introduced KTRR, which kind of proves that 201 00:19:27,130 --> 00:19:34,700 and they really managed to do an unpatchable kernel. So how does KTRR work? 202 00:19:34,700 --> 00:19:40,584 So Kernel Text Readonly Region, I'm going to present as described by Siguza in his 203 00:19:40,584 --> 00:19:49,061 blog, adds an extra memory controller which is the AMCC which traps all writes to 204 00:19:49,061 --> 00:19:56,750 the read-only region. And there's extra CPU registers which mark and executable range 205 00:19:56,750 --> 00:20:02,524 which are the KTRR registers and they obviously mark a subsection of the 206 00:20:02,524 --> 00:20:08,720 read-only region, so you have hardware enforcement at boot time for read-only 207 00:20:08,720 --> 00:20:15,352 memory region and hardware enforcement at boot-time for an executable memory region. 208 00:20:15,682 --> 00:20:21,350 So this the CPU. This is the memory at the bottom. You would set the read-only region 209 00:20:21,350 --> 00:20:26,320 at boot and since that's enforced by the hardware memory controller everything 210 00:20:26,320 --> 00:20:32,470 inside that region is not writable and everything outside that region is 211 00:20:32,470 --> 00:20:40,850 writable. And the CPU got KTRR registers which mark begin and end. So the 212 00:20:40,850 --> 00:20:46,809 executable region is a subsection of the read-only region. Everything outside there 213 00:20:46,809 --> 00:20:52,246 cannot be executed by the CPU. Everything inside the read-only region cannot be 214 00:20:52,246 --> 00:20:58,679 modified. And this has not been truly bypassed yet. There's been a bypass but 215 00:20:58,679 --> 00:21:04,409 that actually targeted how that thing gets set up. But that's fakes and now it's 216 00:21:04,409 --> 00:21:11,000 probably setting up everything and so far it hasn't been bypassed. So jailbreaks are 217 00:21:11,000 --> 00:21:15,710 still around. So what are they doing? Well, they just walk around kernel patches 218 00:21:15,710 --> 00:21:22,600 and this is when KPP jailbreaks evolved. Which means, they just don't patch 219 00:21:22,600 --> 00:21:28,330 the kernel. But before we dive into that, let's take a look what previous jailbreaks 220 00:21:28,330 --> 00:21:35,029 actually did patch in the kernel. So the general goals are to disable code signing 221 00:21:35,029 --> 00:21:41,460 to disable the sandbox to make the root file system writable to somehow make 222 00:21:41,460 --> 00:21:46,951 tweaks work which involves making mobile substrate or libsubstitute work which is 223 00:21:46,951 --> 00:21:53,650 the library for hooking. And I was about to make a list of kernel patches which you 224 00:21:53,650 --> 00:22:00,220 could simply apply, however, the techniques and patches vary across 225 00:22:00,220 --> 00:22:03,750 individual jailbreaks so much that I couldn't even come up with the list of 226 00:22:03,750 --> 00:22:09,568 kernel patches among the different jailbreaks I worked on. So there's no 227 00:22:09,568 --> 00:22:13,429 general set of patches, some prefer to do it that way, some prefer to do it that 228 00:22:13,429 --> 00:22:18,970 way. So instead of doing a kind of full list, I'll just show you what the Helix 229 00:22:18,970 --> 00:22:24,340 jailbreak does patch. So the Helix jailbreak first patches the 230 00:22:24,340 --> 00:22:30,411 i_can_has_debugger, which is a boot arc. It's a variable in the kernel and if you 231 00:22:30,411 --> 00:22:36,299 set that to true that would relax the sandbox. So to relax the sandbox or to 232 00:22:36,299 --> 00:22:42,049 disable code signing usually involves multiple steps. Also since iOS 7 you need 233 00:22:42,049 --> 00:22:48,450 to patch mount because there's actual hardcoded that the root filesystem cannot 234 00:22:48,450 --> 00:22:54,539 be mounted as read-write. Since iOS 10.3, there is also hardcoded that you cannot 235 00:22:54,539 --> 00:22:59,492 mount the root filesystem without the nosuid flag, so you probably want to patch 236 00:22:59,492 --> 00:23:04,538 that out as well. And then if you patch both these you can remount the root 237 00:23:04,538 --> 00:23:09,279 filesystem as read-and-write, however you cannot actually write to the files on the 238 00:23:09,279 --> 00:23:14,419 root filesystem unless you patch Light- Weight Volume Manager which you also only 239 00:23:14,419 --> 00:23:21,220 need to do in iOS 9 up to iOS 10.3. Later when they switched to APFS you don't 240 00:23:21,220 --> 00:23:27,779 actually need that anymore. Also there's a variable called proc_enforce. You set that 241 00:23:27,779 --> 00:23:34,149 to 0 to disable code signing which is one of the things you need to do to disable 242 00:23:34,149 --> 00:23:43,090 code signing. Another flag is cs_enforcement_disable, set that to 1 to 243 00:23:43,090 --> 00:23:50,550 disable code signing. So amfi, which is Apple mobile file integrity is a kext which 244 00:23:50,550 --> 00:23:59,519 handles the code signing checks. In that kext it imports the mem-copy function. 245 00:23:59,519 --> 00:24:05,399 So there's a stub and one of the patches is to patch that stub to always return 0 246 00:24:05,399 --> 00:24:10,496 by some simple gadget. So what this does is, whenever it compares something in a 247 00:24:10,496 --> 00:24:16,370 code, it would just always compare… say that the compare succeeds and is equal. 248 00:24:16,370 --> 00:24:21,982 I'm not entirely sure what it does, so this patch dates back to Yalu 249 00:24:21,982 --> 00:24:24,010 but like just supplying that patch helps 250 00:24:24,010 --> 00:24:29,820 killing code signing, so that's why it's in there. Another thing h3lix does is, it 251 00:24:29,820 --> 00:24:36,009 adds the get-task-allow entitlement to every process and this is for allowing 252 00:24:36,009 --> 00:24:41,190 read/ write/executable mappings and this is what you want for a mobile substrate 253 00:24:41,190 --> 00:24:46,450 tweaks. So initially this entitlement is used for debugging because 254 00:24:46,450 --> 00:24:52,700 there you also need to be able to modify code at runtime for setting breakpoints 255 00:24:52,700 --> 00:24:59,580 while we use it for getting tweaks to work. Since iOS 10.3 there's... h3lix also 256 00:24:59,580 --> 00:25:07,110 patches label_update_execve patch... label_update_execve function. So the idea 257 00:25:07,110 --> 00:25:11,879 of that patch was to fix the "process-exec denied while updating label" error message 258 00:25:11,879 --> 00:25:17,389 in Cydia and several other processes. Well that seems to completely nuke the sandbox 259 00:25:17,389 --> 00:25:22,890 and also break sandbox containers so this is also the reason why if you're 260 00:25:22,890 --> 00:25:28,090 jailbreaking with h3lix apps would save their data in the global directory instead 261 00:25:28,090 --> 00:25:33,350 of their sandbox containers. And you also kill a bunch of checks in 262 00:25:33,350 --> 00:25:40,650 map_ops_policy... mac_policy_ops to relax the sandbox. So if you want to check out 263 00:25:40,650 --> 00:25:45,429 how that works yourself, unfortunately h3lix itself is not open-source and I've 264 00:25:45,429 --> 00:25:50,409 no plans of open-sourcing that. But there's two very very closely related 265 00:25:50,409 --> 00:25:55,960 projects which are open-source which is doubleH3lix – this is pretty much exactly 266 00:25:55,960 --> 00:26:03,980 the same but for 64 bit devices which does include the KPP bypass, so it also 267 00:26:03,980 --> 00:26:11,409 patches the kernel – and jelbrekTime, which is the watchOS jailbreak. But h3lix 268 00:26:11,409 --> 00:26:17,850 is for iOS 10 and the watchOS jailbreak is kind of the iOS 11 equivalent but it 269 00:26:17,850 --> 00:26:21,950 shares like most of the code. So most of the patch code is the same if you want to 270 00:26:21,950 --> 00:26:29,000 check that out. Check these out. So, KPPless jailbreaks. So the idea is, don't 271 00:26:29,000 --> 00:26:35,230 patch the kernel code but instead patch the data. So for an example we go for 272 00:26:35,230 --> 00:26:39,370 remounting root file system. We know we have hardcoded checks which forbid us to 273 00:26:39,370 --> 00:26:44,540 mount the root file system read/write. But what we can do is in the kernel there's 274 00:26:44,540 --> 00:26:49,110 this structure representing the root file system and we can patch that structure 275 00:26:49,110 --> 00:26:54,020 removing the flag saying that this structure represents the root file system. 276 00:26:54,020 --> 00:27:00,210 And we simply remove that and then we can call remount on the root file system and 277 00:27:00,210 --> 00:27:05,851 then we put back in the flag. So we kind of bypass the hardcoded check. For 278 00:27:05,851 --> 00:27:12,620 disabling code signing and disabling sandbox there are several approaches. 279 00:27:12,620 --> 00:27:17,169 In the kernel there's a trust cache so usually amfi handles the code signing. 280 00:27:17,169 --> 00:27:21,280 The demon in userspace handles the code signing requests. But the demon itself 281 00:27:21,280 --> 00:27:25,270 also needs to be code-signed. So you have the chicken and egg problem. That's why in 282 00:27:25,270 --> 00:27:31,392 the kernel there is a list of hashes of binaries which are allowed to execute. And 283 00:27:31,392 --> 00:27:35,409 this thing is actually writable because when you mount the developer disk image it 284 00:27:35,409 --> 00:27:40,919 actually adds some debugging things to it so you can simply inject your own hash 285 00:27:40,919 --> 00:27:46,779 into the trust cache making the binary trusted. Another approach taken by 286 00:27:46,779 --> 00:27:51,830 jailbreakd and the latest electro jailbreak is to have a process, in this 287 00:27:51,830 --> 00:27:58,070 case jailbreakd, which would patch the processes on creation, so when you spawn a 288 00:27:58,070 --> 00:28:03,889 process that thing would immediately stop the process, go into the kernel, look up 289 00:28:03,889 --> 00:28:10,620 the structure and remove the flags saying "kill this process when the cold 290 00:28:10,620 --> 00:28:15,809 signature becomes involved" and it will invalid. And it would also add the 291 00:28:15,809 --> 00:28:20,808 get-task-low entitlements. And then after it's done that it would resume the process 292 00:28:20,808 --> 00:28:25,850 and then the process won't get killed any more because it's kind of already trusted. 293 00:28:25,850 --> 00:28:33,450 And the third approach taken or demoed by bazad was to take over amfid and userspace 294 00:28:33,450 --> 00:28:41,210 completely. So if you can get a Mac port to launchd or to amfid you can impersonate 295 00:28:41,210 --> 00:28:47,340 that and whenever the kernel asks and feels that it's trusted you would reply 296 00:28:47,340 --> 00:28:51,190 "Okay yeah that's trusted that's fine you can run it" so that way you don't need 297 00:28:51,190 --> 00:28:59,510 to go for the kernel at all. So future jailbreaks. Kernel patches are not really 298 00:28:59,510 --> 00:29:04,879 possible anymore and they're not even required. Because we can still patch the 299 00:29:04,879 --> 00:29:13,080 kernel data or not go for the kernel at all. But we're still not done yet, we 300 00:29:13,080 --> 00:29:21,639 still didn't go for Post-Apocalyptic or short PAC. Well actually 301 00:29:21,639 --> 00:29:25,039 PAC stands for pointer authentication codes but you get the joke. 302 00:29:25,039 --> 00:29:30,590 So pointer authentication codes were introduced with the iPhone Xs and if we 303 00:29:30,590 --> 00:29:36,532 quote Qualcomm "This is a stronger version off stack protection". And pointer 304 00:29:36,532 --> 00:29:41,809 authentication codes are similar to message authentication codes but for 305 00:29:41,809 --> 00:29:47,490 pointers, if you are familiar with that. And the idea of that is to protect data in 306 00:29:47,490 --> 00:29:55,389 memory in relation to context with a secret key. So the data in memory could be 307 00:29:55,389 --> 00:30:00,869 the return value and the context could be the stack pointer or data in memory could 308 00:30:00,869 --> 00:30:07,749 be a function pointer and the context could be a vtable. So if we take a look 309 00:30:07,749 --> 00:30:14,649 how PAC is implemented. So at the left you can see function entry and like function 310 00:30:14,649 --> 00:30:19,740 prologue and function epilogue without PAC and with PAC the only thing that would be 311 00:30:19,740 --> 00:30:27,139 changed is when you enter a function before actually doing anything inside it, 312 00:30:27,139 --> 00:30:31,980 you would normally store the return value on the stack but when doing that you would 313 00:30:31,980 --> 00:30:39,299 first authenticate the pointer with the context and then kinda create the 314 00:30:39,299 --> 00:30:44,358 signature and store it inside the pointer and then put it on the stack. And then 315 00:30:44,358 --> 00:30:49,549 when you leave the function you would just take back the pointer, again calculate the 316 00:30:49,549 --> 00:30:56,429 signature and see if these both signatures matches and if they do then just return 317 00:30:56,429 --> 00:31:03,977 and if the signature's invalid you would just throw a hardware fault. So this is 318 00:31:03,977 --> 00:31:10,649 how it looks like for 64-bit pointers. You don't really use all of the available bits. 319 00:31:10,649 --> 00:31:16,820 So usually you use 48 bits for virtual memory which is more than enough. 320 00:31:16,820 --> 00:31:22,200 If you use memory tagging you have seven bits left for putting in 321 00:31:22,200 --> 00:31:28,989 the signature or if you do not use memory tagging you can use up to 15 bits for the 322 00:31:28,989 --> 00:31:39,852 pointer authentication code. So the basic idea of PAC is to kill ROP like code reuse 323 00:31:39,852 --> 00:31:46,402 attacks. You cannot simply smash the stack and create a ROP chain because every 324 00:31:46,402 --> 00:31:53,899 return would have an instruction verifying the signature of the return value and that 325 00:31:53,899 --> 00:32:00,580 means you would need to sign everything, every single of these pointers and since 326 00:32:00,580 --> 00:32:07,103 you don't know the key you can't do that in advance. So you cannot modify a return 327 00:32:07,103 --> 00:32:12,049 value and you cannot swap two signed values on the stack unless the stack 328 00:32:12,049 --> 00:32:22,677 pointer is the same for both. Can we bypass it? Maybe. I don't know. But we can 329 00:32:22,690 --> 00:32:29,484 take a look at how that thing is implemented. So if we take a look at the 330 00:32:29,484 --> 00:32:35,792 ARM slides you can see that PAC is basically derived from a pointer and a 331 00:32:35,792 --> 00:32:41,659 64-bit context value and the key and we put all of that in the algorithm P. And 332 00:32:41,659 --> 00:32:48,230 that gives us the PAC which we store in the unused bits. So the algorithm P can 333 00:32:48,230 --> 00:32:56,450 either be QARMA or it can be something completely custom. And the instructions, 334 00:32:56,450 --> 00:33:03,419 the ARM instructions, kind of hide the implementation details. So if you would go 335 00:33:03,419 --> 00:33:11,350 for attacking PAC, there's two ways of attack strategies. We can either try and 336 00:33:11,350 --> 00:33:16,140 go straight for the cryptographic primitive like take a look what cipher it 337 00:33:16,140 --> 00:33:22,419 is or how that cipher is implemented. Maybe it's weak or we can go and attack 338 00:33:22,419 --> 00:33:29,029 the implementation. So if we go and attack the implementation we could look for 339 00:33:29,029 --> 00:33:35,379 signing primitives, which could be like small gadgets we could jump to somehow, 340 00:33:35,379 --> 00:33:42,499 somehow execute to sign a value which could be either an arbitrary context 341 00:33:42,499 --> 00:33:50,369 signing gadget or maybe a fixed context signing gadget. We could also look for 342 00:33:50,369 --> 00:33:56,640 unauthenticated code, for example I imagine the code which sets up PAC itself 343 00:33:56,640 --> 00:34:03,529 is probably not protected by PAC because you can't sign the pointer if the key is 344 00:34:03,529 --> 00:34:08,900 not set up yet. Maybe that code is still accessible. We could look for something 345 00:34:08,900 --> 00:34:17,720 like that. We could also try to replace pointers which share the same context. 346 00:34:17,720 --> 00:34:23,710 It's probably not feasible for return values on the stack, but maybe it's 347 00:34:23,710 --> 00:34:30,089 feasible for swapping pointers in the vtable. Or maybe you come up with your own 348 00:34:30,089 --> 00:34:37,049 clever idea how to bypass that. These are just like some ideas. So I want to make a 349 00:34:37,049 --> 00:34:44,639 point here, that in my opinion it doesn't make much sense to try to attack the 350 00:34:44,639 --> 00:34:51,550 underlying cryptography on PAC, so I think that if we go for attacking PAC it makes 351 00:34:51,550 --> 00:34:56,329 much more sense to look for implementation attacks and not attacking the cryptography 352 00:34:56,329 --> 00:35:04,290 and the next few slides are just there to explain why I think that. So if we take a 353 00:35:04,290 --> 00:35:10,309 look at QARMA which was proposed by ARM as being one of the possible ways of 354 00:35:10,309 --> 00:35:16,750 implementing PAC. PAC, uhm, QARMA is a tweakable block cipher, so it takes an 355 00:35:16,750 --> 00:35:22,859 input, a tweak and gives you an output. Which kind of fits perfectly for what we 356 00:35:22,859 --> 00:35:30,390 want. And then I started looking at QARMA and came up with ideas on how are you 357 00:35:30,390 --> 00:35:35,780 could maybe attack that cipher. At some point I realized that practical crypto 358 00:35:35,780 --> 00:35:42,550 attacks on QARMA if there will be any in the future will probably that's what I 359 00:35:42,550 --> 00:35:51,140 think completely irrelevant to the PAC security. So why's that? If we define – 360 00:35:51,140 --> 00:35:55,349 So just so you know, the next few slides I'm going to bore you with some math but 361 00:35:55,349 --> 00:36:03,510 it's not too complex. So if we define PAC as a function which takes a 128 bit input 362 00:36:03,510 --> 00:36:11,540 and a 120-bit key and maps it to 15 bits output. Or we can more realistically 363 00:36:11,540 --> 00:36:18,190 define it as a function which takes 96 bits input with a 128-bit key because we 364 00:36:18,190 --> 00:36:24,080 have a 48-bit pointer because the other ones we can't use because that's where we 365 00:36:24,080 --> 00:36:29,770 store the signature and we're most likely using the stack pointer as a context so 366 00:36:29,770 --> 00:36:38,970 that one will also only use 48-bit pointers, 48 bits. Then we have PAC as a 367 00:36:38,970 --> 00:36:44,297 construct so then we define the attacker with following capabilities. The attacker 368 00:36:44,297 --> 00:36:50,650 is allowed to observe some pointer and signature pairs and I assume that you can 369 00:36:50,650 --> 00:36:54,579 get that through some info leaks, for example you have some bug in the code 370 00:36:54,579 --> 00:37:01,220 which lets you dump a portion of the stack with a bunch of signed pointers. 371 00:37:01,220 --> 00:37:06,829 This is why you can observe some, not all, but you can see some and I would also 372 00:37:06,829 --> 00:37:13,240 allow to have the attacker be able to slightly modify the context and what I 373 00:37:13,240 --> 00:37:19,619 mean by that is I imagine a scenario where the attacker could maybe shift the stack, 374 00:37:19,619 --> 00:37:25,277 maybe through more nested function calls before executing the leak which will give 375 00:37:25,277 --> 00:37:31,821 you actually two signatures for the same pointer but with a different context. 376 00:37:31,821 --> 00:37:39,240 Maybe that's somewhat helpful. But still we realize that the attacker, the 377 00:37:39,240 --> 00:37:45,990 cryptographic attacker, is super weak so the only other cryptographic problem there 378 00:37:45,990 --> 00:37:52,570 could be is collisions. And for those of you who seen my last talk they probably 379 00:37:52,570 --> 00:38:02,280 know I love collisions. So we have 48-bit pointer, 48-bit context and 128-bit key. 380 00:38:02,280 --> 00:38:08,559 We sum that up and we divide that by the 15-bit of output we get from PAC which 381 00:38:08,559 --> 00:38:17,069 gives us 2 to the power of 209 possible collisions because we map so many bits to 382 00:38:17,069 --> 00:38:24,670 so little bits. But even if we reduce the pointers because practically probably less 383 00:38:24,670 --> 00:38:33,059 than 34 bit of a pointer are really used, we still get 2 to the power 181 384 00:38:33,059 --> 00:38:38,340 collisions, which is a lot of collisions but the bad thing here is random 385 00:38:38,340 --> 00:38:45,323 collisions are not very useful to us unless we can predict them somehow. So 386 00:38:45,323 --> 00:38:50,700 let's take a look how a cryptographically secure MAC is defined. So a MAC is defined 387 00:38:50,700 --> 00:38:55,250 as following: Let p be a MAC with the following components and those are 388 00:38:55,250 --> 00:39:00,791 basically Gen(), Mac() and Vrfy(). So Gen() just somehow generates a key, it's 389 00:39:00,791 --> 00:39:06,010 only here for the sake of mathematical completeness. Just assume we generate the 390 00:39:06,010 --> 00:39:14,385 key by randomly choosing n bits or however how much bits the key needs. And Mac() is 391 00:39:14,385 --> 00:39:22,020 just a function where you put in an n-bit message called m and it gives us a 392 00:39:22,020 --> 00:39:25,569 signature t. And I'm going to say signature but in reality I mean a message 393 00:39:25,569 --> 00:39:30,940 authentication code. And the third function is Vrfy() and you give it a 394 00:39:30,940 --> 00:39:34,880 message and a signature and that just returns true if that signature is valid 395 00:39:34,880 --> 00:39:41,670 for the message or false if it's not. And when cryptographers prove that something 396 00:39:41,670 --> 00:39:46,700 is secure they like to play games. So I'm gonna to show you my favorite game, which 397 00:39:46,700 --> 00:39:52,230 is Mac-forge game. So the game is pretty simple you have to the left the game 398 00:39:52,230 --> 00:39:58,652 master which is playing Mac-forge and to the right the attacker. So the game 399 00:39:58,652 --> 00:40:04,369 starts when the Mac-forge game master informs the attacker how much bits are we 400 00:40:04,369 --> 00:40:08,609 playing. So this is the first 1 to the power of n, basically means hey we're 401 00:40:08,609 --> 00:40:13,934 having MAC-forge with, I don't know, 64-bit messages so the attacker knows the 402 00:40:13,934 --> 00:40:22,130 size. Then the game master just generates the key and then the attacker can choose to 403 00:40:22,130 --> 00:40:30,500 q messages of n-bit length and send them over to the game master and the game 404 00:40:30,500 --> 00:40:36,210 master will generate signatures and send them back. So then the attacker can 405 00:40:36,210 --> 00:40:42,390 observe all the messages he generated and all the matching signatures. So what the 406 00:40:42,390 --> 00:40:47,059 attacker needs to do then is to choose another message which he did not send over 407 00:40:47,059 --> 00:40:56,119 yet and somehow come up with a valid signature and if he can manage to do that 408 00:40:56,119 --> 00:41:02,619 he sends it over and if that's actually a valid signature for the message then he 409 00:41:02,619 --> 00:41:09,490 wins the game, otherwise he looses the game. So we say a Mac is secure if the 410 00:41:09,490 --> 00:41:15,996 probability that an attacker can somehow win this is negligible. So I'm gonna spare 411 00:41:15,996 --> 00:41:20,059 you the mathematical definition of what negligible means but like just guessing or 412 00:41:20,059 --> 00:41:27,670 trying means that it's still secure if that's the best tech. So as you can see is 413 00:41:27,670 --> 00:41:36,650 a MAC which is secure needs to withstand this. But for our PAC attacker we do not 414 00:41:36,650 --> 00:41:43,105 even have this oracle. So our attacker for PAC is even weaker than that. So why do we 415 00:41:43,105 --> 00:41:49,230 not have this oracle? Well simple if we allow the attacker to sign arbitrary 416 00:41:49,230 --> 00:41:55,819 messages the attacker wouldn't even need to try to somehow get the key or forged 417 00:41:55,819 --> 00:42:00,900 message because then he could just send over all the messages. All the pointers he 418 00:42:00,900 --> 00:42:05,390 wants to sign get back signed pointers and you wouldn't need to bother about breaking 419 00:42:05,390 --> 00:42:11,109 the crypto at all. So basically the point I'm trying to make here is that the PAC 420 00:42:11,109 --> 00:42:18,609 attacker is weaker than a MAC attacker. So every secure MAC we know is also a secure 421 00:42:18,609 --> 00:42:28,750 PAC, but even then an insecure MAC might still be sufficiently secure for PAC so 422 00:42:28,750 --> 00:42:33,900 secure MACs have been around for a while and thus in my opinion, I think if 423 00:42:33,900 --> 00:42:41,250 somebody, who knows what he's doing, designs a PAC algorithm today it will 424 00:42:41,250 --> 00:42:49,069 likely be secure. So instead of going for the crypto I think we should rather go for 425 00:42:49,069 --> 00:42:53,579 implementation attacks instead because those will be around forever. And by that 426 00:42:53,579 --> 00:43:00,170 I mean well you can either see how the crypto itself is implemented, what I mean 427 00:43:00,170 --> 00:43:07,224 especially by that is you could see how the PAC is used in the actual code. Maybe 428 00:43:07,224 --> 00:43:12,155 you can find signing oracles, maybe you can find unauthenticated code. I think 429 00:43:12,155 --> 00:43:20,260 this is where we need to go if wanna bypass PAC somehow. So just to recap where 430 00:43:20,260 --> 00:43:29,987 we're coming from. Future iPhone hacks probably gonna not try to bypass KTRR. I 431 00:43:29,987 --> 00:43:35,420 think they will not try to patch Kernel code because we can achieve pretty much 432 00:43:35,420 --> 00:43:41,240 all the things we want to achieve for end user jailbreak without having to patch the 433 00:43:41,240 --> 00:43:49,110 kernel so far. And I think people are going to struggle a bit. At least a bit 434 00:43:49,110 --> 00:43:56,885 when exploiting with PAC because that kind will either make some bugs unexploitable 435 00:43:56,885 --> 00:44:04,550 or really really hard to exploit. Also maybe we're gonna avoid the Kernel at all 436 00:44:04,550 --> 00:44:10,140 as it has demoed that userland-only jailbreaks are possible. Maybe we're going 437 00:44:10,140 --> 00:44:15,680 to recalculate what the low hanging fruits are. Maybe just go back to iBoot or look 438 00:44:15,680 --> 00:44:22,490 for what other thing is interesting. So, that was about it, thank you very much for 439 00:44:22,490 --> 00:44:34,259 your attention. *Applause* 440 00:44:34,259 --> 00:44:38,730 Herald-Engel: Thank you, sir. If you would like to ask a question please line up 441 00:44:38,730 --> 00:44:48,809 on the microphones in the room. We do not have a question from the Internet. 442 00:44:48,809 --> 00:44:53,369 One question over there, yes please. Question: Hi. I would like to be 443 00:44:53,369 --> 00:44:58,109 interested what your comment is on the statement from Zarek that basically 444 00:44:58,109 --> 00:45:01,960 jailbreaking is not a thing anymore because you're breaking so much security 445 00:45:01,960 --> 00:45:07,520 features that makes the phone basically more insecure than the former reasons of 446 00:45:07,520 --> 00:45:15,579 doing a jailbreaking allow for. tihmstar: Well, jailbreaking -- I don't 447 00:45:15,579 --> 00:45:21,540 think jailbreaking itself nowadays makes a phone really insecure. So of course if you 448 00:45:21,540 --> 00:45:25,855 patched a kernel and disable all of the security features that will be less 449 00:45:25,855 --> 00:45:31,020 secure. But if you take a look what we have here with the unpatchable kernel I 450 00:45:31,020 --> 00:45:35,700 think the main downside of being jailbroken is the fact that you cannot go 451 00:45:35,700 --> 00:45:42,419 to the latest software version because you want the box to be in there to have the 452 00:45:42,419 --> 00:45:51,270 jailbreak. So I don't really think if you have like a KTRR device the jailbreak 453 00:45:51,270 --> 00:45:56,079 itself makes it less secure. Just the fact that you are not on the latest firmware is 454 00:45:56,079 --> 00:46:01,000 the insecure part of it. Herald: Alright, thank you. 455 00:46:01,000 --> 00:46:05,759 Microphone number two, your question. Mic #2: Hi good talk. Could you go back to 456 00:46:05,759 --> 00:46:13,589 the capabilities of the adversary please? Yeah. So you said you can do basically two 457 00:46:13,589 --> 00:46:17,690 things right. This one, yes. Yeah you can observe some pointers and some signature 458 00:46:17,690 --> 00:46:23,960 pairs. But why is this not an oracle? tihmstar: Because you cannot choose... 459 00:46:23,960 --> 00:46:26,420 Mic #2: Your message yourself. tihmstar: ...your message yourself. 460 00:46:26,420 --> 00:46:31,080 Mic #2: And you have also an oracle that says if the signature is valid. For a 461 00:46:31,080 --> 00:46:33,829 chosen message. tihmstar: Well yeah but this is if you 462 00:46:33,829 --> 00:46:39,490 take a look at the game and this game for a secure MAC the attacker can choose up to 463 00:46:39,490 --> 00:46:44,890 q messages sending over... like he can do whatever he wants with that messages and 464 00:46:44,890 --> 00:46:51,900 get a signature while the package hacker can see a few very limited amount of 465 00:46:51,900 --> 00:46:59,243 messages and their matching signature and he has little to no influence on these 466 00:46:59,243 --> 00:47:04,800 messages. Mic #2: Okay. So it's a bit weaker. 467 00:47:04,800 --> 00:47:08,240 tihmstar: So yeah that's the point. Just that it's weaker. 468 00:47:08,240 --> 00:47:10,600 Mic #2: Thanks. Herald-Engel: Do we have a question from 469 00:47:10,600 --> 00:47:23,599 the internet? No. OK. Yes please. All right then I don't see anyone else being 470 00:47:23,599 --> 00:47:31,214 lined up and... please give a lot of applause for tihmstar for his awesome 471 00:47:31,214 --> 00:47:35,955 talk! *Applause* 472 00:47:35,955 --> 00:47:46,137 *postroll music* 473 00:47:46,137 --> 00:47:58,000 subtitles created by c3subtitles.de in the year 2020. Join, and help us!