0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1262 Thanks! 1 00:00:20,550 --> 00:00:22,679 So the next talk is 2 00:00:22,680 --> 00:00:25,199 called Katie R W The Cherny 3 00:00:25,200 --> 00:00:27,510 to build a debacle iPhone. 4 00:00:28,530 --> 00:00:30,689 Well, hardware debugging of 5 00:00:30,690 --> 00:00:32,520 an iPhone is usually not possible. 6 00:00:33,750 --> 00:00:35,669 It's not possible if IOW devices or it 7 00:00:35,670 --> 00:00:38,549 wasn't possible if I was devices 8 00:00:38,550 --> 00:00:41,009 and security research of the kernel 9 00:00:41,010 --> 00:00:42,869 is therefore quite a challenge. 10 00:00:45,010 --> 00:00:47,069 Well, move the apple a 10 11 00:00:47,070 --> 00:00:49,389 chip. Apple implemented a thing called 12 00:00:49,390 --> 00:00:51,549 kernel text read only regions, which 13 00:00:51,550 --> 00:00:53,889 is called Katie are 14 00:00:53,890 --> 00:00:55,189 in charge. 15 00:00:55,190 --> 00:00:57,399 And Brendan Asset 16 00:00:57,400 --> 00:00:59,289 of Google Project 0. 17 00:00:59,290 --> 00:01:02,349 He found a way to 18 00:01:02,350 --> 00:01:04,299 make a debacle iPhone. 19 00:01:04,300 --> 00:01:06,429 And tonight, he's gonna 20 00:01:06,430 --> 00:01:08,159 tell us how he broke this. 21 00:01:08,160 --> 00:01:10,539 Cathi. Katie are and 22 00:01:10,540 --> 00:01:12,939 how he made, uh, debacle iPhone 23 00:01:12,940 --> 00:01:15,339 out of a regular production iPhone. 24 00:01:15,340 --> 00:01:17,379 Please give a warm round of applause to 25 00:01:17,380 --> 00:01:18,380 Brendan. 26 00:01:20,870 --> 00:01:21,870 Thanks. 27 00:01:23,060 --> 00:01:24,289 Awesome. 28 00:01:24,290 --> 00:01:26,359 Thank you very much. I'm very excited to 29 00:01:26,360 --> 00:01:28,099 be here. Thank you for showing up to my 30 00:01:28,100 --> 00:01:29,100 talk. 31 00:01:29,480 --> 00:01:31,609 And today, I'm going to take you 32 00:01:31,610 --> 00:01:33,679 along my journey to 33 00:01:33,680 --> 00:01:36,019 build a capability that I've wanted to 34 00:01:36,020 --> 00:01:38,569 have for a very long time. 35 00:01:38,570 --> 00:01:40,459 A deep, huggable iPhone. 36 00:01:41,720 --> 00:01:43,669 So what exactly do I mean by a deep, 37 00:01:43,670 --> 00:01:45,319 huggable iPhone? 38 00:01:45,320 --> 00:01:46,609 Well, in order to kind of give you the 39 00:01:46,610 --> 00:01:48,679 context that you need to understand this, 40 00:01:48,680 --> 00:01:50,029 I'm gonna need to talk about something 41 00:01:50,030 --> 00:01:52,099 which isn't frequently talked 42 00:01:52,100 --> 00:01:53,419 about in public. 43 00:01:53,420 --> 00:01:55,699 And that's the thing called Dev fuzed 44 00:01:55,700 --> 00:01:58,429 device's development fuzed devices, 45 00:01:58,430 --> 00:02:00,409 prototype iPhones. 46 00:02:00,410 --> 00:02:02,809 These are all names for similar 47 00:02:02,810 --> 00:02:04,909 concept, which is a 48 00:02:04,910 --> 00:02:07,039 type of device, a type of iPhone that 49 00:02:07,040 --> 00:02:09,258 has extra 50 00:02:09,259 --> 00:02:11,419 debug capabilities built into it. 51 00:02:11,420 --> 00:02:14,269 So that's things like serial liar, debug 52 00:02:14,270 --> 00:02:17,029 J Tag, basically functionality 53 00:02:17,030 --> 00:02:19,369 that now allows you to debug 54 00:02:19,370 --> 00:02:20,899 the phone at a very low level. 55 00:02:20,900 --> 00:02:22,969 For example, doing things like single, 56 00:02:22,970 --> 00:02:25,069 stepping through the bootloader, putting 57 00:02:25,070 --> 00:02:26,899 breakpoints in kernel mode and dumping 58 00:02:26,900 --> 00:02:29,209 registers, modifying registers, 59 00:02:29,210 --> 00:02:30,529 sorts of things which would be very 60 00:02:30,530 --> 00:02:32,629 important for Apple engineers to be 61 00:02:32,630 --> 00:02:34,939 able to do, but which are 62 00:02:34,940 --> 00:02:36,889 definitely not something Apple wants 63 00:02:36,890 --> 00:02:38,269 available on production. 64 00:02:38,270 --> 00:02:40,490 IPhone's distributed en masse. 65 00:02:41,600 --> 00:02:43,819 Now, in order to connect to 66 00:02:43,820 --> 00:02:45,469 the special type of iPhone's debug 67 00:02:45,470 --> 00:02:48,079 capabilities, you need a 68 00:02:48,080 --> 00:02:50,419 really special type of cable 69 00:02:50,420 --> 00:02:52,889 usually called a probe. 70 00:02:52,890 --> 00:02:55,069 It here's an example of what's called 71 00:02:55,070 --> 00:02:56,839 a Kanzi cable. 72 00:02:56,840 --> 00:02:58,939 It has a special lightning connector 73 00:02:58,940 --> 00:03:01,339 on one end, which 74 00:03:01,340 --> 00:03:02,779 has a special accessory. 75 00:03:02,780 --> 00:03:04,459 I.T. burned into it, which allows it to 76 00:03:04,460 --> 00:03:06,739 communicate with the debug hardware 77 00:03:06,740 --> 00:03:07,909 on the phone. 78 00:03:07,910 --> 00:03:09,799 It has a controller, which is the chunky 79 00:03:09,800 --> 00:03:11,449 part in the middle, which is able to talk 80 00:03:11,450 --> 00:03:13,009 the debugging protocol. 81 00:03:13,010 --> 00:03:15,109 And it has a USP port 82 00:03:15,110 --> 00:03:16,519 on the other end, which you can connect 83 00:03:16,520 --> 00:03:18,079 to a laptop. 84 00:03:18,080 --> 00:03:20,779 And on a laptop you would typically run 85 00:03:20,780 --> 00:03:21,859 software. 86 00:03:21,860 --> 00:03:23,779 For example, there's this tool which you 87 00:03:23,780 --> 00:03:26,299 can find online called Astra. 88 00:03:26,300 --> 00:03:28,579 This is not software which 89 00:03:28,580 --> 00:03:30,529 Apple is willingly distributing. 90 00:03:30,530 --> 00:03:32,689 This is kind of, as I understand it, 91 00:03:32,690 --> 00:03:34,339 leaked code. 92 00:03:34,340 --> 00:03:35,840 So it's not something which 93 00:03:37,400 --> 00:03:39,859 is like, you know, sanctioned, 94 00:03:39,860 --> 00:03:42,169 but there are people who are able to 95 00:03:42,170 --> 00:03:44,419 obtain this software and use 96 00:03:44,420 --> 00:03:47,689 it to operate these debugging probes. 97 00:03:47,690 --> 00:03:49,519 Here's an example of a screenshot where 98 00:03:49,520 --> 00:03:51,709 someone was able to use a 99 00:03:51,710 --> 00:03:54,319 Kong serial wire debug probe 100 00:03:54,320 --> 00:03:56,779 and connect it to a 32 bit 101 00:03:56,780 --> 00:03:59,149 dev used iPhone and 102 00:03:59,150 --> 00:04:01,159 you can see registered dumps. 103 00:04:01,160 --> 00:04:03,109 You can read and write memory dos, all 104 00:04:03,110 --> 00:04:06,409 sorts of really low level debugging 105 00:04:06,410 --> 00:04:07,410 on this iPhone. 106 00:04:08,330 --> 00:04:10,849 Now I need to say I 107 00:04:10,850 --> 00:04:12,919 do not use dev use 108 00:04:12,920 --> 00:04:13,849 devices. 109 00:04:13,850 --> 00:04:15,859 I don't have access to these devices. 110 00:04:15,860 --> 00:04:17,299 I don't want to have access to these 111 00:04:17,300 --> 00:04:19,369 devices to do my work. 112 00:04:19,370 --> 00:04:21,499 That being said, it would really 113 00:04:21,500 --> 00:04:23,659 be incredibly useful to 114 00:04:23,660 --> 00:04:25,759 have such a low level and 115 00:04:25,760 --> 00:04:27,529 powerful debug capability. 116 00:04:29,330 --> 00:04:31,579 So this is the motivation for 117 00:04:31,580 --> 00:04:33,169 my research project. 118 00:04:33,170 --> 00:04:36,199 I wanted to find some way to build 119 00:04:36,200 --> 00:04:38,419 a debug capability on 120 00:04:38,420 --> 00:04:39,470 a regular 121 00:04:40,790 --> 00:04:43,019 Apple certified iPhone. 122 00:04:44,180 --> 00:04:46,589 Some way to build my own home brewed 123 00:04:46,590 --> 00:04:47,590 phone. 124 00:04:47,930 --> 00:04:49,129 And there are a number of different features 125 00:04:49,130 --> 00:04:51,519 that I wanted present in this homebrew 126 00:04:51,520 --> 00:04:52,909 dev phone. 127 00:04:52,910 --> 00:04:54,889 I wanted the ability to patch kernel 128 00:04:54,890 --> 00:04:57,019 memory and in particular the ability 129 00:04:57,020 --> 00:04:59,209 to patch the executable 130 00:04:59,210 --> 00:05:00,139 code in the kernel. 131 00:05:00,140 --> 00:05:02,389 For example, modifying existing 132 00:05:02,390 --> 00:05:04,639 instructions or injecting 133 00:05:04,640 --> 00:05:06,260 kernel shell code or things like that. 134 00:05:07,640 --> 00:05:09,889 I wanted the ability to 135 00:05:09,890 --> 00:05:11,809 kind of do your standard debugger feature 136 00:05:11,810 --> 00:05:13,850 set breakpoints, set watch points. 137 00:05:16,070 --> 00:05:18,199 The third item that I wanted this debug 138 00:05:18,200 --> 00:05:20,899 phone to be capable of is I wanted it to 139 00:05:20,900 --> 00:05:23,479 use only, you know, standard 140 00:05:23,480 --> 00:05:24,659 off the shelf debugger. 141 00:05:24,660 --> 00:05:26,929 So I didn't want to use to depend 142 00:05:26,930 --> 00:05:30,349 upon a proprietary 143 00:05:30,350 --> 00:05:32,359 Apple software like astronauts in order 144 00:05:32,360 --> 00:05:33,360 to operate. 145 00:05:34,900 --> 00:05:37,489 The next item is I wanted this 146 00:05:37,490 --> 00:05:39,559 homebrew def phone to be 147 00:05:39,560 --> 00:05:41,839 updated all. So I wanted to find 148 00:05:41,840 --> 00:05:44,419 some sort of low level vulnerability 149 00:05:44,420 --> 00:05:46,369 such that if I'm going to spend, you 150 00:05:46,370 --> 00:05:49,099 know, three months trying to create this 151 00:05:49,100 --> 00:05:51,229 debug cell phone and then Apple 152 00:05:51,230 --> 00:05:53,959 is able to patch the 153 00:05:53,960 --> 00:05:55,669 whatever technique was being used in the 154 00:05:55,670 --> 00:05:56,839 next version of ISIS. 155 00:05:56,840 --> 00:05:58,729 And now all of a sudden, I no longer am 156 00:05:58,730 --> 00:06:01,099 able to debug the latest version. 157 00:06:01,100 --> 00:06:02,749 Certainly this would be very useful. 158 00:06:02,750 --> 00:06:05,089 I can always def 159 00:06:05,090 --> 00:06:06,289 kind of the differences between 160 00:06:06,290 --> 00:06:07,459 subsequent versions of IO. 161 00:06:07,460 --> 00:06:09,619 Esta still got useful information 162 00:06:09,620 --> 00:06:12,139 from my debugger, but 163 00:06:12,140 --> 00:06:13,429 I would really love to be able to 164 00:06:13,430 --> 00:06:15,559 amortize the development costs to 165 00:06:15,560 --> 00:06:17,959 the debugger over many 166 00:06:17,960 --> 00:06:20,089 iterations of the IO is operating 167 00:06:20,090 --> 00:06:21,949 system. So keep this capability alive as 168 00:06:21,950 --> 00:06:23,689 long as possible. 169 00:06:23,690 --> 00:06:25,489 In practice, what this meant was I was 170 00:06:25,490 --> 00:06:27,439 going to be looking for perhaps a 171 00:06:27,440 --> 00:06:29,809 bootloader vulnerability, 172 00:06:29,810 --> 00:06:31,339 maybe some sort of hardware bug, 173 00:06:31,340 --> 00:06:33,769 something which was either difficult 174 00:06:33,770 --> 00:06:36,019 to patch or even if it was 175 00:06:36,020 --> 00:06:38,119 patched. It was early enough in the 176 00:06:38,120 --> 00:06:39,829 boot process that it would still be 177 00:06:39,830 --> 00:06:42,439 possible to update 178 00:06:42,440 --> 00:06:44,539 the version of the ISIS 179 00:06:44,540 --> 00:06:46,739 kernel running on the device. 180 00:06:48,200 --> 00:06:50,299 And the final thing is I 181 00:06:50,300 --> 00:06:52,399 wanted this damn phone to 182 00:06:52,400 --> 00:06:55,039 use only parts that you could obtain 183 00:06:55,040 --> 00:06:56,329 at an Apple store. 184 00:06:56,330 --> 00:06:58,579 So no specially fuzed CPE 185 00:06:58,580 --> 00:07:00,679 use. No 186 00:07:00,680 --> 00:07:02,779 special debug cables. 187 00:07:02,780 --> 00:07:03,780 Nothing of that sort. 188 00:07:06,060 --> 00:07:08,189 Now, I want to mention something really, 189 00:07:08,190 --> 00:07:10,589 really important that happened, probably 190 00:07:10,590 --> 00:07:12,509 the most important thing to happen to 191 00:07:12,510 --> 00:07:14,699 Iowa security research in 192 00:07:14,700 --> 00:07:17,219 several years, and that is 193 00:07:17,220 --> 00:07:19,199 pretty much just a couple of days before 194 00:07:19,200 --> 00:07:20,679 I was about to open source. 195 00:07:20,680 --> 00:07:23,099 OK, TRW Axiom X 196 00:07:23,100 --> 00:07:25,709 released a boot rom exploit 197 00:07:25,710 --> 00:07:28,109 for all iPhones between 198 00:07:28,110 --> 00:07:30,359 the iPhone for us and the iPhone 199 00:07:30,360 --> 00:07:31,379 10. 200 00:07:31,380 --> 00:07:34,409 Now, the boot rom exploit is actually 201 00:07:34,410 --> 00:07:36,959 strictly more powerful than 202 00:07:36,960 --> 00:07:39,749 the capability used in K TRW. 203 00:07:39,750 --> 00:07:41,609 Everything that I want to do in my debug 204 00:07:41,610 --> 00:07:43,739 phone is totally possible to do using 205 00:07:43,740 --> 00:07:44,920 the boot rom x alone. 206 00:07:46,140 --> 00:07:48,179 So I want to tell you this just so that 207 00:07:48,180 --> 00:07:50,309 you're aware that many of the assumptions 208 00:07:50,310 --> 00:07:52,529 that I made going into this 209 00:07:52,530 --> 00:07:54,869 project really don't hold anymore. 210 00:07:54,870 --> 00:07:56,189 But they did hold at the time that I 211 00:07:56,190 --> 00:07:57,240 started this research, 212 00:07:58,310 --> 00:08:00,479 and I do expect that future debug 213 00:08:00,480 --> 00:08:02,099 capabilities and future research 214 00:08:02,100 --> 00:08:04,049 platforms on the iPhone will be based 215 00:08:04,050 --> 00:08:05,529 around the boot rom exploit instead. 216 00:08:07,310 --> 00:08:09,769 So with that, let's talk about the 217 00:08:09,770 --> 00:08:12,079 main mitigation that makes Colonel 218 00:08:12,080 --> 00:08:14,389 debugging on my phone right now, both 219 00:08:14,390 --> 00:08:16,729 really hard to do and also 220 00:08:16,730 --> 00:08:18,529 so important. 221 00:08:18,530 --> 00:08:21,049 And that's a mitigation called Katara. 222 00:08:21,050 --> 00:08:22,729 If we look back at the list of 223 00:08:22,730 --> 00:08:24,799 requirements that I wanted in 224 00:08:24,800 --> 00:08:27,019 my homebrew that found the very 225 00:08:27,020 --> 00:08:29,209 first item on this list was I wanted 226 00:08:29,210 --> 00:08:31,549 the ability to patch kernel memory 227 00:08:31,550 --> 00:08:33,349 and in particular to patch the executable 228 00:08:33,350 --> 00:08:34,668 code. 229 00:08:34,669 --> 00:08:36,589 Now, normally on most systems, this isn't 230 00:08:36,590 --> 00:08:38,149 actually that difficult. 231 00:08:38,150 --> 00:08:40,219 Once you have the ability to read and 232 00:08:40,220 --> 00:08:42,168 write kernel memory, you can just modify 233 00:08:42,169 --> 00:08:44,239 page tables, makes some page 234 00:08:44,240 --> 00:08:46,219 in memory, read, write, execute, stuff 235 00:08:46,220 --> 00:08:47,329 your shell code in there and you're 236 00:08:47,330 --> 00:08:48,829 basically done. 237 00:08:48,830 --> 00:08:50,569 But on the iPhone, Apple, as I did a 238 00:08:50,570 --> 00:08:52,019 mitigation called TRW. 239 00:08:53,360 --> 00:08:55,969 And the idea is that we have 240 00:08:55,970 --> 00:08:57,489 a kernel cache in memory that's been, you 241 00:08:57,490 --> 00:08:59,809 know, put there by some sort of secure 242 00:08:59,810 --> 00:09:00,810 brute process. 243 00:09:02,090 --> 00:09:03,979 But once it's in memory and the system is 244 00:09:03,980 --> 00:09:06,169 running, Apple would really like a way 245 00:09:06,170 --> 00:09:08,389 to guarantee that the kernel 246 00:09:08,390 --> 00:09:10,309 cache gets locked down as much as 247 00:09:10,310 --> 00:09:11,209 possible. 248 00:09:11,210 --> 00:09:13,309 And any data in it, which really 249 00:09:13,310 --> 00:09:15,559 does not need to be readable, is 250 00:09:15,560 --> 00:09:16,849 never going to be modified. 251 00:09:16,850 --> 00:09:19,129 Basically, keep the guarantee 252 00:09:19,130 --> 00:09:21,469 that once an iPhone is booted, 253 00:09:21,470 --> 00:09:22,999 the code running in your kernel is 254 00:09:23,000 --> 00:09:25,249 exactly the code that was protected by 255 00:09:25,250 --> 00:09:27,829 and verified by the secure boot process. 256 00:09:27,830 --> 00:09:29,989 So there is some data in your kernel 257 00:09:29,990 --> 00:09:32,689 which does need to be rateable, 258 00:09:32,690 --> 00:09:34,009 but there's also a bunch of data which 259 00:09:34,010 --> 00:09:36,199 really does not need to be right of all 260 00:09:36,200 --> 00:09:37,999 the most prominent example is the 261 00:09:38,000 --> 00:09:39,049 executable code. 262 00:09:39,050 --> 00:09:40,789 Clearly, we don't want that to be 263 00:09:40,790 --> 00:09:42,859 changeable, but there's 264 00:09:42,860 --> 00:09:44,629 also a bunch of other pieces of data 265 00:09:44,630 --> 00:09:46,669 which are worth protecting. 266 00:09:46,670 --> 00:09:48,379 For example, you have strings, maybe 267 00:09:48,380 --> 00:09:50,449 format strings, virtual 268 00:09:50,450 --> 00:09:52,579 method tables, the page tables 269 00:09:52,580 --> 00:09:53,869 that are mapping in the kernel cache 270 00:09:53,870 --> 00:09:55,729 itself into memory. 271 00:09:55,730 --> 00:09:58,409 All of these additional pieces of data 272 00:09:58,410 --> 00:09:59,869 Apple would really like to have them be 273 00:09:59,870 --> 00:10:02,349 protected and not modifiable. 274 00:10:02,350 --> 00:10:04,159 And that's what KKR does. 275 00:10:04,160 --> 00:10:06,259 It's going to lock down all of this 276 00:10:06,260 --> 00:10:08,809 data that we want to be read only 277 00:10:08,810 --> 00:10:09,810 as the defenders. 278 00:10:11,030 --> 00:10:13,129 So as far as we know, OK, here are stands 279 00:10:13,130 --> 00:10:15,110 for a kernel text read only region. 280 00:10:18,620 --> 00:10:21,429 So what Katara boils down to 281 00:10:21,430 --> 00:10:23,659 is it's a very strong form of write 282 00:10:23,660 --> 00:10:25,789 X or execute protection. 283 00:10:25,790 --> 00:10:27,799 It's available an apple, a 10 C P use in 284 00:10:27,800 --> 00:10:29,869 later, and it provides two very strong 285 00:10:29,870 --> 00:10:31,249 guarantees. 286 00:10:31,250 --> 00:10:33,709 First is that all rights to memory 287 00:10:33,710 --> 00:10:35,989 inside of the region protected 288 00:10:35,990 --> 00:10:37,639 by KKR will fail. 289 00:10:39,200 --> 00:10:40,879 But this basically is what provides kind 290 00:10:40,880 --> 00:10:42,949 of the lock down guarantee that what 291 00:10:42,950 --> 00:10:45,769 was put there by the secure butane 292 00:10:45,770 --> 00:10:47,179 kind of stays that way and can't be 293 00:10:47,180 --> 00:10:48,529 changed. 294 00:10:48,530 --> 00:10:49,909 But there's another part to it which is 295 00:10:49,910 --> 00:10:52,279 equally important, and that is that all 296 00:10:52,280 --> 00:10:54,649 instruction fetches from memory outside 297 00:10:54,650 --> 00:10:56,929 of the protected region are guaranteed 298 00:10:56,930 --> 00:10:58,879 to fail. This is what ensures that you 299 00:10:58,880 --> 00:11:00,859 can't put new executable code in the 300 00:11:00,860 --> 00:11:02,659 kernel, that the only code that you're 301 00:11:02,660 --> 00:11:04,879 allowed to run is the 302 00:11:04,880 --> 00:11:05,899 colonel's own code. 303 00:11:07,520 --> 00:11:09,109 So in order to kind of understand how 304 00:11:09,110 --> 00:11:11,029 this works and a little more detail, 305 00:11:11,030 --> 00:11:13,189 let's look at a oversimplified diagram 306 00:11:13,190 --> 00:11:15,619 of how CPE works. 307 00:11:15,620 --> 00:11:17,839 So here we have the CPE cause 308 00:11:17,840 --> 00:11:19,999 this is for example, in 11 CPO 309 00:11:20,000 --> 00:11:22,189 with six course, the little 310 00:11:22,190 --> 00:11:24,269 purple box and the bottom corner is the 311 00:11:24,270 --> 00:11:25,459 M M U. 312 00:11:25,460 --> 00:11:27,259 We have the highest level of the cash 313 00:11:27,260 --> 00:11:29,479 hierarchies. The L2 cache 314 00:11:29,480 --> 00:11:31,819 behind that is the memory controller 315 00:11:31,820 --> 00:11:34,219 called AMC C and 316 00:11:34,220 --> 00:11:36,859 then this is connected to D Ram. 317 00:11:36,860 --> 00:11:39,919 Now the kernel lives continuously 318 00:11:39,920 --> 00:11:42,439 in physical memory and D ram 319 00:11:42,440 --> 00:11:44,209 and this is what Apple wants to protect 320 00:11:44,210 --> 00:11:45,290 with k tr. 321 00:11:46,870 --> 00:11:49,089 So the first step in order to lock 322 00:11:49,090 --> 00:11:51,359 down this region happens on the MMO. 323 00:11:51,360 --> 00:11:53,440 So let's zoom in to a single CPC core. 324 00:11:54,640 --> 00:11:56,859 What Apple has done, as far as 325 00:11:56,860 --> 00:11:58,919 I understand, is basically just add 326 00:11:58,920 --> 00:12:01,329 a couple of registers to the MMO you 327 00:12:01,330 --> 00:12:03,729 that point to the beginning and ending 328 00:12:03,730 --> 00:12:05,799 address of the region to 329 00:12:05,800 --> 00:12:06,800 protect. 330 00:12:07,810 --> 00:12:10,209 What this allows us to do is the CPO 331 00:12:10,210 --> 00:12:12,339 core can now check whether each 332 00:12:12,340 --> 00:12:14,109 instruction it's about to execute 333 00:12:14,110 --> 00:12:16,359 violates the security guarantees we want 334 00:12:16,360 --> 00:12:17,769 from K TR. 335 00:12:17,770 --> 00:12:19,989 So for example, let's say the CPC wants 336 00:12:19,990 --> 00:12:21,999 to show a right to a physical address 337 00:12:22,000 --> 00:12:24,219 outside of the Katara region. 338 00:12:24,220 --> 00:12:25,959 That's fine. We can actually we can write 339 00:12:25,960 --> 00:12:26,919 to that memory. 340 00:12:26,920 --> 00:12:28,959 So this will be allowed by the enemy. 341 00:12:28,960 --> 00:12:30,399 And the right will go through. 342 00:12:31,600 --> 00:12:33,579 If, however, we try to issue a right to 343 00:12:33,580 --> 00:12:35,829 an address that points to inside the K TR 344 00:12:35,830 --> 00:12:37,119 region. 345 00:12:37,120 --> 00:12:38,969 This violates the security properties of 346 00:12:38,970 --> 00:12:39,999 K TR. 347 00:12:40,000 --> 00:12:42,299 And so the MMR you will recognize this. 348 00:12:42,300 --> 00:12:44,409 It'll deny the right and it'll cause 349 00:12:44,410 --> 00:12:45,700 that instruction default. 350 00:12:46,930 --> 00:12:49,119 Similarly, if the CPA tries 351 00:12:49,120 --> 00:12:51,699 to execute an instruction 352 00:12:51,700 --> 00:12:53,949 that is fetch from an address outside 353 00:12:53,950 --> 00:12:56,019 of the courtyard region and 354 00:12:56,020 --> 00:12:58,179 you can recognize this and cause that 355 00:12:58,180 --> 00:12:59,430 instruction, fetch default. 356 00:13:01,220 --> 00:13:03,269 But so here's the kind of the new picture 357 00:13:03,270 --> 00:13:05,529 of the sea, cause we have a bunch of new 358 00:13:05,530 --> 00:13:07,479 registers and an emu that kind of have 359 00:13:07,480 --> 00:13:09,490 this catch ya protection 360 00:13:10,720 --> 00:13:13,629 built into them the next. 361 00:13:13,630 --> 00:13:15,429 However, this isn't the complete picture 362 00:13:15,430 --> 00:13:17,529 that we need in order to 363 00:13:17,530 --> 00:13:18,969 protect this memory. 364 00:13:18,970 --> 00:13:21,039 See, there are other devices that are 365 00:13:21,040 --> 00:13:22,599 connected to your system. 366 00:13:22,600 --> 00:13:23,649 All sorts of peripherals. 367 00:13:23,650 --> 00:13:25,299 This could be like a Wi-Fi chip. 368 00:13:25,300 --> 00:13:27,939 This could be like a USP stack, 369 00:13:27,940 --> 00:13:29,009 all sorts of thing. 370 00:13:29,010 --> 00:13:31,839 Any sort of hardware device which could 371 00:13:31,840 --> 00:13:33,579 issue DMA commands to your memory 372 00:13:33,580 --> 00:13:34,749 controller. 373 00:13:34,750 --> 00:13:36,549 So in order to protect against malicious 374 00:13:36,550 --> 00:13:38,709 peripherals DRM hanging over 375 00:13:38,710 --> 00:13:40,989 their protected region, we think 376 00:13:40,990 --> 00:13:43,149 that Apple has added a registers 377 00:13:43,150 --> 00:13:44,799 to the memory controller as well. 378 00:13:44,800 --> 00:13:46,509 That also point to the beginning and 379 00:13:46,510 --> 00:13:48,579 ending address of this 380 00:13:48,580 --> 00:13:50,649 locked down region such that 381 00:13:50,650 --> 00:13:52,749 that way any time some peripheral tries 382 00:13:52,750 --> 00:13:55,029 to DMA over the secure region, the memory 383 00:13:55,030 --> 00:13:56,949 controller sees that this DMA doesn't 384 00:13:56,950 --> 00:13:58,839 look valid and it'll just discard the 385 00:13:58,840 --> 00:13:59,840 right. 386 00:14:01,050 --> 00:14:03,239 So this is kind of the picture 387 00:14:03,240 --> 00:14:05,399 that the hardware now looks like in order 388 00:14:05,400 --> 00:14:06,400 to support Katara. 389 00:14:07,710 --> 00:14:09,209 But this isn't actually the complete 390 00:14:09,210 --> 00:14:11,489 story either, because there 391 00:14:11,490 --> 00:14:13,289 is one specific edge case that needs to 392 00:14:13,290 --> 00:14:15,979 be properly handled and that's when ACP 393 00:14:15,980 --> 00:14:17,699 Core goes to sleep for a little bit and 394 00:14:17,700 --> 00:14:19,429 then wakes up what's called resetting. 395 00:14:20,570 --> 00:14:22,859 Anytime they see you, 396 00:14:22,860 --> 00:14:24,419 Core goes to sleep. 397 00:14:24,420 --> 00:14:26,129 It's going to power down registers. 398 00:14:26,130 --> 00:14:28,319 And in particular the MMO you 399 00:14:28,320 --> 00:14:31,229 registers which store the K TR bounds 400 00:14:31,230 --> 00:14:33,119 are going to lose their value and be 401 00:14:33,120 --> 00:14:34,589 reset to zero. 402 00:14:34,590 --> 00:14:36,899 So when the CPO wakes up from sleep, 403 00:14:36,900 --> 00:14:39,269 we need some way to reset those registers 404 00:14:39,270 --> 00:14:40,589 to point to the beginning and ending 405 00:14:40,590 --> 00:14:42,659 bounds of the lock down region. 406 00:14:43,680 --> 00:14:45,809 So the reset vector is 407 00:14:45,810 --> 00:14:47,609 the first piece of code that gets 408 00:14:47,610 --> 00:14:49,619 executed when a CPA core wakes from 409 00:14:49,620 --> 00:14:51,689 sleep. And it does so with the M.M. 410 00:14:51,690 --> 00:14:53,339 you off. 411 00:14:53,340 --> 00:14:55,439 And what Apple has done is they've added 412 00:14:55,440 --> 00:14:57,509 code to the reset vector that 413 00:14:57,510 --> 00:14:59,819 basically just initialize as those KKR 414 00:14:59,820 --> 00:15:02,099 registers the beginning and ending 415 00:15:02,100 --> 00:15:03,929 bounds are stored in these global 416 00:15:03,930 --> 00:15:04,949 variables. 417 00:15:04,950 --> 00:15:06,569 These variables, by the way, happened to 418 00:15:06,570 --> 00:15:08,819 lie inside of the locked down region 419 00:15:08,820 --> 00:15:11,129 so they can't be modified. 420 00:15:11,130 --> 00:15:12,899 And once it reads those values into 421 00:15:12,900 --> 00:15:15,359 general purpose registers, it writes 422 00:15:15,360 --> 00:15:17,549 those bounds into 423 00:15:17,550 --> 00:15:19,769 special system registers 424 00:15:19,770 --> 00:15:21,839 that are used by the imam you to 425 00:15:21,840 --> 00:15:24,749 verify the KBR security properties. 426 00:15:24,750 --> 00:15:27,119 So once this code executes, 427 00:15:27,120 --> 00:15:29,279 K TR will be locked down on the M 428 00:15:29,280 --> 00:15:31,860 you. And once again, you can no longer 429 00:15:32,910 --> 00:15:35,009 execute memory that lies outside of the 430 00:15:35,010 --> 00:15:36,010 lockdown down region. 431 00:15:37,620 --> 00:15:39,719 So now that we have kind of a high level 432 00:15:39,720 --> 00:15:41,819 understanding of how KKR 433 00:15:41,820 --> 00:15:44,219 works, let's look at how 434 00:15:44,220 --> 00:15:47,099 it's possible to break K TR 435 00:15:47,100 --> 00:15:48,749 and we'll start with a few historical 436 00:15:48,750 --> 00:15:49,750 examples. 437 00:15:50,550 --> 00:15:52,799 There are two 438 00:15:52,800 --> 00:15:54,899 historical instances of 439 00:15:54,900 --> 00:15:56,999 partial KKR bypasses up till 440 00:15:57,000 --> 00:15:59,069 now and the first one 441 00:15:59,070 --> 00:16:01,169 came out pretty soon after 442 00:16:01,170 --> 00:16:04,019 the KKR mitigation was first introduced 443 00:16:04,020 --> 00:16:06,049 and it was discovered by Luca Tedesco, 444 00:16:06,050 --> 00:16:07,649 who was gonna be giving a talk. 445 00:16:07,650 --> 00:16:09,690 I think in this room tomorrow evening. 446 00:16:10,950 --> 00:16:13,079 So what Luca found was 447 00:16:13,080 --> 00:16:15,179 that Apple 448 00:16:15,180 --> 00:16:17,399 had left an instruction in the kernel 449 00:16:17,400 --> 00:16:19,619 cache that they 450 00:16:19,620 --> 00:16:21,659 didn't mean to leave executable, but it 451 00:16:21,660 --> 00:16:23,039 accidentally was. 452 00:16:23,040 --> 00:16:25,379 This was the MSR TPR one 453 00:16:25,380 --> 00:16:27,479 instruction which sets the 454 00:16:27,480 --> 00:16:29,709 special TPR one 455 00:16:29,710 --> 00:16:31,319 register. 456 00:16:31,320 --> 00:16:33,689 This register stores the physical address 457 00:16:33,690 --> 00:16:36,659 of the root of the page table hierarchy, 458 00:16:36,660 --> 00:16:38,459 which means that if you're able to modify 459 00:16:38,460 --> 00:16:40,679 the value of this register, then you 460 00:16:40,680 --> 00:16:42,989 are able to supply your own custom page 461 00:16:42,990 --> 00:16:45,749 table hierarchy and therefore remap 462 00:16:45,750 --> 00:16:48,000 virtual memory onto new physical pages. 463 00:16:49,290 --> 00:16:51,179 So this is exactly what he did. 464 00:16:51,180 --> 00:16:53,699 He just chose a 465 00:16:53,700 --> 00:16:56,009 remapping that placed the read 466 00:16:56,010 --> 00:16:58,389 only regions of kernel memory 467 00:16:58,390 --> 00:17:00,599 onto new physical pages that contained 468 00:17:00,600 --> 00:17:03,029 a copy of the original 469 00:17:03,030 --> 00:17:04,030 kernel data. 470 00:17:04,710 --> 00:17:06,659 Now it's important to note that Courtyard 471 00:17:06,660 --> 00:17:09,449 was still actually fully initialized 472 00:17:09,450 --> 00:17:11,459 at the point at which you were able to 473 00:17:11,460 --> 00:17:14,098 execute this MSR instruction. 474 00:17:14,099 --> 00:17:16,409 So we can patch read only 475 00:17:16,410 --> 00:17:18,779 data, but we can't execute 476 00:17:18,780 --> 00:17:20,848 new kernel code because KKR locked 477 00:17:20,849 --> 00:17:23,309 down on the atom. You still did occur. 478 00:17:23,310 --> 00:17:25,469 So what? The K TR bypass 479 00:17:25,470 --> 00:17:27,719 and ten point one basically 480 00:17:27,720 --> 00:17:29,579 achieved was limiting what was protected 481 00:17:29,580 --> 00:17:31,739 by KKR down from the whole read 482 00:17:31,740 --> 00:17:34,019 only region to only the executable 483 00:17:34,020 --> 00:17:36,179 code. But we get a whole bunch 484 00:17:36,180 --> 00:17:38,279 of new data in the kernel, which 485 00:17:38,280 --> 00:17:39,329 is now right. 486 00:17:39,330 --> 00:17:42,149 Well the second 487 00:17:42,150 --> 00:17:44,429 case here are bypass that 488 00:17:44,430 --> 00:17:46,829 was released was more of a bypass 489 00:17:46,830 --> 00:17:48,669 in spirit than in practice. 490 00:17:48,670 --> 00:17:50,909 But it's definitely a very important 491 00:17:50,910 --> 00:17:53,069 tool and a huge inspiration for 492 00:17:53,070 --> 00:17:54,070 my research. 493 00:17:55,380 --> 00:17:58,119 So back in Iowa, eleven 1 2 494 00:17:58,120 --> 00:18:00,569 in beer. Found that 495 00:18:00,570 --> 00:18:03,929 the debugging functionality 496 00:18:03,930 --> 00:18:06,389 in the arm specification was actually 497 00:18:06,390 --> 00:18:08,819 implemented in apples processors 498 00:18:08,820 --> 00:18:10,739 and could be used to implement a full 499 00:18:10,740 --> 00:18:12,239 featured kernel debugger. 500 00:18:12,240 --> 00:18:14,429 So if you read the ARM Architecture 501 00:18:14,430 --> 00:18:16,319 Reference manual, you'll find that there 502 00:18:16,320 --> 00:18:18,569 are documentation on a feature 503 00:18:18,570 --> 00:18:20,459 called Self Hosted Debugging. 504 00:18:20,460 --> 00:18:22,289 Basically, the architecture provides a 505 00:18:22,290 --> 00:18:24,329 set of debug registers which you can 506 00:18:24,330 --> 00:18:26,639 access via MSR 507 00:18:26,640 --> 00:18:28,949 instructions, and you can 508 00:18:28,950 --> 00:18:31,469 use these debugging registers to set 509 00:18:31,470 --> 00:18:33,899 breakpoints in kernel mode and also 510 00:18:33,900 --> 00:18:36,509 to by implementing 511 00:18:36,510 --> 00:18:38,669 exe exception handling code 512 00:18:38,670 --> 00:18:39,599 in your exception handler. 513 00:18:39,600 --> 00:18:41,939 You can catch your own break point 514 00:18:41,940 --> 00:18:44,009 exceptions and basically have the 515 00:18:44,010 --> 00:18:46,949 kernel implement its own debugger. 516 00:18:46,950 --> 00:18:48,179 For example, this might be somewhat 517 00:18:48,180 --> 00:18:50,310 analogous to using 518 00:18:51,420 --> 00:18:53,970 a KDP to debug a MacBook. 519 00:18:55,210 --> 00:18:57,479 Now KDE has actually been removed from 520 00:18:57,480 --> 00:18:59,969 the IOW kernel that's distributed. 521 00:18:59,970 --> 00:19:02,339 On production devices, however, 522 00:19:02,340 --> 00:19:04,439 the debugging registers that one 523 00:19:04,440 --> 00:19:06,269 might use to implement this are still 524 00:19:06,270 --> 00:19:08,459 present, still fully functional, and 525 00:19:08,460 --> 00:19:10,199 what he found was that he could use 526 00:19:10,200 --> 00:19:12,329 return oriented programing to set 527 00:19:12,330 --> 00:19:14,459 the values of these registers correctly 528 00:19:14,460 --> 00:19:16,649 in order to implement a 529 00:19:16,650 --> 00:19:18,240 rather full featured kernel debugger. 530 00:19:19,500 --> 00:19:21,089 He built something that works with Al to 531 00:19:21,090 --> 00:19:23,639 be proved quite useful, 532 00:19:23,640 --> 00:19:26,129 and in particular it was able to, 533 00:19:26,130 --> 00:19:28,259 by setting a breakpoint single stepping, 534 00:19:28,260 --> 00:19:30,749 modify, register values, execute 535 00:19:30,750 --> 00:19:32,429 existing instructions in the kernel and 536 00:19:32,430 --> 00:19:34,259 basically arbitrary order. 537 00:19:34,260 --> 00:19:36,809 So not native like 538 00:19:36,810 --> 00:19:38,789 arbitrary shell code execution, but 539 00:19:38,790 --> 00:19:39,790 pretty darn close. 540 00:19:41,650 --> 00:19:43,959 So I started 541 00:19:43,960 --> 00:19:46,119 this project of trying to find some sort 542 00:19:46,120 --> 00:19:48,339 of caterer bypass by looking and kind 543 00:19:48,340 --> 00:19:50,199 of the places that I thought would be 544 00:19:50,200 --> 00:19:52,329 more powerful, find more 545 00:19:52,330 --> 00:19:54,429 powerful TR bypass is more likely 546 00:19:54,430 --> 00:19:56,559 to lead to something that would be 547 00:19:56,560 --> 00:19:58,549 persistent across multiple versions by 548 00:19:58,550 --> 00:19:59,919 OS. 549 00:19:59,920 --> 00:20:01,569 Where I started was looking and I boot. 550 00:20:01,570 --> 00:20:03,389 I was trying to find some sort of eye 551 00:20:03,390 --> 00:20:05,859 boot bug in the image for passing 552 00:20:05,860 --> 00:20:07,629 and verification functions. 553 00:20:07,630 --> 00:20:09,460 I didn't end up finding anything there. 554 00:20:10,660 --> 00:20:12,279 Next, I kind of read through several 555 00:20:12,280 --> 00:20:15,249 sections of the ARM architecture manual, 556 00:20:15,250 --> 00:20:16,629 saw some interesting things about, you 557 00:20:16,630 --> 00:20:18,129 know, maybe you know, if you have weird 558 00:20:18,130 --> 00:20:19,299 malformed DLP 559 00:20:20,590 --> 00:20:22,599 entry, if you have weird malformed page 560 00:20:22,600 --> 00:20:23,949 table entries, you could do something 561 00:20:23,950 --> 00:20:25,539 weird with the T L.B. 562 00:20:25,540 --> 00:20:27,009 that didn't really end up building 563 00:20:27,010 --> 00:20:28,479 anything useful. 564 00:20:28,480 --> 00:20:29,799 I played around a little bit with, you 565 00:20:29,800 --> 00:20:32,159 know, I kind of misunderstood how KKR 566 00:20:32,160 --> 00:20:33,009 worked a little bit. 567 00:20:33,010 --> 00:20:34,149 And I thought, you know, maybe there's a 568 00:20:34,150 --> 00:20:36,669 way to corrupt the L2 cache 569 00:20:36,670 --> 00:20:39,039 and then bypass KKR that way. 570 00:20:39,040 --> 00:20:41,109 That didn't end up really working either. 571 00:20:41,110 --> 00:20:42,429 So I kind of, you know, tried a bunch of 572 00:20:42,430 --> 00:20:43,989 things. None of them really panned out. 573 00:20:43,990 --> 00:20:46,089 And I put this research on 574 00:20:46,090 --> 00:20:48,289 the backburner for a while. 575 00:20:48,290 --> 00:20:49,479 And it was actually while I was doing 576 00:20:49,480 --> 00:20:51,369 something totally unrelated that I 577 00:20:51,370 --> 00:20:53,679 happened to generate a kernel panic which 578 00:20:53,680 --> 00:20:55,599 reignited my interest. 579 00:20:55,600 --> 00:20:57,519 So I was playing around with interrupts 580 00:20:57,520 --> 00:20:59,639 and I'd managed to get a C Q course 581 00:20:59,640 --> 00:21:01,779 stuck in an infinite loop 582 00:21:01,780 --> 00:21:03,849 with interrupted disabled in kernel mode. 583 00:21:04,960 --> 00:21:06,519 And I got a panic message which said, you 584 00:21:06,520 --> 00:21:08,649 know, panic watchdog time or time 585 00:21:08,650 --> 00:21:10,939 out CPO on has failed to respond. 586 00:21:10,940 --> 00:21:12,159 It's kind of the exact thing you would 587 00:21:12,160 --> 00:21:14,259 expect when you isn't responding because 588 00:21:14,260 --> 00:21:16,659 it's stuck burning you cycles 589 00:21:16,660 --> 00:21:18,069 in an infinite loop. 590 00:21:18,070 --> 00:21:20,109 Eventually system notices and panics 591 00:21:20,110 --> 00:21:21,279 because you know, there's some 592 00:21:21,280 --> 00:21:23,229 significant problem here. 593 00:21:23,230 --> 00:21:24,909 But what really caught my attention about 594 00:21:24,910 --> 00:21:27,219 this panic message was something much 595 00:21:27,220 --> 00:21:29,349 earlier in it where it says attempting to 596 00:21:29,350 --> 00:21:31,090 forcibly halt CPR, you won. 597 00:21:32,210 --> 00:21:33,639 Now, this was really interesting to me 598 00:21:33,640 --> 00:21:35,739 because according to what I'd read 599 00:21:35,740 --> 00:21:38,349 from the Army Manual, 600 00:21:38,350 --> 00:21:40,929 there wasn't any 601 00:21:40,930 --> 00:21:43,509 standard way for one CPR 602 00:21:43,510 --> 00:21:46,089 corps to halt a second CPR you 603 00:21:46,090 --> 00:21:48,219 like. There's no MSR that you can 604 00:21:48,220 --> 00:21:50,829 write to. I didn't really remember any 605 00:21:50,830 --> 00:21:52,899 way to accomplish this. 606 00:21:52,900 --> 00:21:54,609 So what I figured was there's probably 607 00:21:54,610 --> 00:21:57,129 some sort of like proprietary interface 608 00:21:57,130 --> 00:21:58,539 going on here where, you know, maybe 609 00:21:58,540 --> 00:22:00,789 there's a special 610 00:22:00,790 --> 00:22:02,709 CPR control registers which are 611 00:22:02,710 --> 00:22:04,599 accessible via an amnio. 612 00:22:04,600 --> 00:22:06,819 And somehow he was trying 613 00:22:06,820 --> 00:22:08,319 to leverage those in order to halt the 614 00:22:08,320 --> 00:22:09,399 CPR. 615 00:22:09,400 --> 00:22:11,529 So this seems like a pretty interesting 616 00:22:11,530 --> 00:22:12,819 I've never seen something like this 617 00:22:12,820 --> 00:22:13,820 before. 618 00:22:14,320 --> 00:22:16,180 So I decided to, you know, pull up the 619 00:22:19,030 --> 00:22:21,909 security engineering tools needed to 620 00:22:21,910 --> 00:22:24,399 figure out what was going on here. 621 00:22:24,400 --> 00:22:26,109 So I crept through the X and you source 622 00:22:26,110 --> 00:22:28,479 code to try to find the string 623 00:22:28,480 --> 00:22:29,869 attempting to forcibly held CPR. 624 00:22:29,870 --> 00:22:32,169 You pretty quickly came to 625 00:22:32,170 --> 00:22:33,189 the function M.L. 626 00:22:33,190 --> 00:22:35,379 debug wrap hold CPR, which seemed 627 00:22:35,380 --> 00:22:37,419 to implement this functionality. 628 00:22:37,420 --> 00:22:39,519 It takes the index of which CPR 629 00:22:39,520 --> 00:22:40,869 you you want to halt. 630 00:22:40,870 --> 00:22:43,309 So on a CPA with six, 631 00:22:43,310 --> 00:22:46,179 that would be the index 0 through 5. 632 00:22:46,180 --> 00:22:48,459 And the actual part which holds 633 00:22:48,460 --> 00:22:50,619 the CPA is just right down here, 634 00:22:50,620 --> 00:22:52,239 a couple lines lower. 635 00:22:52,240 --> 00:22:54,699 So what this does is it reads a 636 00:22:54,700 --> 00:22:56,799 pointer to some volatile memory from a 637 00:22:56,800 --> 00:22:58,929 person AP data structure. 638 00:22:58,930 --> 00:22:59,919 This is memory. 639 00:22:59,920 --> 00:23:01,389 This variable that stores the pointer to 640 00:23:01,390 --> 00:23:03,909 the memory is called debug wrap drag. 641 00:23:03,910 --> 00:23:05,379 And then the actual part of the code 642 00:23:05,380 --> 00:23:07,839 which holds the CPA is 643 00:23:07,840 --> 00:23:09,639 simply consists of the single line where 644 00:23:09,640 --> 00:23:11,919 it writes some special 645 00:23:11,920 --> 00:23:14,079 debug halt value to the debug wrap 646 00:23:14,080 --> 00:23:15,129 rack. 647 00:23:15,130 --> 00:23:17,229 So this really strongly supports 648 00:23:17,230 --> 00:23:18,969 the idea that this is some, you know, 649 00:23:18,970 --> 00:23:21,219 special M Io register. 650 00:23:21,220 --> 00:23:22,959 And when I was looking online for trying 651 00:23:22,960 --> 00:23:24,729 to find references to this debug wrap 652 00:23:24,730 --> 00:23:27,009 thing, I wasn't really getting 653 00:23:27,010 --> 00:23:28,449 any results. So it kind of really 654 00:23:28,450 --> 00:23:30,519 strongly suggested that, yes, this is 655 00:23:30,520 --> 00:23:33,549 some sort of proprietary Apple specific 656 00:23:33,550 --> 00:23:34,550 interface. 657 00:23:36,220 --> 00:23:37,419 The other thing I kind of caught my 658 00:23:37,420 --> 00:23:39,549 attention was this reference to 659 00:23:39,550 --> 00:23:41,049 something called core site. 660 00:23:41,050 --> 00:23:42,759 I remembered hearing, you know, core site 661 00:23:42,760 --> 00:23:44,139 somewhere else before, but it doesn't 662 00:23:44,140 --> 00:23:46,199 really. Didn't really know what it was. 663 00:23:46,200 --> 00:23:47,590 Market is something to come back to, 664 00:23:48,820 --> 00:23:50,259 but we're really caught my attention. 665 00:23:50,260 --> 00:23:51,539 When I was looking through this file, it 666 00:23:51,540 --> 00:23:53,889 was a function just a few lines down 667 00:23:53,890 --> 00:23:55,959 called M.L. Debug wrap halts CPA with 668 00:23:55,960 --> 00:23:56,949 state. 669 00:23:56,950 --> 00:23:59,199 This does basically the same thing as 670 00:23:59,200 --> 00:24:01,359 the other function, except in addition 671 00:24:01,360 --> 00:24:02,799 to halting a CPA. 672 00:24:02,800 --> 00:24:04,809 It also reads out the values of the 673 00:24:04,810 --> 00:24:06,789 registers on that CPA. 674 00:24:06,790 --> 00:24:08,529 That was just halted. 675 00:24:08,530 --> 00:24:10,059 And the way that does this is actually 676 00:24:10,060 --> 00:24:11,619 quite remarkable. 677 00:24:11,620 --> 00:24:13,029 So first off, you can see that there is 678 00:24:13,030 --> 00:24:15,099 another reference to this core site 679 00:24:15,100 --> 00:24:17,109 thing. It says ensure a memory map course 680 00:24:17,110 --> 00:24:19,239 that registers can be written. 681 00:24:19,240 --> 00:24:21,039 So clearly something with core site is 682 00:24:21,040 --> 00:24:22,569 important here. Maybe it should be block 683 00:24:22,570 --> 00:24:24,249 of registers that contain this 684 00:24:24,250 --> 00:24:25,250 functionality. 685 00:24:26,200 --> 00:24:28,359 But the important part is this a 686 00:24:28,360 --> 00:24:30,639 for loop right below which iterator 687 00:24:30,640 --> 00:24:32,949 ie over the indices of your general 688 00:24:32,950 --> 00:24:33,950 purpose registers. 689 00:24:35,200 --> 00:24:37,299 What this code does is first it's going 690 00:24:37,300 --> 00:24:40,209 to generate the numerical 691 00:24:40,210 --> 00:24:43,239 code for the instruction 692 00:24:43,240 --> 00:24:45,339 which writes the value of general 693 00:24:45,340 --> 00:24:47,829 purpose register x ie into 694 00:24:47,830 --> 00:24:50,139 the special system, register debug 695 00:24:50,140 --> 00:24:51,219 DDR. 696 00:24:51,220 --> 00:24:52,599 So this isn't an instruction which 697 00:24:52,600 --> 00:24:54,189 already exists in the kernel cache, it is 698 00:24:54,190 --> 00:24:56,739 just literally generating the 699 00:24:56,740 --> 00:24:58,989 numerical value of the code for that 700 00:24:58,990 --> 00:24:59,990 instruction. 701 00:25:01,270 --> 00:25:03,399 Next, it passes that 702 00:25:03,400 --> 00:25:04,369 code into M.L. 703 00:25:04,370 --> 00:25:06,759 debug wrap stuff instruction. 704 00:25:06,760 --> 00:25:08,829 And finally, it reads the value of 705 00:25:08,830 --> 00:25:11,229 the debug DDR register and writes 706 00:25:11,230 --> 00:25:13,299 the value into the 707 00:25:13,300 --> 00:25:15,309 output buffers ex AI field. 708 00:25:16,330 --> 00:25:18,039 So this is actually really interesting 709 00:25:18,040 --> 00:25:20,319 because of what it suggests is that 710 00:25:20,320 --> 00:25:22,479 M.L. debug wrap stuff instruction 711 00:25:22,480 --> 00:25:24,879 is somehow executing dynamically 712 00:25:24,880 --> 00:25:26,709 generated instructions. 713 00:25:26,710 --> 00:25:28,629 And this really flies in the face of the 714 00:25:28,630 --> 00:25:30,789 security model that 715 00:25:30,790 --> 00:25:32,349 KKR is designed for. 716 00:25:32,350 --> 00:25:34,659 So KKR is meant to ensure 717 00:25:34,660 --> 00:25:36,729 that, you know all of the instructions 718 00:25:36,730 --> 00:25:38,439 here. Colonel Cash. Those are the only 719 00:25:38,440 --> 00:25:41,169 ones that you're allowed to execute. 720 00:25:41,170 --> 00:25:42,999 But here there's some sort of interface 721 00:25:43,000 --> 00:25:45,189 which seems to be able to execute any 722 00:25:45,190 --> 00:25:47,289 instruction you want on 723 00:25:47,290 --> 00:25:48,290 a halted CPO. 724 00:25:49,580 --> 00:25:51,080 So this is definitely really interesting. 725 00:25:52,100 --> 00:25:53,869 Now, just because there is code to do 726 00:25:53,870 --> 00:25:55,429 something and execute doesn't actually 727 00:25:55,430 --> 00:25:56,989 mean that it necessarily works in 728 00:25:56,990 --> 00:25:57,889 practice. 729 00:25:57,890 --> 00:26:00,949 So I basically just decided to 730 00:26:00,950 --> 00:26:03,979 test to see if this code actually runs. 731 00:26:03,980 --> 00:26:05,659 I pulled up an old kernel exploit that 732 00:26:05,660 --> 00:26:07,069 I'd written and I 733 00:26:08,270 --> 00:26:10,479 basically just wrote and 734 00:26:10,480 --> 00:26:12,109 hacked together something that would call 735 00:26:12,110 --> 00:26:14,089 the function AML debug wrap halts CPA 736 00:26:14,090 --> 00:26:16,669 with state pass it output buffer 737 00:26:16,670 --> 00:26:17,959 and then dump the contents of that 738 00:26:17,960 --> 00:26:18,960 buffer. 739 00:26:19,490 --> 00:26:21,829 And what I found was that the 740 00:26:21,830 --> 00:26:23,899 output buffer really did look like a 741 00:26:23,900 --> 00:26:25,249 bunch of registers. 742 00:26:25,250 --> 00:26:26,779 So there's a bunch of stuff which was 0, 743 00:26:26,780 --> 00:26:28,609 which was kind of weird. 744 00:26:28,610 --> 00:26:30,709 But the value of CPS CSR 745 00:26:30,710 --> 00:26:31,969 does look correct. 746 00:26:31,970 --> 00:26:33,919 It actually looks like a CPA, you running 747 00:26:33,920 --> 00:26:36,049 in kernel mode and the value 748 00:26:36,050 --> 00:26:38,119 of P.C., it doesn't really look like a 749 00:26:38,120 --> 00:26:39,709 normal kernel virtual address. 750 00:26:39,710 --> 00:26:41,359 Those usually start with, you know, like 751 00:26:41,360 --> 00:26:43,429 f f f f, but 752 00:26:43,430 --> 00:26:45,229 it does really look like some sort of 753 00:26:45,230 --> 00:26:47,329 physical address perhaps. 754 00:26:47,330 --> 00:26:49,549 And with a little bit of digging 755 00:26:49,550 --> 00:26:51,679 into this, I pretty quickly discovered 756 00:26:51,680 --> 00:26:53,859 that this is a physical address 757 00:26:53,860 --> 00:26:56,539 of an instruction in the reset vector. 758 00:26:56,540 --> 00:26:58,159 Now, things are really, really getting 759 00:26:58,160 --> 00:27:00,619 interesting because what this suggests 760 00:27:00,620 --> 00:27:02,359 is that we've managed to halt the 761 00:27:02,360 --> 00:27:04,669 execution of a CPE core while 762 00:27:04,670 --> 00:27:06,589 it's actually running the reset vector 763 00:27:06,590 --> 00:27:09,349 and in particular before the EMU 764 00:27:09,350 --> 00:27:10,819 has been turned on. 765 00:27:10,820 --> 00:27:12,919 Now, this is a really critical point in 766 00:27:12,920 --> 00:27:15,109 time for TR because before 767 00:27:15,110 --> 00:27:17,629 the enemy has been turned on K TR 768 00:27:17,630 --> 00:27:20,009 is unable to protect 769 00:27:20,010 --> 00:27:22,219 the CPSU from executing instructions 770 00:27:22,220 --> 00:27:23,990 outside of the locked down region. 771 00:27:25,010 --> 00:27:27,079 So of course what I really wanted to know 772 00:27:27,080 --> 00:27:29,269 was how do we use this capability 773 00:27:29,270 --> 00:27:30,980 in order to bypass Katara? 774 00:27:32,760 --> 00:27:33,989 Well, it turns out that there's kind of a 775 00:27:33,990 --> 00:27:36,059 more fundamental question that I need to 776 00:27:36,060 --> 00:27:38,219 answer first, which was what exactly 777 00:27:38,220 --> 00:27:39,669 is this core site thing? 778 00:27:39,670 --> 00:27:42,599 Anyway, it's really hard in practice to 779 00:27:42,600 --> 00:27:44,189 at least for me to exploit something 780 00:27:44,190 --> 00:27:45,929 without kind of knowing a general sense 781 00:27:45,930 --> 00:27:47,010 of how something works. 782 00:27:48,690 --> 00:27:50,759 And so I basically just searched for a 783 00:27:50,760 --> 00:27:53,399 core site in the arm reference manual 784 00:27:53,400 --> 00:27:55,859 and came across a bunch of references 785 00:27:55,860 --> 00:27:58,079 to core site in connection with 786 00:27:58,080 --> 00:27:59,969 something called the external debug 787 00:27:59,970 --> 00:28:00,970 interface. 788 00:28:01,800 --> 00:28:03,869 Now the external debug interface, it 789 00:28:03,870 --> 00:28:06,029 turns out, is pretty much just a 790 00:28:06,030 --> 00:28:08,099 different way of accessing the 791 00:28:08,100 --> 00:28:10,619 same functionality that Ian used 792 00:28:10,620 --> 00:28:12,929 in his self hosted kernel 793 00:28:12,930 --> 00:28:13,930 debugger. 794 00:28:14,520 --> 00:28:17,309 So the in a self hosted debugging 795 00:28:17,310 --> 00:28:19,619 interface you write to 796 00:28:19,620 --> 00:28:22,139 these debug registers using MSR 797 00:28:22,140 --> 00:28:23,140 instructions. 798 00:28:24,150 --> 00:28:26,309 The external debug interface 799 00:28:26,310 --> 00:28:28,169 provides kind of a similar, very similar 800 00:28:28,170 --> 00:28:30,959 functionality. It's probably the same 801 00:28:30,960 --> 00:28:32,699 debugging hardware under the hood that 802 00:28:32,700 --> 00:28:34,889 you're driving, but the interface 803 00:28:34,890 --> 00:28:37,079 to access these registers is via 804 00:28:37,080 --> 00:28:39,149 MMI O rather than 805 00:28:39,150 --> 00:28:42,029 via executing MSR instructions. 806 00:28:42,030 --> 00:28:43,859 So this means that basically the 807 00:28:43,860 --> 00:28:46,319 functionality that is necessary 808 00:28:46,320 --> 00:28:48,449 to build a kernel debugger is still 809 00:28:48,450 --> 00:28:50,879 there, even though the Brock gadgets 810 00:28:50,880 --> 00:28:53,339 that even used to activate it are 811 00:28:53,340 --> 00:28:56,099 taken away, the memory mapped interface 812 00:28:56,100 --> 00:28:57,100 still exists. 813 00:28:58,480 --> 00:29:00,539 And in fact, this isn't even the first 814 00:29:00,540 --> 00:29:01,589 time. 815 00:29:01,590 --> 00:29:03,359 Not even close to the first time that 816 00:29:03,360 --> 00:29:05,429 someone has tried 817 00:29:05,430 --> 00:29:07,889 to use debugging registers 818 00:29:07,890 --> 00:29:10,109 and an arm processor in order to mount 819 00:29:10,110 --> 00:29:11,029 some sort of privilege. 820 00:29:11,030 --> 00:29:12,030 Just hack. 821 00:29:13,350 --> 00:29:15,279 She knew Nang and Feng ways. 822 00:29:15,280 --> 00:29:17,439 Yang presented an attack at most 823 00:29:17,440 --> 00:29:20,399 like 20 19, where they 824 00:29:20,400 --> 00:29:22,439 basically were able to leverage these 825 00:29:22,440 --> 00:29:24,839 same debugging registers 826 00:29:24,840 --> 00:29:26,969 on Android phones to 827 00:29:26,970 --> 00:29:29,040 break the protection of the 828 00:29:31,440 --> 00:29:32,399 secure world. 829 00:29:32,400 --> 00:29:35,219 So they were able to 830 00:29:35,220 --> 00:29:37,289 make one for you for 831 00:29:37,290 --> 00:29:39,479 debug another CPO core 832 00:29:39,480 --> 00:29:41,849 make that same second CPA core execute 833 00:29:41,850 --> 00:29:43,889 instructions to enter the secure world at 834 00:29:43,890 --> 00:29:46,109 E L3 and then also 835 00:29:46,110 --> 00:29:47,669 make it execute instructions that would 836 00:29:47,670 --> 00:29:49,799 cause it to read and write memory 837 00:29:49,800 --> 00:29:50,800 in the secure world. 838 00:29:53,160 --> 00:29:54,809 So just to summarize kind of the key 839 00:29:54,810 --> 00:29:56,339 concepts behind the external debug 840 00:29:56,340 --> 00:29:58,679 interface, it is an on chip 841 00:29:58,680 --> 00:30:00,139 debugging architecture. 842 00:30:00,140 --> 00:30:02,279 It provides Percy you 843 00:30:02,280 --> 00:30:04,529 debug registers which are accessible 844 00:30:04,530 --> 00:30:06,839 by MMI. So 845 00:30:06,840 --> 00:30:08,909 the actual interface itself, how to use 846 00:30:08,910 --> 00:30:10,589 these registers is really extensively 847 00:30:10,590 --> 00:30:12,779 documented in our manual. 848 00:30:12,780 --> 00:30:14,279 It talks about, you know, what the names 849 00:30:14,280 --> 00:30:15,359 of all the registers are. 850 00:30:15,360 --> 00:30:16,529 The offsets of them 851 00:30:18,120 --> 00:30:20,039 like how to program the registers in 852 00:30:20,040 --> 00:30:22,469 order to do things like set breakpoint 853 00:30:22,470 --> 00:30:23,489 and watch points. 854 00:30:23,490 --> 00:30:26,159 So I'm not going to go over all of that 855 00:30:26,160 --> 00:30:27,389 right here. 856 00:30:27,390 --> 00:30:29,609 But what I will say is that the external 857 00:30:29,610 --> 00:30:31,679 debug interface is certainly more 858 00:30:31,680 --> 00:30:33,719 than powerful enough to do any sort of 859 00:30:33,720 --> 00:30:34,979 kernel debunking that we might be 860 00:30:34,980 --> 00:30:36,829 interested in. Definitely capable of 861 00:30:36,830 --> 00:30:38,639 setting breakpoints and watch points, 862 00:30:38,640 --> 00:30:40,829 single stepping execution, executing 863 00:30:40,830 --> 00:30:43,229 arbitrary instructions, poking 864 00:30:43,230 --> 00:30:44,730 at memory, all this sort of stuff. 865 00:30:46,790 --> 00:30:48,989 So the idea for my attack was we 866 00:30:48,990 --> 00:30:50,579 have these debugging registers. 867 00:30:50,580 --> 00:30:52,649 We can do things like single stepping and 868 00:30:52,650 --> 00:30:54,239 we know that we can halt execution and 869 00:30:54,240 --> 00:30:55,649 the reset vector. 870 00:30:55,650 --> 00:30:57,779 So I basically decided I would 871 00:30:57,780 --> 00:31:00,089 try to use the external debug interface 872 00:31:00,090 --> 00:31:02,249 to single step the reset vector. 873 00:31:02,250 --> 00:31:04,619 And then once the reset vector is about 874 00:31:04,620 --> 00:31:06,839 to execute that Katie or lockdown 875 00:31:06,840 --> 00:31:08,909 instructions just jump over that piece 876 00:31:08,910 --> 00:31:10,859 of code. OK, here are never gets 877 00:31:10,860 --> 00:31:12,539 initialized. 878 00:31:12,540 --> 00:31:14,339 So if we look at the reset vector, we'll 879 00:31:14,340 --> 00:31:16,349 just step through all of the first 880 00:31:16,350 --> 00:31:18,539 instructions. And then once we see that 881 00:31:18,540 --> 00:31:21,329 we've hit this conditional branch 882 00:31:21,330 --> 00:31:23,309 where we're just about to start doing 883 00:31:23,310 --> 00:31:25,879 the. Katie, are registered initialization 884 00:31:25,880 --> 00:31:28,169 set at 17 to zero jump over 885 00:31:28,170 --> 00:31:29,910 the TR code altogether. 886 00:31:32,150 --> 00:31:34,909 Now, this is a nice idea, 887 00:31:34,910 --> 00:31:37,069 but we don't actually have all the tools 888 00:31:37,070 --> 00:31:39,649 yet necessary in order to carry it out. 889 00:31:39,650 --> 00:31:41,599 We know that we can hold the CPO and we 890 00:31:41,600 --> 00:31:43,219 know that we can execute arbitrary 891 00:31:43,220 --> 00:31:45,289 instructions on it and do things like 892 00:31:45,290 --> 00:31:47,689 modify the values and registers. 893 00:31:47,690 --> 00:31:49,789 But we haven't yet found 894 00:31:49,790 --> 00:31:51,979 the ability to resume executing 895 00:31:51,980 --> 00:31:54,469 on the CPSU after it's been halted. 896 00:31:54,470 --> 00:31:56,539 So if we set a breakpoint on the 897 00:31:56,540 --> 00:31:59,059 reset vector, for example, that's nice, 898 00:31:59,060 --> 00:32:00,769 but it's not gonna be of much use if we 899 00:32:00,770 --> 00:32:02,989 can't continue execution after 900 00:32:02,990 --> 00:32:03,990 that point. 901 00:32:04,940 --> 00:32:07,159 Furthermore, there's another somewhat 902 00:32:07,160 --> 00:32:09,889 more subtle issue, which is that 903 00:32:09,890 --> 00:32:12,259 we're using one CPSU 904 00:32:12,260 --> 00:32:14,529 to hijack another CPSU as 905 00:32:14,530 --> 00:32:16,729 it resets, but CPE 906 00:32:16,730 --> 00:32:18,759 resets happen all the time. 907 00:32:18,760 --> 00:32:20,899 Anytime a CPA corps is idle for a couple 908 00:32:20,900 --> 00:32:22,999 of seconds, it'll eventually just do 909 00:32:23,000 --> 00:32:25,129 a reset as it powers down and powers 910 00:32:25,130 --> 00:32:26,130 back up again. 911 00:32:26,960 --> 00:32:29,089 So we're going to have to do 912 00:32:29,090 --> 00:32:30,229 this. 913 00:32:30,230 --> 00:32:31,559 Here are a hijack. 914 00:32:31,560 --> 00:32:33,859 We need to modify the execution 915 00:32:33,860 --> 00:32:36,049 of a reset vector and skip the K TR 916 00:32:36,050 --> 00:32:38,599 initialization every single time 917 00:32:38,600 --> 00:32:40,909 that a few core resets unless 918 00:32:40,910 --> 00:32:42,859 we can find some way to disable the core 919 00:32:42,860 --> 00:32:43,860 from resetting. 920 00:32:45,340 --> 00:32:47,169 So I didn't know how to do either of 921 00:32:47,170 --> 00:32:48,699 these two things. 922 00:32:48,700 --> 00:32:51,159 So I kind of just decided to play around 923 00:32:51,160 --> 00:32:53,649 with that original proprietary 924 00:32:53,650 --> 00:32:55,839 register that I'd found earlier. 925 00:32:55,840 --> 00:32:57,669 So the actual new source code documents a 926 00:32:57,670 --> 00:32:59,259 couple of the bits. I think it documents 927 00:32:59,260 --> 00:33:01,389 two of the bits in that register. 928 00:33:01,390 --> 00:33:03,039 The remaining bits are undocumented. 929 00:33:03,040 --> 00:33:05,019 So I figured, you know, might as well set 930 00:33:05,020 --> 00:33:06,459 some dates, clear some bits. 931 00:33:06,460 --> 00:33:07,869 See what happens. See if I learned 932 00:33:07,870 --> 00:33:09,549 anything interesting. 933 00:33:09,550 --> 00:33:11,619 And I kid you not by sheer dumb 934 00:33:11,620 --> 00:33:13,689 luck. It happens that that register 935 00:33:13,690 --> 00:33:15,609 contained exactly the pieces of 936 00:33:15,610 --> 00:33:17,739 functionality we needed to pull 937 00:33:17,740 --> 00:33:19,449 this hijack together. 938 00:33:19,450 --> 00:33:21,789 So bit 30 actually 939 00:33:21,790 --> 00:33:24,569 will clear the 940 00:33:24,570 --> 00:33:26,499 Haltern and allowed the CPO to resume 941 00:33:26,500 --> 00:33:29,039 executing, and bit twenty six 942 00:33:29,040 --> 00:33:31,179 will keep the CPA powered up 943 00:33:31,180 --> 00:33:33,729 so that it doesn't subsequently 944 00:33:33,730 --> 00:33:35,949 reset. And then we have to re hijack 945 00:33:35,950 --> 00:33:36,950 the reset vector. 946 00:33:38,900 --> 00:33:40,969 So basically, the attack that we 947 00:33:40,970 --> 00:33:43,489 describe before works perfectly 948 00:33:43,490 --> 00:33:44,449 well. 949 00:33:44,450 --> 00:33:46,609 Once we have this new functionality, we 950 00:33:46,610 --> 00:33:48,799 just make sure that once we hit this 951 00:33:48,800 --> 00:33:51,289 branch, we skip over the Katara 952 00:33:51,290 --> 00:33:53,419 Register lockdown code and 953 00:33:53,420 --> 00:33:55,759 then these registers never get written to 954 00:33:55,760 --> 00:33:57,679 Katie are is never initialized on the 955 00:33:57,680 --> 00:33:59,959 system and kernel memory becomes 956 00:33:59,960 --> 00:34:01,219 executable. 957 00:34:01,220 --> 00:34:03,319 So what this looks like is first we 958 00:34:03,320 --> 00:34:05,059 have k tr enabled. 959 00:34:05,060 --> 00:34:07,429 Once we do this hijack, KBR 960 00:34:07,430 --> 00:34:09,678 is disabled on an menu. 961 00:34:09,679 --> 00:34:11,000 And now any 962 00:34:12,170 --> 00:34:13,819 page in kernel memory could now 963 00:34:13,820 --> 00:34:15,139 potentially be executed. 964 00:34:22,500 --> 00:34:23,500 Got a little bit more to go. 965 00:34:26,429 --> 00:34:27,429 Thank you. 966 00:34:28,380 --> 00:34:30,448 So now that we've found a 967 00:34:30,449 --> 00:34:32,638 way to break a terror, I 968 00:34:32,639 --> 00:34:34,259 want to talk about how to build an actual 969 00:34:34,260 --> 00:34:36,359 debugger on top of this, because I 970 00:34:36,360 --> 00:34:38,069 found it to be a quite non-trivial 971 00:34:38,070 --> 00:34:39,070 challenge. 972 00:34:40,330 --> 00:34:41,738 So there are a number of steps involved 973 00:34:41,739 --> 00:34:43,928 in this process, and actually in many 974 00:34:43,929 --> 00:34:45,698 of them I encountered issues that I 975 00:34:45,699 --> 00:34:46,988 thought would be basically 976 00:34:46,989 --> 00:34:48,549 insurmountable. 977 00:34:48,550 --> 00:34:50,678 So the first step in the process is we 978 00:34:50,679 --> 00:34:53,499 need to remap the kernel 979 00:34:53,500 --> 00:34:55,119 because even though we've enabled the 980 00:34:55,120 --> 00:34:56,829 ability to execute arbitrary kernel shell 981 00:34:56,830 --> 00:34:58,689 code, we don't yet have the ability to 982 00:34:58,690 --> 00:34:59,710 patch kernel memory. 983 00:35:01,170 --> 00:35:03,299 Next, we need to figure out 984 00:35:03,300 --> 00:35:04,860 some way to load a kernel extension. 985 00:35:05,910 --> 00:35:08,279 We need to make sure that we're properly 986 00:35:08,280 --> 00:35:09,689 handling interrupts because we're going 987 00:35:09,690 --> 00:35:11,189 to be disabling our. 988 00:35:11,190 --> 00:35:12,959 Sorry, we're gonna be halting CPE use. 989 00:35:12,960 --> 00:35:14,729 And once the CPC was halted, it of course 990 00:35:14,730 --> 00:35:16,550 can't service interrupts anymore. 991 00:35:17,670 --> 00:35:19,109 We're going to need to establish some 992 00:35:19,110 --> 00:35:21,839 sort of communication channel between the 993 00:35:21,840 --> 00:35:23,939 kernel extension running in your iPhone 994 00:35:23,940 --> 00:35:25,619 and your laptop running LTE. 995 00:35:26,640 --> 00:35:29,099 And finally, we need to implement a GDP 996 00:35:29,100 --> 00:35:31,289 stub to process the packets 997 00:35:31,290 --> 00:35:33,479 sent by Al LGB and to drive 998 00:35:33,480 --> 00:35:34,480 the debugging hardware. 999 00:35:36,350 --> 00:35:39,829 So at the point at which we bypass KKR, 1000 00:35:39,830 --> 00:35:42,079 we have the ability 1001 00:35:42,080 --> 00:35:43,999 to execute arbitrary Colonel Shell code. 1002 00:35:44,000 --> 00:35:45,599 But we don't yet have the ability to 1003 00:35:45,600 --> 00:35:47,479 patch kernel memory. 1004 00:35:47,480 --> 00:35:49,039 The reason for this is that even though 1005 00:35:49,040 --> 00:35:51,379 we've disabled K char on the M M use, 1006 00:35:51,380 --> 00:35:53,509 it still fully enabled on the 1007 00:35:53,510 --> 00:35:55,039 memory controller. 1008 00:35:55,040 --> 00:35:57,949 So even though we can 1009 00:35:57,950 --> 00:35:59,719 execute code outside of the read only 1010 00:35:59,720 --> 00:36:02,149 region, the read only regions physical 1011 00:36:02,150 --> 00:36:04,639 pages are still fully protected 1012 00:36:04,640 --> 00:36:06,739 and we can't modify them persistently. 1013 00:36:08,240 --> 00:36:10,939 So this is actually kind of problematic 1014 00:36:10,940 --> 00:36:13,849 for us. We really do need to modify 1015 00:36:13,850 --> 00:36:15,799 the page table permissions in order to 1016 00:36:15,800 --> 00:36:18,109 make the kernel extensions memory 1017 00:36:18,110 --> 00:36:20,539 executable and the root 1018 00:36:20,540 --> 00:36:22,909 of the page table hierarchy 1019 00:36:22,910 --> 00:36:25,459 lies inside of the K TR region, 1020 00:36:25,460 --> 00:36:26,539 which is still protected. 1021 00:36:27,590 --> 00:36:29,599 So the solution to this is to basically 1022 00:36:29,600 --> 00:36:32,089 do exactly the same thing that Luca did 1023 00:36:32,090 --> 00:36:34,279 and the ten point one point one 1024 00:36:34,280 --> 00:36:36,439 bypass, which is to remap the kernel 1025 00:36:36,440 --> 00:36:39,049 onto fresh readable pages and set TPR 1026 00:36:39,050 --> 00:36:40,699 one to point to the new page tables 1027 00:36:40,700 --> 00:36:41,700 instead. 1028 00:36:42,410 --> 00:36:44,629 So what that looks like is initially 1029 00:36:44,630 --> 00:36:46,699 the TPR one registers is going 1030 00:36:46,700 --> 00:36:48,829 to point to the 1031 00:36:48,830 --> 00:36:50,659 root of the page tables, which lies 1032 00:36:50,660 --> 00:36:52,699 inside the protected region. 1033 00:36:52,700 --> 00:36:54,829 What we have to do is we need to copy 1034 00:36:54,830 --> 00:36:57,199 the kernel, the pages containing 1035 00:36:57,200 --> 00:36:58,729 the kernel, we need to copy the data of 1036 00:36:58,730 --> 00:37:00,979 that onto new rateable pages 1037 00:37:00,980 --> 00:37:03,439 that are outside of the protected region. 1038 00:37:03,440 --> 00:37:05,749 Update the page tables in kernel 1039 00:37:05,750 --> 00:37:08,299 memory and then make TTR 1040 00:37:08,300 --> 00:37:10,579 one point to the new modified 1041 00:37:10,580 --> 00:37:11,659 page tables instead. 1042 00:37:12,980 --> 00:37:15,199 And with that, we do now have the ability 1043 00:37:15,200 --> 00:37:16,200 to patch the kernel. 1044 00:37:18,170 --> 00:37:19,879 So the next step in this process is we 1045 00:37:19,880 --> 00:37:21,289 need the ability to load kernel 1046 00:37:21,290 --> 00:37:22,669 extensions. 1047 00:37:22,670 --> 00:37:24,709 This actually turns out is pretty simple 1048 00:37:24,710 --> 00:37:26,839 once we bypass KKR. 1049 00:37:26,840 --> 00:37:28,399 All we have to do is we need to allocate 1050 00:37:28,400 --> 00:37:29,899 some memory to put the kernel extension 1051 00:37:29,900 --> 00:37:32,539 in copy in the binary 1052 00:37:32,540 --> 00:37:35,119 dynamically link the kernel extension 1053 00:37:35,120 --> 00:37:37,489 against the kernel that's running. 1054 00:37:37,490 --> 00:37:39,439 Because if you want to have a kernel 1055 00:37:39,440 --> 00:37:40,669 extension, presumably you're going to 1056 00:37:40,670 --> 00:37:42,889 want to call kernel functions at various 1057 00:37:42,890 --> 00:37:43,890 points. 1058 00:37:44,690 --> 00:37:46,759 After that, we need to modify page 1059 00:37:46,760 --> 00:37:49,099 tables to make the kernel extension 1060 00:37:49,100 --> 00:37:50,269 executable. 1061 00:37:50,270 --> 00:37:52,339 And finally, we need to call some 1062 00:37:52,340 --> 00:37:54,679 function in the kernel extension to begin 1063 00:37:54,680 --> 00:37:55,680 it running. 1064 00:37:57,240 --> 00:37:59,069 And with that, we're now ready to start 1065 00:37:59,070 --> 00:38:02,159 designing a kernel debugger. 1066 00:38:02,160 --> 00:38:04,469 So what I eventually settled on was a 1067 00:38:04,470 --> 00:38:05,729 pretty simple design. 1068 00:38:05,730 --> 00:38:08,249 I would have one core in the CPSU, 1069 00:38:08,250 --> 00:38:09,299 which I call the monitor. 1070 00:38:09,300 --> 00:38:11,879 Core is going to be exclusively reserved 1071 00:38:11,880 --> 00:38:14,639 for the K TRW debugger itself. 1072 00:38:14,640 --> 00:38:16,349 So it's no longer going to be running X 1073 00:38:16,350 --> 00:38:18,539 and all of the other 1074 00:38:18,540 --> 00:38:20,309 cores in the system are going to continue 1075 00:38:20,310 --> 00:38:22,379 to run your operating system as they do 1076 00:38:22,380 --> 00:38:24,509 normally when you set 1077 00:38:24,510 --> 00:38:26,279 a breakpoint or a watch point on one of 1078 00:38:26,280 --> 00:38:28,529 the debug cause it's going to cause 1079 00:38:28,530 --> 00:38:31,259 that core to halt and enter debug state. 1080 00:38:31,260 --> 00:38:33,479 So the monitor core is just 1081 00:38:33,480 --> 00:38:35,999 going to sit in a tight loop pulling 1082 00:38:36,000 --> 00:38:38,069 all of the other cores to see when 1083 00:38:38,070 --> 00:38:39,719 they enter debug state. 1084 00:38:39,720 --> 00:38:41,939 And when it notices this, it'll send 1085 00:38:41,940 --> 00:38:42,919 a message to L.L. 1086 00:38:42,920 --> 00:38:45,279 D.B. over some communication channel 1087 00:38:45,280 --> 00:38:47,099 saying, hey, this court halted because it 1088 00:38:47,100 --> 00:38:49,649 hit a break point and then LTE can 1089 00:38:49,650 --> 00:38:50,650 take care of the rest. 1090 00:38:51,970 --> 00:38:54,009 Now, when I implemented this, I pretty 1091 00:38:54,010 --> 00:38:56,809 quickly encountered weird panic messages. 1092 00:38:56,810 --> 00:38:59,349 So this is one example AP panic. 1093 00:38:59,350 --> 00:39:00,969 No pulse on something or other. 1094 00:39:02,170 --> 00:39:03,489 And it took a little bit of effort. 1095 00:39:03,490 --> 00:39:05,049 But what I eventually learned was this 1096 00:39:05,050 --> 00:39:07,449 was being caused by 1097 00:39:07,450 --> 00:39:09,519 a process around the vise call it 1098 00:39:09,520 --> 00:39:11,679 called the always on processor, 1099 00:39:11,680 --> 00:39:13,809 sending periodic interrupts 1100 00:39:13,810 --> 00:39:16,809 to the main application processor 1101 00:39:16,810 --> 00:39:18,339 and the interrupts that are sent by the 1102 00:39:18,340 --> 00:39:21,129 always on process or need to be handled, 1103 00:39:21,130 --> 00:39:22,809 or else the GOP will panic. 1104 00:39:22,810 --> 00:39:24,969 And once the LP panics, it brings down 1105 00:39:24,970 --> 00:39:26,439 the whole system. 1106 00:39:26,440 --> 00:39:27,909 Now some of these interrupts are actually 1107 00:39:27,910 --> 00:39:29,859 relatively easy to disable. 1108 00:39:29,860 --> 00:39:32,199 I reverse engineered the watchdog 1109 00:39:32,200 --> 00:39:34,359 timer kernel extension and found 1110 00:39:34,360 --> 00:39:36,459 the hardware interface the 1111 00:39:36,460 --> 00:39:38,919 set of registers needed to disable 1112 00:39:38,920 --> 00:39:40,809 that. But there are other interrupts 1113 00:39:40,810 --> 00:39:43,069 which I wasn't able to narrow down. 1114 00:39:43,070 --> 00:39:45,309 I wasn't able to disable 1115 00:39:45,310 --> 00:39:46,479 now. 1116 00:39:46,480 --> 00:39:49,029 I strongly suspect that 1117 00:39:49,030 --> 00:39:51,399 the dev used devices that 1118 00:39:51,400 --> 00:39:53,439 some are able to acquire do have the 1119 00:39:53,440 --> 00:39:55,659 ability to 1120 00:39:55,660 --> 00:39:57,549 disable these interrupts or other or in 1121 00:39:57,550 --> 00:39:59,679 some way are not affected by this 1122 00:39:59,680 --> 00:40:01,719 problem. Because presumably when Apple's 1123 00:40:01,720 --> 00:40:03,969 engineers are using 1124 00:40:03,970 --> 00:40:06,009 one of these devices to debug the kernel 1125 00:40:06,010 --> 00:40:07,239 and they hold the kernel for a few 1126 00:40:07,240 --> 00:40:09,729 seconds, it's not a great user interface. 1127 00:40:09,730 --> 00:40:12,129 If when they resume execution, 1128 00:40:12,130 --> 00:40:14,439 the whole kernel panics because of this 1129 00:40:14,440 --> 00:40:15,440 interrupt problem. 1130 00:40:16,390 --> 00:40:18,429 So I strongly suspect there's a way to 1131 00:40:18,430 --> 00:40:20,559 fix this problem, but I wasn't able 1132 00:40:20,560 --> 00:40:22,039 to find it. 1133 00:40:22,040 --> 00:40:23,769 Instead, I basically implemented a big 1134 00:40:23,770 --> 00:40:25,749 hack, which is that I started servicing 1135 00:40:25,750 --> 00:40:27,909 interrupts from the EOP on 1136 00:40:27,910 --> 00:40:30,729 the monitor core itself. 1137 00:40:30,730 --> 00:40:32,439 Now this introduced its own problem, 1138 00:40:32,440 --> 00:40:34,059 which is that now execution on the 1139 00:40:34,060 --> 00:40:36,249 monitor core can jump back into X 1140 00:40:36,250 --> 00:40:38,559 and you and start running 1141 00:40:38,560 --> 00:40:40,959 the IRA Q handler at basically 1142 00:40:40,960 --> 00:40:43,389 any time, and that includes 1143 00:40:43,390 --> 00:40:45,489 when any of the debug 1144 00:40:45,490 --> 00:40:47,619 cause is halted holding 1145 00:40:47,620 --> 00:40:49,420 an IRA. Q Critical spent lock. 1146 00:40:50,980 --> 00:40:53,319 This is a huge problem because once 1147 00:40:53,320 --> 00:40:55,749 we try to acquire that same spent lock, 1148 00:40:55,750 --> 00:40:56,679 we can't acquire it. 1149 00:40:56,680 --> 00:40:57,789 It's already held. 1150 00:40:57,790 --> 00:40:59,139 And the only way that lock can be 1151 00:40:59,140 --> 00:41:00,999 released is if that debug the cords 1152 00:41:01,000 --> 00:41:03,029 resume, which has to be done by us. 1153 00:41:03,030 --> 00:41:05,139 So we entered this deadlock for a 1154 00:41:05,140 --> 00:41:06,069 very long time. 1155 00:41:06,070 --> 00:41:07,749 I thought that this was pretty much an 1156 00:41:07,750 --> 00:41:09,909 unsolvable problem for my debugger, 1157 00:41:09,910 --> 00:41:11,109 but it actually turns out there's a 1158 00:41:11,110 --> 00:41:13,209 really, really simple solution. 1159 00:41:13,210 --> 00:41:14,949 And the reason is that the action new 1160 00:41:14,950 --> 00:41:16,749 kernel itself has to deal with this 1161 00:41:16,750 --> 00:41:17,799 problem. 1162 00:41:17,800 --> 00:41:20,109 See when an IRA Q is delivered 1163 00:41:20,110 --> 00:41:23,309 and some code is processing the IQ 1164 00:41:23,310 --> 00:41:25,239 if interrupts were enabled. 1165 00:41:25,240 --> 00:41:27,609 Then a second IQ 1166 00:41:27,610 --> 00:41:29,679 could be delivered and cause the 1167 00:41:29,680 --> 00:41:31,779 IQ handler to be reentered. 1168 00:41:31,780 --> 00:41:33,309 In which case that same lock would be 1169 00:41:33,310 --> 00:41:35,049 grabbed a second time. 1170 00:41:35,050 --> 00:41:37,509 What that means is that interrupts 1171 00:41:37,510 --> 00:41:39,609 have to be disabled while 1172 00:41:39,610 --> 00:41:41,799 in an IQ critical region, 1173 00:41:41,800 --> 00:41:43,839 which means it's really easy to test for 1174 00:41:43,840 --> 00:41:45,399 whether it's safe to halt one of the 1175 00:41:45,400 --> 00:41:47,469 debug because you just check whether 1176 00:41:47,470 --> 00:41:49,599 interrupts are enabled or not if 1177 00:41:49,600 --> 00:41:51,189 interrupts are disabled. 1178 00:41:51,190 --> 00:41:53,049 That means that it's possibly in an IRA. 1179 00:41:53,050 --> 00:41:54,969 Q Critical region and you just wait a 1180 00:41:54,970 --> 00:41:56,619 little bit of time before halting that 1181 00:41:56,620 --> 00:41:58,959 core and after that, 1182 00:41:58,960 --> 00:42:00,669 all of my interrupt problems pretty much 1183 00:42:00,670 --> 00:42:01,670 disappeared. 1184 00:42:03,070 --> 00:42:05,529 So now we're at the point where we have 1185 00:42:05,530 --> 00:42:07,659 a text running 1186 00:42:07,660 --> 00:42:09,759 in the kernel. We seem to be able to halt 1187 00:42:09,760 --> 00:42:11,859 and resume CPR course, but we need 1188 00:42:11,860 --> 00:42:13,659 some way for L.L. 1189 00:42:13,660 --> 00:42:15,729 D.B. running on your laptop to 1190 00:42:15,730 --> 00:42:17,979 communicate with the debugger running 1191 00:42:17,980 --> 00:42:19,050 on your iPhone's kernel. 1192 00:42:20,080 --> 00:42:21,249 I considered a number of different 1193 00:42:21,250 --> 00:42:23,589 options, each with various advantages 1194 00:42:23,590 --> 00:42:25,389 and disadvantages. 1195 00:42:25,390 --> 00:42:27,399 Serial is really, really nice because 1196 00:42:27,400 --> 00:42:28,929 it's incredibly simple to implement 1197 00:42:29,980 --> 00:42:30,879 USP. 1198 00:42:30,880 --> 00:42:33,069 I liked because it would be really, 1199 00:42:33,070 --> 00:42:36,339 really fast Wi-Fi. 1200 00:42:36,340 --> 00:42:37,869 I kind of just threw in there in case the 1201 00:42:37,870 --> 00:42:39,159 other two didn't work. There wasn't any 1202 00:42:39,160 --> 00:42:41,499 really compelling reason to implement 1203 00:42:41,500 --> 00:42:42,580 a debugger over Wi-Fi. 1204 00:42:43,960 --> 00:42:45,759 What really made the decision was the 1205 00:42:45,760 --> 00:42:48,309 disadvantages of each 1206 00:42:48,310 --> 00:42:49,449 technique. 1207 00:42:49,450 --> 00:42:51,729 So for Serial, as far as I'm aware, 1208 00:42:51,730 --> 00:42:54,249 you do need special hardware 1209 00:42:54,250 --> 00:42:55,719 in order to operate 1210 00:42:57,140 --> 00:42:59,439 communicate with the iPhone over serial. 1211 00:42:59,440 --> 00:43:01,179 So this basically violates the first 1212 00:43:01,180 --> 00:43:03,309 goal. One of the goals of my 1213 00:43:03,310 --> 00:43:04,779 homebrew dev phone, which is that you 1214 00:43:04,780 --> 00:43:06,519 don't need any special hardware. 1215 00:43:06,520 --> 00:43:08,649 Everything can be purchased from 1216 00:43:08,650 --> 00:43:09,650 an Apple store. 1217 00:43:11,670 --> 00:43:13,839 The other two techniques, you SBN Wi-Fi, 1218 00:43:13,840 --> 00:43:15,689 both suffered from the same problem, 1219 00:43:15,690 --> 00:43:17,369 which is that I would need to write a 1220 00:43:17,370 --> 00:43:19,799 custom driver for the hardware. 1221 00:43:19,800 --> 00:43:22,049 The reason for this is that I cannot rely 1222 00:43:22,050 --> 00:43:24,299 in my debugger on the code 1223 00:43:24,300 --> 00:43:25,559 that I'm debugging. 1224 00:43:25,560 --> 00:43:27,689 If I set a breakpoint and a 1225 00:43:27,690 --> 00:43:30,029 few core halts while it has 1226 00:43:30,030 --> 00:43:32,669 some block used by the Wi-Fi 1227 00:43:32,670 --> 00:43:34,889 or the USP drivers, then 1228 00:43:34,890 --> 00:43:37,169 when my application in my kernel 1229 00:43:37,170 --> 00:43:39,149 debugger tries to communicate over that 1230 00:43:39,150 --> 00:43:41,519 mechanism using the stock 1231 00:43:41,520 --> 00:43:43,679 built in to X and you, it's 1232 00:43:43,680 --> 00:43:45,119 going to try to take the same lock and 1233 00:43:45,120 --> 00:43:47,219 deadlock, same problem we had before. 1234 00:43:47,220 --> 00:43:49,559 So whatever communication channel we use, 1235 00:43:49,560 --> 00:43:51,719 we to implement a custom driver for 1236 00:43:51,720 --> 00:43:53,489 it, which is self-contained. 1237 00:43:53,490 --> 00:43:55,979 So out of USP and Wi-Fi. 1238 00:43:55,980 --> 00:43:58,289 I basically figured that writing a USP 1239 00:43:58,290 --> 00:43:59,970 stock was slightly less painful. 1240 00:44:01,580 --> 00:44:02,959 It was pretty easy to figure out with 1241 00:44:02,960 --> 00:44:05,969 some Googling. Which hardware 1242 00:44:05,970 --> 00:44:08,989 USB controller wasn't used in the iPhone. 1243 00:44:08,990 --> 00:44:11,359 It's a controller by synopsis called 1244 00:44:11,360 --> 00:44:13,729 the design where high speed USB 2.0 1245 00:44:13,730 --> 00:44:14,730 on the go controller 1246 00:44:15,820 --> 00:44:17,689 was somewhat unfortunate about this 1247 00:44:17,690 --> 00:44:19,759 controller is that it is 1248 00:44:19,760 --> 00:44:22,189 proprietary. The interface that it uses 1249 00:44:22,190 --> 00:44:24,289 to communicate is not one of the standard 1250 00:44:24,290 --> 00:44:26,749 USP interfaces, which means that you 1251 00:44:26,750 --> 00:44:29,209 cannot use kind of your stock 1252 00:44:29,210 --> 00:44:31,519 open source off the shelf drivers 1253 00:44:31,520 --> 00:44:32,520 for it. 1254 00:44:33,710 --> 00:44:35,359 And when I tried to look at the data 1255 00:44:35,360 --> 00:44:37,529 sheet to see how I could 1256 00:44:37,530 --> 00:44:39,649 program my own driver, I quickly ran 1257 00:44:39,650 --> 00:44:41,929 into a log in while I couldn't 1258 00:44:41,930 --> 00:44:42,919 actually access it. 1259 00:44:42,920 --> 00:44:45,199 And I was unable to obtain 1260 00:44:45,200 --> 00:44:46,200 the data sheet for it. 1261 00:44:47,390 --> 00:44:48,889 So this seemed really problematic. 1262 00:44:48,890 --> 00:44:52,189 But one thing that I could find was 1263 00:44:52,190 --> 00:44:54,229 open source header files for this 1264 00:44:54,230 --> 00:44:55,279 hardware. 1265 00:44:55,280 --> 00:44:57,469 Now there are open source drivers 1266 00:44:57,470 --> 00:44:59,209 for operating it, but all the ones that I 1267 00:44:59,210 --> 00:45:01,489 was able to find that 1268 00:45:01,490 --> 00:45:03,619 operated this hardware did so in a 1269 00:45:03,620 --> 00:45:04,279 host mode. 1270 00:45:04,280 --> 00:45:06,409 So kind of as a laptop rather than as 1271 00:45:06,410 --> 00:45:08,689 a device, you plug into it. 1272 00:45:08,690 --> 00:45:10,339 And that didn't really work for me. 1273 00:45:10,340 --> 00:45:11,809 So that wouldn't 1274 00:45:13,490 --> 00:45:15,469 be that wasn't what I wanted. 1275 00:45:15,470 --> 00:45:17,689 But I was able to use the header 1276 00:45:17,690 --> 00:45:19,379 files which contained the register 1277 00:45:19,380 --> 00:45:20,380 definitions. 1278 00:45:21,620 --> 00:45:23,239 Now, the only place that I could think of 1279 00:45:23,240 --> 00:45:25,489 that contained a fully 1280 00:45:25,490 --> 00:45:28,099 self-contained implementation 1281 00:45:28,100 --> 00:45:29,100 of the 1282 00:45:30,220 --> 00:45:33,559 USP stock that operated the exact same 1283 00:45:33,560 --> 00:45:35,659 hardware as using the iPhone 1284 00:45:35,660 --> 00:45:37,939 was the iPhone's very 1285 00:45:37,940 --> 00:45:39,199 own secure ROM. 1286 00:45:39,200 --> 00:45:41,329 So the secure Rahm is the 1287 00:45:41,330 --> 00:45:43,519 very first piece of code that runs on 1288 00:45:43,520 --> 00:45:45,229 the application process or when it starts 1289 00:45:45,230 --> 00:45:47,389 up and it needs the USP stack 1290 00:45:47,390 --> 00:45:49,819 in order to communicate with 1291 00:45:49,820 --> 00:45:52,079 a computer over for DFA. 1292 00:45:52,080 --> 00:45:53,480 You firmware upgrades. 1293 00:45:54,690 --> 00:45:56,959 So I basically took Apple 1294 00:45:56,960 --> 00:45:59,009 secure from their dumps of it that you 1295 00:45:59,010 --> 00:46:00,659 can find online. 1296 00:46:00,660 --> 00:46:02,939 And I put it into IDA and 1297 00:46:02,940 --> 00:46:05,489 reverse engineered the 1298 00:46:05,490 --> 00:46:07,829 secure ROMs USP stock basically 1299 00:46:07,830 --> 00:46:09,989 back to source and then re implemented it 1300 00:46:09,990 --> 00:46:10,990 in C. 1301 00:46:11,880 --> 00:46:13,919 And so this was a rather painful process, 1302 00:46:13,920 --> 00:46:16,169 but the end result was that 1303 00:46:16,170 --> 00:46:18,539 I was able to make my iPhone 1304 00:46:18,540 --> 00:46:20,699 appear to my laptop as a 1305 00:46:20,700 --> 00:46:23,009 special key TRW USP 1306 00:46:23,010 --> 00:46:24,010 device. 1307 00:46:33,220 --> 00:46:35,199 And with that, the only step left in 1308 00:46:35,200 --> 00:46:37,209 actually implementing a debugger is 1309 00:46:37,210 --> 00:46:39,249 implementing the GDP stub. 1310 00:46:39,250 --> 00:46:41,349 This is pretty easy 1311 00:46:41,350 --> 00:46:43,449 as compared to kind of the other stuff 1312 00:46:43,450 --> 00:46:44,739 in this project. 1313 00:46:44,740 --> 00:46:47,059 The GDP specification is open source. 1314 00:46:47,060 --> 00:46:48,939 It's basically just a bunch of passing 1315 00:46:48,940 --> 00:46:51,279 and then driving the external debug 1316 00:46:51,280 --> 00:46:52,779 interface. 1317 00:46:52,780 --> 00:46:54,849 And once that was done, I had 1318 00:46:54,850 --> 00:46:56,949 the ability to debug a production 1319 00:46:56,950 --> 00:46:59,589 iPhone over USP. 1320 00:46:59,590 --> 00:47:01,689 No special cables, no leaks, software 1321 00:47:01,690 --> 00:47:02,690 involved. 1322 00:47:03,940 --> 00:47:05,250 Yeah, it was pretty cool. 1323 00:47:13,080 --> 00:47:15,269 So here I'll do a hopefully very quick 1324 00:47:15,270 --> 00:47:17,339 demo of how to operate 1325 00:47:17,340 --> 00:47:18,299 this debugger. 1326 00:47:18,300 --> 00:47:20,159 So I have an iPhone, which 1327 00:47:21,300 --> 00:47:22,859 you can see here. 1328 00:47:22,860 --> 00:47:24,870 Right now you're able to see the 1329 00:47:25,980 --> 00:47:27,749 kind of the screenshot of it on the 1330 00:47:27,750 --> 00:47:29,759 laptop. But as soon as I operate the 1331 00:47:29,760 --> 00:47:31,409 debugger, the USP stack will be taken 1332 00:47:31,410 --> 00:47:33,779 over and you'll no longer be able to see 1333 00:47:33,780 --> 00:47:34,830 this part of it. So 1334 00:47:35,970 --> 00:47:38,579 what I'll do is I'll simply start the 1335 00:47:38,580 --> 00:47:40,530 app that loads the kernel extension. 1336 00:47:42,640 --> 00:47:44,609 And so once that's running, we'll lose 1337 00:47:44,610 --> 00:47:46,049 connectivity with advice, but we can 1338 00:47:46,050 --> 00:47:47,689 connect to it with LGB. 1339 00:47:50,840 --> 00:47:51,769 And yeah. OK. 1340 00:47:51,770 --> 00:47:54,109 So I'll LGB has recognized 1341 00:47:54,110 --> 00:47:56,479 this device as an OS device 1342 00:47:56,480 --> 00:47:58,609 and I OS kernel cache, it's discovered 1343 00:47:58,610 --> 00:48:00,319 the load address and it's halted the 1344 00:48:00,320 --> 00:48:03,649 kernel so we can now resume execution. 1345 00:48:03,650 --> 00:48:06,079 Now I can't show this on the display, 1346 00:48:06,080 --> 00:48:07,939 but for those of you in person, you can 1347 00:48:07,940 --> 00:48:10,669 see that the device is still responsive. 1348 00:48:10,670 --> 00:48:13,389 You can do things like load apps 1349 00:48:13,390 --> 00:48:14,899 and yet there's still a kernel debugger 1350 00:48:14,900 --> 00:48:15,920 attached to the device 1351 00:48:17,540 --> 00:48:18,679 so we can do things. 1352 00:48:18,680 --> 00:48:20,209 For example, all set a breakpoint 1353 00:48:21,680 --> 00:48:23,449 on the sister call main core. 1354 00:48:25,340 --> 00:48:27,139 All right. So we have a breakpoint set. 1355 00:48:27,140 --> 00:48:29,839 Now I have an application on the device 1356 00:48:29,840 --> 00:48:31,669 that is simply going to call Main Core 1357 00:48:31,670 --> 00:48:34,099 with very distinctive arguments. 1358 00:48:34,100 --> 00:48:36,379 It is possible to load an app 1359 00:48:36,380 --> 00:48:38,509 onto the device over Wi-Fi even once 1360 00:48:38,510 --> 00:48:41,659 the USP hardware has been co-opted. 1361 00:48:41,660 --> 00:48:43,729 But for this demo, I'm just going to 1362 00:48:43,730 --> 00:48:45,679 have the app pre install the device. 1363 00:48:45,680 --> 00:48:47,209 I'm going to click on the application 1364 00:48:47,210 --> 00:48:49,399 icon and it basically 1365 00:48:49,400 --> 00:48:51,349 immediately halts. 1366 00:48:51,350 --> 00:48:53,389 The phone is no longer responsive because 1367 00:48:53,390 --> 00:48:55,279 we're halted our breakpoint and we can do 1368 00:48:55,280 --> 00:48:57,139 things like get a back trace, we can 1369 00:48:57,140 --> 00:48:59,539 examine registers all look at 1370 00:48:59,540 --> 00:49:01,819 the memory point you do by 1371 00:49:01,820 --> 00:49:03,919 register x1 and we can indeed 1372 00:49:03,920 --> 00:49:06,229 see are arguments that were passed 1373 00:49:06,230 --> 00:49:07,819 from user space. 1374 00:49:07,820 --> 00:49:09,569 We can do things like that, watch points, 1375 00:49:09,570 --> 00:49:11,599 kind of all of your standard debugging 1376 00:49:11,600 --> 00:49:12,600 functionality. 1377 00:49:19,220 --> 00:49:21,259 So we'll set a watch point on this memory 1378 00:49:21,260 --> 00:49:23,899 address and resume execution 1379 00:49:23,900 --> 00:49:25,309 and we basically immediately hit the 1380 00:49:25,310 --> 00:49:26,310 watch point. 1381 00:49:29,050 --> 00:49:30,909 And you can see the instruction that 1382 00:49:30,910 --> 00:49:32,859 triggered this watch point loads x10 an X 1383 00:49:32,860 --> 00:49:33,860 eleven. 1384 00:49:35,990 --> 00:49:37,249 And these are indeed the values that we 1385 00:49:37,250 --> 00:49:38,599 expect. So at what point seemed to 1386 00:49:38,600 --> 00:49:40,999 function correctly, we can 1387 00:49:41,000 --> 00:49:42,800 disable the breakpoint 1388 00:49:44,000 --> 00:49:46,129 and the watch point and 1389 00:49:46,130 --> 00:49:48,059 resume execution. 1390 00:49:48,060 --> 00:49:49,279 The app runs again. Your phone is 1391 00:49:49,280 --> 00:49:50,779 responsive. 1392 00:49:50,780 --> 00:49:52,129 So basically a full feature kernel 1393 00:49:52,130 --> 00:49:53,130 debugger. 1394 00:50:01,240 --> 00:50:03,249 So thank you very much. 1395 00:50:03,250 --> 00:50:05,439 The Debugger Source code 1396 00:50:05,440 --> 00:50:07,119 is available on the Google project zero 1397 00:50:07,120 --> 00:50:08,019 GitHub. 1398 00:50:08,020 --> 00:50:10,209 I also wrote a blog post kind 1399 00:50:10,210 --> 00:50:12,279 of describing in more detail 1400 00:50:12,280 --> 00:50:15,309 the process of finding the KKR bypass. 1401 00:50:15,310 --> 00:50:17,419 This was a really, really fun project 1402 00:50:17,420 --> 00:50:19,659 and I am really 1403 00:50:19,660 --> 00:50:21,489 excited to hopefully make Colonel 1404 00:50:21,490 --> 00:50:23,139 debugging on the iPhone just a little bit 1405 00:50:23,140 --> 00:50:25,419 easier. Future versions will probably be 1406 00:50:25,420 --> 00:50:27,489 based on the BU RAM exploit, which 1407 00:50:27,490 --> 00:50:29,349 I'm really excited to see what comes out 1408 00:50:29,350 --> 00:50:30,739 of that. So thank you. 1409 00:50:36,490 --> 00:50:38,109 Thank you very much. 1410 00:50:38,110 --> 00:50:40,209 So we have five minutes left for 1411 00:50:40,210 --> 00:50:41,979 a Q and A, please queue up on the 1412 00:50:41,980 --> 00:50:44,309 microphones in between microphone 1413 00:50:44,310 --> 00:50:45,489 one, two, three, four. 1414 00:50:45,490 --> 00:50:47,569 We have some more. So 1415 00:50:47,570 --> 00:50:48,999 and maybe you have questions from the 1416 00:50:49,000 --> 00:50:50,540 Signal Angels, Signal Angel. 1417 00:50:52,550 --> 00:50:54,139 No questions from the Signal Angels. 1418 00:50:54,140 --> 00:50:55,390 So microphone one, please. 1419 00:50:56,930 --> 00:50:59,019 Yeah. Thanks for the amazing talk. 1420 00:50:59,020 --> 00:51:00,879 At the beginning you showed us a tweet of 1421 00:51:00,880 --> 00:51:02,969 the exploit and just 1422 00:51:02,970 --> 00:51:05,079 said that everything you could 1423 00:51:05,080 --> 00:51:07,149 do was possible with this one as well. 1424 00:51:07,150 --> 00:51:09,069 It said that it's not touchable. 1425 00:51:09,070 --> 00:51:11,169 So do you see any problems 1426 00:51:11,170 --> 00:51:13,239 regarding security or anything 1427 00:51:13,240 --> 00:51:14,649 using such a technique? 1428 00:51:14,650 --> 00:51:16,839 And is it possible to run 1429 00:51:16,840 --> 00:51:17,840 it like without 1430 00:51:19,420 --> 00:51:20,709 having the iPhone unlocked? 1431 00:51:20,710 --> 00:51:22,569 And is there any way to sort of abuse 1432 00:51:22,570 --> 00:51:23,570 this? 1433 00:51:24,280 --> 00:51:26,649 Do you mean the RAM bug 1434 00:51:26,650 --> 00:51:28,539 or do you mean the debugging registers 1435 00:51:28,540 --> 00:51:31,099 used here or both or either? 1436 00:51:31,100 --> 00:51:32,319 Yeah, just. 1437 00:51:32,320 --> 00:51:33,429 Everything. All the above. 1438 00:51:35,500 --> 00:51:36,999 I don't really know. 1439 00:51:37,000 --> 00:51:38,949 This isn't really kind of my area of 1440 00:51:38,950 --> 00:51:40,929 expertise. I can see, you know, some 1441 00:51:40,930 --> 00:51:43,029 people might be able to leverage 1442 00:51:43,030 --> 00:51:44,619 these types of vulnerabilities for, you 1443 00:51:44,620 --> 00:51:47,379 know, proximal physical attacks. 1444 00:51:47,380 --> 00:51:49,479 The debugging registers that I'm using 1445 00:51:49,480 --> 00:51:51,999 here aren't really all that useful 1446 00:51:52,000 --> 00:51:54,549 for a remote attack because 1447 00:51:54,550 --> 00:51:56,099 you encounter that problem or, you know, 1448 00:51:56,100 --> 00:51:58,509 CPE or resets and the KKR bypass 1449 00:51:58,510 --> 00:51:59,589 gets lost. 1450 00:51:59,590 --> 00:52:01,719 And really, once you have a kernel 1451 00:52:01,720 --> 00:52:02,979 code execution, you should really 1452 00:52:02,980 --> 00:52:04,689 consider your advice fully compromised 1453 00:52:04,690 --> 00:52:07,459 anyway. So I don't really think that 1454 00:52:07,460 --> 00:52:10,089 the debug registers are a security issue 1455 00:52:10,090 --> 00:52:11,249 to boot rom. 1456 00:52:11,250 --> 00:52:12,989 You know, maybe for physical stuff, but 1457 00:52:14,070 --> 00:52:15,909 it depends on your threat model. 1458 00:52:15,910 --> 00:52:17,049 Thank you. 1459 00:52:17,050 --> 00:52:18,190 Microphone four, please. 1460 00:52:19,390 --> 00:52:21,069 Did you have a look in to do you Linux 1461 00:52:21,070 --> 00:52:22,389 kernel for the design? 1462 00:52:22,390 --> 00:52:24,529 What to quote a driver because it's in 1463 00:52:24,530 --> 00:52:26,679 drivers use BTC too I think. 1464 00:52:26,680 --> 00:52:28,629 Yeah. So this was actually really funny. 1465 00:52:28,630 --> 00:52:30,819 Basically as soon as I had finished 1466 00:52:30,820 --> 00:52:33,009 implementing the USP stack 1467 00:52:33,010 --> 00:52:35,079 and I'd got it working, I realized 1468 00:52:35,080 --> 00:52:37,299 that the reason I couldn't find any 1469 00:52:37,300 --> 00:52:39,939 open source drivers online was because 1470 00:52:39,940 --> 00:52:42,039 I was searching for the wrong things in 1471 00:52:42,040 --> 00:52:43,959 Google. I'm just really bad at googling 1472 00:52:43,960 --> 00:52:46,689 and the files containing 1473 00:52:46,690 --> 00:52:48,819 the driver for operating 1474 00:52:48,820 --> 00:52:50,949 it in device mode 1475 00:52:50,950 --> 00:52:52,449 were just named something different than 1476 00:52:52,450 --> 00:52:53,450 I expected. 1477 00:52:54,340 --> 00:52:56,559 So you learn as you go. 1478 00:52:58,060 --> 00:53:00,849 Great. Thanks. Microphone one, please. 1479 00:53:00,850 --> 00:53:01,869 Hi. 1480 00:53:01,870 --> 00:53:04,089 Great talk. I really enjoyed it. 1481 00:53:04,090 --> 00:53:06,489 So I have a quick comment and then 1482 00:53:06,490 --> 00:53:07,509 a question. 1483 00:53:07,510 --> 00:53:09,790 So comment is 1484 00:53:11,290 --> 00:53:13,899 this is the first time this is publicly 1485 00:53:13,900 --> 00:53:16,059 revealed. But the veto was 1486 00:53:16,060 --> 00:53:18,189 actually the trust zone was 1487 00:53:18,190 --> 00:53:20,259 first dumped exactly the same 1488 00:53:20,260 --> 00:53:23,139 way through the course site registers. 1489 00:53:23,140 --> 00:53:24,429 That was 2014. 1490 00:53:24,430 --> 00:53:25,819 That's pretty financing. 1491 00:53:25,820 --> 00:53:28,209 Is this still happening again? 1492 00:53:28,210 --> 00:53:30,339 Again, my question is, you said 1493 00:53:30,340 --> 00:53:32,050 you reversed the 1494 00:53:33,100 --> 00:53:34,579 USP from secure. 1495 00:53:34,580 --> 00:53:35,880 So did you find checkmate? 1496 00:53:38,320 --> 00:53:40,299 So first about your comment. 1497 00:53:40,300 --> 00:53:42,459 Definitely. I know that there 1498 00:53:42,460 --> 00:53:44,409 are tons of people who have found similar 1499 00:53:44,410 --> 00:53:46,479 capabilities. Basically, nothing 1500 00:53:46,480 --> 00:53:48,130 that I've done in this project is 1501 00:53:49,240 --> 00:53:51,549 original work. All of it is building off 1502 00:53:51,550 --> 00:53:53,109 of stuff which other people have done. 1503 00:53:53,110 --> 00:53:54,999 So absolutely. That's definitely the case 1504 00:53:56,170 --> 00:53:58,059 about whether I discover checkmate or 1505 00:53:58,060 --> 00:54:00,189 not. The first time I was looking at I 1506 00:54:00,190 --> 00:54:02,919 boot, I basically saw the USP 1507 00:54:02,920 --> 00:54:05,079 stock code and I was like, oh my god, 1508 00:54:05,080 --> 00:54:06,339 this is so complicated. 1509 00:54:06,340 --> 00:54:07,809 I want to avoid touching this if at all 1510 00:54:07,810 --> 00:54:09,579 possible. So now I completely missed 1511 00:54:09,580 --> 00:54:10,580 that. 1512 00:54:12,520 --> 00:54:13,429 Thank you. 1513 00:54:13,430 --> 00:54:15,879 So no more questions, please. 1514 00:54:15,880 --> 00:54:17,709 Another big round of applause for 1515 00:54:17,710 --> 00:54:18,710 Brandon.