WEBVTT

00:00:03.970 --> 00:00:16.730
<i>35C3 preroll music</i>

00:00:16.730 --> 00:00:22.010
Herald-Angel: All right, let's start with
our next talk in the security track of the

00:00:22.010 --> 00:00:27.239
chaos communication congress. The talk is
called jailbreaking iOS from past to

00:00:27.239 --> 00:00:34.954
present. Done by tihmstar. He spoke at the
32nd C3 already and researched on several

00:00:34.954 --> 00:00:40.470
jailbreaks like the Phoenix or the
jelbrekTime for the Apple Watch and he's

00:00:40.470 --> 00:00:44.800
gonna talk about the history of
jailbreaks. He's going to familiarize you

00:00:44.800 --> 00:00:52.020
with the terminology of jailbreaking and
about exploit mitigations and how you can

00:00:52.020 --> 00:00:55.910
circumvent these mitigations. Please
welcome him with a huge round of applause.

00:00:55.910 --> 00:01:02.620
<i>Applause</i>

00:01:02.620 --> 00:01:08.800
tihmstar: Thank you very much. So hello
room, I'm tihmstar, and as already said I

00:01:08.800 --> 00:01:13.910
want to talk about jailbreaking iOS from
past to present and the topics I'm going

00:01:13.910 --> 00:01:19.800
to cover "what is jailbreaking?". I will
give an overview in general. I'm going to

00:01:19.800 --> 00:01:25.600
introduce you to how jailbreak started,
how they got into the phone at first and

00:01:25.600 --> 00:01:30.950
how all of these progressed. I'll
introduce you to the terminology which is

00:01:30.950 --> 00:01:37.460
"tethered", "untethered", "semi-tethered",
"semi-untethered" jailbreaks. Stuff you

00:01:37.460 --> 00:01:41.400
probably heard but some of you don't know
what that means. I'm gonna talk a bit

00:01:41.400 --> 00:01:46.250
about hardware mitigations which were
introduced by Apple which is KPP, KTRR and

00:01:46.250 --> 00:01:52.799
a little bit about PAC. I'm going to talk
about the general goals of... About the

00:01:52.799 --> 00:01:57.790
technical goals of jailbreaking and the
kernel patches and what you want to do

00:01:57.790 --> 00:02:02.698
with those and brief overview how
jailbreaking could look like in the future.

00:02:02.698 --> 00:02:10.769
So who am I? I'm tihmstar. I got
my first iPod touch with iOS 5.1 and since

00:02:10.769 --> 00:02:15.740
then I pretty much played with jailbreaks
and then I got really interested into that

00:02:15.740 --> 00:02:19.440
and started doing my own research. I
eventually started doing my own

00:02:19.440 --> 00:02:23.510
jailbreaks. I kinda started with
downgrading – so I've been here two years

00:02:23.510 --> 00:02:28.840
ago with my presentation "iOS Downgrading:
From past to present". I kept hacking

00:02:28.840 --> 00:02:33.530
since then. So back then I kind of talked
about the projects I made and related to

00:02:33.530 --> 00:02:38.610
downgrading which was tsschecker,
futurerestore, img4tool, you probably have

00:02:38.610 --> 00:02:42.520
heard of that. And since then I was
working on several jailbreaking tools

00:02:42.520 --> 00:02:49.690
ranging from iOS 8.4.1 to 10.3.3, among
those 32bit jailbreaks, untethered

00:02:49.690 --> 00:02:54.510
jailbreaks, remote jailbreaks like
jailbreak.me and the jailbreak for the

00:02:54.510 --> 00:03:02.200
Apple Watch. So, what is this jailbreaking
I am talking about? Basically, the goal is

00:03:02.200 --> 00:03:08.620
to get control over a device you own. You
want to escape the sandbox which the apps

00:03:08.620 --> 00:03:14.440
are put in. You want to elevate the
privileges to root and eventually to

00:03:14.440 --> 00:03:20.030
kernel, you want to disable code signing
because all applications on iOS are code-

00:03:20.030 --> 00:03:24.090
signed and you cannot run unsigned
binaries. You pretty much want to disable

00:03:24.090 --> 00:03:29.959
that to run unsigned binaries. And the
most popular about people on jailbreak is

00:03:29.959 --> 00:03:35.620
to install tweaks! And also a lot of
people install a jailbreak or jailbreak

00:03:35.620 --> 00:03:39.241
their devices for doing security analysis.
For example if you want to pentest your

00:03:39.241 --> 00:03:44.980
application and see how an attack goes
foot – you want to debug that stuff and

00:03:44.980 --> 00:03:51.120
you want to have a jailbroken phone for
that. So what are these tweaks? Tweaks are

00:03:51.120 --> 00:03:55.830
usually modifications of built-in
userspace programs, for example one of the

00:03:55.830 --> 00:03:59.739
programs is springboard. Springboard is
what you see if you turn on your phone.

00:03:59.739 --> 00:04:04.790
This is where all the icons are at. And
usually you can install tweaks to, I don't

00:04:04.790 --> 00:04:10.680
know, modify the look, the behavior or add
functionality, just this customization,

00:04:10.680 --> 00:04:17.880
this is how it started with jailbreaking.
What is usually bundled when you install a

00:04:17.880 --> 00:04:23.720
jailbreak is Cydia. So you install dpkg
and apt which is the Debian package

00:04:23.720 --> 00:04:31.630
manager and you also get Cydia which is a
user-friendly graphical user interface for

00:04:31.630 --> 00:04:38.280
the decentralized or centralized package
installer system. I'm saying centralized

00:04:38.280 --> 00:04:42.250
because it is pretty much all in one spot,
you just open the app and you can get all

00:04:42.250 --> 00:04:47.250
your tweaks and it's also decentralized
because you can just add up your own repo,

00:04:47.250 --> 00:04:54.200
you can make your own repo, you can add
other repos and you're not kinda tied to

00:04:54.200 --> 00:04:58.460
one spot where you get the tweaks from, 
like from the App Store you can only download

00:04:58.460 --> 00:05:02.266
from the App Store. But with Cydia you can
pretty much download from everywhere.

00:05:02.266 --> 00:05:09.210
You're probably familiar with Debian and
it's pretty much the same. So this talk is

00:05:09.210 --> 00:05:15.610
pretty much structured around this tweet:
the "Ages of jailbreaking". So as you can

00:05:15.610 --> 00:05:20.490
see we get the Golden Age, the BootRom,
the Industrial Age and The Post-

00:05:20.490 --> 00:05:25.160
Apocalyptic age. And I kind of agree with
that. So this is why I decided to

00:05:25.160 --> 00:05:29.530
structure my talk around that and walk you
through the different ages of

