[Script Info] Title: [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:03.97,0:00:16.73,Default,,0000,0000,0000,,{\i1}35C3 preroll music{\i0} Dialogue: 0,0:00:16.73,0:00:22.01,Default,,0000,0000,0000,,Herald-Angel: All right, let's start with\Nour next talk in the security track of the Dialogue: 0,0:00:22.01,0:00:27.24,Default,,0000,0000,0000,,chaos communication congress. The talk is\Ncalled jailbreaking iOS from past to Dialogue: 0,0:00:27.24,0:00:34.95,Default,,0000,0000,0000,,present. Done by tihmstar. He spoke at the\N32nd C3 already and researched on several Dialogue: 0,0:00:34.95,0:00:40.47,Default,,0000,0000,0000,,jailbreaks like the Phoenix or the\NjelbrekTime for the Apple Watch and he's Dialogue: 0,0:00:40.47,0:00:44.80,Default,,0000,0000,0000,,gonna talk about the history of\Njailbreaks. He's going to familiarize you Dialogue: 0,0:00:44.80,0:00:52.02,Default,,0000,0000,0000,,with the terminology of jailbreaking and\Nabout exploit mitigations and how you can Dialogue: 0,0:00:52.02,0:00:55.91,Default,,0000,0000,0000,,circumvent these mitigations. Please\Nwelcome him with a huge round of applause. Dialogue: 0,0:00:55.91,0:01:02.62,Default,,0000,0000,0000,,{\i1}Applause{\i0} Dialogue: 0,0:01:02.62,0:01:08.80,Default,,0000,0000,0000,,tihmstar: Thank you very much. So hello\Nroom, I'm tihmstar, and as already said I Dialogue: 0,0:01:08.80,0:01:13.91,Default,,0000,0000,0000,,want to talk about jailbreaking iOS from\Npast to present and the topics I'm going Dialogue: 0,0:01:13.91,0:01:19.80,Default,,0000,0000,0000,,to cover "what is jailbreaking?". I will\Ngive an overview in general. I'm going to Dialogue: 0,0:01:19.80,0:01:25.60,Default,,0000,0000,0000,,introduce you to how jailbreak started,\Nhow they got into the phone at first and Dialogue: 0,0:01:25.60,0:01:30.95,Default,,0000,0000,0000,,how all of these progressed. I'll\Nintroduce you to the terminology which is Dialogue: 0,0:01:30.95,0:01:37.46,Default,,0000,0000,0000,,"tethered", "untethered", "semi-tethered",\N"semi-untethered" jailbreaks. Stuff you Dialogue: 0,0:01:37.46,0:01:41.40,Default,,0000,0000,0000,,probably heard but some of you don't know\Nwhat that means. I'm gonna talk a bit Dialogue: 0,0:01:41.40,0:01:46.25,Default,,0000,0000,0000,,about hardware mitigations which were\Nintroduced by Apple which is KPP, KTRR and Dialogue: 0,0:01:46.25,0:01:52.80,Default,,0000,0000,0000,,a little bit about PAC. I'm going to talk\Nabout the general goals of... About the Dialogue: 0,0:01:52.80,0:01:57.79,Default,,0000,0000,0000,,technical goals of jailbreaking and the\Nkernel patches and what you want to do Dialogue: 0,0:01:57.79,0:02:02.70,Default,,0000,0000,0000,,with those and brief overview how\Njailbreaking could look like in the future. Dialogue: 0,0:02:02.70,0:02:10.77,Default,,0000,0000,0000,,So who am I? I'm tihmstar. I got\Nmy first iPod touch with iOS 5.1 and since Dialogue: 0,0:02:10.77,0:02:15.74,Default,,0000,0000,0000,,then I pretty much played with jailbreaks\Nand then I got really interested into that Dialogue: 0,0:02:15.74,0:02:19.44,Default,,0000,0000,0000,,and started doing my own research. I\Neventually started doing my own Dialogue: 0,0:02:19.44,0:02:23.51,Default,,0000,0000,0000,,jailbreaks. I kinda started with\Ndowngrading – so I've been here two years Dialogue: 0,0:02:23.51,0:02:28.84,Default,,0000,0000,0000,,ago with my presentation "iOS Downgrading:\NFrom past to present". I kept hacking Dialogue: 0,0:02:28.84,0:02:33.53,Default,,0000,0000,0000,,since then. So back then I kind of talked\Nabout the projects I made and related to Dialogue: 0,0:02:33.53,0:02:38.61,Default,,0000,0000,0000,,downgrading which was tsschecker,\Nfuturerestore, img4tool, you probably have Dialogue: 0,0:02:38.61,0:02:42.52,Default,,0000,0000,0000,,heard of that. And since then I was\Nworking on several jailbreaking tools Dialogue: 0,0:02:42.52,0:02:49.69,Default,,0000,0000,0000,,ranging from iOS 8.4.1 to 10.3.3, among\Nthose 32bit jailbreaks, untethered Dialogue: 0,0:02:49.69,0:02:54.51,Default,,0000,0000,0000,,jailbreaks, remote jailbreaks like\Njailbreak.me and the jailbreak for the Dialogue: 0,0:02:54.51,0:03:02.20,Default,,0000,0000,0000,,Apple Watch. So, what is this jailbreaking\NI am talking about? Basically, the goal is Dialogue: 0,0:03:02.20,0:03:08.62,Default,,0000,0000,0000,,to get control over a device you own. You\Nwant to escape the sandbox which the apps Dialogue: 0,0:03:08.62,0:03:14.44,Default,,0000,0000,0000,,are put in. You want to elevate the\Nprivileges to root and eventually to Dialogue: 0,0:03:14.44,0:03:20.03,Default,,0000,0000,0000,,kernel, you want to disable code signing\Nbecause all applications on iOS are code- Dialogue: 0,0:03:20.03,0:03:24.09,Default,,0000,0000,0000,,signed and you cannot run unsigned\Nbinaries. You pretty much want to disable Dialogue: 0,0:03:24.09,0:03:29.96,Default,,0000,0000,0000,,that to run unsigned binaries. And the\Nmost popular about people on jailbreak is Dialogue: 0,0:03:29.96,0:03:35.62,Default,,0000,0000,0000,,to install tweaks! And also a lot of\Npeople install a jailbreak or jailbreak Dialogue: 0,0:03:35.62,0:03:39.24,Default,,0000,0000,0000,,their devices for doing security analysis.\NFor example if you want to pentest your Dialogue: 0,0:03:39.24,0:03:44.98,Default,,0000,0000,0000,,application and see how an attack goes\Nfoot – you want to debug that stuff and Dialogue: 0,0:03:44.98,0:03:51.12,Default,,0000,0000,0000,,you want to have a jailbroken phone for\Nthat. So what are these tweaks? Tweaks are Dialogue: 0,0:03:51.12,0:03:55.83,Default,,0000,0000,0000,,usually modifications of built-in\Nuserspace programs, for example one of the Dialogue: 0,0:03:55.83,0:03:59.74,Default,,0000,0000,0000,,programs is springboard. Springboard is\Nwhat you see if you turn on your phone. Dialogue: 0,0:03:59.74,0:04:04.79,Default,,0000,0000,0000,,This is where all the icons are at. And\Nusually you can install tweaks to, I don't Dialogue: 0,0:04:04.79,0:04:10.68,Default,,0000,0000,0000,,know, modify the look, the behavior or add\Nfunctionality, just this customization, Dialogue: 0,0:04:10.68,0:04:17.88,Default,,0000,0000,0000,,this is how it started with jailbreaking.\NWhat is usually bundled when you install a Dialogue: 0,0:04:17.88,0:04:23.72,Default,,0000,0000,0000,,jailbreak is Cydia. So you install dpkg\Nand apt which is the Debian package Dialogue: 0,0:04:23.72,0:04:31.63,Default,,0000,0000,0000,,manager and you also get Cydia which is a\Nuser-friendly graphical user interface for Dialogue: 0,0:04:31.63,0:04:38.28,Default,,0000,0000,0000,,the decentralized or centralized package\Ninstaller system. I'm saying centralized Dialogue: 0,0:04:38.28,0:04:42.25,Default,,0000,0000,0000,,because it is pretty much all in one spot,\Nyou just open the app and you can get all Dialogue: 0,0:04:42.25,0:04:47.25,Default,,0000,0000,0000,,your tweaks and it's also decentralized\Nbecause you can just add up your own repo, Dialogue: 0,0:04:47.25,0:04:54.20,Default,,0000,0000,0000,,you can make your own repo, you can add\Nother repos and you're not kinda tied to Dialogue: 0,0:04:54.20,0:04:58.46,Default,,0000,0000,0000,,one spot where you get the tweaks from, \Nlike from the App Store you can only download Dialogue: 0,0:04:58.46,0:05:02.27,Default,,0000,0000,0000,,from the App Store. But with Cydia you can\Npretty much download from everywhere. Dialogue: 0,0:05:02.27,0:05:09.21,Default,,0000,0000,0000,,You're probably familiar with Debian and\Nit's pretty much the same. So this talk is Dialogue: 0,0:05:09.21,0:05:15.61,Default,,0000,0000,0000,,pretty much structured around this tweet:\Nthe "Ages of jailbreaking". So as you can Dialogue: 0,0:05:15.61,0:05:20.49,Default,,0000,0000,0000,,see we get the Golden Age, the BootRom,\Nthe Industrial Age and The Post- Dialogue: 0,0:05:20.49,0:05:25.16,Default,,0000,0000,0000,,Apocalyptic age. And I kind of agree with\Nthat. So this is why I decided to Dialogue: 0,0:05:25.16,0:05:29.53,Default,,0000,0000,0000,,structure my talk around that and walk you\Nthrough the different ages of Dialogue: 0,0:05:29.53,0:05:35.35,Default,,0000,0000,0000,,jailbreaking. So starting with the first\NiPhone OS jailbreak – then it was actually Dialogue: 0,0:05:35.35,0:05:42.49,Default,,0000,0000,0000,,called iPhone OS not iOS – it was not the\NBootROM yet. So the first was a buffer Dialogue: 0,0:05:42.49,0:05:49.56,Default,,0000,0000,0000,,overflow and the iPhone's libTitt library.\NAnd this is an image parsing library. Dialogue: 0,0:05:49.56,0:05:54.93,Default,,0000,0000,0000,,It was exploited through Safari and used as\Nan entry point to get code execution. Dialogue: 0,0:05:54.93,0:06:00.90,Default,,0000,0000,0000,,It was the first time that non-Apple software\Nwas run on an iPhone and people installed Dialogue: 0,0:06:00.90,0:06:06.85,Default,,0000,0000,0000,,applications like Installer or AppTapp\Nwhich were stores similar to Cydia back Dialogue: 0,0:06:06.85,0:06:11.59,Default,,0000,0000,0000,,then and those were used to install apps\Nor games because for the first iPhone OS Dialogue: 0,0:06:11.59,0:06:16.65,Default,,0000,0000,0000,,there was no way to install applications\Nanyhow, as the App Store got introduced Dialogue: 0,0:06:16.65,0:06:24.49,Default,,0000,0000,0000,,with iOS 2. So then, going to the Golden\NAge, the attention kind of shifted to the Dialogue: 0,0:06:24.49,0:06:29.95,Default,,0000,0000,0000,,BootROM; people started looking at the\Nboot process and they found this device Dialogue: 0,0:06:29.95,0:06:39.12,Default,,0000,0000,0000,,firmware upgrade mode which is a part of\NROM. So the most famous BootROM exploit Dialogue: 0,0:06:39.12,0:06:45.12,Default,,0000,0000,0000,,was limera1n by geohot. It was a bug in\Nhardware and it was unpatchable with Dialogue: 0,0:06:45.12,0:06:52.65,Default,,0000,0000,0000,,software. So this bug was used to\Njailbreak devices up to the iPhone 4. Dialogue: 0,0:06:52.65,0:06:56.67,Default,,0000,0000,0000,,There were also several other jailbreaks –\Nwe didn't rely on that one – but this one, Dialogue: 0,0:06:56.67,0:07:00.38,Default,,0000,0000,0000,,once discovered, you can use it over and\Nover again and there's no way to patch Dialogue: 0,0:07:00.38,0:07:06.69,Default,,0000,0000,0000,,that. So this was later patched in a new\Nhardware revision which is the iPhone 4s. Dialogue: 0,0:07:06.69,0:07:09.83,Default,,0000,0000,0000,,So with that BootROM bug – Dialogue: 0,0:07:09.83,0:07:15.93,Default,,0000,0000,0000,,This is how kind of tethered jailbreaks\Nbecame a thing. So limera1n exploits a bug Dialogue: 0,0:07:15.93,0:07:24.34,Default,,0000,0000,0000,,in DFU mode which allows you to load\Nunsigned software through USB. However Dialogue: 0,0:07:24.34,0:07:29.73,Default,,0000,0000,0000,,when you reboot the device a computer was\Nrequired to re-exploit and again load your Dialogue: 0,0:07:29.73,0:07:36.38,Default,,0000,0000,0000,,unsigned code. And then load the\Nbootloaders, load the patched kernel and Dialogue: 0,0:07:36.38,0:07:40.35,Default,,0000,0000,0000,,thus the jailbreak was kind of tethered to\Nthe computer because whenever you shut Dialogue: 0,0:07:40.35,0:07:46.16,Default,,0000,0000,0000,,down you need to be back at a computer to\Nboot your phone up. So historically a Dialogue: 0,0:07:46.16,0:07:51.52,Default,,0000,0000,0000,,tethered jailbroken phone does not boot\Nwithout a computer at all. And the reason Dialogue: 0,0:07:51.52,0:07:57.99,Default,,0000,0000,0000,,for that is because the jailbreaks would\Nmodify the kernel and the bootloaders on Dialogue: 0,0:07:57.99,0:08:04.12,Default,,0000,0000,0000,,the file system for performance reasons,\Nso when you do the actual tether boot you Dialogue: 0,0:08:04.12,0:08:09.23,Default,,0000,0000,0000,,would need to upload a very tiny payload\Nvia USB which then in turn would load Dialogue: 0,0:08:09.23,0:08:14.38,Default,,0000,0000,0000,,everything else from the file system\Nitself. But this results in a broken chain Dialogue: 0,0:08:14.38,0:08:18.78,Default,,0000,0000,0000,,of trust. When the normal boot process\Nruns and the bootloader checks the Dialogue: 0,0:08:18.78,0:08:23.34,Default,,0000,0000,0000,,signature of the first-stage bootloader\Nthat would be invalid so the bootloader Dialogue: 0,0:08:23.34,0:08:29.34,Default,,0000,0000,0000,,would refuse to boot that and it would end\Nup in DFU mode so basically a phone won't Dialogue: 0,0:08:29.34,0:08:36.35,Default,,0000,0000,0000,,boot. Sometime around then, the idea for\Nsemi-tethered jailbreak came up and the Dialogue: 0,0:08:36.35,0:08:40.48,Default,,0000,0000,0000,,idea behind that is very simple: just\Ndon't break the chain of trust for Dialogue: 0,0:08:40.48,0:08:47.15,Default,,0000,0000,0000,,tethered jailbreaks. So, what you would do\Ndifferently is you do not modify the Dialogue: 0,0:08:47.15,0:08:52.22,Default,,0000,0000,0000,,kernel on the file system, don't touch the\Nbootloaders at all and then when you Dialogue: 0,0:08:52.22,0:08:56.23,Default,,0000,0000,0000,,would boot tethered, you would need to\Nupload all the bootloaders like the first Dialogue: 0,0:08:56.23,0:09:00.79,Default,,0000,0000,0000,,stage bootloader, then the second stage\Nbootloader which is iBoot and then the Dialogue: 0,0:09:00.79,0:09:05.55,Default,,0000,0000,0000,,kernel via USB to boot into jailbroken\Nmode. However when you reboot you could Dialogue: 0,0:09:05.55,0:09:10.55,Default,,0000,0000,0000,,boot all those components from the file\Nsystem so you could actually boot your Dialogue: 0,0:09:10.55,0:09:17.15,Default,,0000,0000,0000,,phone into non-jailbroken mode. If you\Ndon't install any tweaks or modifications Dialogue: 0,0:09:17.15,0:09:22.02,Default,,0000,0000,0000,,which modify critical system components\Nbecause if you tamper with, for example, Dialogue: 0,0:09:22.02,0:09:25.21,Default,,0000,0000,0000,,the signature of the mount binary the\Nsystem obviously cannot boot Dialogue: 0,0:09:25.21,0:09:28.81,Default,,0000,0000,0000,,in non-jailbroken mode. Dialogue: 0,0:09:28.81,0:09:35.91,Default,,0000,0000,0000,,So, this is kind of the Golden age. \NSo let's continue with the Industrial age. Dialogue: 0,0:09:35.91,0:09:43.83,Default,,0000,0000,0000,,So with the release of the\NiPhone 4s and iOS 5, Apple fixed the Dialogue: 0,0:09:43.83,0:09:49.69,Default,,0000,0000,0000,,BootROM bug and essentially killed\Nlimera1n. They also introduced APTickets Dialogue: 0,0:09:49.69,0:09:55.66,Default,,0000,0000,0000,,and nonces to bootloaders, which I'm just\Nmentioning because it's kind of a Dialogue: 0,0:09:55.66,0:10:00.98,Default,,0000,0000,0000,,throwback for downgrading: before that you\Ncan have a phone if you update to the Dialogue: 0,0:10:00.98,0:10:05.53,Default,,0000,0000,0000,,latest firmware and before you save your\NSHSH blobs you could just downgrade and Dialogue: 0,0:10:05.53,0:10:09.28,Default,,0000,0000,0000,,then jailbreak again which wasn't a big\Ndeal but with that they also added Dialogue: 0,0:10:09.28,0:10:13.81,Default,,0000,0000,0000,,downgrade protection so jailbreaking\Nbecame harder. If you wanted to know more Dialogue: 0,0:10:13.81,0:10:20.01,Default,,0000,0000,0000,,about how the boot process works, what\NSHSH blobs are, what APTickets are, you Dialogue: 0,0:10:20.01,0:10:24.04,Default,,0000,0000,0000,,should check out my talk from two years\Nago, I go in-depth on how all of that Dialogue: 0,0:10:24.04,0:10:30.47,Default,,0000,0000,0000,,works. So, I'm skipping that for this\Ntalk. So the binaries the phone boots are Dialogue: 0,0:10:30.47,0:10:35.83,Default,,0000,0000,0000,,encrypted so the bootloaders are encrypted\Nand until recently the kernel used to be Dialogue: 0,0:10:35.83,0:10:41.75,Default,,0000,0000,0000,,encrypted as well. And the key encryption\Nkey is fused into the devices and it is Dialogue: 0,0:10:41.75,0:10:46.33,Default,,0000,0000,0000,,impossible to get through hardware\Nattacks. At least there's no public case Dialogue: 0,0:10:46.33,0:10:53.10,Default,,0000,0000,0000,,where somebody actually got that recovered\Nat keys so it's probably impossible, Dialogue: 0,0:10:53.10,0:11:01.06,Default,,0000,0000,0000,,nobody has done it yet. So old boot files\Nare decrypted at boot by the previous Dialogue: 0,0:11:01.06,0:11:09.61,Default,,0000,0000,0000,,bootloader. And before the iPhone 4s you\Ncould actually just talk to the hardware Dialogue: 0,0:11:09.61,0:11:15.08,Default,,0000,0000,0000,,iOS engine as soon as you got kernel-level\Ncode execution. But with the iPhone 4s Dialogue: 0,0:11:15.08,0:11:19.47,Default,,0000,0000,0000,,they introduced a feature where before the\Nkernel would boot they would shut off the Dialogue: 0,0:11:19.47,0:11:25.87,Default,,0000,0000,0000,,iOS engine by hardware, so there is no way\Nto decrypt bootloader files anymore so Dialogue: 0,0:11:25.87,0:11:33.02,Default,,0000,0000,0000,,easily unless you got code execution in\Nthe bootloader itself. So decrypting Dialogue: 0,0:11:33.02,0:11:38.72,Default,,0000,0000,0000,,bootloaders is a struggle from now on. So\NI think kind of because of that the Dialogue: 0,0:11:38.72,0:11:44.81,Default,,0000,0000,0000,,attention shifted to userland and from now\Nthe jailbreaks kind of had to be Dialogue: 0,0:11:44.81,0:11:50.57,Default,,0000,0000,0000,,untethered. So untethered here means that\Nif you jailbreak your device, you turn it Dialogue: 0,0:11:50.57,0:11:55.82,Default,,0000,0000,0000,,off, you boot it again, then the device is\Nstill jailbroken, and this is usually Dialogue: 0,0:11:55.82,0:12:01.09,Default,,0000,0000,0000,,achieved through re-exploitation at some\Npoint in the boot process. So you can't Dialogue: 0,0:12:01.09,0:12:05.53,Default,,0000,0000,0000,,just patch the kernel on file system\Nbecause that would invalidate signatures, Dialogue: 0,0:12:05.53,0:12:09.94,Default,,0000,0000,0000,,so instead you would, I don't know, add\Nsome configuration files to some demons Dialogue: 0,0:12:09.94,0:12:16.08,Default,,0000,0000,0000,,which would trigger bugs and then exploit.\NSo jailbreaks then chained many bugs Dialogue: 0,0:12:16.08,0:12:21.25,Default,,0000,0000,0000,,together, sometimes six or more bugs to \Nget initial code execution, kernel code Dialogue: 0,0:12:21.25,0:12:28.08,Default,,0000,0000,0000,,execution and persistence. This somewhat\Nchanged when Apple introduced free Dialogue: 0,0:12:28.08,0:12:33.76,Default,,0000,0000,0000,,developer accounts around the time they\Nreleased iOS 9. So these developer Dialogue: 0,0:12:33.76,0:12:38.95,Default,,0000,0000,0000,,accounts allow everybody who has an Apple\NID to get a valid signing certificate for Dialogue: 0,0:12:38.95,0:12:44.97,Default,,0000,0000,0000,,seven days for free. So you can actually\Ncreate an XCode project and run your app Dialogue: 0,0:12:44.97,0:12:49.94,Default,,0000,0000,0000,,on your physical device. Before that that\Nwas not possible, so the only way to run Dialogue: 0,0:12:49.94,0:12:56.40,Default,,0000,0000,0000,,your own code on your device was to buy a\Npaid developer account which is 100$ per Dialogue: 0,0:12:56.40,0:13:03.15,Default,,0000,0000,0000,,year if you a buy personal developer\Naccount. But now you can just get that for Dialogue: 0,0:13:03.15,0:13:07.67,Default,,0000,0000,0000,,free. And after seven days the certificate\Nexpires, but you can just, for free, Dialogue: 0,0:13:07.67,0:13:12.04,Default,,0000,0000,0000,,request another one and keep doing that.\NWhich is totally enough if you develop Dialogue: 0,0:13:12.04,0:13:18.54,Default,,0000,0000,0000,,apps. So this kind of led to semi-\Nuntethered jailbreaks because initial code Dialogue: 0,0:13:18.54,0:13:21.74,Default,,0000,0000,0000,,execution was not an issue anymore.\NAnybody could just get that free Dialogue: 0,0:13:21.74,0:13:28.56,Default,,0000,0000,0000,,certificate, sign apps and run some kind\Nof code that was sandboxed. So jailbreak Dialogue: 0,0:13:28.56,0:13:36.35,Default,,0000,0000,0000,,focus shifted to more powerful kernel bugs\Nwhich were reachable from sandbox. So we Dialogue: 0,0:13:36.35,0:13:40.81,Default,,0000,0000,0000,,had jailbreaks using just one single bug\Nor maybe just two bugs and the jailbreaks Dialogue: 0,0:13:40.81,0:13:46.63,Default,,0000,0000,0000,,then were distributed as an IPA, which is\Nan installable app people would download, Dialogue: 0,0:13:46.63,0:13:53.49,Default,,0000,0000,0000,,sign themselves, put on the phone and just\Nrun the app. So semi-untethered means Dialogue: 0,0:13:53.49,0:13:59.64,Default,,0000,0000,0000,,you can reboot into non-jailbroken mode,\Nhowever you can get to jailbroken mode Dialogue: 0,0:13:59.64,0:14:06.37,Default,,0000,0000,0000,,easily by just pressing an app. And over\Nthe years Apple stepped up its game Dialogue: 0,0:14:06.37,0:14:13.83,Default,,0000,0000,0000,,constantly. So with iOS 5 they introduced\NASLR address space layer randomisation, Dialogue: 0,0:14:13.83,0:14:21.31,Default,,0000,0000,0000,,with iOS 6 they added kernel ASLR, with\Nthe introduction of the iPhone 5, as they Dialogue: 0,0:14:21.31,0:14:27.95,Default,,0000,0000,0000,,added 64bit CPUs, which isn't really a\Nsecurity mitigation, it just changed a bit Dialogue: 0,0:14:27.95,0:14:37.63,Default,,0000,0000,0000,,how you would exploit. So the real deal\Nstarted to come with iOS 9, where they Dialogue: 0,0:14:37.63,0:14:42.69,Default,,0000,0000,0000,,first introduced Kernel Patch Protection,\Nan attempt to make the kernel immutable Dialogue: 0,0:14:42.69,0:14:50.11,Default,,0000,0000,0000,,and not patchable. And they stepped up that \Nwith the iPhone 7 where they introduced Dialogue: 0,0:14:50.11,0:14:57.55,Default,,0000,0000,0000,,Kernel Text Readonly Region, also known as\NKTRR. So with iOS 11 they removed 32bit Dialogue: 0,0:14:57.55,0:15:03.46,Default,,0000,0000,0000,,libraries, which I think has very little\Nto no impact on exploitation; it's mainly Dialogue: 0,0:15:03.46,0:15:09.70,Default,,0000,0000,0000,,in the list because up to that point Cydia\Nwas compiled as a 32bit binary and that Dialogue: 0,0:15:09.70,0:15:17.72,Default,,0000,0000,0000,,stopped working, that's why that had to be\Nrecompiled for 64bit, which took someone Dialogue: 0,0:15:17.72,0:15:26.04,Default,,0000,0000,0000,,to do until you could get a working Cydia\Non 64bits iOS 11. So with the iPhone Xs Dialogue: 0,0:15:26.04,0:15:30.99,Default,,0000,0000,0000,,which came out just recently they\Nintroduced Pointer Authentication Codes, Dialogue: 0,0:15:30.99,0:15:35.39,Default,,0000,0000,0000,,and I'm gonna go more in detail into these\Nhardware mitigations in the next few Dialogue: 0,0:15:35.39,0:15:42.08,Default,,0000,0000,0000,,slides. So let's start with Kernel Patch\NProtection. So when people say KPP, they Dialogue: 0,0:15:42.08,0:15:47.52,Default,,0000,0000,0000,,usually refer to what Apple calls\Nwatchtower. So watchtower, as the name Dialogue: 0,0:15:47.52,0:15:53.77,Default,,0000,0000,0000,,suggests, watches over the kernel and\Npanics when modifications are detected, Dialogue: 0,0:15:53.77,0:15:58.86,Default,,0000,0000,0000,,and it prevents the kernel from being\Npatched. At least that's the idea of it. Dialogue: 0,0:15:58.86,0:16:03.07,Default,,0000,0000,0000,,It doesn't really prevent it because it's\Nbroken but when they engineered it, it Dialogue: 0,0:16:03.07,0:16:08.69,Default,,0000,0000,0000,,should prevent you from patching the\Nkernel. So how does it work? Watchtower is Dialogue: 0,0:16:08.69,0:16:13.30,Default,,0000,0000,0000,,a piece of software which runs in EL3\Nwhich is the ARM exception level 3. Dialogue: 0,0:16:13.30,0:16:18.71,Default,,0000,0000,0000,,So exception levels are kind of privilege\Nseparations while 3 is the highest and 0 Dialogue: 0,0:16:18.71,0:16:24.52,Default,,0000,0000,0000,,is the lowest. And you can kind of trigger\Nan exception to call handler code in Dialogue: 0,0:16:24.52,0:16:31.46,Default,,0000,0000,0000,,higher levels. So the idea of watchtowers\Nthat recurring events which is FPU usage Dialogue: 0,0:16:31.46,0:16:35.72,Default,,0000,0000,0000,,trigger Watchtower inspection of the\Nkernel, and you cannot really turn it off Dialogue: 0,0:16:35.72,0:16:41.82,Default,,0000,0000,0000,,because you do need the FPU. So if you\Npicture how it looks like, we have the Dialogue: 0,0:16:41.82,0:16:46.92,Default,,0000,0000,0000,,Watchtower to the left (which totally\Nlooks like a lighthouse) and the Dialogue: 0,0:16:46.92,0:16:51.15,Default,,0000,0000,0000,,applications at the right. So in the\Nmiddle, in EL1, we have the kernel and Dialogue: 0,0:16:51.15,0:17:00.72,Default,,0000,0000,0000,,recent studies revealed that this is\Nexactly how the XNU kernel looks like. So Dialogue: 0,0:17:00.72,0:17:06.06,Default,,0000,0000,0000,,how can we be worse? An event occurs from\Ntime to time which is from using userland Dialogue: 0,0:17:06.06,0:17:11.11,Default,,0000,0000,0000,,application, for example JavaScript makes\Nheavy use of floating points, and the Dialogue: 0,0:17:11.11,0:17:15.93,Default,,0000,0000,0000,,event would then go to the kernel and the\Nkernel would then trigger Watchtower as it Dialogue: 0,0:17:15.93,0:17:24.05,Default,,0000,0000,0000,,tries to enable the FPU. Watchtower would\Nscan the kernel and then if everything is Dialogue: 0,0:17:24.05,0:17:28.71,Default,,0000,0000,0000,,fine it would transition execution back\Ninto the kernel which then in turn would Dialogue: 0,0:17:28.71,0:17:36.01,Default,,0000,0000,0000,,transition back into userspace which can\Nthen use the FPU. However with a modified Dialogue: 0,0:17:36.01,0:17:41.97,Default,,0000,0000,0000,,kernel, when Watchtower scans the kernel\Nand detects modification, it would just Dialogue: 0,0:17:41.97,0:17:48.94,Default,,0000,0000,0000,,panic. So the idea is that the kernel is\Nforced to call Watchtower because the FPU Dialogue: 0,0:17:48.94,0:17:54.13,Default,,0000,0000,0000,,is blocked otherwise. But the problem at\Nthe same time is that the kernel is in Dialogue: 0,0:17:54.13,0:18:00.48,Default,,0000,0000,0000,,control before it calls watchtower. And\Nthis thing was fully defeated by qwerty in Dialogue: 0,0:18:00.48,0:18:09.72,Default,,0000,0000,0000,,yalu102. So how qwerty's KPP bypass works:\NThe idea is: you copy the kernel in memory Dialogue: 0,0:18:09.72,0:18:15.86,Default,,0000,0000,0000,,and you mody the copied kernel. Then you\Nwould modify the page tables to use the Dialogue: 0,0:18:15.86,0:18:23.98,Default,,0000,0000,0000,,patched kernel. And whenever the FPU\Ntriggers a Watchtower inspection, before Dialogue: 0,0:18:23.98,0:18:29.54,Default,,0000,0000,0000,,actually calling Watchtower you would\Nswitch back to the unmodified kernel and Dialogue: 0,0:18:29.54,0:18:34.06,Default,,0000,0000,0000,,then let it run, let it check the\Nunmodified kernel when that returns you Dialogue: 0,0:18:34.06,0:18:39.91,Default,,0000,0000,0000,,would go back to the modified kernel. So\Nthis one it looks like: we copy the kernel Dialogue: 0,0:18:39.91,0:18:47.13,Default,,0000,0000,0000,,in memory, we patch the modified copy, we\Nswitch the page tables to actually use the Dialogue: 0,0:18:47.13,0:18:53.67,Default,,0000,0000,0000,,modified copy and when we have the FPU\Nevent it would just switch the page tables Dialogue: 0,0:18:53.67,0:19:00.19,Default,,0000,0000,0000,,back, forward the call to Watchtower, make\Nthen watch tower scan the unmodified Dialogue: 0,0:19:00.19,0:19:08.49,Default,,0000,0000,0000,,kernel and after the scan we would just\Nreturn to the patched kernel. So the Dialogue: 0,0:19:08.49,0:19:13.82,Default,,0000,0000,0000,,problem here is: Time of check – Time of\NUse, the classical TOCTOU. And this works Dialogue: 0,0:19:13.82,0:19:20.37,Default,,0000,0000,0000,,on the iPhone 5s, the iPhone 6 and the\NiPhone 6s and it's not really patchable. Dialogue: 0,0:19:20.37,0:19:27.13,Default,,0000,0000,0000,,However, with the iPhone 7, Apple\Nintroduced KTRR, which kind of proves that Dialogue: 0,0:19:27.13,0:19:34.70,Default,,0000,0000,0000,,and they really managed to do an\Nunpatchable kernel. So how does KTRR work? Dialogue: 0,0:19:34.70,0:19:40.58,Default,,0000,0000,0000,,So Kernel Text Readonly Region, I'm going\Nto present as described by Siguza in his Dialogue: 0,0:19:40.58,0:19:49.06,Default,,0000,0000,0000,,blog, adds an extra memory controller\Nwhich is the AMCC which traps all writes to Dialogue: 0,0:19:49.06,0:19:56.75,Default,,0000,0000,0000,,the read-only region. And there's extra CPU\Nregisters which mark and executable range Dialogue: 0,0:19:56.75,0:20:02.52,Default,,0000,0000,0000,,which are the KTRR registers and they\Nobviously mark a subsection of the Dialogue: 0,0:20:02.52,0:20:08.72,Default,,0000,0000,0000,,read-only region, so you have hardware\Nenforcement at boot time for read-only Dialogue: 0,0:20:08.72,0:20:15.35,Default,,0000,0000,0000,,memory region and hardware enforcement at\Nboot-time for an executable memory region. Dialogue: 0,0:20:15.68,0:20:21.35,Default,,0000,0000,0000,,So this the CPU. This is the memory at the\Nbottom. You would set the read-only region Dialogue: 0,0:20:21.35,0:20:26.32,Default,,0000,0000,0000,,at boot and since that's enforced by the\Nhardware memory controller everything Dialogue: 0,0:20:26.32,0:20:32.47,Default,,0000,0000,0000,,inside that region is not writable and\Neverything outside that region is Dialogue: 0,0:20:32.47,0:20:40.85,Default,,0000,0000,0000,,writable. And the CPU got KTRR registers\Nwhich mark begin and end. So the Dialogue: 0,0:20:40.85,0:20:46.81,Default,,0000,0000,0000,,executable region is a subsection of the\Nread-only region. Everything outside there Dialogue: 0,0:20:46.81,0:20:52.25,Default,,0000,0000,0000,,cannot be executed by the CPU. Everything\Ninside the read-only region cannot be Dialogue: 0,0:20:52.25,0:20:58.68,Default,,0000,0000,0000,,modified. And this has not been truly\Nbypassed yet. There's been a bypass but Dialogue: 0,0:20:58.68,0:21:04.41,Default,,0000,0000,0000,,that actually targeted how that thing gets\Nset up. But that's fakes and now it's Dialogue: 0,0:21:04.41,0:21:11.00,Default,,0000,0000,0000,,probably setting up everything and so far\Nit hasn't been bypassed. So jailbreaks are Dialogue: 0,0:21:11.00,0:21:15.71,Default,,0000,0000,0000,,still around. So what are they doing?\NWell, they just walk around kernel patches Dialogue: 0,0:21:15.71,0:21:22.60,Default,,0000,0000,0000,,and this is when KPP jailbreaks evolved. \NWhich means, they just don't patch Dialogue: 0,0:21:22.60,0:21:28.33,Default,,0000,0000,0000,,the kernel. But before we dive into that,\Nlet's take a look what previous jailbreaks Dialogue: 0,0:21:28.33,0:21:35.03,Default,,0000,0000,0000,,actually did patch in the kernel. So the\Ngeneral goals are to disable code signing Dialogue: 0,0:21:35.03,0:21:41.46,Default,,0000,0000,0000,,to disable the sandbox to make the root\Nfile system writable to somehow make Dialogue: 0,0:21:41.46,0:21:46.95,Default,,0000,0000,0000,,tweaks work which involves making mobile\Nsubstrate or libsubstitute work which is Dialogue: 0,0:21:46.95,0:21:53.65,Default,,0000,0000,0000,,the library for hooking. And I was about\Nto make a list of kernel patches which you Dialogue: 0,0:21:53.65,0:22:00.22,Default,,0000,0000,0000,,could simply apply, however, the\Ntechniques and patches vary across Dialogue: 0,0:22:00.22,0:22:03.75,Default,,0000,0000,0000,,individual jailbreaks so much that I\Ncouldn't even come up with the list of Dialogue: 0,0:22:03.75,0:22:09.57,Default,,0000,0000,0000,,kernel patches among the different\Njailbreaks I worked on. So there's no Dialogue: 0,0:22:09.57,0:22:13.43,Default,,0000,0000,0000,,general set of patches, some prefer to do\Nit that way, some prefer to do it that Dialogue: 0,0:22:13.43,0:22:18.97,Default,,0000,0000,0000,,way. So instead of doing a kind of full\Nlist, I'll just show you what the Helix Dialogue: 0,0:22:18.97,0:22:24.34,Default,,0000,0000,0000,,jailbreak does patch. So the Helix\Njailbreak first patches the Dialogue: 0,0:22:24.34,0:22:30.41,Default,,0000,0000,0000,,i_can_has_debugger, which is a boot arc.\NIt's a variable in the kernel and if you Dialogue: 0,0:22:30.41,0:22:36.30,Default,,0000,0000,0000,,set that to true that would relax the\Nsandbox. So to relax the sandbox or to Dialogue: 0,0:22:36.30,0:22:42.05,Default,,0000,0000,0000,,disable code signing usually involves\Nmultiple steps. Also since iOS 7 you need Dialogue: 0,0:22:42.05,0:22:48.45,Default,,0000,0000,0000,,to patch mount because there's actual\Nhardcoded that the root filesystem cannot Dialogue: 0,0:22:48.45,0:22:54.54,Default,,0000,0000,0000,,be mounted as read-write. Since iOS 10.3,\Nthere is also hardcoded that you cannot Dialogue: 0,0:22:54.54,0:22:59.49,Default,,0000,0000,0000,,mount the root filesystem without the\Nnosuid flag, so you probably want to patch Dialogue: 0,0:22:59.49,0:23:04.54,Default,,0000,0000,0000,,that out as well. And then if you patch\Nboth these you can remount the root Dialogue: 0,0:23:04.54,0:23:09.28,Default,,0000,0000,0000,,filesystem as read-and-write, however you\Ncannot actually write to the files on the Dialogue: 0,0:23:09.28,0:23:14.42,Default,,0000,0000,0000,,root filesystem unless you patch Light-\NWeight Volume Manager which you also only Dialogue: 0,0:23:14.42,0:23:21.22,Default,,0000,0000,0000,,need to do in iOS 9 up to iOS 10.3. Later\Nwhen they switched to APFS you don't Dialogue: 0,0:23:21.22,0:23:27.78,Default,,0000,0000,0000,,actually need that anymore. Also there's a\Nvariable called proc_enforce. You set that Dialogue: 0,0:23:27.78,0:23:34.15,Default,,0000,0000,0000,,to 0 to disable code signing which is one\Nof the things you need to do to disable Dialogue: 0,0:23:34.15,0:23:43.09,Default,,0000,0000,0000,,code signing. Another flag is\Ncs_enforcement_disable, set that to 1 to Dialogue: 0,0:23:43.09,0:23:50.55,Default,,0000,0000,0000,,disable code signing. So amfi, which is\NApple mobile file integrity is a kext which Dialogue: 0,0:23:50.55,0:23:59.52,Default,,0000,0000,0000,,handles the code signing checks. In that \Nkext it imports the mem-copy function. Dialogue: 0,0:23:59.52,0:24:05.40,Default,,0000,0000,0000,,So there's a stub and one of the patches\Nis to patch that stub to always return 0 Dialogue: 0,0:24:05.40,0:24:10.50,Default,,0000,0000,0000,,by some simple gadget. So what this does\Nis, whenever it compares something in a Dialogue: 0,0:24:10.50,0:24:16.37,Default,,0000,0000,0000,,code, it would just always compare… say\Nthat the compare succeeds and is equal. Dialogue: 0,0:24:16.37,0:24:21.98,Default,,0000,0000,0000,,I'm not entirely sure what it does,\Nso this patch dates back to Yalu Dialogue: 0,0:24:21.98,0:24:24.01,Default,,0000,0000,0000,,but like just supplying that patch helps Dialogue: 0,0:24:24.01,0:24:29.82,Default,,0000,0000,0000,,killing code signing, so that's why it's\Nin there. Another thing h3lix does is, it Dialogue: 0,0:24:29.82,0:24:36.01,Default,,0000,0000,0000,,adds the get-task-allow entitlement to\Nevery process and this is for allowing Dialogue: 0,0:24:36.01,0:24:41.19,Default,,0000,0000,0000,,read/ write/executable mappings and this\Nis what you want for a mobile substrate Dialogue: 0,0:24:41.19,0:24:46.45,Default,,0000,0000,0000,,tweaks. So initially this entitlement \Nis used for debugging because Dialogue: 0,0:24:46.45,0:24:52.70,Default,,0000,0000,0000,,there you also need to be able to modify\Ncode at runtime for setting breakpoints Dialogue: 0,0:24:52.70,0:24:59.58,Default,,0000,0000,0000,,while we use it for getting tweaks to\Nwork. Since iOS 10.3 there's... h3lix also Dialogue: 0,0:24:59.58,0:25:07.11,Default,,0000,0000,0000,,patches label_update_execve patch...\Nlabel_update_execve function. So the idea Dialogue: 0,0:25:07.11,0:25:11.88,Default,,0000,0000,0000,,of that patch was to fix the "process-exec\Ndenied while updating label" error message Dialogue: 0,0:25:11.88,0:25:17.39,Default,,0000,0000,0000,,in Cydia and several other processes. Well\Nthat seems to completely nuke the sandbox Dialogue: 0,0:25:17.39,0:25:22.89,Default,,0000,0000,0000,,and also break sandbox containers so this\Nis also the reason why if you're Dialogue: 0,0:25:22.89,0:25:28.09,Default,,0000,0000,0000,,jailbreaking with h3lix apps would save\Ntheir data in the global directory instead Dialogue: 0,0:25:28.09,0:25:33.35,Default,,0000,0000,0000,,of their sandbox containers. And you also\Nkill a bunch of checks in Dialogue: 0,0:25:33.35,0:25:40.65,Default,,0000,0000,0000,,map_ops_policy... mac_policy_ops to relax\Nthe sandbox. So if you want to check out Dialogue: 0,0:25:40.65,0:25:45.43,Default,,0000,0000,0000,,how that works yourself, unfortunately\Nh3lix itself is not open-source and I've Dialogue: 0,0:25:45.43,0:25:50.41,Default,,0000,0000,0000,,no plans of open-sourcing that. But\Nthere's two very very closely related Dialogue: 0,0:25:50.41,0:25:55.96,Default,,0000,0000,0000,,projects which are open-source which is\NdoubleH3lix – this is pretty much exactly Dialogue: 0,0:25:55.96,0:26:03.98,Default,,0000,0000,0000,,the same but for 64 bit devices which\Ndoes include the KPP bypass, so it also Dialogue: 0,0:26:03.98,0:26:11.41,Default,,0000,0000,0000,,patches the kernel – and jelbrekTime,\Nwhich is the watchOS jailbreak. But h3lix Dialogue: 0,0:26:11.41,0:26:17.85,Default,,0000,0000,0000,,is for iOS 10 and the watchOS jailbreak is\Nkind of the iOS 11 equivalent but it Dialogue: 0,0:26:17.85,0:26:21.95,Default,,0000,0000,0000,,shares like most of the code. So most of\Nthe patch code is the same if you want to Dialogue: 0,0:26:21.95,0:26:29.00,Default,,0000,0000,0000,,check that out. Check these out. So,\NKPPless jailbreaks. So the idea is, don't Dialogue: 0,0:26:29.00,0:26:35.23,Default,,0000,0000,0000,,patch the kernel code but instead patch\Nthe data. So for an example we go for Dialogue: 0,0:26:35.23,0:26:39.37,Default,,0000,0000,0000,,remounting root file system. We know we\Nhave hardcoded checks which forbid us to Dialogue: 0,0:26:39.37,0:26:44.54,Default,,0000,0000,0000,,mount the root file system read/write. But\Nwhat we can do is in the kernel there's Dialogue: 0,0:26:44.54,0:26:49.11,Default,,0000,0000,0000,,this structure representing the root file\Nsystem and we can patch that structure Dialogue: 0,0:26:49.11,0:26:54.02,Default,,0000,0000,0000,,removing the flag saying that this\Nstructure represents the root file system. Dialogue: 0,0:26:54.02,0:27:00.21,Default,,0000,0000,0000,,And we simply remove that and then we can\Ncall remount on the root file system and Dialogue: 0,0:27:00.21,0:27:05.85,Default,,0000,0000,0000,,then we put back in the flag. So we kind\Nof bypass the hardcoded check. For Dialogue: 0,0:27:05.85,0:27:12.62,Default,,0000,0000,0000,,disabling code signing and disabling\Nsandbox there are several approaches. Dialogue: 0,0:27:12.62,0:27:17.17,Default,,0000,0000,0000,,In the kernel there's a trust cache so\Nusually amfi handles the code signing. Dialogue: 0,0:27:17.17,0:27:21.28,Default,,0000,0000,0000,,The demon in userspace handles the code\Nsigning requests. But the demon itself Dialogue: 0,0:27:21.28,0:27:25.27,Default,,0000,0000,0000,,also needs to be code-signed. So you have\Nthe chicken and egg problem. That's why in Dialogue: 0,0:27:25.27,0:27:31.39,Default,,0000,0000,0000,,the kernel there is a list of hashes of\Nbinaries which are allowed to execute. And Dialogue: 0,0:27:31.39,0:27:35.41,Default,,0000,0000,0000,,this thing is actually writable because\Nwhen you mount the developer disk image it Dialogue: 0,0:27:35.41,0:27:40.92,Default,,0000,0000,0000,,actually adds some debugging things to it\Nso you can simply inject your own hash Dialogue: 0,0:27:40.92,0:27:46.78,Default,,0000,0000,0000,,into the trust cache making the binary\Ntrusted. Another approach taken by Dialogue: 0,0:27:46.78,0:27:51.83,Default,,0000,0000,0000,,jailbreakd and the latest electro\Njailbreak is to have a process, in this Dialogue: 0,0:27:51.83,0:27:58.07,Default,,0000,0000,0000,,case jailbreakd, which would patch the\Nprocesses on creation, so when you spawn a Dialogue: 0,0:27:58.07,0:28:03.89,Default,,0000,0000,0000,,process that thing would immediately stop\Nthe process, go into the kernel, look up Dialogue: 0,0:28:03.89,0:28:10.62,Default,,0000,0000,0000,,the structure and remove the flags\Nsaying "kill this process when the cold Dialogue: 0,0:28:10.62,0:28:15.81,Default,,0000,0000,0000,,signature becomes involved" and it will\Ninvalid. And it would also add the Dialogue: 0,0:28:15.81,0:28:20.81,Default,,0000,0000,0000,,get-task-low entitlements. And then after \Nit's done that it would resume the process Dialogue: 0,0:28:20.81,0:28:25.85,Default,,0000,0000,0000,,and then the process won't get killed any \Nmore because it's kind of already trusted. Dialogue: 0,0:28:25.85,0:28:33.45,Default,,0000,0000,0000,,And the third approach taken or demoed by\Nbazad was to take over amfid and userspace Dialogue: 0,0:28:33.45,0:28:41.21,Default,,0000,0000,0000,,completely. So if you can get a Mac port\Nto launchd or to amfid you can impersonate Dialogue: 0,0:28:41.21,0:28:47.34,Default,,0000,0000,0000,,that and whenever the kernel asks and\Nfeels that it's trusted you would reply Dialogue: 0,0:28:47.34,0:28:51.19,Default,,0000,0000,0000,,"Okay yeah that's trusted that's fine\Nyou can run it" so that way you don't need Dialogue: 0,0:28:51.19,0:28:59.51,Default,,0000,0000,0000,,to go for the kernel at all. So future\Njailbreaks. Kernel patches are not really Dialogue: 0,0:28:59.51,0:29:04.88,Default,,0000,0000,0000,,possible anymore and they're not even\Nrequired. Because we can still patch the Dialogue: 0,0:29:04.88,0:29:13.08,Default,,0000,0000,0000,,kernel data or not go for the kernel at\Nall. But we're still not done yet, we Dialogue: 0,0:29:13.08,0:29:21.64,Default,,0000,0000,0000,,still didn't go for Post-Apocalyptic\Nor short PAC. Well actually Dialogue: 0,0:29:21.64,0:29:25.04,Default,,0000,0000,0000,,PAC stands for pointer authentication\Ncodes but you get the joke. Dialogue: 0,0:29:25.04,0:29:30.59,Default,,0000,0000,0000,,So pointer authentication codes were\Nintroduced with the iPhone Xs and if we Dialogue: 0,0:29:30.59,0:29:36.53,Default,,0000,0000,0000,,quote Qualcomm "This is a stronger version\Noff stack protection". And pointer Dialogue: 0,0:29:36.53,0:29:41.81,Default,,0000,0000,0000,,authentication codes are similar to\Nmessage authentication codes but for Dialogue: 0,0:29:41.81,0:29:47.49,Default,,0000,0000,0000,,pointers, if you are familiar with that.\NAnd the idea of that is to protect data in Dialogue: 0,0:29:47.49,0:29:55.39,Default,,0000,0000,0000,,memory in relation to context with a\Nsecret key. So the data in memory could be Dialogue: 0,0:29:55.39,0:30:00.87,Default,,0000,0000,0000,,the return value and the context could be\Nthe stack pointer or data in memory could Dialogue: 0,0:30:00.87,0:30:07.75,Default,,0000,0000,0000,,be a function pointer and the context\Ncould be a vtable. So if we take a look Dialogue: 0,0:30:07.75,0:30:14.65,Default,,0000,0000,0000,,how PAC is implemented. So at the left you\Ncan see function entry and like function Dialogue: 0,0:30:14.65,0:30:19.74,Default,,0000,0000,0000,,prologue and function epilogue without PAC\Nand with PAC the only thing that would be Dialogue: 0,0:30:19.74,0:30:27.14,Default,,0000,0000,0000,,changed is when you enter a function\Nbefore actually doing anything inside it, Dialogue: 0,0:30:27.14,0:30:31.98,Default,,0000,0000,0000,,you would normally store the return value\Non the stack but when doing that you would Dialogue: 0,0:30:31.98,0:30:39.30,Default,,0000,0000,0000,,first authenticate the pointer with the\Ncontext and then kinda create the Dialogue: 0,0:30:39.30,0:30:44.36,Default,,0000,0000,0000,,signature and store it inside the pointer\Nand then put it on the stack. And then Dialogue: 0,0:30:44.36,0:30:49.55,Default,,0000,0000,0000,,when you leave the function you would just\Ntake back the pointer, again calculate the Dialogue: 0,0:30:49.55,0:30:56.43,Default,,0000,0000,0000,,signature and see if these both signatures\Nmatches and if they do then just return Dialogue: 0,0:30:56.43,0:31:03.98,Default,,0000,0000,0000,,and if the signature's invalid you would\Njust throw a hardware fault. So this is Dialogue: 0,0:31:03.98,0:31:10.65,Default,,0000,0000,0000,,how it looks like for 64-bit pointers. You\Ndon't really use all of the available bits. Dialogue: 0,0:31:10.65,0:31:16.82,Default,,0000,0000,0000,,So usually you use 48 bits for\Nvirtual memory which is more than enough. Dialogue: 0,0:31:16.82,0:31:22.20,Default,,0000,0000,0000,,If you use memory tagging\Nyou have seven bits left for putting in Dialogue: 0,0:31:22.20,0:31:28.99,Default,,0000,0000,0000,,the signature or if you do not use memory\Ntagging you can use up to 15 bits for the Dialogue: 0,0:31:28.99,0:31:39.85,Default,,0000,0000,0000,,pointer authentication code. So the basic\Nidea of PAC is to kill ROP like code reuse Dialogue: 0,0:31:39.85,0:31:46.40,Default,,0000,0000,0000,,attacks. You cannot simply smash the stack\Nand create a ROP chain because every Dialogue: 0,0:31:46.40,0:31:53.90,Default,,0000,0000,0000,,return would have an instruction verifying\Nthe signature of the return value and that Dialogue: 0,0:31:53.90,0:32:00.58,Default,,0000,0000,0000,,means you would need to sign everything,\Nevery single of these pointers and since Dialogue: 0,0:32:00.58,0:32:07.10,Default,,0000,0000,0000,,you don't know the key you can't do that\Nin advance. So you cannot modify a return Dialogue: 0,0:32:07.10,0:32:12.05,Default,,0000,0000,0000,,value and you cannot swap two signed\Nvalues on the stack unless the stack Dialogue: 0,0:32:12.05,0:32:22.68,Default,,0000,0000,0000,,pointer is the same for both. Can we\Nbypass it? Maybe. I don't know. But we can Dialogue: 0,0:32:22.69,0:32:29.48,Default,,0000,0000,0000,,take a look at how that thing is\Nimplemented. So if we take a look at the Dialogue: 0,0:32:29.48,0:32:35.79,Default,,0000,0000,0000,,ARM slides you can see that PAC is\Nbasically derived from a pointer and a Dialogue: 0,0:32:35.79,0:32:41.66,Default,,0000,0000,0000,,64-bit context value and the key and we\Nput all of that in the algorithm P. And Dialogue: 0,0:32:41.66,0:32:48.23,Default,,0000,0000,0000,,that gives us the PAC which we store in\Nthe unused bits. So the algorithm P can Dialogue: 0,0:32:48.23,0:32:56.45,Default,,0000,0000,0000,,either be QARMA or it can be something\Ncompletely custom. And the instructions, Dialogue: 0,0:32:56.45,0:33:03.42,Default,,0000,0000,0000,,the ARM instructions, kind of hide the\Nimplementation details. So if you would go Dialogue: 0,0:33:03.42,0:33:11.35,Default,,0000,0000,0000,,for attacking PAC, there's two ways of\Nattack strategies. We can either try and Dialogue: 0,0:33:11.35,0:33:16.14,Default,,0000,0000,0000,,go straight for the cryptographic\Nprimitive like take a look what cipher it Dialogue: 0,0:33:16.14,0:33:22.42,Default,,0000,0000,0000,,is or how that cipher is implemented.\NMaybe it's weak or we can go and attack Dialogue: 0,0:33:22.42,0:33:29.03,Default,,0000,0000,0000,,the implementation. So if we go and attack\Nthe implementation we could look for Dialogue: 0,0:33:29.03,0:33:35.38,Default,,0000,0000,0000,,signing primitives, which could be like\Nsmall gadgets we could jump to somehow, Dialogue: 0,0:33:35.38,0:33:42.50,Default,,0000,0000,0000,,somehow execute to sign a value which\Ncould be either an arbitrary context Dialogue: 0,0:33:42.50,0:33:50.37,Default,,0000,0000,0000,,signing gadget or maybe a fixed context\Nsigning gadget. We could also look for Dialogue: 0,0:33:50.37,0:33:56.64,Default,,0000,0000,0000,,unauthenticated code, for example I\Nimagine the code which sets up PAC itself Dialogue: 0,0:33:56.64,0:34:03.53,Default,,0000,0000,0000,,is probably not protected by PAC because\Nyou can't sign the pointer if the key is Dialogue: 0,0:34:03.53,0:34:08.90,Default,,0000,0000,0000,,not set up yet. Maybe that code is still\Naccessible. We could look for something Dialogue: 0,0:34:08.90,0:34:17.72,Default,,0000,0000,0000,,like that. We could also try to replace\Npointers which share the same context. Dialogue: 0,0:34:17.72,0:34:23.71,Default,,0000,0000,0000,,It's probably not feasible for return\Nvalues on the stack, but maybe it's Dialogue: 0,0:34:23.71,0:34:30.09,Default,,0000,0000,0000,,feasible for swapping pointers in the\Nvtable. Or maybe you come up with your own Dialogue: 0,0:34:30.09,0:34:37.05,Default,,0000,0000,0000,,clever idea how to bypass that. These are\Njust like some ideas. So I want to make a Dialogue: 0,0:34:37.05,0:34:44.64,Default,,0000,0000,0000,,point here, that in my opinion it doesn't\Nmake much sense to try to attack the Dialogue: 0,0:34:44.64,0:34:51.55,Default,,0000,0000,0000,,underlying cryptography on PAC, so I think\Nthat if we go for attacking PAC it makes Dialogue: 0,0:34:51.55,0:34:56.33,Default,,0000,0000,0000,,much more sense to look for implementation\Nattacks and not attacking the cryptography Dialogue: 0,0:34:56.33,0:35:04.29,Default,,0000,0000,0000,,and the next few slides are just there to\Nexplain why I think that. So if we take a Dialogue: 0,0:35:04.29,0:35:10.31,Default,,0000,0000,0000,,look at QARMA which was proposed by ARM as\Nbeing one of the possible ways of Dialogue: 0,0:35:10.31,0:35:16.75,Default,,0000,0000,0000,,implementing PAC. PAC, uhm, QARMA is a\Ntweakable block cipher, so it takes an Dialogue: 0,0:35:16.75,0:35:22.86,Default,,0000,0000,0000,,input, a tweak and gives you an output.\NWhich kind of fits perfectly for what we Dialogue: 0,0:35:22.86,0:35:30.39,Default,,0000,0000,0000,,want. And then I started looking at QARMA\Nand came up with ideas on how are you Dialogue: 0,0:35:30.39,0:35:35.78,Default,,0000,0000,0000,,could maybe attack that cipher. At some\Npoint I realized that practical crypto Dialogue: 0,0:35:35.78,0:35:42.55,Default,,0000,0000,0000,,attacks on QARMA if there will be any in\Nthe future will probably that's what I Dialogue: 0,0:35:42.55,0:35:51.14,Default,,0000,0000,0000,,think completely irrelevant to the PAC\Nsecurity. So why's that? If we define – Dialogue: 0,0:35:51.14,0:35:55.35,Default,,0000,0000,0000,,So just so you know, the next few slides\NI'm going to bore you with some math but Dialogue: 0,0:35:55.35,0:36:03.51,Default,,0000,0000,0000,,it's not too complex. So if we define PAC\Nas a function which takes a 128 bit input Dialogue: 0,0:36:03.51,0:36:11.54,Default,,0000,0000,0000,,and a 120-bit key and maps it to 15 bits\Noutput. Or we can more realistically Dialogue: 0,0:36:11.54,0:36:18.19,Default,,0000,0000,0000,,define it as a function which takes 96\Nbits input with a 128-bit key because we Dialogue: 0,0:36:18.19,0:36:24.08,Default,,0000,0000,0000,,have a 48-bit pointer because the other\Nones we can't use because that's where we Dialogue: 0,0:36:24.08,0:36:29.77,Default,,0000,0000,0000,,store the signature and we're most likely\Nusing the stack pointer as a context so Dialogue: 0,0:36:29.77,0:36:38.97,Default,,0000,0000,0000,,that one will also only use 48-bit \Npointers, 48 bits. Then we have PAC as a Dialogue: 0,0:36:38.97,0:36:44.30,Default,,0000,0000,0000,,construct so then we define the attacker\Nwith following capabilities. The attacker Dialogue: 0,0:36:44.30,0:36:50.65,Default,,0000,0000,0000,,is allowed to observe some pointer and\Nsignature pairs and I assume that you can Dialogue: 0,0:36:50.65,0:36:54.58,Default,,0000,0000,0000,,get that through some info leaks, for\Nexample you have some bug in the code Dialogue: 0,0:36:54.58,0:37:01.22,Default,,0000,0000,0000,,which lets you dump a portion of the stack\Nwith a bunch of signed pointers. Dialogue: 0,0:37:01.22,0:37:06.83,Default,,0000,0000,0000,,This is why you can observe some, not all,\Nbut you can see some and I would also Dialogue: 0,0:37:06.83,0:37:13.24,Default,,0000,0000,0000,,allow to have the attacker be able to\Nslightly modify the context and what I Dialogue: 0,0:37:13.24,0:37:19.62,Default,,0000,0000,0000,,mean by that is I imagine a scenario where\Nthe attacker could maybe shift the stack, Dialogue: 0,0:37:19.62,0:37:25.28,Default,,0000,0000,0000,,maybe through more nested function calls\Nbefore executing the leak which will give Dialogue: 0,0:37:25.28,0:37:31.82,Default,,0000,0000,0000,,you actually two signatures for the same\Npointer but with a different context. Dialogue: 0,0:37:31.82,0:37:39.24,Default,,0000,0000,0000,,Maybe that's somewhat helpful. But still\Nwe realize that the attacker, the Dialogue: 0,0:37:39.24,0:37:45.99,Default,,0000,0000,0000,,cryptographic attacker, is super weak so\Nthe only other cryptographic problem there Dialogue: 0,0:37:45.99,0:37:52.57,Default,,0000,0000,0000,,could be is collisions. And for those of\Nyou who seen my last talk they probably Dialogue: 0,0:37:52.57,0:38:02.28,Default,,0000,0000,0000,,know I love collisions. So we have 48-bit\Npointer, 48-bit context and 128-bit key. Dialogue: 0,0:38:02.28,0:38:08.56,Default,,0000,0000,0000,,We sum that up and we divide that by the\N15-bit of output we get from PAC which Dialogue: 0,0:38:08.56,0:38:17.07,Default,,0000,0000,0000,,gives us 2 to the power of 209 possible\Ncollisions because we map so many bits to Dialogue: 0,0:38:17.07,0:38:24.67,Default,,0000,0000,0000,,so little bits. But even if we reduce the\Npointers because practically probably less Dialogue: 0,0:38:24.67,0:38:33.06,Default,,0000,0000,0000,,than 34 bit of a pointer are really used,\Nwe still get 2 to the power 181 Dialogue: 0,0:38:33.06,0:38:38.34,Default,,0000,0000,0000,,collisions, which is a lot of collisions\Nbut the bad thing here is random Dialogue: 0,0:38:38.34,0:38:45.32,Default,,0000,0000,0000,,collisions are not very useful to us\Nunless we can predict them somehow. So Dialogue: 0,0:38:45.32,0:38:50.70,Default,,0000,0000,0000,,let's take a look how a cryptographically\Nsecure MAC is defined. So a MAC is defined Dialogue: 0,0:38:50.70,0:38:55.25,Default,,0000,0000,0000,,as following: Let p be a MAC with the\Nfollowing components and those are Dialogue: 0,0:38:55.25,0:39:00.79,Default,,0000,0000,0000,,basically Gen(), Mac() and Vrfy(). So\NGen() just somehow generates a key, it's Dialogue: 0,0:39:00.79,0:39:06.01,Default,,0000,0000,0000,,only here for the sake of mathematical\Ncompleteness. Just assume we generate the Dialogue: 0,0:39:06.01,0:39:14.38,Default,,0000,0000,0000,,key by randomly choosing n bits or however\Nhow much bits the key needs. And Mac() is Dialogue: 0,0:39:14.38,0:39:22.02,Default,,0000,0000,0000,,just a function where you put in an n-bit\Nmessage called m and it gives us a Dialogue: 0,0:39:22.02,0:39:25.57,Default,,0000,0000,0000,,signature t. And I'm going to say\Nsignature but in reality I mean a message Dialogue: 0,0:39:25.57,0:39:30.94,Default,,0000,0000,0000,,authentication code. And the third\Nfunction is Vrfy() and you give it a Dialogue: 0,0:39:30.94,0:39:34.88,Default,,0000,0000,0000,,message and a signature and that just\Nreturns true if that signature is valid Dialogue: 0,0:39:34.88,0:39:41.67,Default,,0000,0000,0000,,for the message or false if it's not. And\Nwhen cryptographers prove that something Dialogue: 0,0:39:41.67,0:39:46.70,Default,,0000,0000,0000,,is secure they like to play games. So I'm\Ngonna to show you my favorite game, which Dialogue: 0,0:39:46.70,0:39:52.23,Default,,0000,0000,0000,,is Mac-forge game. So the game is pretty\Nsimple you have to the left the game Dialogue: 0,0:39:52.23,0:39:58.65,Default,,0000,0000,0000,,master which is playing Mac-forge and\Nto the right the attacker. So the game Dialogue: 0,0:39:58.65,0:40:04.37,Default,,0000,0000,0000,,starts when the Mac-forge game master\Ninforms the attacker how much bits are we Dialogue: 0,0:40:04.37,0:40:08.61,Default,,0000,0000,0000,,playing. So this is the first 1 to the\Npower of n, basically means hey we're Dialogue: 0,0:40:08.61,0:40:13.93,Default,,0000,0000,0000,,having MAC-forge with, I don't know,\N64-bit messages so the attacker knows the Dialogue: 0,0:40:13.93,0:40:22.13,Default,,0000,0000,0000,,size. Then the game master just generates\Nthe key and then the attacker can choose to Dialogue: 0,0:40:22.13,0:40:30.50,Default,,0000,0000,0000,,q messages of n-bit length and send them\Nover to the game master and the game Dialogue: 0,0:40:30.50,0:40:36.21,Default,,0000,0000,0000,,master will generate signatures and send\Nthem back. So then the attacker can Dialogue: 0,0:40:36.21,0:40:42.39,Default,,0000,0000,0000,,observe all the messages he generated and\Nall the matching signatures. So what the Dialogue: 0,0:40:42.39,0:40:47.06,Default,,0000,0000,0000,,attacker needs to do then is to choose\Nanother message which he did not send over Dialogue: 0,0:40:47.06,0:40:56.12,Default,,0000,0000,0000,,yet and somehow come up with a valid\Nsignature and if he can manage to do that Dialogue: 0,0:40:56.12,0:41:02.62,Default,,0000,0000,0000,,he sends it over and if that's actually a\Nvalid signature for the message then he Dialogue: 0,0:41:02.62,0:41:09.49,Default,,0000,0000,0000,,wins the game, otherwise he looses the\Ngame. So we say a Mac is secure if the Dialogue: 0,0:41:09.49,0:41:15.100,Default,,0000,0000,0000,,probability that an attacker can somehow\Nwin this is negligible. So I'm gonna spare Dialogue: 0,0:41:15.100,0:41:20.06,Default,,0000,0000,0000,,you the mathematical definition of what\Nnegligible means but like just guessing or Dialogue: 0,0:41:20.06,0:41:27.67,Default,,0000,0000,0000,,trying means that it's still secure if\Nthat's the best tech. So as you can see is Dialogue: 0,0:41:27.67,0:41:36.65,Default,,0000,0000,0000,,a MAC which is secure needs to withstand\Nthis. But for our PAC attacker we do not Dialogue: 0,0:41:36.65,0:41:43.10,Default,,0000,0000,0000,,even have this oracle. So our attacker for\NPAC is even weaker than that. So why do we Dialogue: 0,0:41:43.10,0:41:49.23,Default,,0000,0000,0000,,not have this oracle? Well simple if we\Nallow the attacker to sign arbitrary Dialogue: 0,0:41:49.23,0:41:55.82,Default,,0000,0000,0000,,messages the attacker wouldn't even need\Nto try to somehow get the key or forged Dialogue: 0,0:41:55.82,0:42:00.90,Default,,0000,0000,0000,,message because then he could just send\Nover all the messages. All the pointers he Dialogue: 0,0:42:00.90,0:42:05.39,Default,,0000,0000,0000,,wants to sign get back signed pointers and\Nyou wouldn't need to bother about breaking Dialogue: 0,0:42:05.39,0:42:11.11,Default,,0000,0000,0000,,the crypto at all. So basically the point\NI'm trying to make here is that the PAC Dialogue: 0,0:42:11.11,0:42:18.61,Default,,0000,0000,0000,,attacker is weaker than a MAC attacker. So\Nevery secure MAC we know is also a secure Dialogue: 0,0:42:18.61,0:42:28.75,Default,,0000,0000,0000,,PAC, but even then an insecure MAC might\Nstill be sufficiently secure for PAC so Dialogue: 0,0:42:28.75,0:42:33.90,Default,,0000,0000,0000,,secure MACs have been around for a while\Nand thus in my opinion, I think if Dialogue: 0,0:42:33.90,0:42:41.25,Default,,0000,0000,0000,,somebody, who knows what he's doing,\Ndesigns a PAC algorithm today it will Dialogue: 0,0:42:41.25,0:42:49.07,Default,,0000,0000,0000,,likely be secure. So instead of going for\Nthe crypto I think we should rather go for Dialogue: 0,0:42:49.07,0:42:53.58,Default,,0000,0000,0000,,implementation attacks instead because\Nthose will be around forever. And by that Dialogue: 0,0:42:53.58,0:43:00.17,Default,,0000,0000,0000,,I mean well you can either see how the\Ncrypto itself is implemented, what I mean Dialogue: 0,0:43:00.17,0:43:07.22,Default,,0000,0000,0000,,especially by that is you could see how\Nthe PAC is used in the actual code. Maybe Dialogue: 0,0:43:07.22,0:43:12.16,Default,,0000,0000,0000,,you can find signing oracles, maybe you\Ncan find unauthenticated code. I think Dialogue: 0,0:43:12.16,0:43:20.26,Default,,0000,0000,0000,,this is where we need to go if wanna\Nbypass PAC somehow. So just to recap where Dialogue: 0,0:43:20.26,0:43:29.99,Default,,0000,0000,0000,,we're coming from. Future iPhone hacks\Nprobably gonna not try to bypass KTRR. I Dialogue: 0,0:43:29.99,0:43:35.42,Default,,0000,0000,0000,,think they will not try to patch Kernel\Ncode because we can achieve pretty much Dialogue: 0,0:43:35.42,0:43:41.24,Default,,0000,0000,0000,,all the things we want to achieve for end\Nuser jailbreak without having to patch the Dialogue: 0,0:43:41.24,0:43:49.11,Default,,0000,0000,0000,,kernel so far. And I think people are\Ngoing to struggle a bit. At least a bit Dialogue: 0,0:43:49.11,0:43:56.88,Default,,0000,0000,0000,,when exploiting with PAC because that kind\Nwill either make some bugs unexploitable Dialogue: 0,0:43:56.88,0:44:04.55,Default,,0000,0000,0000,,or really really hard to exploit. Also\Nmaybe we're gonna avoid the Kernel at all Dialogue: 0,0:44:04.55,0:44:10.14,Default,,0000,0000,0000,,as it has demoed that userland-only\Njailbreaks are possible. Maybe we're going Dialogue: 0,0:44:10.14,0:44:15.68,Default,,0000,0000,0000,,to recalculate what the low hanging fruits\Nare. Maybe just go back to iBoot or look Dialogue: 0,0:44:15.68,0:44:22.49,Default,,0000,0000,0000,,for what other thing is interesting. So,\Nthat was about it, thank you very much for Dialogue: 0,0:44:22.49,0:44:34.26,Default,,0000,0000,0000,,your attention.\N{\i1}Applause{\i0} Dialogue: 0,0:44:34.26,0:44:38.73,Default,,0000,0000,0000,,Herald-Engel: Thank you, sir. If you would\Nlike to ask a question please line up Dialogue: 0,0:44:38.73,0:44:48.81,Default,,0000,0000,0000,,on the microphones in the room. We do not\Nhave a question from the Internet. Dialogue: 0,0:44:48.81,0:44:53.37,Default,,0000,0000,0000,,One question over there, yes please.\NQuestion: Hi. I would like to be Dialogue: 0,0:44:53.37,0:44:58.11,Default,,0000,0000,0000,,interested what your comment is on the\Nstatement from Zarek that basically Dialogue: 0,0:44:58.11,0:45:01.96,Default,,0000,0000,0000,,jailbreaking is not a thing anymore\Nbecause you're breaking so much security Dialogue: 0,0:45:01.96,0:45:07.52,Default,,0000,0000,0000,,features that makes the phone basically\Nmore insecure than the former reasons of Dialogue: 0,0:45:07.52,0:45:15.58,Default,,0000,0000,0000,,doing a jailbreaking allow for.\Ntihmstar: Well, jailbreaking -- I don't Dialogue: 0,0:45:15.58,0:45:21.54,Default,,0000,0000,0000,,think jailbreaking itself nowadays makes a\Nphone really insecure. So of course if you Dialogue: 0,0:45:21.54,0:45:25.86,Default,,0000,0000,0000,,patched a kernel and disable all of the\Nsecurity features that will be less Dialogue: 0,0:45:25.86,0:45:31.02,Default,,0000,0000,0000,,secure. But if you take a look what we\Nhave here with the unpatchable kernel I Dialogue: 0,0:45:31.02,0:45:35.70,Default,,0000,0000,0000,,think the main downside of being\Njailbroken is the fact that you cannot go Dialogue: 0,0:45:35.70,0:45:42.42,Default,,0000,0000,0000,,to the latest software version because you\Nwant the box to be in there to have the Dialogue: 0,0:45:42.42,0:45:51.27,Default,,0000,0000,0000,,jailbreak. So I don't really think if you\Nhave like a KTRR device the jailbreak Dialogue: 0,0:45:51.27,0:45:56.08,Default,,0000,0000,0000,,itself makes it less secure. Just the fact\Nthat you are not on the latest firmware is Dialogue: 0,0:45:56.08,0:46:01.00,Default,,0000,0000,0000,,the insecure part of it.\NHerald: Alright, thank you. Dialogue: 0,0:46:01.00,0:46:05.76,Default,,0000,0000,0000,,Microphone number two, your question.\NMic #2: Hi good talk. Could you go back to Dialogue: 0,0:46:05.76,0:46:13.59,Default,,0000,0000,0000,,the capabilities of the adversary please?\NYeah. So you said you can do basically two Dialogue: 0,0:46:13.59,0:46:17.69,Default,,0000,0000,0000,,things right. This one, yes. Yeah you can\Nobserve some pointers and some signature Dialogue: 0,0:46:17.69,0:46:23.96,Default,,0000,0000,0000,,pairs. But why is this not an oracle?\Ntihmstar: Because you cannot choose... Dialogue: 0,0:46:23.96,0:46:26.42,Default,,0000,0000,0000,,Mic #2: Your message yourself.\Ntihmstar: ...your message yourself. Dialogue: 0,0:46:26.42,0:46:31.08,Default,,0000,0000,0000,,Mic #2: And you have also an oracle that\Nsays if the signature is valid. For a Dialogue: 0,0:46:31.08,0:46:33.83,Default,,0000,0000,0000,,chosen message.\Ntihmstar: Well yeah but this is if you Dialogue: 0,0:46:33.83,0:46:39.49,Default,,0000,0000,0000,,take a look at the game and this game for\Na secure MAC the attacker can choose up to Dialogue: 0,0:46:39.49,0:46:44.89,Default,,0000,0000,0000,,q messages sending over... like he can do\Nwhatever he wants with that messages and Dialogue: 0,0:46:44.89,0:46:51.90,Default,,0000,0000,0000,,get a signature while the package hacker\Ncan see a few very limited amount of Dialogue: 0,0:46:51.90,0:46:59.24,Default,,0000,0000,0000,,messages and their matching signature and\Nhe has little to no influence on these Dialogue: 0,0:46:59.24,0:47:04.80,Default,,0000,0000,0000,,messages.\NMic #2: Okay. So it's a bit weaker. Dialogue: 0,0:47:04.80,0:47:08.24,Default,,0000,0000,0000,,tihmstar: So yeah that's the point. Just\Nthat it's weaker. Dialogue: 0,0:47:08.24,0:47:10.60,Default,,0000,0000,0000,,Mic #2: Thanks.\NHerald-Engel: Do we have a question from Dialogue: 0,0:47:10.60,0:47:23.60,Default,,0000,0000,0000,,the internet? No. OK. Yes please. All\Nright then I don't see anyone else being Dialogue: 0,0:47:23.60,0:47:31.21,Default,,0000,0000,0000,,lined up and... please give a lot of\Napplause for tihmstar for his awesome Dialogue: 0,0:47:31.21,0:47:35.96,Default,,0000,0000,0000,,talk!\N{\i1}Applause{\i0} Dialogue: 0,0:47:35.96,0:47:46.14,Default,,0000,0000,0000,,{\i1}postroll music{\i0} Dialogue: 0,0:47:46.14,0:47:58.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!