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