00:05:29.530 --> 00:05:35.350
jailbreaking. So starting with the first
iPhone OS jailbreak – then it was actually

00:05:35.350 --> 00:05:42.490
called iPhone OS not iOS – it was not the
BootROM yet. So the first was a buffer

00:05:42.490 --> 00:05:49.560
overflow and the iPhone's libTitt library.
And this is an image parsing library.

00:05:49.560 --> 00:05:54.930
It was exploited through Safari and used as
an entry point to get code execution.

00:05:54.930 --> 00:06:00.900
It was the first time that non-Apple software
was run on an iPhone and people installed

00:06:00.900 --> 00:06:06.850
applications like Installer or AppTapp
which were stores similar to Cydia back

00:06:06.850 --> 00:06:11.590
then and those were used to install apps
or games because for the first iPhone OS

00:06:11.590 --> 00:06:16.650
there was no way to install applications
anyhow, as the App Store got introduced

00:06:16.650 --> 00:06:24.490
with iOS 2. So then, going to the Golden
Age, the attention kind of shifted to the

00:06:24.490 --> 00:06:29.949
BootROM; people started looking at the
boot process and they found this device

00:06:29.949 --> 00:06:39.120
firmware upgrade mode which is a part of
ROM. So the most famous BootROM exploit

00:06:39.120 --> 00:06:45.120
was limera1n by geohot. It was a bug in
hardware and it was unpatchable with

00:06:45.120 --> 00:06:52.650
software. So this bug was used to
jailbreak devices up to the iPhone 4.

00:06:52.650 --> 00:06:56.669
There were also several other jailbreaks –
we didn't rely on that one – but this one,

00:06:56.669 --> 00:07:00.375
once discovered, you can use it over and
over again and there's no way to patch

00:07:00.375 --> 00:07:06.690
that. So this was later patched in a new
hardware revision which is the iPhone 4s.

00:07:06.690 --> 00:07:09.830
So with that BootROM bug –

00:07:09.830 --> 00:07:15.930
This is how kind of tethered jailbreaks
became a thing. So limera1n exploits a bug

00:07:15.930 --> 00:07:24.340
in DFU mode which allows you to load
unsigned software through USB. However

00:07:24.340 --> 00:07:29.729
when you reboot the device a computer was
required to re-exploit and again load your

00:07:29.729 --> 00:07:36.380
unsigned code. And then load the
bootloaders, load the patched kernel and

00:07:36.380 --> 00:07:40.350
thus the jailbreak was kind of tethered to
the computer because whenever you shut

00:07:40.350 --> 00:07:46.160
down you need to be back at a computer to
boot your phone up. So historically a

00:07:46.160 --> 00:07:51.520
tethered jailbroken phone does not boot
without a computer at all. And the reason

00:07:51.520 --> 00:07:57.990
for that is because the jailbreaks would
modify the kernel and the bootloaders on

00:07:57.990 --> 00:08:04.120
the file system for performance reasons,
so when you do the actual tether boot you

00:08:04.120 --> 00:08:09.229
would need to upload a very tiny payload
via USB which then in turn would load

00:08:09.229 --> 00:08:14.380
everything else from the file system
itself. But this results in a broken chain

00:08:14.380 --> 00:08:18.780
of trust. When the normal boot process
runs and the bootloader checks the

00:08:18.780 --> 00:08:23.340
signature of the first-stage bootloader
that would be invalid so the bootloader

00:08:23.340 --> 00:08:29.340
would refuse to boot that and it would end
up in DFU mode so basically a phone won't

00:08:29.340 --> 00:08:36.349
boot. Sometime around then, the idea for
semi-tethered jailbreak came up and the

00:08:36.349 --> 00:08:40.479
idea behind that is very simple: just
don't break the chain of trust for

00:08:40.479 --> 00:08:47.149
tethered jailbreaks. So, what you would do
differently is you do not modify the

00:08:47.149 --> 00:08:52.220
kernel on the file system, don't touch the
bootloaders at all and then when you

00:08:52.220 --> 00:08:56.230
would boot tethered, you would need to
upload all the bootloaders like the first

00:08:56.230 --> 00:09:00.790
stage bootloader, then the second stage
bootloader which is iBoot and then the

00:09:00.790 --> 00:09:05.550
kernel via USB to boot into jailbroken
mode. However when you reboot you could

00:09:05.550 --> 00:09:10.550
boot all those components from the file
system so you could actually boot your

00:09:10.550 --> 00:09:17.149
phone into non-jailbroken mode. If you
don't install any tweaks or modifications

00:09:17.149 --> 00:09:22.020
which modify critical system components
because if you tamper with, for example,

00:09:22.020 --> 00:09:25.210
the signature of the mount binary the
system obviously cannot boot

00:09:25.210 --> 00:09:28.810
in non-jailbroken mode.

00:09:28.810 --> 00:09:35.910
So, this is kind of the Golden age. 
So let's continue with the Industrial age.

00:09:35.910 --> 00:09:43.829
So with the release of the
iPhone 4s and iOS 5, Apple fixed the

00:09:43.829 --> 00:09:49.689
BootROM bug and essentially killed
limera1n. They also introduced APTickets

00:09:49.689 --> 00:09:55.660
and nonces to bootloaders, which I'm just
mentioning because it's kind of a

00:09:55.660 --> 00:10:00.980
throwback for downgrading: before that you
can have a phone if you update to the

00:10:00.980 --> 00:10:05.529
latest firmware and before you save your
SHSH blobs you could just downgrade and

00:10:05.529 --> 00:10:09.279
then jailbreak again which wasn't a big
deal but with that they also added

00:10:09.279 --> 00:10:13.809
downgrade protection so jailbreaking
became harder. If you wanted to know more

00:10:13.809 --> 00:10:20.009
about how the boot process works, what
SHSH blobs are, what APTickets are, you

00:10:20.009 --> 00:10:24.040
should check out my talk from two years
ago, I go in-depth on how all of that

00:10:24.040 --> 00:10:30.470
works. So, I'm skipping that for this
talk. So the binaries the phone boots are

00:10:30.470 --> 00:10:35.829
encrypted so the bootloaders are encrypted
and until recently the kernel used to be

00:10:35.829 --> 00:10:41.749
encrypted as well. And the key encryption
key is fused into the devices and it is

00:10:41.749 --> 00:10:46.329
impossible to get through hardware
attacks. At least there's no public case

00:10:46.329 --> 00:10:53.100
where somebody actually got that recovered
at keys so it's probably impossible,

00:10:53.100 --> 00:11:01.059
nobody has done it yet. So old boot files
are decrypted at boot by the previous

00:11:01.059 --> 00:11:09.610
bootloader. And before the iPhone 4s you
could actually just talk to the hardware

