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/707 Thanks! 1 00:00:13,310 --> 00:00:15,490 Our next speaker is Team Star 2 00:00:16,520 --> 00:00:17,959 personally for me. 3 00:00:17,960 --> 00:00:19,909 I'm happy to I can announce this talk. 4 00:00:19,910 --> 00:00:21,529 I own an Apple device, but for me, the 5 00:00:21,530 --> 00:00:23,599 point of owning this Apple device is that 6 00:00:23,600 --> 00:00:24,679 it just works. Right. 7 00:00:24,680 --> 00:00:26,749 I don't like to tinker with that specific 8 00:00:26,750 --> 00:00:28,639 device. So I'm very grateful that there 9 00:00:28,640 --> 00:00:30,739 are people who actually would like to 10 00:00:30,740 --> 00:00:32,839 tinker with Apple devices such as 11 00:00:32,840 --> 00:00:33,840 Team Star. 12 00:00:34,400 --> 00:00:36,109 So personally, I'm looking forward to 13 00:00:36,110 --> 00:00:38,839 learning all about downgrading iOS, 14 00:00:38,840 --> 00:00:40,489 how it worked in the past, how it works 15 00:00:40,490 --> 00:00:42,649 in the present, and what new that 16 00:00:42,650 --> 00:00:44,719 what new will be in the presentation that 17 00:00:44,720 --> 00:00:46,249 Team Star can teach us. 18 00:00:46,250 --> 00:00:48,439 So with that, I would like 19 00:00:48,440 --> 00:00:50,599 to ask all of you to give Team 20 00:00:50,600 --> 00:00:52,339 Star a warm round of applause. 21 00:00:52,340 --> 00:00:53,340 Thanks. 22 00:01:00,840 --> 00:01:02,369 Alice, thank you very much. 23 00:01:02,370 --> 00:01:04,499 Um, yeah, I'm Tim, sir, and I'm 24 00:01:04,500 --> 00:01:05,969 going to present you downgrading files 25 00:01:05,970 --> 00:01:07,889 from past to present. 26 00:01:07,890 --> 00:01:10,109 So the topics of this talk will be 27 00:01:10,110 --> 00:01:12,149 the I was Bushin and how it changed 28 00:01:12,150 --> 00:01:13,289 through the versions. 29 00:01:13,290 --> 00:01:15,749 I'm going to talk about SHC, blob's 30 00:01:15,750 --> 00:01:17,609 and AP tickets, what those are. 31 00:01:18,930 --> 00:01:21,239 I'm going to talk about the pastorate 32 00:01:21,240 --> 00:01:22,919 methods. 33 00:01:22,920 --> 00:01:24,449 Real quick intro. And I'm just three 34 00:01:24,450 --> 00:01:26,249 names for file format. 35 00:01:26,250 --> 00:01:28,229 Um, then I'm going to tell you what the 36 00:01:28,230 --> 00:01:30,599 basement and sepoys problem is, which 37 00:01:30,600 --> 00:01:31,859 we encounter with songwriting. 38 00:01:31,860 --> 00:01:33,989 And at the end there is something new 39 00:01:33,990 --> 00:01:35,640 for 64 bit devices. 40 00:01:37,230 --> 00:01:39,569 So this is the year Bushin 41 00:01:39,570 --> 00:01:41,669 um, I'm going to see this 42 00:01:41,670 --> 00:01:43,319 picture a few times in this presentation. 43 00:01:43,320 --> 00:01:44,999 But basically right here we have two 44 00:01:45,000 --> 00:01:46,079 routes. 45 00:01:46,080 --> 00:01:48,239 We have the normal board and 46 00:01:48,240 --> 00:01:50,309 we have to give you both to you the 47 00:01:50,310 --> 00:01:52,679 device from or upgrade, um, 48 00:01:52,680 --> 00:01:54,209 if you upgrade the device. 49 00:01:54,210 --> 00:01:56,309 So, yeah, what you can see 50 00:01:56,310 --> 00:01:58,379 here is that, uh, the boardroom first 51 00:01:58,380 --> 00:02:00,479 puts the first stage bootloader, 52 00:02:00,480 --> 00:02:02,339 the first stage up with the second stage 53 00:02:02,340 --> 00:02:04,559 bootloader, which is I would normal board 54 00:02:04,560 --> 00:02:07,499 or IBRC if you go to a restaurant, 55 00:02:07,500 --> 00:02:09,399 if you go to normal, but then the kernel 56 00:02:09,400 --> 00:02:11,669 boards and for a 64 bit devices this 57 00:02:11,670 --> 00:02:13,139 new the sepoys booths. 58 00:02:13,140 --> 00:02:15,119 What that is I'm going to talk about in a 59 00:02:15,120 --> 00:02:16,349 few slides. 60 00:02:16,350 --> 00:02:18,509 If you go to def, you wrote, um, 61 00:02:18,510 --> 00:02:20,099 then the ram is going to Colonel has put 62 00:02:20,100 --> 00:02:22,409 it, this is much like a live system 63 00:02:22,410 --> 00:02:24,149 and you use that for restoring. 64 00:02:26,070 --> 00:02:28,169 So yeah. Let's talk a bit about Iowa's 65 00:02:28,170 --> 00:02:30,299 history with the iPhone 66 00:02:30,300 --> 00:02:32,729 2G. We had iPhone, 67 00:02:32,730 --> 00:02:34,859 iPhone W one and iPhone 68 00:02:34,860 --> 00:02:37,019 two and three and there were Precint 69 00:02:37,020 --> 00:02:39,119 and it was just possible there 70 00:02:39,120 --> 00:02:40,839 was like nothing stopping you from 71 00:02:40,840 --> 00:02:43,229 downgrading that this changed a bit 72 00:02:43,230 --> 00:02:45,149 in iPhone 3G. 73 00:02:45,150 --> 00:02:47,339 Well, it didn't change in iPhone was two 74 00:02:47,340 --> 00:02:48,959 and three. It was basically the same, but 75 00:02:48,960 --> 00:02:51,059 it changed with I was four 76 00:02:51,060 --> 00:02:53,399 on your iPhone 3G, Apple added software, 77 00:02:53,400 --> 00:02:56,099 SHC checks and 78 00:02:56,100 --> 00:02:57,779 don't worry, it was still possible with a 79 00:02:57,780 --> 00:02:58,780 few hacks. 80 00:02:59,850 --> 00:03:02,009 So let's take a look at the chain 81 00:03:02,010 --> 00:03:03,479 off an iPhone 3G. 82 00:03:03,480 --> 00:03:05,189 I was four. 83 00:03:05,190 --> 00:03:06,629 I want to nod real quick. 84 00:03:06,630 --> 00:03:08,729 I'm only talking about iPhones. 85 00:03:08,730 --> 00:03:10,829 Uh, but this also applies 86 00:03:10,830 --> 00:03:13,079 to iPads and iPods with the same 87 00:03:13,080 --> 00:03:15,479 hardware. So keep that in mind. 88 00:03:15,480 --> 00:03:18,059 So what you can see here that the, um, 89 00:03:18,060 --> 00:03:20,249 put components check each other like, 90 00:03:20,250 --> 00:03:21,809 uh, first stage bootloader checks, the 91 00:03:21,810 --> 00:03:23,789 second stage bootloader, second stage 92 00:03:23,790 --> 00:03:25,559 Boolarra checks the kernel and the 93 00:03:25,560 --> 00:03:26,909 Ramdisk and so on. 94 00:03:26,910 --> 00:03:28,619 But you could see here there are missing, 95 00:03:28,620 --> 00:03:30,569 uh, one thing the boot from doesn't check 96 00:03:30,570 --> 00:03:32,219 the first stage bootloader doesn't check 97 00:03:32,220 --> 00:03:34,169 ILB or IBS. 98 00:03:34,170 --> 00:03:36,449 So if you want to go back to Iowa three, 99 00:03:36,450 --> 00:03:38,519 two or one, you could just do it. 100 00:03:38,520 --> 00:03:40,019 The Woodrum doesn't check, doesn't 101 00:03:40,020 --> 00:03:41,020 prevent that. 102 00:03:42,060 --> 00:03:44,399 So what are those SHC blobs 103 00:03:44,400 --> 00:03:45,329 I'm talking about? 104 00:03:45,330 --> 00:03:47,459 Well, Apple introduced those who control 105 00:03:47,460 --> 00:03:49,289 what iOS version can be installed on your 106 00:03:49,290 --> 00:03:50,459 device. 107 00:03:50,460 --> 00:03:52,529 And those need to be requested from 108 00:03:52,530 --> 00:03:54,689 Apple by restoring and 109 00:03:54,690 --> 00:03:56,969 just blob is basically a signed 110 00:03:56,970 --> 00:03:59,429 hash plus the essence of the device. 111 00:03:59,430 --> 00:04:01,799 So this makes them unique 112 00:04:01,800 --> 00:04:02,789 for every device. 113 00:04:02,790 --> 00:04:04,979 You can't just take one just from one 114 00:04:04,980 --> 00:04:06,959 device and try to use it with a different 115 00:04:06,960 --> 00:04:08,909 device. That won't work because the ESET 116 00:04:08,910 --> 00:04:09,910 is different. 117 00:04:11,280 --> 00:04:14,129 So, um, let's take a look at 118 00:04:14,130 --> 00:04:17,069 this age and IMGs RE5 format. 119 00:04:17,070 --> 00:04:18,869 So on the left image, you can see the 120 00:04:18,870 --> 00:04:20,159 grammar for our names. 121 00:04:20,160 --> 00:04:21,778 Yes, we file basically we have some 122 00:04:21,779 --> 00:04:24,029 magic, we have some sizes and 123 00:04:24,030 --> 00:04:26,129 we have a bunch of images, retakes and 124 00:04:26,130 --> 00:04:28,019 also actually interesting ones. 125 00:04:28,020 --> 00:04:30,159 And those, um, what those 126 00:04:30,160 --> 00:04:32,099 images retakes can be, you can see on the 127 00:04:32,100 --> 00:04:34,529 right, this is a picture taken from 128 00:04:34,530 --> 00:04:36,899 the iPhone WICKY and 129 00:04:36,900 --> 00:04:39,239 those files contain stuff like the Abbott 130 00:04:39,240 --> 00:04:41,309 version, what chip this former 131 00:04:41,310 --> 00:04:42,239 is to be used on. 132 00:04:42,240 --> 00:04:45,179 And you can also see SHC age 133 00:04:45,180 --> 00:04:47,249 and the sex age is basically 134 00:04:47,250 --> 00:04:49,439 an RSA encrypted one hash of 135 00:04:49,440 --> 00:04:50,440 the file. 136 00:04:51,960 --> 00:04:54,089 So this is how it looks like if 137 00:04:54,090 --> 00:04:56,279 you open up in a Hex editor, you can 138 00:04:56,280 --> 00:04:58,379 see a bunch of 139 00:04:58,380 --> 00:05:00,989 IMG three tags and 140 00:05:00,990 --> 00:05:03,229 the one which I highlighted is the 141 00:05:03,230 --> 00:05:04,889 price tag. 142 00:05:04,890 --> 00:05:06,959 So it's basically the arrows are 143 00:05:06,960 --> 00:05:09,239 one encrypted Szechuan hash. 144 00:05:09,240 --> 00:05:10,410 And Belal, this is 145 00:05:11,430 --> 00:05:12,659 what you can't really see. 146 00:05:12,660 --> 00:05:14,759 Here is the certificate, which 147 00:05:14,760 --> 00:05:16,649 contains Apple's public key, which you 148 00:05:16,650 --> 00:05:18,329 can use to verify that signature. 149 00:05:19,850 --> 00:05:21,429 So let's continue with the obvious 150 00:05:21,430 --> 00:05:24,139 mystery with iPhone 3GS 151 00:05:24,140 --> 00:05:26,359 and the iPhone four, 152 00:05:26,360 --> 00:05:28,579 things changed a bit with I was three two 153 00:05:28,580 --> 00:05:30,839 hours for Apple, had hardware 154 00:05:30,840 --> 00:05:33,289 and forced, um, SHC 155 00:05:33,290 --> 00:05:35,509 checks. Those were new those two 156 00:05:35,510 --> 00:05:36,739 devices. 157 00:05:36,740 --> 00:05:39,179 And starting with I was, uh, five, 158 00:05:39,180 --> 00:05:41,359 um, Apple introduced AP tickets. 159 00:05:41,360 --> 00:05:43,429 But what that is, um, we'll 160 00:05:43,430 --> 00:05:44,430 see later. 161 00:05:45,480 --> 00:05:47,999 So this is how the Bush-Cheney looks like 162 00:05:48,000 --> 00:05:50,309 on Prius five, on iPhone 163 00:05:50,310 --> 00:05:51,690 four and iPhone 3GS. 164 00:05:53,110 --> 00:05:54,909 And you can see the only difference here 165 00:05:54,910 --> 00:05:57,579 is that the board room does verify the 166 00:05:57,580 --> 00:05:59,799 blobs, so that's 167 00:05:59,800 --> 00:06:01,060 actually the only difference. 168 00:06:02,620 --> 00:06:03,909 How do we downgrade this? 169 00:06:03,910 --> 00:06:06,039 Well, um, 170 00:06:06,040 --> 00:06:08,979 as I just blob is just assigned 171 00:06:08,980 --> 00:06:11,109 hash of the former. 172 00:06:11,110 --> 00:06:13,059 So there is nothing which prevent us from 173 00:06:13,060 --> 00:06:13,989 a downgrade attack. 174 00:06:13,990 --> 00:06:16,119 What you would do is you save as I just 175 00:06:16,120 --> 00:06:18,489 blob's while they're assigned and 176 00:06:18,490 --> 00:06:19,899 there are a bunch of tubes which can do 177 00:06:19,900 --> 00:06:21,969 that, for example, tiny umbrella and 178 00:06:21,970 --> 00:06:23,529 they're their effect. 179 00:06:23,530 --> 00:06:25,599 And when Apple doesn't sign 180 00:06:25,600 --> 00:06:27,429 them anymore you can just reapply them. 181 00:06:27,430 --> 00:06:28,989 So what you would do is you hook you up 182 00:06:28,990 --> 00:06:31,419 your device up to iTunes and 183 00:06:31,420 --> 00:06:32,689 when iTunes would ask the Apple. 184 00:06:32,690 --> 00:06:34,809 So you just met in the middle of traffic 185 00:06:34,810 --> 00:06:36,519 and sent the blob's you saved. 186 00:06:36,520 --> 00:06:38,379 And I would give it to the device and the 187 00:06:38,380 --> 00:06:39,909 device would accept it and you could 188 00:06:39,910 --> 00:06:40,910 download it. 189 00:06:42,190 --> 00:06:44,479 OK, so what are those 190 00:06:44,480 --> 00:06:45,369 AP tickets? 191 00:06:45,370 --> 00:06:47,829 Maybe tickets is as one formatted 192 00:06:47,830 --> 00:06:48,789 container. 193 00:06:48,790 --> 00:06:51,069 It contains an esad aboard a 194 00:06:51,070 --> 00:06:53,199 chip idee and the hashes of 195 00:06:53,200 --> 00:06:55,719 all the FERMA files and 196 00:06:55,720 --> 00:06:57,729 Anon's, and it's obviously signed. 197 00:06:57,730 --> 00:06:59,769 So you can't tamper with that data. 198 00:06:59,770 --> 00:07:01,899 Those things are packed 199 00:07:01,900 --> 00:07:04,029 inside and I'm just file and Flesche 200 00:07:04,030 --> 00:07:05,049 along with the boot files. 201 00:07:06,520 --> 00:07:09,189 So this is how the Bhushan looks like on 202 00:07:09,190 --> 00:07:11,559 all 32 bit devices on iOS 203 00:07:11,560 --> 00:07:12,549 five. 204 00:07:12,550 --> 00:07:14,739 And later, what you can see here, 205 00:07:14,740 --> 00:07:16,809 the Buttram still checks for 206 00:07:16,810 --> 00:07:18,369 the blobs. 207 00:07:18,370 --> 00:07:20,769 But if you go the different 208 00:07:20,770 --> 00:07:22,959 route, the IBS 209 00:07:22,960 --> 00:07:25,179 checks now with the API ticket instead 210 00:07:25,180 --> 00:07:27,339 of the single SHC, H1 and 211 00:07:27,340 --> 00:07:29,169 what it actually does when it puts up 212 00:07:29,170 --> 00:07:31,599 Avios, it would generate a nonce. 213 00:07:31,600 --> 00:07:32,619 And this is random. 214 00:07:32,620 --> 00:07:34,689 And what you need to do is you need to 215 00:07:34,690 --> 00:07:36,369 reload that Norns from the device. 216 00:07:36,370 --> 00:07:38,529 You need to request an app ticket 217 00:07:38,530 --> 00:07:40,089 for that specific nonce. 218 00:07:40,090 --> 00:07:42,129 Then you could stitch that Norns to IBRC 219 00:07:42,130 --> 00:07:43,869 and then you could put it back and then 220 00:07:43,870 --> 00:07:44,919 you do the same Firebacks. 221 00:07:44,920 --> 00:07:46,779 So it would read ordinance, it would 222 00:07:46,780 --> 00:07:48,489 stitch it to the remnants in the kernel 223 00:07:48,490 --> 00:07:50,889 and you can budos for 224 00:07:50,890 --> 00:07:53,859 the normal. But um, the ILB 225 00:07:53,860 --> 00:07:55,959 and I would also check the app 226 00:07:55,960 --> 00:07:58,209 ticket, but they don't check the nonce. 227 00:07:58,210 --> 00:08:00,959 Well this is because um 228 00:08:00,960 --> 00:08:03,129 I can't really check Anon's 229 00:08:03,130 --> 00:08:05,769 because if you would the nonce, um, 230 00:08:05,770 --> 00:08:07,659 generate the nonce randomly, then you 231 00:08:07,660 --> 00:08:09,789 would have to request a new ticket for 232 00:08:09,790 --> 00:08:10,629 everything about. 233 00:08:10,630 --> 00:08:12,519 And since the devices and bootloader 234 00:08:12,520 --> 00:08:14,739 can't really do that, so nonces ignored 235 00:08:14,740 --> 00:08:16,269 a normal. But and this is fine. 236 00:08:18,160 --> 00:08:20,439 So this is how on it looks like 237 00:08:20,440 --> 00:08:23,199 if you decoded with Issan one 238 00:08:23,200 --> 00:08:25,309 saw in the left image, you can see it as 239 00:08:25,310 --> 00:08:27,429 one decoded. The right image is a built 240 00:08:27,430 --> 00:08:29,409 manifest taken from an iPhone Fermor 241 00:08:29,410 --> 00:08:30,399 file. 242 00:08:30,400 --> 00:08:31,419 So I left. 243 00:08:31,420 --> 00:08:33,219 The first thing you can see is the ESET 244 00:08:33,220 --> 00:08:35,859 of the device this blob's belongs to. 245 00:08:35,860 --> 00:08:38,199 Then you have a bunch of hashes and those 246 00:08:38,200 --> 00:08:39,879 actually correspond to the one you can 247 00:08:39,880 --> 00:08:41,529 see in the manifest. 248 00:08:41,530 --> 00:08:43,449 So the one I highlighted there is the 249 00:08:43,450 --> 00:08:44,529 epilog or hash. 250 00:08:45,790 --> 00:08:47,649 Then you can see the nonce, the iBOT 251 00:08:47,650 --> 00:08:49,779 version and a bunch of other stuff. 252 00:08:49,780 --> 00:08:51,099 And at the very bottom you have the 253 00:08:51,100 --> 00:08:53,589 signature and build a signature, 254 00:08:53,590 --> 00:08:55,839 a certificate which you can use to verify 255 00:08:55,840 --> 00:08:57,580 the, um, signature. 256 00:08:59,850 --> 00:09:01,709 So if you pack that inside and I'm just 257 00:09:01,710 --> 00:09:03,869 refile, there's nothing too special about 258 00:09:03,870 --> 00:09:06,149 it. This is how it looks like you can see 259 00:09:06,150 --> 00:09:08,339 the identifier here 260 00:09:08,340 --> 00:09:09,719 is Seab. 261 00:09:09,720 --> 00:09:12,149 You need to read that little endian. 262 00:09:12,150 --> 00:09:14,460 So that's basically just the ticket. 263 00:09:15,930 --> 00:09:18,029 And storing all those information about 264 00:09:18,030 --> 00:09:20,219 the device in one single file, um, 265 00:09:20,220 --> 00:09:22,379 removes the need to have it and bunch 266 00:09:22,380 --> 00:09:24,329 of files. So it just collects all in one 267 00:09:24,330 --> 00:09:25,330 place. 268 00:09:26,370 --> 00:09:28,409 So how do we do it. 269 00:09:28,410 --> 00:09:30,509 Well we have lime lamebrain a 270 00:09:30,510 --> 00:09:33,599 sibutramine exploit from Geohot 271 00:09:33,600 --> 00:09:36,569 and it works up to the iPhone four 272 00:09:36,570 --> 00:09:38,639 and patch to the iPhone for us, but up to 273 00:09:38,640 --> 00:09:40,769 the iPhone works and we can make 274 00:09:40,770 --> 00:09:43,529 the boot from boot anything we want. 275 00:09:43,530 --> 00:09:45,839 So what we could do is we could patch 276 00:09:45,840 --> 00:09:48,059 out the app to get checks and 277 00:09:48,060 --> 00:09:50,219 Ebsen IBRC and then 278 00:09:50,220 --> 00:09:52,499 we could boot ibises, ABAC, 279 00:09:52,500 --> 00:09:54,599 Ramdisk and a kernel without any 280 00:09:54,600 --> 00:09:55,600 app ticket. 281 00:09:56,310 --> 00:09:58,919 What we would do then is we would restore 282 00:09:58,920 --> 00:10:01,229 with the previously saved app ticket and 283 00:10:01,230 --> 00:10:02,489 since the nonces and checked on. 284 00:10:02,490 --> 00:10:04,559 No, but we are good to go. 285 00:10:06,390 --> 00:10:08,819 So this is uh, an image visualizing 286 00:10:08,820 --> 00:10:11,159 the downgrade using Lamebrain first step 287 00:10:11,160 --> 00:10:12,980 upon a Woodrum, then you 288 00:10:14,100 --> 00:10:15,689 send a budget. 289 00:10:15,690 --> 00:10:17,849 I work on Ramdisk and so on, 290 00:10:17,850 --> 00:10:19,349 simply restor. 291 00:10:19,350 --> 00:10:21,359 And then if you restore with a valid 292 00:10:21,360 --> 00:10:23,579 ticket, you can see that 293 00:10:23,580 --> 00:10:25,799 everything from there is valid if you go 294 00:10:25,800 --> 00:10:26,930 the normal budget. 295 00:10:28,440 --> 00:10:30,869 So what about 296 00:10:30,870 --> 00:10:33,059 newer devices where we don't have 297 00:10:33,060 --> 00:10:34,060 lamebrain? 298 00:10:34,830 --> 00:10:37,799 Well, first, some background info 299 00:10:37,800 --> 00:10:40,349 from our files are encrypted 300 00:10:40,350 --> 00:10:42,449 and the decryption is not possible 301 00:10:42,450 --> 00:10:43,949 any more. 302 00:10:43,950 --> 00:10:46,049 Then the kernel has put it this 303 00:10:46,050 --> 00:10:48,269 is disabled by hardware since the iPhone 304 00:10:48,270 --> 00:10:50,399 four. So before the iPhone for us, 305 00:10:50,400 --> 00:10:52,889 you could actually decrypted with the 306 00:10:52,890 --> 00:10:53,999 engine on the phone. 307 00:10:54,000 --> 00:10:55,679 But since the iPhone four, as this is 308 00:10:55,680 --> 00:10:57,899 disabled by hardware and you can't 309 00:10:57,900 --> 00:10:59,609 use it anymore once the kernel has put it 310 00:10:59,610 --> 00:11:01,659 once and yes. 311 00:11:01,660 --> 00:11:03,939 So basically to get the keys, you need 312 00:11:03,940 --> 00:11:06,120 to either reboot or goodrum exploit. 313 00:11:07,470 --> 00:11:09,569 But luckily, in the general 314 00:11:09,570 --> 00:11:11,819 community, we have some people who have 315 00:11:11,820 --> 00:11:14,189 private iPod exploits on 316 00:11:14,190 --> 00:11:16,259 WI and we have people who have 317 00:11:16,260 --> 00:11:18,389 private hardware hacking techniques. 318 00:11:18,390 --> 00:11:20,549 And those people, they're able to get 319 00:11:20,550 --> 00:11:22,979 the keys and 320 00:11:22,980 --> 00:11:25,109 they're so kind to share them with us. 321 00:11:25,110 --> 00:11:26,669 You can find them on the iPhone. 322 00:11:26,670 --> 00:11:27,959 Vickey. 323 00:11:27,960 --> 00:11:30,329 So, yeah, they're publicly available for 324 00:11:30,330 --> 00:11:32,399 many device nyos combinations, not 325 00:11:32,400 --> 00:11:34,829 for all, but for a lot of them. 326 00:11:34,830 --> 00:11:37,499 Also, we have Kalodner by Willkomm 327 00:11:37,500 --> 00:11:39,839 and what it could do, it could bootstrap 328 00:11:39,840 --> 00:11:41,789 irra image from kernel mold. 329 00:11:41,790 --> 00:11:43,949 So what you could do then 330 00:11:43,950 --> 00:11:45,929 is something like jumping back to the 331 00:11:45,930 --> 00:11:47,999 bootloader, for example, by booting 332 00:11:48,000 --> 00:11:49,000 IBS. 333 00:11:50,220 --> 00:11:53,139 So taking all these possibilities, 334 00:11:53,140 --> 00:11:55,409 um we have or this is a, this 335 00:11:55,410 --> 00:11:57,959 is a technique by sirup 336 00:11:57,960 --> 00:12:00,149 he uses gericke, he uses a task 337 00:12:00,150 --> 00:12:02,279 to put Zeron closer to bootstrap 338 00:12:02,280 --> 00:12:03,869 and ibises. 339 00:12:03,870 --> 00:12:06,029 I personally call this Kadee if 340 00:12:06,030 --> 00:12:07,529 few more currently fumo. 341 00:12:07,530 --> 00:12:09,509 It's similar to the pontiff. 342 00:12:09,510 --> 00:12:11,549 You mold with lamebrain where it would 343 00:12:11,550 --> 00:12:13,709 like accept anything 344 00:12:13,710 --> 00:12:14,849 which you would give it. It would just 345 00:12:14,850 --> 00:12:17,669 put it. You can do the same if you 346 00:12:17,670 --> 00:12:19,859 bootstrap decrypted 347 00:12:19,860 --> 00:12:22,349 and patched IBS. 348 00:12:22,350 --> 00:12:24,659 But the only difference is since 349 00:12:24,660 --> 00:12:26,579 internally from what the kernel has 350 00:12:26,580 --> 00:12:28,919 booted once the 351 00:12:28,920 --> 00:12:30,089 engine is disabled. 352 00:12:30,090 --> 00:12:32,369 So this means you cannot decrypt 353 00:12:32,370 --> 00:12:35,399 Fermor files anymore. 354 00:12:35,400 --> 00:12:37,769 Um, so the solution to this problem 355 00:12:37,770 --> 00:12:39,989 is we simply built the custom former 356 00:12:39,990 --> 00:12:42,330 Ascender form of files decrypted already. 357 00:12:43,620 --> 00:12:45,809 So yeah, we decrypt ibises, IBRC remnant 358 00:12:45,810 --> 00:12:47,759 kernel and a file system and just send it 359 00:12:47,760 --> 00:12:49,439 so the device doesn't need to decrypt 360 00:12:49,440 --> 00:12:50,969 them and we can do that. 361 00:12:50,970 --> 00:12:53,039 So this is what it looks like if 362 00:12:53,040 --> 00:12:55,199 we're downgrading using this was 363 00:12:55,200 --> 00:12:57,179 the first thing you have here is the 364 00:12:57,180 --> 00:12:59,639 normal board. You boot up the old 365 00:12:59,640 --> 00:13:01,739 ILB and in this case old 366 00:13:01,740 --> 00:13:03,659 means before the downgrade, a new means 367 00:13:03,660 --> 00:13:05,489 after the downgrade. 368 00:13:05,490 --> 00:13:07,439 Budarin verifies, I'll be, I'll be 369 00:13:07,440 --> 00:13:08,639 verifiers. I would. 370 00:13:08,640 --> 00:13:10,319 And so on to the kernel. 371 00:13:10,320 --> 00:13:12,119 Then you pon the kernel, you generate the 372 00:13:12,120 --> 00:13:14,639 kernel unable to ask for zero. 373 00:13:14,640 --> 00:13:16,929 Then your uncle order and put, 374 00:13:16,930 --> 00:13:19,109 uh, patched and 375 00:13:19,110 --> 00:13:20,729 decrypted IBS. 376 00:13:20,730 --> 00:13:22,709 And this is what I call quite a few more 377 00:13:22,710 --> 00:13:24,779 than this, because if your device 378 00:13:24,780 --> 00:13:26,999 booted IBS s, it 379 00:13:27,000 --> 00:13:29,189 behaves to the outside world like as 380 00:13:29,190 --> 00:13:30,959 of would be in kadiatu mode. 381 00:13:30,960 --> 00:13:32,879 So the outside world couldn't tell if 382 00:13:32,880 --> 00:13:33,959 it's actually abscessed. 383 00:13:33,960 --> 00:13:36,599 OK, if you moad or if you mozote. 384 00:13:36,600 --> 00:13:37,679 This is why I call this Kadee. 385 00:13:37,680 --> 00:13:40,499 If you got what you would do then is 386 00:13:40,500 --> 00:13:42,929 decrypted and patched Dybek and decrypted 387 00:13:42,930 --> 00:13:44,399 and patched Rammasun kernel, 388 00:13:45,540 --> 00:13:47,099 then you would simply run the normal 389 00:13:47,100 --> 00:13:49,319 restor but you would restore Ravella 390 00:13:49,320 --> 00:13:50,369 ap take it. 391 00:13:50,370 --> 00:13:52,499 And if you try to then 392 00:13:52,500 --> 00:13:54,899 puram verifies be 393 00:13:54,900 --> 00:13:56,839 in the AP to get the nonsense ignored. 394 00:13:56,840 --> 00:13:58,649 So you're good to go and you could put. 395 00:14:00,790 --> 00:14:02,859 So this really cool, but in 396 00:14:02,860 --> 00:14:04,989 this talk, I haven't talked about the 397 00:14:04,990 --> 00:14:07,839 basement, the basement is the processor 398 00:14:07,840 --> 00:14:09,939 which handles communication, like 399 00:14:09,940 --> 00:14:11,679 when you're trying to call someone and 400 00:14:11,680 --> 00:14:12,849 stuff like that. 401 00:14:12,850 --> 00:14:15,189 And the security of the basement 402 00:14:15,190 --> 00:14:17,259 has improved, too. And Donna, it is not 403 00:14:17,260 --> 00:14:18,260 really possible. 404 00:14:19,090 --> 00:14:21,669 Also, less people care 405 00:14:21,670 --> 00:14:23,769 about basement at all since 406 00:14:23,770 --> 00:14:25,329 Carious start to unlock phones. 407 00:14:25,330 --> 00:14:27,429 So in the early days of iPhones, 408 00:14:27,430 --> 00:14:28,989 the reason why I would want to hack the 409 00:14:28,990 --> 00:14:30,489 basement is because the carrier would 410 00:14:30,490 --> 00:14:32,529 sell a similar phone and you want to use 411 00:14:32,530 --> 00:14:34,209 the phone with a different carrier. 412 00:14:34,210 --> 00:14:36,129 So you would try to hack the basement and 413 00:14:36,130 --> 00:14:37,779 get an unlocked so you can use the phone 414 00:14:37,780 --> 00:14:39,190 with a different SIM card. 415 00:14:40,360 --> 00:14:42,039 But since carriers start to sell 416 00:14:42,040 --> 00:14:43,959 unlocked, phones don't really need that 417 00:14:43,960 --> 00:14:44,889 anymore. 418 00:14:44,890 --> 00:14:46,989 But from the earlier days, the common 419 00:14:46,990 --> 00:14:49,299 practice became not to update baseband 420 00:14:49,300 --> 00:14:51,369 because security proved that 421 00:14:51,370 --> 00:14:53,439 to what you would do 422 00:14:53,440 --> 00:14:55,779 is when you are upgrading the US, 423 00:14:55,780 --> 00:14:58,239 you would keep the old baseband 424 00:14:58,240 --> 00:15:00,339 so you could still keep all 425 00:15:00,340 --> 00:15:02,409 the vulnerabilities and exploit it 426 00:15:02,410 --> 00:15:04,899 again. And when you gericke the device, 427 00:15:04,900 --> 00:15:06,729 you could then exploit again the basement 428 00:15:06,730 --> 00:15:07,899 and you could unlock your phone. 429 00:15:09,070 --> 00:15:11,229 And from those times we know that 430 00:15:11,230 --> 00:15:13,179 many non default iOS based on 431 00:15:13,180 --> 00:15:14,679 combinations are working combinations 432 00:15:14,680 --> 00:15:16,269 that weren't shipped. 433 00:15:16,270 --> 00:15:18,549 Some are not, but a lot of them 434 00:15:18,550 --> 00:15:19,550 are working. 435 00:15:21,580 --> 00:15:23,889 So, yeah, we know that the 436 00:15:23,890 --> 00:15:26,139 new I was an old Bassman works, 437 00:15:26,140 --> 00:15:28,599 but the other way around works 438 00:15:28,600 --> 00:15:31,269 too if the gap isn't too big. 439 00:15:31,270 --> 00:15:33,039 So Odyssey's uses this fact. 440 00:15:33,040 --> 00:15:35,109 It keeps the baseband with its 441 00:15:35,110 --> 00:15:36,459 signature and downgrading 442 00:15:37,570 --> 00:15:39,699 since the iPhone four is the basement 443 00:15:39,700 --> 00:15:40,779 is stored on a file system. 444 00:15:40,780 --> 00:15:43,329 Before that, it's stored on some memory. 445 00:15:43,330 --> 00:15:45,609 But, um, since for 446 00:15:45,610 --> 00:15:46,839 us it's on a file system. 447 00:15:46,840 --> 00:15:49,149 And this is why, uh, you need 448 00:15:49,150 --> 00:15:52,239 to patch to former for not updating 449 00:15:52,240 --> 00:15:53,589 the basement. So what you would actually 450 00:15:53,590 --> 00:15:55,689 do, you would grab the old baseband from 451 00:15:55,690 --> 00:15:57,909 the phone, create a custom 452 00:15:57,910 --> 00:15:59,559 firmware where you put this old basement 453 00:15:59,560 --> 00:16:01,539 in and you would flechette knew the 454 00:16:01,540 --> 00:16:03,219 custom former with the old basement. 455 00:16:04,940 --> 00:16:07,399 So then we have 456 00:16:07,400 --> 00:16:09,949 Orissa's Hotta, so, 457 00:16:09,950 --> 00:16:12,049 um, Epel science, Orte 458 00:16:12,050 --> 00:16:14,239 blob's four, I was six point 459 00:16:14,240 --> 00:16:16,609 one point three for the iPhone for us and 460 00:16:16,610 --> 00:16:17,989 for the iPad two. 461 00:16:17,990 --> 00:16:20,149 And what exactly are those Altium blobs? 462 00:16:20,150 --> 00:16:22,519 Well, old Heet means over the year. 463 00:16:23,750 --> 00:16:26,029 If you update your device, um, 464 00:16:26,030 --> 00:16:27,709 not using iTunes, but if you go to 465 00:16:27,710 --> 00:16:30,059 settings and update and just download 466 00:16:30,060 --> 00:16:33,229 the former and updates 467 00:16:33,230 --> 00:16:35,899 and this is what we call an update 468 00:16:35,900 --> 00:16:37,969 and Apple Science, uh, six point one 469 00:16:37,970 --> 00:16:39,709 point three for this device, because 470 00:16:39,710 --> 00:16:41,539 those were shipped initially with iOS 471 00:16:41,540 --> 00:16:42,649 five. 472 00:16:42,650 --> 00:16:44,559 And for some reason, you can't just 473 00:16:44,560 --> 00:16:46,669 straight go from iOS five to eight or 474 00:16:46,670 --> 00:16:48,859 nine or think you can't even go to iOS 475 00:16:48,860 --> 00:16:50,599 eight. So what you would need to do if 476 00:16:50,600 --> 00:16:52,589 those devices are still now is five, you 477 00:16:52,590 --> 00:16:54,829 need to upgrade first to six one three. 478 00:16:54,830 --> 00:16:56,929 And from there you could go to iOS nine. 479 00:16:58,400 --> 00:17:00,709 And same applies for iOS eight 480 00:17:00,710 --> 00:17:03,889 for one for some other devices. 481 00:17:03,890 --> 00:17:05,969 So the idea with desire 482 00:17:05,970 --> 00:17:08,209 is to use fresh old 483 00:17:08,210 --> 00:17:09,289 tickets. 484 00:17:09,290 --> 00:17:11,598 And, uh, you can also grab a baseband 485 00:17:11,599 --> 00:17:13,429 ticket since that's sign, too. 486 00:17:13,430 --> 00:17:15,769 And this allows us to actually downgrade 487 00:17:15,770 --> 00:17:17,389 the basement, because the only thing 488 00:17:17,390 --> 00:17:18,858 which was, uh, stopping us from 489 00:17:18,859 --> 00:17:20,419 downgrading the baseband is the fact that 490 00:17:20,420 --> 00:17:21,469 it wasn't signed. 491 00:17:21,470 --> 00:17:23,509 But since it's signed here, we could just 492 00:17:23,510 --> 00:17:24,949 grab tickets and downgrade. 493 00:17:24,950 --> 00:17:27,439 Is this what this was discovered 494 00:17:27,440 --> 00:17:29,749 by sirup and me around the same time? 495 00:17:29,750 --> 00:17:31,819 We're using different techniques like 496 00:17:31,820 --> 00:17:34,009 I'm pitching to form a bundle to 497 00:17:34,010 --> 00:17:36,139 use to generate the custom firmware. 498 00:17:36,140 --> 00:17:38,759 He added the command line parameter to 499 00:17:38,760 --> 00:17:41,029 restore where you possibly manifest, 500 00:17:41,030 --> 00:17:43,579 but it's basically the same thing. 501 00:17:43,580 --> 00:17:46,579 So, um, normal 502 00:17:46,580 --> 00:17:48,649 a ticket and a ticket 503 00:17:48,650 --> 00:17:50,809 only differ by the Ramdas cash. 504 00:17:50,810 --> 00:17:52,609 And this also makes sense because if 505 00:17:52,610 --> 00:17:54,679 you're upgrading using iTunes, you 506 00:17:54,680 --> 00:17:57,199 what you want the upgrade process 507 00:17:57,200 --> 00:17:58,669 to be handled by iTunes. 508 00:17:58,670 --> 00:18:00,539 But if you're upgrading, using the old 509 00:18:00,540 --> 00:18:02,209 method, you want your phone to do it on 510 00:18:02,210 --> 00:18:03,349 its own without iTunes. 511 00:18:03,350 --> 00:18:05,569 So we need to build a different ramdisk. 512 00:18:05,570 --> 00:18:07,669 And the hash of the RAM doesn't really 513 00:18:07,670 --> 00:18:09,799 matter because we're putting 514 00:18:09,800 --> 00:18:11,199 that thing with Kalodner anyway. 515 00:18:11,200 --> 00:18:12,199 So no nonsense. 516 00:18:12,200 --> 00:18:13,200 No nothing is checked. 517 00:18:15,200 --> 00:18:17,329 So this is cool, but it also 518 00:18:17,330 --> 00:18:19,789 has some limitations. 519 00:18:19,790 --> 00:18:21,919 It only works for certain 520 00:18:21,920 --> 00:18:24,349 devices and you need for Merkies 521 00:18:24,350 --> 00:18:27,049 because, you know, the 522 00:18:27,050 --> 00:18:29,029 device can't handle the decryption. 523 00:18:29,030 --> 00:18:30,030 You need to decrypt it. 524 00:18:31,070 --> 00:18:32,569 You also need custom bundles. 525 00:18:32,570 --> 00:18:34,729 So know how to make 526 00:18:34,730 --> 00:18:37,009 the custom for I need all these patches 527 00:18:37,010 --> 00:18:39,409 and also not available for 528 00:18:39,410 --> 00:18:40,639 all device. 529 00:18:40,640 --> 00:18:41,990 And I use combinations. 530 00:18:43,920 --> 00:18:46,139 So what about 531 00:18:46,140 --> 00:18:47,309 64 bit devices? 532 00:18:48,810 --> 00:18:50,639 Well, let's have first some background 533 00:18:50,640 --> 00:18:52,479 info was 64 devices. 534 00:18:52,480 --> 00:18:54,719 Apple switched to the I'm due 535 00:18:54,720 --> 00:18:56,789 for file format 536 00:18:56,790 --> 00:18:59,189 and we also have a new enemy, the secure 537 00:18:59,190 --> 00:19:02,129 and safe processor or short sap. 538 00:19:02,130 --> 00:19:04,289 And SAP is used for touch 539 00:19:04,290 --> 00:19:06,689 ID. It's used for filesystem 540 00:19:06,690 --> 00:19:08,849 encryption and some other 541 00:19:08,850 --> 00:19:10,559 things, and it's definitely required for 542 00:19:10,560 --> 00:19:12,659 booting. So you can't just decide to 543 00:19:12,660 --> 00:19:14,129 not put it and use the phone. 544 00:19:14,130 --> 00:19:16,259 This won't work because you wouldn't be 545 00:19:16,260 --> 00:19:18,240 able to decrypt your file system. 546 00:19:19,530 --> 00:19:22,499 SAP has its own Norns inside 547 00:19:22,500 --> 00:19:24,689 it and those need to match the one 548 00:19:24,690 --> 00:19:26,729 SAP generates when it boots. 549 00:19:26,730 --> 00:19:28,829 So also there are no 550 00:19:28,830 --> 00:19:30,309 known exploits for them. 551 00:19:30,310 --> 00:19:33,089 So for those who expected a 552 00:19:33,090 --> 00:19:34,979 zero day for that to be dropped, I'm 553 00:19:34,980 --> 00:19:36,559 sorry, no exploits for THEP. 554 00:19:38,500 --> 00:19:41,039 So, yeah, let's take a look at the 555 00:19:41,040 --> 00:19:43,119 four or five format I'm due 556 00:19:43,120 --> 00:19:45,189 for a sannyasin one formatted 557 00:19:45,190 --> 00:19:45,879 container. 558 00:19:45,880 --> 00:19:48,069 This is the uncoded and 559 00:19:48,070 --> 00:19:50,199 what assigned signed IMG for basically 560 00:19:50,200 --> 00:19:52,299 is it's just I'm for 561 00:19:52,300 --> 00:19:53,529 P this is the payload. 562 00:19:53,530 --> 00:19:55,649 This is like, uh, just 563 00:19:55,650 --> 00:19:57,939 the word file labeled or something 564 00:19:57,940 --> 00:20:00,039 like that with an aim for M 565 00:20:00,040 --> 00:20:02,049 and I'm for M is the manifest and the 566 00:20:02,050 --> 00:20:04,180 manifest is basically the AP ticket. 567 00:20:05,710 --> 00:20:07,809 And uh, the interesting thing here 568 00:20:07,810 --> 00:20:10,539 is that every IMG for file has 569 00:20:10,540 --> 00:20:12,909 its own copy of the manifest 570 00:20:12,910 --> 00:20:14,019 of the ticket. 571 00:20:14,020 --> 00:20:16,119 This eliminates the need for a 572 00:20:16,120 --> 00:20:18,129 ticket only file like we used to have 573 00:20:18,130 --> 00:20:20,409 with the three file format. 574 00:20:20,410 --> 00:20:22,509 And this is probably required for 575 00:20:22,510 --> 00:20:24,879 Zebb because all bootloader 576 00:20:24,880 --> 00:20:27,009 files are flashes from memory except for 577 00:20:27,010 --> 00:20:28,779 Zip Zeppos, the only thing which is 578 00:20:28,780 --> 00:20:30,849 stored on a file system. 579 00:20:30,850 --> 00:20:33,099 And this is maybe why 580 00:20:33,100 --> 00:20:35,439 they made a single copy of the ticket 581 00:20:35,440 --> 00:20:36,440 to every file. 582 00:20:37,840 --> 00:20:40,119 So yeah, let's take a look at the IMG 583 00:20:40,120 --> 00:20:42,069 four or five from it. You could see here 584 00:20:42,070 --> 00:20:44,139 on the left side, this is if you 585 00:20:44,140 --> 00:20:46,269 just simply assign one, decrypt 586 00:20:46,270 --> 00:20:47,799 a decode the file. 587 00:20:47,800 --> 00:20:50,139 You can see I'm for I'm for P 588 00:20:50,140 --> 00:20:52,389 and the tech of that file, this 589 00:20:52,390 --> 00:20:54,729 is speed. This is a separate S 590 00:20:54,730 --> 00:20:56,589 which is um. 591 00:20:56,590 --> 00:20:58,329 Yeah. Display Dorottya. 592 00:20:58,330 --> 00:21:00,009 Then you have the actual setup, then you 593 00:21:00,010 --> 00:21:01,899 have the Chebeague and the Chebeague is 594 00:21:01,900 --> 00:21:04,599 actually an encrypted 595 00:21:04,600 --> 00:21:07,239 key which the device could decrypt 596 00:21:07,240 --> 00:21:09,129 and it could use that key to decrypt 597 00:21:09,130 --> 00:21:10,130 Fermor. 598 00:21:11,140 --> 00:21:13,299 So below that you have 599 00:21:13,300 --> 00:21:14,319 the time frame. 600 00:21:14,320 --> 00:21:16,149 This is basically the manifest, but you 601 00:21:16,150 --> 00:21:18,249 can actually see that better on the right 602 00:21:18,250 --> 00:21:20,379 image. Right image is what I'm 603 00:21:20,380 --> 00:21:21,609 going to gives you. 604 00:21:21,610 --> 00:21:23,829 If you just displayed a file, 605 00:21:23,830 --> 00:21:26,049 um, basically also the X and 606 00:21:26,050 --> 00:21:28,449 you can see there I'm for M and 607 00:21:28,450 --> 00:21:30,399 I work through all those things real 608 00:21:30,400 --> 00:21:31,389 quick. 609 00:21:31,390 --> 00:21:33,579 The BNC H is the 610 00:21:33,580 --> 00:21:36,339 AP Nunc um which is inside 611 00:21:36,340 --> 00:21:38,029 the ticket. 612 00:21:38,030 --> 00:21:40,509 Then you have some device specific, 613 00:21:40,510 --> 00:21:42,699 uh data. You have the Essid 614 00:21:42,700 --> 00:21:45,009 for which, which 615 00:21:45,010 --> 00:21:47,499 device, uh which specific unique device 616 00:21:47,500 --> 00:21:49,659 this uh ticket can be used 617 00:21:49,660 --> 00:21:52,239 and the unknown is the nuns 618 00:21:52,240 --> 00:21:54,459 and s RVN is 619 00:21:54,460 --> 00:21:55,779 the server nuns. 620 00:21:55,780 --> 00:21:57,669 Uh it's basically server generates. 621 00:21:57,670 --> 00:21:59,829 So even if you request um 622 00:21:59,830 --> 00:22:01,449 over and over again a ticket with the 623 00:22:01,450 --> 00:22:03,099 same parameters, you would still get a 624 00:22:03,100 --> 00:22:04,539 different ticket because the server 625 00:22:04,540 --> 00:22:05,799 announced changes. 626 00:22:05,800 --> 00:22:07,719 And as far as I know, the server nonsense 627 00:22:07,720 --> 00:22:09,489 not really used for anything. 628 00:22:09,490 --> 00:22:11,949 So below that, you have a bunch of 629 00:22:11,950 --> 00:22:14,139 hashes from all the different files 630 00:22:14,140 --> 00:22:16,029 right here you can see the hash for the 631 00:22:16,030 --> 00:22:17,950 bed, zero image. 632 00:22:19,750 --> 00:22:21,789 So this is how the Bush-Cheney looks like 633 00:22:21,790 --> 00:22:23,739 on 64 bit devices. 634 00:22:23,740 --> 00:22:25,569 If you go the normal Bujold, the only 635 00:22:25,570 --> 00:22:27,519 thing which really changed there is 636 00:22:27,520 --> 00:22:29,139 starting with the board from the AP 637 00:22:29,140 --> 00:22:30,129 ticket has changed. 638 00:22:30,130 --> 00:22:32,079 Earlier this was the age. 639 00:22:32,080 --> 00:22:34,149 And if you go the diff, you 640 00:22:34,150 --> 00:22:36,669 wrote not only the dbu 641 00:22:36,670 --> 00:22:39,249 drum checks, the AP tickets and 642 00:22:39,250 --> 00:22:41,649 AP non. So actually you need to request 643 00:22:41,650 --> 00:22:44,109 an appearance from the boardroom and 644 00:22:44,110 --> 00:22:46,089 so on. But you also need to request 645 00:22:46,090 --> 00:22:48,249 acceptance and put it inside 646 00:22:48,250 --> 00:22:49,250 your ticket. 647 00:22:50,540 --> 00:22:53,359 Um, yeah, 648 00:22:53,360 --> 00:22:55,639 so we've seen this all 649 00:22:55,640 --> 00:22:57,949 improved a lot, but 650 00:22:57,950 --> 00:23:00,049 can we still do it 651 00:23:00,050 --> 00:23:01,369 and yes, we can. 652 00:23:02,920 --> 00:23:05,379 So let's make a downgrade plan for 653 00:23:05,380 --> 00:23:07,329 64 bit devices. 654 00:23:07,330 --> 00:23:09,609 Well, we know that the baseband iOS 655 00:23:09,610 --> 00:23:11,019 mismatch works. 656 00:23:11,020 --> 00:23:13,479 And what if this 657 00:23:13,480 --> 00:23:15,489 would work for SEPTA? 658 00:23:15,490 --> 00:23:16,490 That would be cool, right. 659 00:23:17,530 --> 00:23:19,689 And also, every emoji for 660 00:23:19,690 --> 00:23:21,819 file contains its own 661 00:23:21,820 --> 00:23:23,859 copy of the app ticket. 662 00:23:23,860 --> 00:23:26,170 But do they actually need to be the same? 663 00:23:28,120 --> 00:23:30,129 Well, let's continue with our plan here. 664 00:23:30,130 --> 00:23:32,439 What I did here is I made a little 665 00:23:32,440 --> 00:23:34,359 tool. I get Norns. 666 00:23:34,360 --> 00:23:36,759 Basically all it does, it fetches 667 00:23:36,760 --> 00:23:38,949 the appearance and disappearance from 668 00:23:38,950 --> 00:23:40,779 the device and all the different modes. 669 00:23:40,780 --> 00:23:42,429 What I did then, I took my iPhone, 670 00:23:42,430 --> 00:23:44,619 FIFA's, uh, put it in default mode 671 00:23:44,620 --> 00:23:46,899 connected to computer and 672 00:23:46,900 --> 00:23:48,119 read out the nonsense. 673 00:23:48,120 --> 00:23:49,029 Um, yeah. 674 00:23:49,030 --> 00:23:51,339 For AP inceptions, what I did then 675 00:23:51,340 --> 00:23:53,619 is I requested and ticket 676 00:23:53,620 --> 00:23:55,839 for those two specific nonces for 677 00:23:55,840 --> 00:23:58,299 my device with test checker 678 00:23:58,300 --> 00:24:00,849 and stitched that ticket to 679 00:24:00,850 --> 00:24:02,979 IBS and I booted 680 00:24:02,980 --> 00:24:03,980 ibises. 681 00:24:04,630 --> 00:24:07,029 Then I again checked what nonsense 682 00:24:07,030 --> 00:24:09,399 are generated and I've seen 683 00:24:09,400 --> 00:24:10,719 Non's doesn't change. 684 00:24:10,720 --> 00:24:13,299 So I again stitched with uh 685 00:24:13,300 --> 00:24:15,609 Stich that ticket to IBRC 686 00:24:15,610 --> 00:24:17,619 and Budha Dybek and again I requested the 687 00:24:17,620 --> 00:24:19,809 nonce. And again, Anon's 688 00:24:19,810 --> 00:24:22,059 doesn't change. So this is definitely 689 00:24:22,060 --> 00:24:23,079 something we can work with. 690 00:24:24,820 --> 00:24:26,919 Yeah. We seen we get the same Norns 691 00:24:26,920 --> 00:24:29,349 uh for these few ideas. 692 00:24:29,350 --> 00:24:31,719 IBRC and this is a this 693 00:24:31,720 --> 00:24:34,269 also works if you go from about 694 00:24:34,270 --> 00:24:36,279 two IBRC and this is actually Derald, 695 00:24:36,280 --> 00:24:37,809 we're going to go for downgrading. 696 00:24:37,810 --> 00:24:40,359 You'll see why in a few slides 697 00:24:40,360 --> 00:24:42,399 and also notice that the sentence is 698 00:24:42,400 --> 00:24:43,299 completely ignored. 699 00:24:43,300 --> 00:24:45,579 And Ebsen IBRC 700 00:24:45,580 --> 00:24:47,859 it only matters when booting 701 00:24:47,860 --> 00:24:49,959 Sep, which 702 00:24:49,960 --> 00:24:52,419 kind of makes sense I guess. 703 00:24:52,420 --> 00:24:54,669 So um, what happens if 704 00:24:54,670 --> 00:24:57,249 you could somehow predict or 705 00:24:57,250 --> 00:24:58,809 regenerate an abstinence? 706 00:25:00,760 --> 00:25:02,829 Well, this is where Prometheus comes 707 00:25:02,830 --> 00:25:04,059 in. 708 00:25:04,060 --> 00:25:06,189 Let's for a second assume we 709 00:25:06,190 --> 00:25:08,439 somehow can predict an abstinence. 710 00:25:08,440 --> 00:25:11,079 What we could do then is we would request 711 00:25:11,080 --> 00:25:13,359 now a ticket for Anon's, which 712 00:25:13,360 --> 00:25:15,069 will be generated later. 713 00:25:15,070 --> 00:25:17,529 And once it isn't signed anymore, we can 714 00:25:17,530 --> 00:25:19,299 somehow make the device, magically 715 00:25:19,300 --> 00:25:21,159 regenerate the nonce and use the ticket 716 00:25:21,160 --> 00:25:22,160 we saved before. 717 00:25:23,320 --> 00:25:25,479 So this brings us back to the old 718 00:25:25,480 --> 00:25:27,219 classic replay attack. 719 00:25:27,220 --> 00:25:30,039 And we could build up to the remnants 720 00:25:30,040 --> 00:25:32,049 so we can only put up to the remise 721 00:25:32,050 --> 00:25:33,309 because they're still Zebb. 722 00:25:33,310 --> 00:25:35,139 We can't do this for them and we need 723 00:25:35,140 --> 00:25:37,119 somehow to good sep. 724 00:25:37,120 --> 00:25:39,339 Well, what we can do here is we can 725 00:25:39,340 --> 00:25:41,859 just put it possibly newer, 726 00:25:41,860 --> 00:25:42,849 but signs sep. 727 00:25:42,850 --> 00:25:44,919 And since that side we can request 728 00:25:44,920 --> 00:25:47,379 a valid ticket and 729 00:25:47,380 --> 00:25:49,689 we also restoring the newer 730 00:25:49,690 --> 00:25:51,819 but sine SEP and we're also doing the 731 00:25:51,820 --> 00:25:52,929 same for the baseband. 732 00:25:52,930 --> 00:25:54,939 So fix everything right. 733 00:25:56,470 --> 00:25:58,489 This is how Prometheus looks like. 734 00:25:58,490 --> 00:26:00,219 Um, yeah. 735 00:26:00,220 --> 00:26:02,529 When putting the stuff first you board 736 00:26:02,530 --> 00:26:05,109 to ILB then 737 00:26:05,110 --> 00:26:06,759 I bought. This is checked by the AP 738 00:26:06,760 --> 00:26:08,019 ticket on a device. 739 00:26:08,020 --> 00:26:09,909 If you hold down your home button while 740 00:26:09,910 --> 00:26:13,059 booting, you will get into recovery mode 741 00:26:13,060 --> 00:26:14,889 and it will stop there. 742 00:26:14,890 --> 00:26:17,349 Um then we do some wudu magic 743 00:26:17,350 --> 00:26:19,989 and make the device regenerate the 744 00:26:19,990 --> 00:26:22,329 nonce which we have uh saved 745 00:26:22,330 --> 00:26:23,499 the ticket for. 746 00:26:23,500 --> 00:26:25,329 Then we stitch that ticket to IBRC and 747 00:26:25,330 --> 00:26:27,399 Boutet and again to save tickets 748 00:26:27,400 --> 00:26:28,989 to shit to the remnants of Colonel. 749 00:26:28,990 --> 00:26:31,119 And with that and what we're doing 750 00:26:31,120 --> 00:26:33,459 here is we booting not the ships 751 00:26:33,460 --> 00:26:36,159 but the latest step, for example 752 00:26:36,160 --> 00:26:38,379 with a valid ticket, 753 00:26:38,380 --> 00:26:40,329 which we just requested for the Nonsuch 754 00:26:40,330 --> 00:26:42,849 generated us and we that 755 00:26:42,850 --> 00:26:44,949 then we're doing a normal Ristau with the 756 00:26:44,950 --> 00:26:47,199 difference that we're restoring the AP 757 00:26:47,200 --> 00:26:48,549 ticket we saved 758 00:26:49,660 --> 00:26:51,999 and we are restoring, uh, the newer 759 00:26:52,000 --> 00:26:54,939 SEP with a different AP ticket. 760 00:26:54,940 --> 00:26:57,339 And we can do that because every Imja 761 00:26:57,340 --> 00:26:59,499 four or five stores its own copy of the 762 00:26:59,500 --> 00:27:00,500 ticket. 763 00:27:00,860 --> 00:27:02,410 Um, yeah. 764 00:27:03,550 --> 00:27:05,979 No, the only real question is 765 00:27:05,980 --> 00:27:08,589 how do we predict the opinions? 766 00:27:08,590 --> 00:27:10,959 Because if we can't predict the opinions, 767 00:27:10,960 --> 00:27:12,489 we can't really use all this. 768 00:27:13,810 --> 00:27:16,449 OK, let's take a look at the RTA 769 00:27:16,450 --> 00:27:18,249 update procedure. 770 00:27:18,250 --> 00:27:20,559 So, uh, when you take your phone, 771 00:27:20,560 --> 00:27:22,719 go to settings, update, uh, what 772 00:27:22,720 --> 00:27:25,059 it would do. It would download 773 00:27:25,060 --> 00:27:27,409 the boot files and stored the Ramdisk 774 00:27:27,410 --> 00:27:29,679 in memory. It would set some Buraq 775 00:27:29,680 --> 00:27:31,209 and it would reboot. 776 00:27:31,210 --> 00:27:32,679 Uh, dreaminess is not encrypted. 777 00:27:32,680 --> 00:27:33,939 The Woodford's are. 778 00:27:33,940 --> 00:27:36,129 And you need an 779 00:27:36,130 --> 00:27:38,319 app ticket to boot, so 780 00:27:38,320 --> 00:27:40,449 you can't really request an app 781 00:27:40,450 --> 00:27:42,019 ticket while you're in recovery. 782 00:27:42,020 --> 00:27:43,959 This means you need to request a ticket 783 00:27:43,960 --> 00:27:46,059 before going to recovery. 784 00:27:46,060 --> 00:27:47,919 And we have a problem here. 785 00:27:47,920 --> 00:27:50,259 So there's something needed 786 00:27:50,260 --> 00:27:51,159 to be stored. 787 00:27:51,160 --> 00:27:53,709 So the app so the updater 788 00:27:53,710 --> 00:27:55,929 can predict what nonsense 789 00:27:55,930 --> 00:27:57,819 will be generated on next Puzzo. 790 00:27:57,820 --> 00:28:00,129 So we can request now, uh, NAPI ticket 791 00:28:00,130 --> 00:28:01,510 and use it on the next reboot. 792 00:28:02,930 --> 00:28:04,879 So are we going to do is find this 793 00:28:04,880 --> 00:28:06,139 something? 794 00:28:06,140 --> 00:28:08,209 Well, let's take a look and enviro. 795 00:28:08,210 --> 00:28:10,309 So in the big picture, you can see 796 00:28:10,310 --> 00:28:13,109 Colonel Cash from iOS 10. 797 00:28:13,110 --> 00:28:15,199 Um, yeah. Apple was so kind to 798 00:28:15,200 --> 00:28:17,119 ship iOS 10 unencrypted. 799 00:28:17,120 --> 00:28:18,799 So we can just take a look here. 800 00:28:18,800 --> 00:28:21,079 And what we see here is that 801 00:28:21,080 --> 00:28:23,359 Apple, that system non's. 802 00:28:23,360 --> 00:28:25,489 And the only thing left is figuring out 803 00:28:25,490 --> 00:28:26,929 what all those values mean. 804 00:28:26,930 --> 00:28:29,179 And if you Google, you'll eventually 805 00:28:29,180 --> 00:28:31,459 end up on your end of your age 806 00:28:31,460 --> 00:28:33,529 on open source told Apple Dotcom. 807 00:28:33,530 --> 00:28:35,839 And then you can see this, uh, 808 00:28:35,840 --> 00:28:38,119 of variables, this, uh, variable 809 00:28:38,120 --> 00:28:39,019 table. 810 00:28:39,020 --> 00:28:41,209 And so basically the elements here 811 00:28:41,210 --> 00:28:43,369 are first the string and then 812 00:28:43,370 --> 00:28:45,499 the type, then the permission. 813 00:28:45,500 --> 00:28:48,769 And the last thing is probably counter. 814 00:28:48,770 --> 00:28:51,139 So if you take a look at the kernel dump, 815 00:28:51,140 --> 00:28:53,539 we see, um, uh, zero 816 00:28:53,540 --> 00:28:55,759 three and zero three for the type 817 00:28:55,760 --> 00:28:56,689 and for the permission. 818 00:28:56,690 --> 00:28:59,119 And if we take a look at the type, it's, 819 00:28:59,120 --> 00:29:00,499 uh, type string. 820 00:29:00,500 --> 00:29:02,809 And if we check the permission, it is 821 00:29:02,810 --> 00:29:04,999 permission kernel only, which 822 00:29:05,000 --> 00:29:07,309 is kind of bad, but it's 823 00:29:07,310 --> 00:29:08,779 nothing we couldn't change with the 824 00:29:08,780 --> 00:29:10,609 kernel patch. So patching this a 825 00:29:10,610 --> 00:29:12,799 permission user, it would allow us 826 00:29:12,800 --> 00:29:15,049 to use the envir, I'm told, to read and 827 00:29:15,050 --> 00:29:16,789 write this variable from user land. 828 00:29:18,560 --> 00:29:20,629 So, um, yeah, how do we 829 00:29:20,630 --> 00:29:22,699 predict opinions so 830 00:29:22,700 --> 00:29:24,799 the generator is saved and we 831 00:29:24,800 --> 00:29:27,079 run once a, uh, once 832 00:29:27,080 --> 00:29:29,179 you request from lockdown the Anon's and 833 00:29:29,180 --> 00:29:31,579 you can do that by either, uh, requesting 834 00:29:31,580 --> 00:29:33,649 Anon's with items or 835 00:29:33,650 --> 00:29:35,599 the updater can request the nonce from 836 00:29:35,600 --> 00:29:36,739 knocked on them. 837 00:29:36,740 --> 00:29:38,989 And that generator is safe 838 00:29:38,990 --> 00:29:41,599 to Elverum and consumed on the next 839 00:29:41,600 --> 00:29:44,119 reboot. So you can't really predict, 840 00:29:44,120 --> 00:29:45,529 uh, Norns twice. 841 00:29:45,530 --> 00:29:47,000 You can do just just once. 842 00:29:48,170 --> 00:29:50,449 So this is how such a generator looks 843 00:29:50,450 --> 00:29:52,729 like and it generates the following 844 00:29:52,730 --> 00:29:55,069 Norns on my iPhone six. 845 00:29:55,070 --> 00:29:56,989 And yes, since the permissions are 846 00:29:56,990 --> 00:29:59,149 currently, you need to patch to colonel 847 00:29:59,150 --> 00:30:01,459 to be able to read and write that. 848 00:30:01,460 --> 00:30:03,649 So this is kind of a demo. 849 00:30:03,650 --> 00:30:05,179 I guess it's just an image. 850 00:30:05,180 --> 00:30:08,029 But still, this is my iPhone 851 00:30:08,030 --> 00:30:10,819 six running iOS nine point one. 852 00:30:10,820 --> 00:30:13,189 And what you what I did here is 853 00:30:13,190 --> 00:30:15,409 first I requested a nonce from Lockton 854 00:30:15,410 --> 00:30:17,509 De then I run and run minus 855 00:30:17,510 --> 00:30:19,579 P to print all the variables. 856 00:30:19,580 --> 00:30:22,039 Then you can see we only have Buderus 857 00:30:22,040 --> 00:30:24,469 de boatyards output and becknell 858 00:30:24,470 --> 00:30:26,719 backlight level, then running 859 00:30:26,720 --> 00:30:29,269 nondenial which patches, um, 860 00:30:29,270 --> 00:30:30,559 the kernel. 861 00:30:30,560 --> 00:30:32,809 And again I run and run minus 862 00:30:32,810 --> 00:30:34,959 P you can see the complex 863 00:30:34,960 --> 00:30:36,859 system, but Norns magically appears and 864 00:30:36,860 --> 00:30:38,660 we can read it and we also can write it. 865 00:30:39,950 --> 00:30:42,019 So this is the only way. 866 00:30:42,020 --> 00:30:44,149 Well the nonce, 20 867 00:30:44,150 --> 00:30:46,279 bytes and this means we have 868 00:30:46,280 --> 00:30:48,649 two to the power of 160 different 869 00:30:48,650 --> 00:30:50,869 possibilities and this 870 00:30:50,870 --> 00:30:53,389 is just too many to brute force. 871 00:30:53,390 --> 00:30:55,579 The generator, on the other hand, is 872 00:30:55,580 --> 00:30:56,629 eight bytes. 873 00:30:56,630 --> 00:30:58,699 This is two to the power of 874 00:30:58,700 --> 00:31:01,099 sixty four possibilities. 875 00:31:01,100 --> 00:31:03,379 But this is still too many. 876 00:31:03,380 --> 00:31:05,449 Unless you're the NSA, there's even no 877 00:31:05,450 --> 00:31:06,859 point in trying. 878 00:31:06,860 --> 00:31:08,989 But I did all these calculations 879 00:31:08,990 --> 00:31:10,069 after I tried that. 880 00:31:10,070 --> 00:31:12,529 So let me show you my results. 881 00:31:14,520 --> 00:31:17,099 So I wrote the little script, basically, 882 00:31:17,100 --> 00:31:18,959 all it does is puts your device into 883 00:31:18,960 --> 00:31:21,149 recovery, sets the boot are 884 00:31:21,150 --> 00:31:23,339 to fall. So you always put into recovery 885 00:31:23,340 --> 00:31:25,529 when you reboot, then it reads out 886 00:31:25,530 --> 00:31:26,670 the nonce 887 00:31:27,900 --> 00:31:29,999 and reboots, then again reads 888 00:31:30,000 --> 00:31:31,079 ordinance and so on. 889 00:31:31,080 --> 00:31:33,089 And I let us run for, I don't know, two 890 00:31:33,090 --> 00:31:35,219 hours. And it gave me like two 891 00:31:35,220 --> 00:31:37,049 thousand answers. 892 00:31:37,050 --> 00:31:39,269 And if we take a look at the answers 893 00:31:39,270 --> 00:31:40,709 there on the right side. 894 00:31:40,710 --> 00:31:42,179 So I ordered them. 895 00:31:42,180 --> 00:31:44,429 And you can see the first 896 00:31:44,430 --> 00:31:46,169 thing there is the nonce. 897 00:31:46,170 --> 00:31:48,299 Then in the second column, this is how 898 00:31:48,300 --> 00:31:50,309 often that was generated. 899 00:31:50,310 --> 00:31:53,309 And the last column is the percentage 900 00:31:53,310 --> 00:31:55,439 sold. The one highlighted in blue 901 00:31:55,440 --> 00:31:57,479 is not actually one generated most often, 902 00:31:57,480 --> 00:31:58,619 but it's my favorite one. 903 00:31:58,620 --> 00:32:00,239 That's why it's blue. 904 00:32:00,240 --> 00:32:02,519 And if you, 905 00:32:02,520 --> 00:32:04,739 uh, take a look and some all this 906 00:32:04,740 --> 00:32:07,079 up, you can see that five finances 907 00:32:07,080 --> 00:32:09,299 are 20 percent. 908 00:32:09,300 --> 00:32:11,459 So we can definitely work with 909 00:32:11,460 --> 00:32:12,460 that. 910 00:32:13,200 --> 00:32:15,959 We also had some community 911 00:32:15,960 --> 00:32:18,209 test results. So I asked on Twitter, 912 00:32:18,210 --> 00:32:20,519 um, just take your phones 913 00:32:20,520 --> 00:32:22,919 and traders to and I've seen multiple 914 00:32:22,920 --> 00:32:25,259 iPhone five s generate, uh, 915 00:32:25,260 --> 00:32:27,299 the same nonsenses nine three two 916 00:32:28,410 --> 00:32:29,969 nine three five. 917 00:32:29,970 --> 00:32:32,069 And this also works with 918 00:32:32,070 --> 00:32:34,749 multiple iPod ers, um, 919 00:32:34,750 --> 00:32:36,399 and gross versions. 920 00:32:36,400 --> 00:32:38,519 Uh, I haven't tried 32 921 00:32:38,520 --> 00:32:39,599 bit devices. 922 00:32:39,600 --> 00:32:41,309 Maybe it works, maybe it doesn't. 923 00:32:41,310 --> 00:32:43,439 I have tried later devices like 924 00:32:43,440 --> 00:32:45,629 iPhone six six s and 925 00:32:45,630 --> 00:32:47,339 I don't know if someone tried a knife on 926 00:32:47,340 --> 00:32:49,409 seven, but those don't 927 00:32:49,410 --> 00:32:51,119 generate collisions. 928 00:32:51,120 --> 00:32:53,399 Also, the funny thing here is 929 00:32:53,400 --> 00:32:55,649 that, uh, I have seen collisions 930 00:32:55,650 --> 00:32:57,239 on I was nine three. 931 00:32:57,240 --> 00:32:59,609 I have seen collisions on iOS ten, ten, 932 00:32:59,610 --> 00:33:01,409 one and two, but I haven't seen any 933 00:33:01,410 --> 00:33:03,509 collisions on I was nine 934 00:33:03,510 --> 00:33:05,609 point one and nine point zero. 935 00:33:05,610 --> 00:33:08,209 So maybe that's something, 936 00:33:08,210 --> 00:33:10,169 some part that Apple introduced a nine 937 00:33:10,170 --> 00:33:11,849 three. I don't know, I haven't seen any 938 00:33:11,850 --> 00:33:14,219 collisions for iPhone five s and 939 00:33:14,220 --> 00:33:15,220 nine point zero. 940 00:33:16,350 --> 00:33:18,809 So it seems some collisions are possible 941 00:33:18,810 --> 00:33:21,389 for some device iOS combinations 942 00:33:21,390 --> 00:33:23,669 and this can be used 943 00:33:23,670 --> 00:33:26,189 to download it without a jailbreak. 944 00:33:26,190 --> 00:33:28,259 So what you should do is run your 945 00:33:28,260 --> 00:33:30,539 own tests, um, figure out what 946 00:33:30,540 --> 00:33:32,969 nonsense generated the most and 947 00:33:32,970 --> 00:33:35,099 get a ticket for that specific 948 00:33:35,100 --> 00:33:36,100 NUNC. 949 00:33:36,870 --> 00:33:38,999 So downgrade scenario here would 950 00:33:39,000 --> 00:33:41,789 be you upgrade to newer iOS 951 00:33:41,790 --> 00:33:43,979 and figure out what nonsense 952 00:33:43,980 --> 00:33:45,449 generated the most often. 953 00:33:45,450 --> 00:33:47,599 And you need to do that because maybe 954 00:33:47,600 --> 00:33:49,529 it changes what nonsense generated. 955 00:33:49,530 --> 00:33:50,849 And yeah. 956 00:33:50,850 --> 00:33:53,039 So you would request an app ticket 957 00:33:53,040 --> 00:33:55,289 with that specific Norns for an older 958 00:33:55,290 --> 00:33:57,509 iOS while it's still signed when Apple 959 00:33:57,510 --> 00:33:59,609 releases new, I was the older 960 00:33:59,610 --> 00:34:01,769 one assigned for a certain amount 961 00:34:01,770 --> 00:34:03,629 of time and you you would need to do that 962 00:34:03,630 --> 00:34:05,699 while the older one assigned and when the 963 00:34:05,700 --> 00:34:07,199 signing window closes, you make the 964 00:34:07,200 --> 00:34:09,178 device regenerate the same nonce you have 965 00:34:09,179 --> 00:34:11,459 the ticket for and you could download it. 966 00:34:11,460 --> 00:34:14,039 You could even train up, um, 967 00:34:14,040 --> 00:34:16,109 different iOS versions, like for a strong 968 00:34:16,110 --> 00:34:17,099 reading phone. 969 00:34:17,100 --> 00:34:19,349 I was ten to nine because nine, 970 00:34:19,350 --> 00:34:21,928 three, five maybe generates a different, 971 00:34:21,929 --> 00:34:24,089 uh, Norns and then you can use 972 00:34:24,090 --> 00:34:25,829 the tickets with the save on stare, make 973 00:34:25,830 --> 00:34:28,369 the device regenerates another 974 00:34:28,370 --> 00:34:29,968 not another nonce which you have the 975 00:34:29,969 --> 00:34:32,549 ticket for and you could go even further. 976 00:34:32,550 --> 00:34:34,649 Uh, I need to say at this 977 00:34:34,650 --> 00:34:36,809 point that it does 978 00:34:36,810 --> 00:34:39,149 work for downgrading. 979 00:34:39,150 --> 00:34:41,879 I would, but the 980 00:34:41,880 --> 00:34:44,279 iOS Ten, SEP is not compatible 981 00:34:44,280 --> 00:34:46,448 with iOS nine. So if you try 982 00:34:46,449 --> 00:34:48,539 to downgrade iOS ten to nine by 983 00:34:48,540 --> 00:34:51,059 restoring and I was ten Sep to nine, 984 00:34:51,060 --> 00:34:53,399 you don't get a working system, 985 00:34:53,400 --> 00:34:54,839 so don't do that. 986 00:34:56,820 --> 00:34:59,309 Well, this is cool, but Prometheus 987 00:34:59,310 --> 00:35:02,129 had lots of limitations and 988 00:35:02,130 --> 00:35:04,679 it relies on the fact that the basement 989 00:35:04,680 --> 00:35:07,079 and iOS versions are not tied together 990 00:35:07,080 --> 00:35:09,369 and checks for that can easily 991 00:35:09,370 --> 00:35:10,559 be added. 992 00:35:10,560 --> 00:35:12,719 Also, SEP and Baseband 993 00:35:12,720 --> 00:35:14,789 are always the latest 994 00:35:14,790 --> 00:35:17,159 version and they might not work 995 00:35:17,160 --> 00:35:18,269 with all the ISO. 996 00:35:18,270 --> 00:35:20,759 This is the case for iOS ten, SEP 997 00:35:20,760 --> 00:35:22,589 with iOS nine. 998 00:35:22,590 --> 00:35:25,109 Also, the opinions must be predictable 999 00:35:25,110 --> 00:35:27,329 and Apple can make our 1000 00:35:27,330 --> 00:35:28,739 lives really hard here. 1001 00:35:28,740 --> 00:35:29,969 They could, for example, 1002 00:35:31,080 --> 00:35:33,509 at a sold in Ibold 1003 00:35:33,510 --> 00:35:35,849 and change that and every different 1004 00:35:35,850 --> 00:35:37,139 abled version. And since they're 1005 00:35:37,140 --> 00:35:39,179 encrypted, there's no chance that you can 1006 00:35:39,180 --> 00:35:40,529 get that sold. 1007 00:35:40,530 --> 00:35:42,709 So it would kind of eliminate 1008 00:35:42,710 --> 00:35:44,669 the downward without Cherrix. 1009 00:35:44,670 --> 00:35:47,009 So, um, yeah, Apple can really 1010 00:35:47,010 --> 00:35:48,150 do lots of things here. 1011 00:35:49,860 --> 00:35:52,079 So for future downgrades. 1012 00:35:52,080 --> 00:35:54,209 Um, yeah. Saving AP tickets is 1013 00:35:54,210 --> 00:35:55,919 always a good idea. 1014 00:35:55,920 --> 00:35:57,719 Even if you can't downgrade right now, 1015 00:35:57,720 --> 00:35:59,969 maybe you can in future and maybe 1016 00:35:59,970 --> 00:36:02,069 that will be new box and futures 1017 00:36:02,070 --> 00:36:04,439 are new techniques and 1018 00:36:04,440 --> 00:36:06,300 yeah, definitely save you tickets. 1019 00:36:07,740 --> 00:36:09,689 So the tools are used. 1020 00:36:09,690 --> 00:36:11,699 Here is checker. 1021 00:36:11,700 --> 00:36:13,589 DNS Checker is a tool. 1022 00:36:13,590 --> 00:36:16,019 For requesting air tickets from Apple 1023 00:36:16,020 --> 00:36:18,659 with a lot of customizations, 1024 00:36:18,660 --> 00:36:20,879 you can manually specify the 1025 00:36:20,880 --> 00:36:23,159 opinions Decepticons you want a ticket 1026 00:36:23,160 --> 00:36:25,589 for if you want to postpone 1027 00:36:25,590 --> 00:36:26,939 ticket, if you don't want a baseball 1028 00:36:26,940 --> 00:36:28,769 ticket and really lots of stuff. 1029 00:36:28,770 --> 00:36:30,629 And I haven't seen any other tool which 1030 00:36:30,630 --> 00:36:32,909 can do that. So please check 1031 00:36:32,910 --> 00:36:33,989 out the school for that. 1032 00:36:33,990 --> 00:36:35,849 Also, HMG for Tool. 1033 00:36:35,850 --> 00:36:38,039 It is used for manipulating images 1034 00:36:38,040 --> 00:36:40,619 for I am for a friend files. 1035 00:36:40,620 --> 00:36:42,719 You can view those files, 1036 00:36:42,720 --> 00:36:44,849 you can search for files, you 1037 00:36:44,850 --> 00:36:47,219 can check the 1038 00:36:47,220 --> 00:36:49,919 manifest and stuff like that. 1039 00:36:49,920 --> 00:36:51,989 Also futurists or this is 1040 00:36:51,990 --> 00:36:55,199 the actual implementation of 1041 00:36:55,200 --> 00:36:56,649 the Prometheus Thouret method. 1042 00:36:56,650 --> 00:36:58,679 So what future Restor allows you to do is 1043 00:36:58,680 --> 00:37:00,779 to specify the ticket you want to 1044 00:37:00,780 --> 00:37:03,149 use the specified ASEP, you want to 1045 00:37:03,150 --> 00:37:05,159 install in the specify the basement you 1046 00:37:05,160 --> 00:37:06,329 want to install. 1047 00:37:06,330 --> 00:37:08,489 And all of these, uh, will 1048 00:37:08,490 --> 00:37:09,989 be open source. T.S.A. 1049 00:37:09,990 --> 00:37:11,909 is open source right now. 1050 00:37:11,910 --> 00:37:14,039 I'm due for school and future store will 1051 00:37:14,040 --> 00:37:16,229 be open source shortly after the stock. 1052 00:37:16,230 --> 00:37:18,689 And yeah, at this point, 1053 00:37:18,690 --> 00:37:21,089 I want to thank Nikias, who made 1054 00:37:21,090 --> 00:37:23,339 Multitool script for building futurists 1055 00:37:23,340 --> 00:37:25,409 or futurist stories, uh, really 1056 00:37:25,410 --> 00:37:27,989 messy, uh, project, which consists 1057 00:37:27,990 --> 00:37:30,089 of these Chicca IMG for Tool and 1058 00:37:30,090 --> 00:37:32,039 I advisory store. 1059 00:37:32,040 --> 00:37:33,809 It's just all packed together and made 1060 00:37:33,810 --> 00:37:36,179 some work. So it was really complicated 1061 00:37:36,180 --> 00:37:38,519 to make, uh, both files for that 1062 00:37:38,520 --> 00:37:40,199 and. Yeah, thank you. 1063 00:37:40,200 --> 00:37:42,539 And now it's time for some 1064 00:37:42,540 --> 00:37:43,540 Q&A. 1065 00:37:55,320 --> 00:37:57,269 Thank you very much for the presentation. 1066 00:37:57,270 --> 00:37:59,069 If there are any questions in the 1067 00:37:59,070 --> 00:38:01,139 audience, we have four microphones 1068 00:38:01,140 --> 00:38:03,059 at which you can line up and then I will 1069 00:38:03,060 --> 00:38:05,159 call you if you need to 1070 00:38:05,160 --> 00:38:07,469 leave the room. Now, that's OK. 1071 00:38:07,470 --> 00:38:09,719 But please do so quietly and take 1072 00:38:09,720 --> 00:38:11,849 some trash with you if you can. 1073 00:38:11,850 --> 00:38:13,709 I think the first question was at the 1074 00:38:13,710 --> 00:38:14,639 very back of the room. 1075 00:38:14,640 --> 00:38:15,640 Yes. 1076 00:38:15,990 --> 00:38:17,939 Thanks. So my question is but generic. 1077 00:38:17,940 --> 00:38:20,219 But since you're in the scene, 1078 00:38:20,220 --> 00:38:22,409 right, why 1079 00:38:22,410 --> 00:38:24,959 do jailbreak and 1080 00:38:24,960 --> 00:38:27,359 iOS hardware hackers never 1081 00:38:27,360 --> 00:38:29,609 consider hacking is the Carter 1082 00:38:29,610 --> 00:38:30,539 directly? 1083 00:38:30,540 --> 00:38:31,540 Or maybe they do. 1084 00:38:32,480 --> 00:38:34,689 Um, I think they 1085 00:38:34,690 --> 00:38:37,139 are people doing hardware hacking. 1086 00:38:37,140 --> 00:38:38,969 I know that some people are doing 1087 00:38:38,970 --> 00:38:41,369 hardware hacking for getting 1088 00:38:41,370 --> 00:38:42,900 the former keys, 1089 00:38:44,400 --> 00:38:46,589 but I think most likely 1090 00:38:46,590 --> 00:38:48,869 this is because hardware attacks 1091 00:38:48,870 --> 00:38:51,059 are not really practical for 1092 00:38:51,060 --> 00:38:52,109 the average user. 1093 00:38:52,110 --> 00:38:54,359 So you can't tell a user, well, 1094 00:38:54,360 --> 00:38:55,829 you need to open up the device, you need 1095 00:38:55,830 --> 00:38:57,719 to wire those two pins and then you have 1096 00:38:57,720 --> 00:38:59,999 a jailbreak. So this is why I think 1097 00:39:00,000 --> 00:39:01,859 mostly it's focused on software. 1098 00:39:03,320 --> 00:39:04,729 All right, we are going to take one 1099 00:39:04,730 --> 00:39:06,229 question from the Internet, please. 1100 00:39:06,230 --> 00:39:07,759 Thank you. What is the point in 1101 00:39:07,760 --> 00:39:08,960 downgrading a device? 1102 00:39:11,870 --> 00:39:12,870 Well, 1103 00:39:14,180 --> 00:39:16,399 I actually asked myself a few times, 1104 00:39:16,400 --> 00:39:18,649 but it seems like there are really lots 1105 00:39:18,650 --> 00:39:20,479 of people who do want to it for some 1106 00:39:20,480 --> 00:39:23,299 reason. For example, if you use this 1107 00:39:23,300 --> 00:39:25,669 technique to downgrade without a gericke 1108 00:39:25,670 --> 00:39:27,859 right now, you could right now, 1109 00:39:27,860 --> 00:39:29,599 the latest version is I was ten point 1110 00:39:29,600 --> 00:39:31,879 two. And if you put all this 1111 00:39:31,880 --> 00:39:33,529 voodoo magic, you could right now 1112 00:39:33,530 --> 00:39:35,659 downgrade with that to iOS 10 1113 00:39:35,660 --> 00:39:37,729 one one. And there are some break 1114 00:39:37,730 --> 00:39:39,139 for that. So you could basically 1115 00:39:39,140 --> 00:39:42,169 downgrade to get to Gericke, but 1116 00:39:42,170 --> 00:39:44,349 most likely you can't do this. 1117 00:39:44,350 --> 00:39:45,979 Um, so I don't know. 1118 00:39:45,980 --> 00:39:48,289 Maybe many people say newer 1119 00:39:48,290 --> 00:39:50,779 versions are slower, so they downgrade 1120 00:39:50,780 --> 00:39:52,229 for speech. 1121 00:39:52,230 --> 00:39:53,389 I don't know. People just want 1122 00:39:53,390 --> 00:39:54,390 downgrades. 1123 00:39:57,080 --> 00:39:58,519 All right. We're going to take a question 1124 00:39:58,520 --> 00:40:00,139 from the frontier. 1125 00:40:00,140 --> 00:40:03,349 Yeah, I have a question about NSA 1126 00:40:03,350 --> 00:40:05,509 spying. The study found that there 1127 00:40:05,510 --> 00:40:06,799 are some nonsense that are much more 1128 00:40:06,800 --> 00:40:08,479 frequent than others. 1129 00:40:08,480 --> 00:40:09,439 Is that right? 1130 00:40:09,440 --> 00:40:11,569 Yeah. And did you investigate 1131 00:40:11,570 --> 00:40:12,679 why this could happen? 1132 00:40:12,680 --> 00:40:14,319 Like, did you find the algorithm which 1133 00:40:14,320 --> 00:40:15,980 generates somewhere in the firmware? 1134 00:40:17,630 --> 00:40:19,789 Um, I haven't really 1135 00:40:19,790 --> 00:40:22,399 looked into that part. 1136 00:40:22,400 --> 00:40:24,289 What I did this just basically tried. 1137 00:40:24,290 --> 00:40:26,659 I figured out if you take lots of iPhone 1138 00:40:26,660 --> 00:40:29,359 five hours on iOS nine through something, 1139 00:40:29,360 --> 00:40:31,459 it would generate the same 1140 00:40:31,460 --> 00:40:33,559 Norns across the devices. 1141 00:40:33,560 --> 00:40:35,629 But I haven't really looked into it. 1142 00:40:35,630 --> 00:40:37,759 Why they're doing that specific 1143 00:40:37,760 --> 00:40:38,749 Norns. 1144 00:40:38,750 --> 00:40:40,699 I didn't even expect this to work at all, 1145 00:40:40,700 --> 00:40:41,749 so I was surprised. 1146 00:40:41,750 --> 00:40:42,750 Why does it even work? 1147 00:40:44,050 --> 00:40:45,759 Thank you. All right, we're going to take 1148 00:40:45,760 --> 00:40:46,909 a question from the front, please. 1149 00:40:48,410 --> 00:40:50,209 That was actually my question as well, 1150 00:40:50,210 --> 00:40:52,279 but could I could I just get a picture of 1151 00:40:52,280 --> 00:40:54,769 that? Not that Norns collision slide, 1152 00:40:54,770 --> 00:40:56,419 that was fantastic. 1153 00:40:56,420 --> 00:40:58,519 I think there yeah, 1154 00:40:58,520 --> 00:41:00,619 I think they're even more on 1155 00:41:00,620 --> 00:41:03,169 Reddit post, which there's a guy who 1156 00:41:03,170 --> 00:41:05,299 I published them on my blog 1157 00:41:05,300 --> 00:41:07,039 and there's a guy on Reddit who put them 1158 00:41:07,040 --> 00:41:08,599 all together. And even different 1159 00:41:08,600 --> 00:41:10,339 statistic. I was thinking about taking 1160 00:41:10,340 --> 00:41:12,409 that image to a presentation, but it's 1161 00:41:12,410 --> 00:41:14,929 somewhere on Reddit which devices 1162 00:41:14,930 --> 00:41:17,030 generate collisions and which don't. 1163 00:41:18,320 --> 00:41:19,729 OK, we're going to take one more question 1164 00:41:19,730 --> 00:41:21,049 from the Internet, please. 1165 00:41:21,050 --> 00:41:23,149 Thank you. Will it work on all 1166 00:41:23,150 --> 00:41:24,449 64 devices? 1167 00:41:26,270 --> 00:41:28,519 Well, I guess 1168 00:41:28,520 --> 00:41:30,529 the only thing which would stop it from 1169 00:41:30,530 --> 00:41:32,719 work on the iPhone seven right now 1170 00:41:32,720 --> 00:41:34,819 is that I haven't pulled 1171 00:41:34,820 --> 00:41:37,189 the, um. Well, what the iPhone seven 1172 00:41:37,190 --> 00:41:39,349 is doing with the basement are changed 1173 00:41:39,350 --> 00:41:41,269 to baseband. And I haven't pulled the 1174 00:41:41,270 --> 00:41:43,549 idea as we saw commits 1175 00:41:43,550 --> 00:41:45,559 for handling the new basement format. 1176 00:41:45,560 --> 00:41:47,119 This is why it doesn't work right now. 1177 00:41:47,120 --> 00:41:49,339 And I don't I don't know 1178 00:41:49,340 --> 00:41:51,019 what the new memory protection, the 1179 00:41:51,020 --> 00:41:52,819 iPhone seven, um, does. 1180 00:41:52,820 --> 00:41:54,919 If it stops it if it doesn't stop 1181 00:41:54,920 --> 00:41:56,689 it from patching, I don't know. 1182 00:41:56,690 --> 00:41:58,009 It will probably work. 1183 00:41:58,010 --> 00:42:00,649 Well, I assume it works with all 64 1184 00:42:00,650 --> 00:42:03,199 devices. It might even work with 32 1185 00:42:03,200 --> 00:42:05,030 bit devices. But I never tried. 1186 00:42:06,500 --> 00:42:07,969 OK, question from the back. 1187 00:42:09,470 --> 00:42:10,789 Thanks for the talk. 1188 00:42:10,790 --> 00:42:12,889 My question is 1189 00:42:12,890 --> 00:42:15,169 more or less a dummy question 1190 00:42:15,170 --> 00:42:17,239 you showed us in 1191 00:42:17,240 --> 00:42:19,489 the slides that work 1192 00:42:19,490 --> 00:42:21,919 for nine three five 1193 00:42:21,920 --> 00:42:24,379 and nine three three. 1194 00:42:24,380 --> 00:42:26,539 And now you're set by 1195 00:42:26,540 --> 00:42:28,699 answer answering 1196 00:42:28,700 --> 00:42:30,889 the first question that does work with 1197 00:42:30,890 --> 00:42:32,659 iOS 10. 1198 00:42:32,660 --> 00:42:34,849 And maybe I misunderstand 1199 00:42:34,850 --> 00:42:37,399 something. You mean that slide, 1200 00:42:37,400 --> 00:42:38,929 right? Yes. 1201 00:42:38,930 --> 00:42:41,059 Well, basically what the slide 1202 00:42:41,060 --> 00:42:43,449 is saying that I had people with 1203 00:42:43,450 --> 00:42:45,559 iPhone five s on nine 1204 00:42:45,560 --> 00:42:47,269 three two nine three three ninety four 1205 00:42:47,270 --> 00:42:48,439 and five. 1206 00:42:48,440 --> 00:42:50,749 And they were trying to generate Anon's. 1207 00:42:50,750 --> 00:42:53,269 And this was the same across 1208 00:42:53,270 --> 00:42:55,669 all these devices, so generated the same. 1209 00:42:55,670 --> 00:42:57,859 But the iPhone five s also 1210 00:42:57,860 --> 00:43:00,769 generates nonces 1211 00:43:00,770 --> 00:43:03,199 collisions on iOS 10 zero 1212 00:43:03,200 --> 00:43:04,759 10 one 10 two. 1213 00:43:04,760 --> 00:43:06,589 There are there there's a difference 1214 00:43:06,590 --> 00:43:08,809 between nine and 10 that they're just 1215 00:43:08,810 --> 00:43:11,179 simply different ones like five 1216 00:43:11,180 --> 00:43:13,699 five of these files, nine and on now 1217 00:43:13,700 --> 00:43:15,739 just five different ones. 1218 00:43:15,740 --> 00:43:17,949 Um, can I 1219 00:43:17,950 --> 00:43:18,919 sorry. We're going to take another 1220 00:43:18,920 --> 00:43:19,920 question from the front. 1221 00:43:21,060 --> 00:43:23,369 Thank you for talking still about the 1222 00:43:23,370 --> 00:43:25,319 repeated nonsense you already answered 1223 00:43:25,320 --> 00:43:27,179 that you haven't looked into how they're 1224 00:43:27,180 --> 00:43:29,489 generated, but is that code in 1225 00:43:29,490 --> 00:43:32,129 the publicly reversible 1226 00:43:32,130 --> 00:43:34,229 part, like how hard would it be to 1227 00:43:34,230 --> 00:43:36,330 figure out how they're generated? 1228 00:43:37,860 --> 00:43:40,349 Well, if you put the device 1229 00:43:40,350 --> 00:43:42,419 and request the nonce from there, that 1230 00:43:42,420 --> 00:43:45,059 would be a nonce generated from 1231 00:43:45,060 --> 00:43:47,669 the bootloader from Ibold or something. 1232 00:43:47,670 --> 00:43:49,769 So you would probably need to 1233 00:43:49,770 --> 00:43:51,299 dump Ibold and reverse that. 1234 00:43:51,300 --> 00:43:53,969 They are the random number generator. 1235 00:43:53,970 --> 00:43:55,949 What I did is I took a look at the 1236 00:43:55,950 --> 00:43:58,049 generator thing and I figured out 1237 00:43:58,050 --> 00:44:00,389 is just the, um, the little 1238 00:44:00,390 --> 00:44:01,319 engine and coding. 1239 00:44:01,320 --> 00:44:03,269 And if you hash that bitstream, this is 1240 00:44:03,270 --> 00:44:04,499 basically the nonce. 1241 00:44:04,500 --> 00:44:05,729 So I focus on that. 1242 00:44:05,730 --> 00:44:08,099 So you just take eight bytes, 1243 00:44:08,100 --> 00:44:09,599 hash that and this is the Norns. 1244 00:44:09,600 --> 00:44:11,279 This is also what T.S.A. 1245 00:44:11,280 --> 00:44:12,569 does when saving lobs. 1246 00:44:12,570 --> 00:44:15,239 It would make random it by its hash them 1247 00:44:15,240 --> 00:44:17,039 so we know you can use that specific 1248 00:44:17,040 --> 00:44:18,209 generator if you're related to 1249 00:44:18,210 --> 00:44:19,649 environment would generate the same 1250 00:44:19,650 --> 00:44:21,839 nodes. But I haven't really looked 1251 00:44:21,840 --> 00:44:23,909 into how Ibold generates a 1252 00:44:23,910 --> 00:44:25,289 random nonsense. 1253 00:44:25,290 --> 00:44:27,359 But I would is there 1254 00:44:27,360 --> 00:44:29,319 are decrypted Eberts available for 1255 00:44:29,320 --> 00:44:30,869 reversing order? 1256 00:44:30,870 --> 00:44:33,239 I don't think that they are decrypted. 1257 00:44:33,240 --> 00:44:35,669 Once you I know there is a technique 1258 00:44:35,670 --> 00:44:37,769 by Kurti where you could dump 1259 00:44:37,770 --> 00:44:39,869 enabled from iOS eight 1260 00:44:39,870 --> 00:44:42,689 devices for 64 bit 1261 00:44:42,690 --> 00:44:45,239 for S2, but there are decrypted 1262 00:44:45,240 --> 00:44:47,369 Frommer's. But I haven't really 1263 00:44:47,370 --> 00:44:49,289 looked into that on this. 1264 00:44:49,290 --> 00:44:51,539 I have focused on 64 bit. 1265 00:44:51,540 --> 00:44:53,639 Thank you. OK, one more question from the 1266 00:44:53,640 --> 00:44:54,749 Internet, please. 1267 00:44:54,750 --> 00:44:56,639 Thank you. Is it possible to get around 1268 00:44:56,640 --> 00:44:59,279 the theft protection with downgrading 1269 00:44:59,280 --> 00:45:00,839 a device? 1270 00:45:00,840 --> 00:45:03,119 No, it is not, because after 1271 00:45:03,120 --> 00:45:05,279 your downgrade or restore in 1272 00:45:05,280 --> 00:45:07,349 general, you 1273 00:45:07,350 --> 00:45:09,209 need to activate the device. 1274 00:45:09,210 --> 00:45:11,249 And this is completely separated from the 1275 00:45:11,250 --> 00:45:13,469 system. So we would need to 1276 00:45:13,470 --> 00:45:14,759 get an activation record. 1277 00:45:14,760 --> 00:45:16,769 This has nothing to do with downgrading, 1278 00:45:16,770 --> 00:45:18,879 restoring. So now you cannot bypass 1279 00:45:18,880 --> 00:45:20,999 theft protection question in 1280 00:45:21,000 --> 00:45:22,000 the front. 1281 00:45:22,590 --> 00:45:24,869 Yes, earlier you said that the basement 1282 00:45:24,870 --> 00:45:27,029 itself was used primarily for tying 1283 00:45:27,030 --> 00:45:29,339 devices to a specific carrier and 1284 00:45:29,340 --> 00:45:30,779 that for a while you could drive a 1285 00:45:30,780 --> 00:45:33,569 different baseband and AOS combinations. 1286 00:45:33,570 --> 00:45:35,489 But then at the end, you said that they 1287 00:45:35,490 --> 00:45:37,079 were now tied together. 1288 00:45:37,080 --> 00:45:38,909 What is actually inside the baseband? 1289 00:45:38,910 --> 00:45:40,679 What is it being used for in modern 1290 00:45:40,680 --> 00:45:41,159 times? 1291 00:45:41,160 --> 00:45:43,379 Well, you have four, as far 1292 00:45:43,380 --> 00:45:45,719 as I understand, the different some 1293 00:45:45,720 --> 00:45:48,009 kind of chip and the baseband 1294 00:45:48,010 --> 00:45:50,939 is the former for that specific chip 1295 00:45:50,940 --> 00:45:53,489 and that handles the common 1296 00:45:53,490 --> 00:45:55,679 communication with the GSM and stuff like 1297 00:45:55,680 --> 00:45:57,839 that. So if you want to use 1298 00:45:57,840 --> 00:46:00,059 LTE or if you call someone, 1299 00:46:00,060 --> 00:46:02,159 then you using that specific 1300 00:46:02,160 --> 00:46:04,289 chip with that specific Fermor, talk to 1301 00:46:04,290 --> 00:46:04,979 that. 1302 00:46:04,980 --> 00:46:07,049 And this baseband 1303 00:46:07,050 --> 00:46:09,179 is the US of the thing 1304 00:46:09,180 --> 00:46:10,949 that handles telephone and stuff like 1305 00:46:10,950 --> 00:46:11,639 that. 1306 00:46:11,640 --> 00:46:12,899 And does it have storage? 1307 00:46:12,900 --> 00:46:14,519 Could there be cryptographically relevant 1308 00:46:14,520 --> 00:46:17,129 information in that particular 1309 00:46:17,130 --> 00:46:17,989 section? 1310 00:46:17,990 --> 00:46:20,369 Um, probably there are some 1311 00:46:20,370 --> 00:46:22,949 carrier formations I don't really know, 1312 00:46:22,950 --> 00:46:25,169 but does nothing or really what 1313 00:46:25,170 --> 00:46:27,239 the user would have access 1314 00:46:27,240 --> 00:46:28,240 to anyhow. 1315 00:46:29,310 --> 00:46:31,079 OK, another question in front, please. 1316 00:46:31,080 --> 00:46:33,269 I thank you for the talk I wanted to ask 1317 00:46:33,270 --> 00:46:35,459 you about. Is there a way to get 1318 00:46:35,460 --> 00:46:37,889 a kilo there for 64 bit devices? 1319 00:46:39,720 --> 00:46:40,919 Honestly, I don't know. 1320 00:46:41,920 --> 00:46:42,920 OK. 1321 00:46:44,360 --> 00:46:46,489 Another question from the Internet, have 1322 00:46:46,490 --> 00:46:47,840 you ever the device? 1323 00:46:48,980 --> 00:46:50,659 If I ever break the device, 1324 00:46:52,580 --> 00:46:53,630 no, I haven't. 1325 00:46:58,260 --> 00:47:00,659 Any other questions, now's 1326 00:47:00,660 --> 00:47:01,919 your chance. 1327 00:47:01,920 --> 00:47:02,909 Yes, please. 1328 00:47:02,910 --> 00:47:04,439 You mentioned that it wasn't possible to 1329 00:47:04,440 --> 00:47:07,499 downgrade from ten to nine point five, 1330 00:47:07,500 --> 00:47:09,809 but then you also had a slide on chaining 1331 00:47:09,810 --> 00:47:11,549 those downgrades. 1332 00:47:11,550 --> 00:47:13,109 Can you talk about that? 1333 00:47:13,110 --> 00:47:15,449 So this slides 1334 00:47:15,450 --> 00:47:17,579 were made in the days where I 1335 00:47:17,580 --> 00:47:19,799 was and I was still signed. 1336 00:47:19,800 --> 00:47:22,139 So I wrongly assumed you can what the 1337 00:47:22,140 --> 00:47:23,999 really thing which is stopping you from 1338 00:47:24,000 --> 00:47:26,519 downgrading iOS 10 to iOS nine 1339 00:47:26,520 --> 00:47:28,829 is that you cannot use 1340 00:47:28,830 --> 00:47:31,289 iOS 10 SEP on 1341 00:47:31,290 --> 00:47:32,939 the iOS nine Fermor. 1342 00:47:32,940 --> 00:47:35,369 You could finish up the restore, 1343 00:47:35,370 --> 00:47:37,349 but at the very end of the restore, it 1344 00:47:37,350 --> 00:47:38,549 would fail. 1345 00:47:38,550 --> 00:47:40,679 At that point, it would have already 1346 00:47:40,680 --> 00:47:42,959 written the bootloader and I would 1347 00:47:42,960 --> 00:47:45,089 so we could build up to recovery. 1348 00:47:45,090 --> 00:47:47,559 But there's some stuff at the end which 1349 00:47:47,560 --> 00:47:48,749 is stored and finished. 1350 00:47:48,750 --> 00:47:50,489 You don't have a file. 1351 00:47:50,490 --> 00:47:51,689 I don't know if you have a file system, 1352 00:47:51,690 --> 00:47:53,039 but you have don't have a phone. 1353 00:47:53,040 --> 00:47:55,229 You could use the bootloader 1354 00:47:55,230 --> 00:47:56,580 there, but that's it. 1355 00:47:58,740 --> 00:48:01,109 Another question on the front, please. 1356 00:48:01,110 --> 00:48:02,789 This might be a dumb question as well, 1357 00:48:02,790 --> 00:48:04,649 but after the downgrade, are still the 1358 00:48:04,650 --> 00:48:06,809 user data on the phone 1359 00:48:06,810 --> 00:48:09,139 maintained or are they wiped afterwards? 1360 00:48:10,230 --> 00:48:12,509 Um, this is a good question. 1361 00:48:12,510 --> 00:48:14,799 This is actually a restore. 1362 00:48:14,800 --> 00:48:17,339 So when you restore, you can 1363 00:48:17,340 --> 00:48:18,749 wipe the whole data. 1364 00:48:18,750 --> 00:48:20,849 There's also an option to upgrade 1365 00:48:20,850 --> 00:48:23,129 where you don't actually erase the data. 1366 00:48:24,510 --> 00:48:26,849 Um, I have an option in 1367 00:48:26,850 --> 00:48:29,279 future restor, which sets 1368 00:48:29,280 --> 00:48:31,649 the flag for a device restore 1369 00:48:31,650 --> 00:48:33,729 to not wipe the position, but to 1370 00:48:33,730 --> 00:48:35,069 the upgrade instead. 1371 00:48:35,070 --> 00:48:37,739 So you could try downgrading 1372 00:48:37,740 --> 00:48:39,959 and with that flag set so it would 1373 00:48:39,960 --> 00:48:41,309 keep the data. 1374 00:48:41,310 --> 00:48:43,739 But I don't know if it's a good idea 1375 00:48:43,740 --> 00:48:45,929 to do that, if it would mess stuff 1376 00:48:45,930 --> 00:48:48,660 up. I haven't tried that, but maybe 1377 00:48:49,680 --> 00:48:52,879 I get another question from the Internet. 1378 00:48:52,880 --> 00:48:55,049 Um, thank you. Can you save the set 1379 00:48:55,050 --> 00:48:57,239 before updating and use it, 1380 00:48:57,240 --> 00:48:59,339 um, again after you 1381 00:48:59,340 --> 00:49:01,859 downgraded to a previous version? 1382 00:49:01,860 --> 00:49:04,679 Um, no, you cannot, because, 1383 00:49:04,680 --> 00:49:06,899 um, when the 1384 00:49:06,900 --> 00:49:09,209 sep when restoring, you 1385 00:49:09,210 --> 00:49:11,789 put, um, Ramdisk 1386 00:49:11,790 --> 00:49:14,399 and then you also need to board 1387 00:49:14,400 --> 00:49:15,959 to Ceppos. 1388 00:49:15,960 --> 00:49:18,269 So, um, and before rebooted 1389 00:49:18,270 --> 00:49:19,709 the Sepoys you can't really 1390 00:49:21,030 --> 00:49:23,679 start to downgrade and 1391 00:49:23,680 --> 00:49:26,069 um the normal download 1392 00:49:26,070 --> 00:49:27,929 we the file system and stuff. 1393 00:49:27,930 --> 00:49:30,029 And the Sep Fermor actually 1394 00:49:30,030 --> 00:49:32,969 handles the restore process for the SEP. 1395 00:49:32,970 --> 00:49:35,189 So four it would restore 1396 00:49:35,190 --> 00:49:37,559 also the SEP and those nonces 1397 00:49:37,560 --> 00:49:38,909 need to match. 1398 00:49:38,910 --> 00:49:41,459 So it's a completely separate 1399 00:49:41,460 --> 00:49:42,659 restore process. 1400 00:49:42,660 --> 00:49:44,729 So we come to that question 1401 00:49:44,730 --> 00:49:45,730 in the front, please. 1402 00:49:46,410 --> 00:49:48,659 Why is the baseband so hard to exploit? 1403 00:49:49,690 --> 00:49:51,209 I'm not saying the basement is hard to 1404 00:49:51,210 --> 00:49:53,129 exploit, but I have the feeling 1405 00:49:53,130 --> 00:49:55,109 personally that not many people are 1406 00:49:55,110 --> 00:49:57,509 looking into it because, um, 1407 00:49:57,510 --> 00:49:59,939 I wouldn't know what I would do with, 1408 00:49:59,940 --> 00:50:02,039 like, it's a lot of work just 1409 00:50:02,040 --> 00:50:03,329 so we could download it. 1410 00:50:03,330 --> 00:50:05,459 I'm not saying why would anyone should, 1411 00:50:05,460 --> 00:50:07,769 uh, would do that in 1412 00:50:07,770 --> 00:50:09,839 theory. You could, um, exploit 1413 00:50:09,840 --> 00:50:12,329 the basement. You could try to downgrade 1414 00:50:12,330 --> 00:50:13,229 that. 1415 00:50:13,230 --> 00:50:16,109 What you also could do is you could 1416 00:50:16,110 --> 00:50:18,599 pitch the older, um, 1417 00:50:18,600 --> 00:50:21,359 us so it would understand 1418 00:50:21,360 --> 00:50:23,729 the newer basement API and get 1419 00:50:23,730 --> 00:50:25,559 that somehow to work. 1420 00:50:25,560 --> 00:50:27,629 It's definitely doable, but 1421 00:50:27,630 --> 00:50:29,849 easier ways. Just hope that it works. 1422 00:50:32,340 --> 00:50:34,379 Thanks. Another question from Alice. 1423 00:50:37,540 --> 00:50:39,999 Is it so what software 1424 00:50:40,000 --> 00:50:42,099 handles writing the firmware 1425 00:50:42,100 --> 00:50:44,469 to the SAP and things like that, and 1426 00:50:44,470 --> 00:50:46,089 would it be possible to patch that in the 1427 00:50:46,090 --> 00:50:47,439 same way that you would patch the kernel 1428 00:50:47,440 --> 00:50:49,629 to just not write the sap so that 1429 00:50:49,630 --> 00:50:51,879 you would be able to do downgrades 1430 00:50:51,880 --> 00:50:53,109 and things like that without having to 1431 00:50:53,110 --> 00:50:54,110 write the Nuers up? 1432 00:50:56,920 --> 00:50:59,139 I don't think you can do that 1433 00:50:59,140 --> 00:51:00,129 just as easily. 1434 00:51:00,130 --> 00:51:02,229 Maybe you probably need to 1435 00:51:02,230 --> 00:51:04,359 exploit the SAP Fermor and 1436 00:51:04,360 --> 00:51:06,669 to stop it from downgrading because 1437 00:51:06,670 --> 00:51:08,409 SAP handles a lot of stuff like 1438 00:51:09,670 --> 00:51:11,859 Sweida, random, true random number 1439 00:51:11,860 --> 00:51:13,929 generator and other things. 1440 00:51:13,930 --> 00:51:16,359 So I think to not update 1441 00:51:16,360 --> 00:51:18,159 the sap, you would need to actually 1442 00:51:18,160 --> 00:51:19,149 exploit the sap. 1443 00:51:19,150 --> 00:51:21,099 But I haven't really looked into the 1444 00:51:21,100 --> 00:51:22,510 Sabbath, just what I assume. 1445 00:51:26,580 --> 00:51:28,340 Any other final questions? 1446 00:51:31,690 --> 00:51:33,159 All right, so when you go, please take 1447 00:51:33,160 --> 00:51:35,079 some trash with you and please give 1448 00:51:35,080 --> 00:51:37,079 another warm round of applause to.