00:11:09.610 --> 00:11:15.079
iOS engine as soon as you got kernel-level
code execution. But with the iPhone 4s

00:11:15.079 --> 00:11:19.471
they introduced a feature where before the
kernel would boot they would shut off the

00:11:19.471 --> 00:11:25.870
iOS engine by hardware, so there is no way
to decrypt bootloader files anymore so

00:11:25.870 --> 00:11:33.019
easily unless you got code execution in
the bootloader itself. So decrypting

00:11:33.019 --> 00:11:38.720
bootloaders is a struggle from now on. So
I think kind of because of that the

00:11:38.720 --> 00:11:44.810
attention shifted to userland and from now
the jailbreaks kind of had to be

00:11:44.810 --> 00:11:50.569
untethered. So untethered here means that
if you jailbreak your device, you turn it

00:11:50.569 --> 00:11:55.820
off, you boot it again, then the device is
still jailbroken, and this is usually

00:11:55.820 --> 00:12:01.089
achieved through re-exploitation at some
point in the boot process. So you can't

00:12:01.089 --> 00:12:05.529
just patch the kernel on file system
because that would invalidate signatures,

00:12:05.529 --> 00:12:09.939
so instead you would, I don't know, add
some configuration files to some demons

00:12:09.939 --> 00:12:16.079
which would trigger bugs and then exploit.
So jailbreaks then chained many bugs

00:12:16.079 --> 00:12:21.249
together, sometimes six or more bugs to 
get initial code execution, kernel code

00:12:21.249 --> 00:12:28.078
execution and persistence. This somewhat
changed when Apple introduced free

00:12:28.078 --> 00:12:33.759
developer accounts around the time they
released iOS 9. So these developer

00:12:33.759 --> 00:12:38.949
accounts allow everybody who has an Apple
ID to get a valid signing certificate for

00:12:38.949 --> 00:12:44.970
seven days for free. So you can actually
create an XCode project and run your app

00:12:44.970 --> 00:12:49.939
on your physical device. Before that that
was not possible, so the only way to run

00:12:49.939 --> 00:12:56.400
your own code on your device was to buy a
paid developer account which is 100$ per

00:12:56.400 --> 00:13:03.149
year if you a buy personal developer
account. But now you can just get that for

00:13:03.149 --> 00:13:07.670
free. And after seven days the certificate
expires, but you can just, for free,

00:13:07.670 --> 00:13:12.040
request another one and keep doing that.
Which is totally enough if you develop

00:13:12.040 --> 00:13:18.540
apps. So this kind of led to semi-
untethered jailbreaks because initial code

00:13:18.540 --> 00:13:21.737
execution was not an issue anymore.
Anybody could just get that free

00:13:21.737 --> 00:13:28.564
certificate, sign apps and run some kind
of code that was sandboxed. So jailbreak

00:13:28.564 --> 00:13:36.350
focus shifted to more powerful kernel bugs
which were reachable from sandbox. So we

00:13:36.350 --> 00:13:40.809
had jailbreaks using just one single bug
or maybe just two bugs and the jailbreaks

00:13:40.809 --> 00:13:46.629
then were distributed as an IPA, which is
an installable app people would download,

00:13:46.629 --> 00:13:53.489
sign themselves, put on the phone and just
run the app. So semi-untethered means

00:13:53.489 --> 00:13:59.639
you can reboot into non-jailbroken mode,
however you can get to jailbroken mode

00:13:59.639 --> 00:14:06.370
easily by just pressing an app. And over
the years Apple stepped up its game

00:14:06.370 --> 00:14:13.829
constantly. So with iOS 5 they introduced
ASLR address space layer randomisation,

00:14:13.829 --> 00:14:21.310
with iOS 6 they added kernel ASLR, with
the introduction of the iPhone 5, as they

00:14:21.310 --> 00:14:27.949
added 64bit CPUs, which isn't really a
security mitigation, it just changed a bit

00:14:27.949 --> 00:14:37.629
how you would exploit. So the real deal
started to come with iOS 9, where they

00:14:37.629 --> 00:14:42.689
first introduced Kernel Patch Protection,
an attempt to make the kernel immutable

00:14:42.689 --> 00:14:50.109
and not patchable. And they stepped up that 
with the iPhone 7 where they introduced

00:14:50.109 --> 00:14:57.551
Kernel Text Readonly Region, also known as
KTRR. So with iOS 11 they removed 32bit

00:14:57.551 --> 00:15:03.459
libraries, which I think has very little
to no impact on exploitation; it's mainly

00:15:03.459 --> 00:15:09.699
in the list because up to that point Cydia
was compiled as a 32bit binary and that

00:15:09.699 --> 00:15:17.720
stopped working, that's why that had to be
recompiled for 64bit, which took someone

00:15:17.720 --> 00:15:26.040
to do until you could get a working Cydia
on 64bits iOS 11. So with the iPhone Xs

00:15:26.040 --> 00:15:30.989
which came out just recently they
introduced Pointer Authentication Codes,

00:15:30.989 --> 00:15:35.386
and I'm gonna go more in detail into these
hardware mitigations in the next few

00:15:35.386 --> 00:15:42.079
slides. So let's start with Kernel Patch
Protection. So when people say KPP, they

00:15:42.079 --> 00:15:47.519
usually refer to what Apple calls
watchtower. So watchtower, as the name

00:15:47.519 --> 00:15:53.769
suggests, watches over the kernel and
panics when modifications are detected,

00:15:53.769 --> 00:15:58.859
and it prevents the kernel from being
patched. At least that's the idea of it.

00:15:58.859 --> 00:16:03.069
It doesn't really prevent it because it's
broken but when they engineered it, it

00:16:03.069 --> 00:16:08.689
should prevent you from patching the
kernel. So how does it work? Watchtower is

00:16:08.689 --> 00:16:13.301
a piece of software which runs in EL3
which is the ARM exception level 3.

00:16:13.301 --> 00:16:18.709
So exception levels are kind of privilege
separations while 3 is the highest and 0

00:16:18.709 --> 00:16:24.519
is the lowest. And you can kind of trigger
an exception to call handler code in

00:16:24.519 --> 00:16:31.459
higher levels. So the idea of watchtowers
that recurring events which is FPU usage

00:16:31.459 --> 00:16:35.720
trigger Watchtower inspection of the
kernel, and you cannot really turn it off

00:16:35.720 --> 00:16:41.819
because you do need the FPU. So if you
picture how it looks like, we have the

00:16:41.819 --> 00:16:46.919
Watchtower to the left (which totally
looks like a lighthouse) and the

00:16:46.919 --> 00:16:51.149
applications at the right. So in the
middle, in EL1, we have the kernel and

00:16:51.149 --> 00:17:00.720
recent studies revealed that this is
exactly how the XNU kernel looks like. So

00:17:00.720 --> 00:17:06.060
how can we be worse? An event occurs from
time to time which is from using userland

00:17:06.060 --> 00:17:11.110
application, for example JavaScript makes
heavy use of floating points, and the

00:17:11.110 --> 00:17:15.929
event would then go to the kernel and the
kernel would then trigger Watchtower as it

00:17:15.929 --> 00:17:24.049
tries to enable the FPU. Watchtower would
scan the kernel and then if everything is

00:17:24.049 --> 00:17:28.710
fine it would transition execution back
into the kernel which then in turn would

00:17:28.710 --> 00:17:36.009
transition back into userspace which can
then use the FPU. However with a modified

00:17:36.009 --> 00:17:41.974
kernel, when Watchtower scans the kernel
and detects modification, it would just

00:17:41.974 --> 00:17:48.940
panic. So the idea is that the kernel is
forced to call Watchtower because the FPU

00:17:48.940 --> 00:17:54.130
is blocked otherwise. But the problem at
the same time is that the kernel is in

00:17:54.130 --> 00:18:00.480
control before it calls watchtower. And
this thing was fully defeated by qwerty in

00:18:00.480 --> 00:18:09.720
yalu102. So how qwerty's KPP bypass works:
The idea is: you copy the kernel in memory

00:18:09.720 --> 00:18:15.860
and you mody the copied kernel. Then you
would modify the page tables to use the

00:18:15.860 --> 00:18:23.981
patched kernel. And whenever the FPU
triggers a Watchtower inspection, before

00:18:23.981 --> 00:18:29.539
actually calling Watchtower you would
switch back to the unmodified kernel and

00:18:29.539 --> 00:18:34.059
then let it run, let it check the
unmodified kernel when that returns you

00:18:34.059 --> 00:18:39.909
would go back to the modified kernel. So
this one it looks like: we copy the kernel

00:18:39.909 --> 00:18:47.130
in memory, we patch the modified copy, we
switch the page tables to actually use the

00:18:47.130 --> 00:18:53.669
modified copy and when we have the FPU
event it would just switch the page tables

00:18:53.669 --> 00:19:00.190
back, forward the call to Watchtower, make
then watch tower scan the unmodified

00:19:00.190 --> 00:19:08.490
kernel and after the scan we would just
return to the patched kernel. So the

00:19:08.490 --> 00:19:13.820
problem here is: Time of check – Time of
Use, the classical TOCTOU. And this works

00:19:13.820 --> 00:19:20.370
on the iPhone 5s, the iPhone 6 and the
iPhone 6s and it's not really patchable.

00:19:20.370 --> 00:19:27.130
However, with the iPhone 7, Apple
introduced KTRR, which kind of proves that

00:19:27.130 --> 00:19:34.700
and they really managed to do an
unpatchable kernel. So how does KTRR work?

00:19:34.700 --> 00:19:40.584
So Kernel Text Readonly Region, I'm going
to present as described by Siguza in his

00:19:40.584 --> 00:19:49.061
blog, adds an extra memory controller
which is the AMCC which traps all writes to

00:19:49.061 --> 00:19:56.750
the read-only region. And there's extra CPU
registers which mark and executable range

00:19:56.750 --> 00:20:02.524
which are the KTRR registers and they
obviously mark a subsection of the

00:20:02.524 --> 00:20:08.720
read-only region, so you have hardware
enforcement at boot time for read-only

00:20:08.720 --> 00:20:15.352
memory region and hardware enforcement at
boot-time for an executable memory region.

00:20:15.682 --> 00:20:21.350
So this the CPU. This is the memory at the
bottom. You would set the read-only region

00:20:21.350 --> 00:20:26.320
at boot and since that's enforced by the
hardware memory controller everything

00:20:26.320 --> 00:20:32.470
inside that region is not writable and
everything outside that region is

00:20:32.470 --> 00:20:40.850
writable. And the CPU got KTRR registers
which mark begin and end. So the

00:20:40.850 --> 00:20:46.809
executable region is a subsection of the
read-only region. Everything outside there

00:20:46.809 --> 00:20:52.246
cannot be executed by the CPU. Everything
inside the read-only region cannot be

00:20:52.246 --> 00:20:58.679
modified. And this has not been truly
bypassed yet. There's been a bypass but

00:20:58.679 --> 00:21:04.409
that actually targeted how that thing gets
set up. But that's fakes and now it's

00:21:04.409 --> 00:21:11.000
probably setting up everything and so far
it hasn't been bypassed. So jailbreaks are

00:21:11.000 --> 00:21:15.710
still around. So what are they doing?
Well, they just walk around kernel patches

00:21:15.710 --> 00:21:22.600
and this is when KPP jailbreaks evolved. 
Which means, they just don't patch

00:21:22.600 --> 00:21:28.330
the kernel. But before we dive into that,
let's take a look what previous jailbreaks

00:21:28.330 --> 00:21:35.029
actually did patch in the kernel. So the
general goals are to disable code signing

00:21:35.029 --> 00:21:41.460
to disable the sandbox to make the root
file system writable to somehow make

00:21:41.460 --> 00:21:46.951
tweaks work which involves making mobile
substrate or libsubstitute work which is

00:21:46.951 --> 00:21:53.650
the library for hooking. And I was about
to make a list of kernel patches which you

00:21:53.650 --> 00:22:00.220
could simply apply, however, the
techniques and patches vary across

00:22:00.220 --> 00:22:03.750
individual jailbreaks so much that I
couldn't even come up with the list of

00:22:03.750 --> 00:22:09.568
kernel patches among the different
jailbreaks I worked on. So there's no

00:22:09.568 --> 00:22:13.429
general set of patches, some prefer to do
it that way, some prefer to do it that

00:22:13.429 --> 00:22:18.970
way. So instead of doing a kind of full
list, I'll just show you what the Helix

00:22:18.970 --> 00:22:24.340
jailbreak does patch. So the Helix
jailbreak first patches the

00:22:24.340 --> 00:22:30.411
i_can_has_debugger, which is a boot arc.
It's a variable in the kernel and if you

00:22:30.411 --> 00:22:36.299
set that to true that would relax the
sandbox. So to relax the sandbox or to

00:22:36.299 --> 00:22:42.049
disable code signing usually involves
multiple steps. Also since iOS 7 you need

00:22:42.049 --> 00:22:48.450
to patch mount because there's actual
hardcoded that the root filesystem cannot

00:22:48.450 --> 00:22:54.539
be mounted as read-write. Since iOS 10.3,
there is also hardcoded that you cannot

00:22:54.539 --> 00:22:59.492
mount the root filesystem without the
nosuid flag, so you probably want to patch

00:22:59.492 --> 00:23:04.538
that out as well. And then if you patch
both these you can remount the root

00:23:04.538 --> 00:23:09.279
filesystem as read-and-write, however you
cannot actually write to the files on the

00:23:09.279 --> 00:23:14.419
root filesystem unless you patch Light-
Weight Volume Manager which you also only

00:23:14.419 --> 00:23:21.220
need to do in iOS 9 up to iOS 10.3. Later
when they switched to APFS you don't

00:23:21.220 --> 00:23:27.779
actually need that anymore. Also there's a
variable called proc_enforce. You set that

00:23:27.779 --> 00:23:34.149
to 0 to disable code signing which is one
of the things you need to do to disable

00:23:34.149 --> 00:23:43.090
code signing. Another flag is
cs_enforcement_disable, set that to 1 to

00:23:43.090 --> 00:23:50.550
disable code signing. So amfi, which is
Apple mobile file integrity is a kext which

00:23:50.550 --> 00:23:59.519
handles the code signing checks. In that 
kext it imports the mem-copy function.

00:23:59.519 --> 00:24:05.399
So there's a stub and one of the patches
is to patch that stub to always return 0

00:24:05.399 --> 00:24:10.496
by some simple gadget. So what this does
is, whenever it compares something in a

00:24:10.496 --> 00:24:16.370
code, it would just always compare… say
that the compare succeeds and is equal.

00:24:16.370 --> 00:24:21.982
I'm not entirely sure what it does,
so this patch dates back to Yalu

00:24:21.982 --> 00:24:24.010
but like just supplying that patch helps

00:24:24.010 --> 00:24:29.820
killing code signing, so that's why it's
in there. Another thing h3lix does is, it

00:24:29.820 --> 00:24:36.009
adds the get-task-allow entitlement to
every process and this is for allowing

00:24:36.009 --> 00:24:41.190
read/ write/executable mappings and this
is what you want for a mobile substrate

00:24:41.190 --> 00:24:46.450
tweaks. So initially this entitlement 
is used for debugging because

00:24:46.450 --> 00:24:52.700
there you also need to be able to modify
code at runtime for setting breakpoints

00:24:52.700 --> 00:24:59.580
while we use it for getting tweaks to
work. Since iOS 10.3 there's... h3lix also

00:24:59.580 --> 00:25:07.110
patches label_update_execve patch...
label_update_execve function. So the idea

00:25:07.110 --> 00:25:11.879
of that patch was to fix the "process-exec
denied while updating label" error message

00:25:11.879 --> 00:25:17.389
in Cydia and several other processes. Well
that seems to completely nuke the sandbox

00:25:17.389 --> 00:25:22.890
and also break sandbox containers so this
is also the reason why if you're

00:25:22.890 --> 00:25:28.090
jailbreaking with h3lix apps would save
their data in the global directory instead

00:25:28.090 --> 00:25:33.350
of their sandbox containers. And you also
kill a bunch of checks in

00:25:33.350 --> 00:25:40.650
map_ops_policy... mac_policy_ops to relax
the sandbox. So if you want to check out

00:25:40.650 --> 00:25:45.429
how that works yourself, unfortunately
h3lix itself is not open-source and I've

00:25:45.429 --> 00:25:50.409
no plans of open-sourcing that. But
there's two very very closely related

00:25:50.409 --> 00:25:55.960
projects which are open-source which is
doubleH3lix – this is pretty much exactly

00:25:55.960 --> 00:26:03.980
the same but for 64 bit devices which
does include the KPP bypass, so it also

00:26:03.980 --> 00:26:11.409
patches the kernel – and jelbrekTime,
which is the watchOS jailbreak. But h3lix

00:26:11.409 --> 00:26:17.850
is for iOS 10 and the watchOS jailbreak is
kind of the iOS 11 equivalent but it

00:26:17.850 --> 00:26:21.950
shares like most of the code. So most of
the patch code is the same if you want to

00:26:21.950 --> 00:26:29.000
check that out. Check these out. So,
KPPless jailbreaks. So the idea is, don't

00:26:29.000 --> 00:26:35.230
patch the kernel code but instead patch
the data. So for an example we go for

00:26:35.230 --> 00:26:39.370
remounting root file system. We know we
have hardcoded checks which forbid us to

00:26:39.370 --> 00:26:44.540
mount the root file system read/write. But
what we can do is in the kernel there's

00:26:44.540 --> 00:26:49.110
this structure representing the root file
system and we can patch that structure

00:26:49.110 --> 00:26:54.020
removing the flag saying that this
structure represents the root file system.

00:26:54.020 --> 00:27:00.210
And we simply remove that and then we can
call remount on the root file system and

00:27:00.210 --> 00:27:05.851
then we put back in the flag. So we kind
of bypass the hardcoded check. For

00:27:05.851 --> 00:27:12.620
disabling code signing and disabling
sandbox there are several approaches.

00:27:12.620 --> 00:27:17.169
In the kernel there's a trust cache so
usually amfi handles the code signing.

00:27:17.169 --> 00:27:21.280
The demon in userspace handles the code
signing requests. But the demon itself

00:27:21.280 --> 00:27:25.270
also needs to be code-signed. So you have
the chicken and egg problem. That's why in

00:27:25.270 --> 00:27:31.392
the kernel there is a list of hashes of
binaries which are allowed to execute. And

00:27:31.392 --> 00:27:35.409
this thing is actually writable because
when you mount the developer disk image it

00:27:35.409 --> 00:27:40.919
actually adds some debugging things to it
so you can simply inject your own hash

00:27:40.919 --> 00:27:46.779
into the trust cache making the binary
trusted. Another approach taken by

00:27:46.779 --> 00:27:51.830
jailbreakd and the latest electro
jailbreak is to have a process, in this

00:27:51.830 --> 00:27:58.070
case jailbreakd, which would patch the
processes on creation, so when you spawn a

00:27:58.070 --> 00:28:03.889
process that thing would immediately stop
the process, go into the kernel, look up

00:28:03.889 --> 00:28:10.620
the structure and remove the flags
saying "kill this process when the cold

00:28:10.620 --> 00:28:15.809
signature becomes involved" and it will
invalid. And it would also add the

00:28:15.809 --> 00:28:20.808
get-task-low entitlements. And then after 
it's done that it would resume the process

00:28:20.808 --> 00:28:25.850
and then the process won't get killed any 
more because it's kind of already trusted.

00:28:25.850 --> 00:28:33.450
And the third approach taken or demoed by
bazad was to take over amfid and userspace

00:28:33.450 --> 00:28:41.210
completely. So if you can get a Mac port
to launchd or to amfid you can impersonate

00:28:41.210 --> 00:28:47.340
that and whenever the kernel asks and
feels that it's trusted you would reply

00:28:47.340 --> 00:28:51.190
"Okay yeah that's trusted that's fine
you can run it" so that way you don't need

00:28:51.190 --> 00:28:59.510
to go for the kernel at all. So future
jailbreaks. Kernel patches are not really

00:28:59.510 --> 00:29:04.879
possible anymore and they're not even
required. Because we can still patch the

00:29:04.879 --> 00:29:13.080
kernel data or not go for the kernel at
all. But we're still not done yet, we

00:29:13.080 --> 00:29:21.639
still didn't go for Post-Apocalyptic
or short PAC. Well actually

00:29:21.639 --> 00:29:25.039
PAC stands for pointer authentication
codes but you get the joke.

00:29:25.039 --> 00:29:30.590
So pointer authentication codes were
introduced with the iPhone Xs and if we

00:29:30.590 --> 00:29:36.532
quote Qualcomm "This is a stronger version
off stack protection". And pointer

00:29:36.532 --> 00:29:41.809
authentication codes are similar to
message authentication codes but for

00:29:41.809 --> 00:29:47.490
pointers, if you are familiar with that.
And the idea of that is to protect data in

00:29:47.490 --> 00:29:55.389
memory in relation to context with a
secret key. So the data in memory could be

00:29:55.389 --> 00:30:00.869
the return value and the context could be
the stack pointer or data in memory could

00:30:00.869 --> 00:30:07.749
be a function pointer and the context
could be a vtable. So if we take a look

00:30:07.749 --> 00:30:14.649
how PAC is implemented. So at the left you
can see function entry and like function

00:30:14.649 --> 00:30:19.740
prologue and function epilogue without PAC
and with PAC the only thing that would be

00:30:19.740 --> 00:30:27.139
changed is when you enter a function
before actually doing anything inside it,

00:30:27.139 --> 00:30:31.980
you would normally store the return value
on the stack but when doing that you would

00:30:31.980 --> 00:30:39.299
first authenticate the pointer with the
context and then kinda create the

00:30:39.299 --> 00:30:44.358
signature and store it inside the pointer
and then put it on the stack. And then

00:30:44.358 --> 00:30:49.549
when you leave the function you would just
take back the pointer, again calculate the

00:30:49.549 --> 00:30:56.429
signature and see if these both signatures
matches and if they do then just return

00:30:56.429 --> 00:31:03.977
and if the signature's invalid you would
just throw a hardware fault. So this is

00:31:03.977 --> 00:31:10.649
how it looks like for 64-bit pointers. You
don't really use all of the available bits.

00:31:10.649 --> 00:31:16.820
So usually you use 48 bits for
virtual memory which is more than enough.

00:31:16.820 --> 00:31:22.200
If you use memory tagging
you have seven bits left for putting in

00:31:22.200 --> 00:31:28.989
the signature or if you do not use memory
tagging you can use up to 15 bits for the

00:31:28.989 --> 00:31:39.852
pointer authentication code. So the basic
idea of PAC is to kill ROP like code reuse

00:31:39.852 --> 00:31:46.402
attacks. You cannot simply smash the stack
and create a ROP chain because every

00:31:46.402 --> 00:31:53.899
return would have an instruction verifying
the signature of the return value and that

00:31:53.899 --> 00:32:00.580
means you would need to sign everything,
every single of these pointers and since

00:32:00.580 --> 00:32:07.103
you don't know the key you can't do that
in advance. So you cannot modify a return

00:32:07.103 --> 00:32:12.049
value and you cannot swap two signed
values on the stack unless the stack

00:32:12.049 --> 00:32:22.677
pointer is the same for both. Can we
bypass it? Maybe. I don't know. But we can

00:32:22.690 --> 00:32:29.484
take a look at how that thing is
implemented. So if we take a look at the

00:32:29.484 --> 00:32:35.792
ARM slides you can see that PAC is
basically derived from a pointer and a

00:32:35.792 --> 00:32:41.659
64-bit context value and the key and we
put all of that in the algorithm P. And

00:32:41.659 --> 00:32:48.230
that gives us the PAC which we store in
the unused bits. So the algorithm P can

00:32:48.230 --> 00:32:56.450
either be QARMA or it can be something
completely custom. And the instructions,

00:32:56.450 --> 00:33:03.419
the ARM instructions, kind of hide the
implementation details. So if you would go

00:33:03.419 --> 00:33:11.350
for attacking PAC, there's two ways of
attack strategies. We can either try and

00:33:11.350 --> 00:33:16.140
go straight for the cryptographic
primitive like take a look what cipher it

00:33:16.140 --> 00:33:22.419
is or how that cipher is implemented.
Maybe it's weak or we can go and attack

00:33:22.419 --> 00:33:29.029
the implementation. So if we go and attack
the implementation we could look for

00:33:29.029 --> 00:33:35.379
signing primitives, which could be like
small gadgets we could jump to somehow,

00:33:35.379 --> 00:33:42.499
somehow execute to sign a value which
could be either an arbitrary context

00:33:42.499 --> 00:33:50.369
signing gadget or maybe a fixed context
signing gadget. We could also look for

00:33:50.369 --> 00:33:56.640
unauthenticated code, for example I
imagine the code which sets up PAC itself

00:33:56.640 --> 00:34:03.529
is probably not protected by PAC because
you can't sign the pointer if the key is

00:34:03.529 --> 00:34:08.900
not set up yet. Maybe that code is still
accessible. We could look for something

00:34:08.900 --> 00:34:17.720
like that. We could also try to replace
pointers which share the same context.

00:34:17.720 --> 00:34:23.710
It's probably not feasible for return
values on the stack, but maybe it's

00:34:23.710 --> 00:34:30.089
feasible for swapping pointers in the
vtable. Or maybe you come up with your own

00:34:30.089 --> 00:34:37.049
clever idea how to bypass that. These are
just like some ideas. So I want to make a

00:34:37.049 --> 00:34:44.639
point here, that in my opinion it doesn't
make much sense to try to attack the

00:34:44.639 --> 00:34:51.550
underlying cryptography on PAC, so I think
that if we go for attacking PAC it makes

00:34:51.550 --> 00:34:56.329
much more sense to look for implementation
attacks and not attacking the cryptography

00:34:56.329 --> 00:35:04.290
and the next few slides are just there to
explain why I think that. So if we take a

00:35:04.290 --> 00:35:10.309
look at QARMA which was proposed by ARM as
being one of the possible ways of

00:35:10.309 --> 00:35:16.750
implementing PAC. PAC, uhm, QARMA is a
tweakable block cipher, so it takes an

00:35:16.750 --> 00:35:22.859
input, a tweak and gives you an output.
Which kind of fits perfectly for what we

00:35:22.859 --> 00:35:30.390
want. And then I started looking at QARMA
and came up with ideas on how are you

00:35:30.390 --> 00:35:35.780
could maybe attack that cipher. At some
point I realized that practical crypto

00:35:35.780 --> 00:35:42.550
attacks on QARMA if there will be any in
the future will probably that's what I

00:35:42.550 --> 00:35:51.140
think completely irrelevant to the PAC
security. So why's that? If we define –

00:35:51.140 --> 00:35:55.349
So just so you know, the next few slides
I'm going to bore you with some math but

00:35:55.349 --> 00:36:03.510
it's not too complex. So if we define PAC
as a function which takes a 128 bit input

00:36:03.510 --> 00:36:11.540
and a 120-bit key and maps it to 15 bits
output. Or we can more realistically

00:36:11.540 --> 00:36:18.190
define it as a function which takes 96
bits input with a 128-bit key because we

00:36:18.190 --> 00:36:24.080
have a 48-bit pointer because the other
ones we can't use because that's where we

00:36:24.080 --> 00:36:29.770
store the signature and we're most likely
using the stack pointer as a context so

00:36:29.770 --> 00:36:38.970
that one will also only use 48-bit 
pointers, 48 bits. Then we have PAC as a

00:36:38.970 --> 00:36:44.297
construct so then we define the attacker
with following capabilities. The attacker

00:36:44.297 --> 00:36:50.650
is allowed to observe some pointer and
signature pairs and I assume that you can

00:36:50.650 --> 00:36:54.579
get that through some info leaks, for
example you have some bug in the code

00:36:54.579 --> 00:37:01.220
which lets you dump a portion of the stack
with a bunch of signed pointers.

00:37:01.220 --> 00:37:06.829
This is why you can observe some, not all,
but you can see some and I would also

00:37:06.829 --> 00:37:13.240
allow to have the attacker be able to
slightly modify the context and what I

00:37:13.240 --> 00:37:19.619
mean by that is I imagine a scenario where
the attacker could maybe shift the stack,

00:37:19.619 --> 00:37:25.277
maybe through more nested function calls
before executing the leak which will give

00:37:25.277 --> 00:37:31.821
you actually two signatures for the same
pointer but with a different context.

00:37:31.821 --> 00:37:39.240
Maybe that's somewhat helpful. But still
we realize that the attacker, the

00:37:39.240 --> 00:37:45.990
cryptographic attacker, is super weak so
the only other cryptographic problem there

00:37:45.990 --> 00:37:52.570
could be is collisions. And for those of
you who seen my last talk they probably

00:37:52.570 --> 00:38:02.280
know I love collisions. So we have 48-bit
pointer, 48-bit context and 128-bit key.

00:38:02.280 --> 00:38:08.559
We sum that up and we divide that by the
15-bit of output we get from PAC which

00:38:08.559 --> 00:38:17.069
gives us 2 to the power of 209 possible
collisions because we map so many bits to

00:38:17.069 --> 00:38:24.670
so little bits. But even if we reduce the
pointers because practically probably less

00:38:24.670 --> 00:38:33.059
than 34 bit of a pointer are really used,
we still get 2 to the power 181

00:38:33.059 --> 00:38:38.340
collisions, which is a lot of collisions
but the bad thing here is random

00:38:38.340 --> 00:38:45.323
collisions are not very useful to us
unless we can predict them somehow. So

00:38:45.323 --> 00:38:50.700
let's take a look how a cryptographically
secure MAC is defined. So a MAC is defined

00:38:50.700 --> 00:38:55.250
as following: Let p be a MAC with the
following components and those are

00:38:55.250 --> 00:39:00.791
basically Gen(), Mac() and Vrfy(). So
Gen() just somehow generates a key, it's

00:39:00.791 --> 00:39:06.010
only here for the sake of mathematical
completeness. Just assume we generate the

00:39:06.010 --> 00:39:14.385
key by randomly choosing n bits or however
how much bits the key needs. And Mac() is

00:39:14.385 --> 00:39:22.020
just a function where you put in an n-bit
message called m and it gives us a

00:39:22.020 --> 00:39:25.569
signature t. And I'm going to say
signature but in reality I mean a message

00:39:25.569 --> 00:39:30.940
authentication code. And the third
function is Vrfy() and you give it a

00:39:30.940 --> 00:39:34.880
message and a signature and that just
returns true if that signature is valid

00:39:34.880 --> 00:39:41.670
for the message or false if it's not. And
when cryptographers prove that something

00:39:41.670 --> 00:39:46.700
is secure they like to play games. So I'm
gonna to show you my favorite game, which

00:39:46.700 --> 00:39:52.230
is Mac-forge game. So the game is pretty
simple you have to the left the game

00:39:52.230 --> 00:39:58.652
master which is playing Mac-forge and
to the right the attacker. So the game

00:39:58.652 --> 00:40:04.369
starts when the Mac-forge game master
informs the attacker how much bits are we

00:40:04.369 --> 00:40:08.609
playing. So this is the first 1 to the
power of n, basically means hey we're

00:40:08.609 --> 00:40:13.934
having MAC-forge with, I don't know,
64-bit messages so the attacker knows the

00:40:13.934 --> 00:40:22.130
size. Then the game master just generates
the key and then the attacker can choose to

00:40:22.130 --> 00:40:30.500
q messages of n-bit length and send them
over to the game master and the game

00:40:30.500 --> 00:40:36.210
master will generate signatures and send
them back. So then the attacker can

00:40:36.210 --> 00:40:42.390
observe all the messages he generated and
all the matching signatures. So what the

00:40:42.390 --> 00:40:47.059
attacker needs to do then is to choose
another message which he did not send over

00:40:47.059 --> 00:40:56.119
yet and somehow come up with a valid
signature and if he can manage to do that

00:40:56.119 --> 00:41:02.619
he sends it over and if that's actually a
valid signature for the message then he

00:41:02.619 --> 00:41:09.490
wins the game, otherwise he looses the
game. So we say a Mac is secure if the

00:41:09.490 --> 00:41:15.996
probability that an attacker can somehow
win this is negligible. So I'm gonna spare

00:41:15.996 --> 00:41:20.059
you the mathematical definition of what
negligible means but like just guessing or

00:41:20.059 --> 00:41:27.670
trying means that it's still secure if
that's the best tech. So as you can see is

00:41:27.670 --> 00:41:36.650
a MAC which is secure needs to withstand
this. But for our PAC attacker we do not

00:41:36.650 --> 00:41:43.105
even have this oracle. So our attacker for
PAC is even weaker than that. So why do we

00:41:43.105 --> 00:41:49.230
not have this oracle? Well simple if we
allow the attacker to sign arbitrary

00:41:49.230 --> 00:41:55.819
messages the attacker wouldn't even need
to try to somehow get the key or forged

00:41:55.819 --> 00:42:00.900
message because then he could just send
over all the messages. All the pointers he

00:42:00.900 --> 00:42:05.390
wants to sign get back signed pointers and
you wouldn't need to bother about breaking

00:42:05.390 --> 00:42:11.109
the crypto at all. So basically the point
I'm trying to make here is that the PAC

00:42:11.109 --> 00:42:18.609
attacker is weaker than a MAC attacker. So
every secure MAC we know is also a secure

00:42:18.609 --> 00:42:28.750
PAC, but even then an insecure MAC might
still be sufficiently secure for PAC so

00:42:28.750 --> 00:42:33.900
secure MACs have been around for a while
and thus in my opinion, I think if

00:42:33.900 --> 00:42:41.250
somebody, who knows what he's doing,
designs a PAC algorithm today it will

00:42:41.250 --> 00:42:49.069
likely be secure. So instead of going for
the crypto I think we should rather go for

00:42:49.069 --> 00:42:53.579
implementation attacks instead because
those will be around forever. And by that

00:42:53.579 --> 00:43:00.170
I mean well you can either see how the
crypto itself is implemented, what I mean

00:43:00.170 --> 00:43:07.224
especially by that is you could see how
the PAC is used in the actual code. Maybe

00:43:07.224 --> 00:43:12.155
you can find signing oracles, maybe you
can find unauthenticated code. I think

00:43:12.155 --> 00:43:20.260
this is where we need to go if wanna
bypass PAC somehow. So just to recap where

00:43:20.260 --> 00:43:29.987
we're coming from. Future iPhone hacks
probably gonna not try to bypass KTRR. I

00:43:29.987 --> 00:43:35.420
think they will not try to patch Kernel
code because we can achieve pretty much

00:43:35.420 --> 00:43:41.240
all the things we want to achieve for end
user jailbreak without having to patch the

00:43:41.240 --> 00:43:49.110
kernel so far. And I think people are
going to struggle a bit. At least a bit

00:43:49.110 --> 00:43:56.885
when exploiting with PAC because that kind
will either make some bugs unexploitable

00:43:56.885 --> 00:44:04.550
or really really hard to exploit. Also
maybe we're gonna avoid the Kernel at all

00:44:04.550 --> 00:44:10.140
as it has demoed that userland-only
jailbreaks are possible. Maybe we're going

00:44:10.140 --> 00:44:15.680
to recalculate what the low hanging fruits
are. Maybe just go back to iBoot or look

00:44:15.680 --> 00:44:22.490
for what other thing is interesting. So,
that was about it, thank you very much for

00:44:22.490 --> 00:44:34.259
your attention.
<i>Applause</i>

00:44:34.259 --> 00:44:38.730
Herald-Engel: Thank you, sir. If you would
like to ask a question please line up

00:44:38.730 --> 00:44:48.809
on the microphones in the room. We do not
have a question from the Internet.

00:44:48.809 --> 00:44:53.369
One question over there, yes please.
Question: Hi. I would like to be

00:44:53.369 --> 00:44:58.109
interested what your comment is on the
statement from Zarek that basically

00:44:58.109 --> 00:45:01.960
jailbreaking is not a thing anymore
because you're breaking so much security

00:45:01.960 --> 00:45:07.520
features that makes the phone basically
more insecure than the former reasons of

00:45:07.520 --> 00:45:15.579
doing a jailbreaking allow for.
tihmstar: Well, jailbreaking -- I don't

00:45:15.579 --> 00:45:21.540
think jailbreaking itself nowadays makes a
phone really insecure. So of course if you

00:45:21.540 --> 00:45:25.855
patched a kernel and disable all of the
security features that will be less

00:45:25.855 --> 00:45:31.020
secure. But if you take a look what we
have here with the unpatchable kernel I

00:45:31.020 --> 00:45:35.700
think the main downside of being
jailbroken is the fact that you cannot go

00:45:35.700 --> 00:45:42.419
to the latest software version because you
want the box to be in there to have the

00:45:42.419 --> 00:45:51.270
jailbreak. So I don't really think if you
have like a KTRR device the jailbreak

00:45:51.270 --> 00:45:56.079
itself makes it less secure. Just the fact
that you are not on the latest firmware is

00:45:56.079 --> 00:46:01.000
the insecure part of it.
Herald: Alright, thank you.

00:46:01.000 --> 00:46:05.759
Microphone number two, your question.
Mic #2: Hi good talk. Could you go back to

00:46:05.759 --> 00:46:13.589
the capabilities of the adversary please?
Yeah. So you said you can do basically two

00:46:13.589 --> 00:46:17.690
things right. This one, yes. Yeah you can
observe some pointers and some signature

00:46:17.690 --> 00:46:23.960
pairs. But why is this not an oracle?
tihmstar: Because you cannot choose...

00:46:23.960 --> 00:46:26.420
Mic #2: Your message yourself.
tihmstar: ...your message yourself.

00:46:26.420 --> 00:46:31.080
Mic #2: And you have also an oracle that
says if the signature is valid. For a

00:46:31.080 --> 00:46:33.829
chosen message.
tihmstar: Well yeah but this is if you

00:46:33.829 --> 00:46:39.490
take a look at the game and this game for
a secure MAC the attacker can choose up to

00:46:39.490 --> 00:46:44.890
q messages sending over... like he can do
whatever he wants with that messages and

00:46:44.890 --> 00:46:51.900
get a signature while the package hacker
can see a few very limited amount of

00:46:51.900 --> 00:46:59.243
messages and their matching signature and
he has little to no influence on these

00:46:59.243 --> 00:47:04.800
messages.
Mic #2: Okay. So it's a bit weaker.

00:47:04.800 --> 00:47:08.240
tihmstar: So yeah that's the point. Just
that it's weaker.

00:47:08.240 --> 00:47:10.600
Mic #2: Thanks.
Herald-Engel: Do we have a question from

00:47:10.600 --> 00:47:23.599
the internet? No. OK. Yes please. All
right then I don't see anyone else being

00:47:23.599 --> 00:47:31.214
lined up and... please give a lot of
applause for tihmstar for his awesome

00:47:31.214 --> 00:47:35.955
talk!
<i>Applause</i>

00:47:35.955 --> 00:47:46.137
<i>postroll music</i>

00:47:46.137 --> 00:47:58.000
subtitles created by c3subtitles.de
in the year 2020. Join, and help us!