00:00:00.634,00:00:05.506
>> Uhm, Hi everyone, welcome to
DefCon. Uhm, my name is Max

00:00:05.506,00:00:08.809
Bazaliy and today my talk will
be about exploit mitigation

00:00:08.809,00:00:13.847
techniques on iOS. Can everybody
hear me on the left... and right

00:00:13.847,00:00:18.285
side? [chatter] Ok cool, so..
[laughter] [chuckles] [pause]

00:00:18.285,00:00:23.290
Uhm... >> This is where...
that's... >> Yea, yea, yea, I

00:00:25.893,00:00:29.963
got it.. Uh, so a few words
about me, uh, I am from Kiev,

00:00:29.963,00:00:33.033
Ukraine. I currently work as a
staff security engineer at

00:00:33.033,00:00:37.738
Lookout. Uh, the last few years
I focused on XNU and LLVM and

00:00:37.738,00:00:41.942
Linux internals. I also, uh,
co-founded a Fried Apple team,

00:00:41.942,00:00:44.778
which main goal is to share iOS
reverse engineering tools and

00:00:44.778,00:00:49.182
techniques and methods. So what
will I cover today? Uh, first of

00:00:49.182,00:00:53.253
all iOS security mechanism - how
the iOS security stuff works.

00:00:53.253,00:00:57.524
Next, uh, a quick introduction
of function hooking on iOS. Uh,

00:00:57.524,00:01:00.827
I will show, uh, techniques that
Apple provide to mitigate, uh,

00:01:00.827,00:01:05.565
exploit development and attacks
on iOS 8 and 9. Uh, and, tsh, I

00:01:05.565,00:01:10.437
will show the real exploit that
I found on iOS 9, and allowed to

00:01:10.437,00:01:15.676
run, uh, and signed code, and as
a final, uh, we will see how the

00:01:15.676,00:01:19.146
future attacks on code sign
might look like. So what are

00:01:19.146,00:01:22.516
higher security mechanisms?
First of all, uh, memory

00:01:22.516,00:01:26.153
protection, it prevents the
change in, uhm, executable page

00:01:26.153,00:01:30.223
permissions so a executable page
cannot be writable. And, uh, as

00:01:30.223,00:01:33.694
part of memory protection we
cannot allocate writable and

00:01:33.694,00:01:37.497
executable regions in the same
time. The code signing which is

00:01:37.497,00:01:41.034
technique that all executable
code must be signed by a trusted

00:01:41.034,00:01:45.672
party. Sandboxing like
isolating, uh, process data from

00:01:45.672,00:01:49.443
each other and restricting
access to files and APIs. Secure

00:01:49.443,00:01:54.214
boot process all elements in a
boot chain must be signed by

00:01:54.214,00:01:58.385
Apple. Uh, data protection which
is hardware based encryption

00:01:58.385,00:02:02.222
for, uh, data at rest, and
kernel patch protection. So it's

00:02:02.222,00:02:05.625
a new technique, uh, that
debuted in iOS 9. Uh, it's a

00:02:05.625,00:02:10.364
special patch guard that live
in, er, kernel... live in, uh,

00:02:10.364,00:02:15.168
IRM trust zone and continuously
check for a a kernel integrity.

00:02:15.168,00:02:19.172
So most interesting for us
refers to, like, memory

00:02:19.172,00:02:22.309
protection, code signing, and I
will focus on them today. Uh, as

00:02:22.309,00:02:24.978
I say memory protections
technique to prevent, uhm,

00:02:24.978,00:02:29.116
exploitable execution. Uh, there
is no way to... for executable

00:02:29.116,00:02:32.419
page to be writable; there is no
way to allocate writable and

00:02:32.419,00:02:36.189
executable regions in the same
time. As a result of that, now

00:02:36.189,00:02:40.494
dynamic generation. Uh, but
starting from iOS 4.3 Apple

00:02:40.494,00:02:44.865
added special entitlement, that
they will use it for allocating

00:02:44.865,00:02:48.702
JID pages in Safari GS neutral
Jan. Uh, as part of memory

00:02:48.702,00:02:52.939
protection non-executable stack
and heap, and ASLR in user land

00:02:52.939,00:02:56.143
and in kernel land. So let's
look how they implement it. Uh,

00:02:56.143,00:03:00.514
here we see "vm_map_enter(...)"
uh, which will be, in, uh, XNU

00:03:00.514,00:03:03.817
source code, which will will be
allocated, which we call it, uh,

00:03:03.817,00:03:07.287
all the time when we allocate a
new region in the URL address

00:03:07.287,00:03:13.260
map. So if region want to be
writable and executable, mmm...

00:03:13.260,00:03:16.530
"vm_map_enter(...)" just disable
"vm_prot_execute" flag. The only

00:03:16.530,00:03:21.368
one exclusion is for "entry
_for_jit". The same stuff for

00:03:21.368,00:03:25.605
changing existing regions, so if
region is executable, is going

00:03:25.605,00:03:29.076
to be writable it just will
disable, uh, executable bit.

00:03:29.076,00:03:32.345
Again, special case for a use it
for a jit-flag is set. [pause]

00:03:32.345,00:03:37.350
Uh, the next security technique
is code signing which is based

00:03:37.350,00:03:40.587
on, uh.. Mandatory Access
Control Framework, uh, it is

00:03:40.587,00:03:44.191
pluggable framework that is
permit in new security policies,

00:03:44.191,00:03:47.727
allowed it, uhm, easy link it in
a kernel load it at, uh, boot

00:03:47.727,00:03:53.700
time, load it runtime, and
it's... it's, uh, a lot of,

00:03:53.700,00:03:58.271
uhmm, features to implement new
security policies. And code

00:03:58.271,00:04:01.408
signing is one the security
policies, it's enforced that all

00:04:01.408,00:04:05.645
code must be signed by a trusted
party. In addition, it.. uhm...

00:04:05.645,00:04:09.082
all running code should match
with signed page hashes, uh, on

00:04:09.082,00:04:13.920
load as well as runtime, uh...
before execution. [pause] So...

00:04:13.920,00:04:17.824
A few words on how the code
signature format is look, uh,

00:04:17.824,00:04:21.194
there is a spatial, uh, in the
markup file there is a special

00:04:21.194,00:04:23.997
load comment called:
"LC_CODE_SIGNATURE" which points

00:04:23.997,00:04:28.802
to code signature blob. The key
component of a blob is, uhm,

00:04:28.802,00:04:33.140
code directory, which contain,
uh, version, flags, signer

00:04:33.140,00:04:38.645
information and, so on. Uh, page
hashes, uh, individually stored

00:04:38.645,00:04:43.817
in, er, slots and have a,
started from index zero. There

00:04:43.817,00:04:47.387
are spatial data slots for code
resources, entitlements and they

00:04:47.387,00:04:52.025
have a negative indexes. Uh,
last is a master hash of all the

00:04:52.025,00:04:55.862
hashes called the CDHash and it
usually use it to verified at

00:04:55.862,00:05:01.067
code signatures. Here is a
picture of how, uh, code sign

00:05:01.067,00:05:05.505
validation on load works in the
kernel. So, uhm, embedded

00:05:05.505,00:05:09.042
signature get copied to a kernel
space, and, uh, and the entire

00:05:09.042,00:05:13.780
CDHash get verified - no
individual page checked yet. We,

00:05:13.780,00:05:17.851
uh, spawn a new process, with
"__mac_execveposix_spawn" and,

00:05:17.851,00:05:21.955
uh, "exec_activate_image" get
called in the kernel. It,

00:05:21.955,00:05:24.991
iterates through all the image
activators called

00:05:24.991,00:05:29.296
"exec_mach_imgact" which handle
mach files and call

00:05:29.296,00:05:31.598
"load_machfile",
"parse_machfile",

00:05:31.598,00:05:35.702
"load_code_signature",
"ubc_cs_blob_add" and finally it

00:05:35.702,00:05:39.906
call "mac_vnode_check_signature"
AMFI hook. This is how stuff

00:05:39.906,00:05:44.311
works, uh, per page, so, page,
uh, code signature validation

00:05:44.311,00:05:49.115
works per page fault, page fault
got generated, uhm, on a page

00:05:49.115,00:05:54.154
load, and "vm_fault_enter" got
called. It, er, calls

00:05:54.154,00:06:00.460
"vm_page_validate_cs" which map,
uh, paged kernel space, call

00:06:00.460,00:06:02.028
"vm_map_validate_cs_mapped",
"vm_page_validate_cs_mapped".

00:06:02.028,00:06:05.899
And final "cs_validate_page"
which do the actual comparison

00:06:05.899,00:06:12.172
between, uh, stored, uh, page
hash and calculated page hash

00:06:12.172,00:06:16.276
More details on, uh, page
validation, so, uh, page fault

00:06:16.276,00:06:19.980
got generated when the page is
loaded and it called "vm_fault".

00:06:19.980,00:06:24.017
There are few states to a page,
one called "Validated" another

00:06:24.017,00:06:28.154
called "Tainted". So validated
page means that page have a hash

00:06:28.154,00:06:31.558
in code signature directory.
Tainted means its calculated

00:06:31.558,00:06:35.528
page hash is not equal to a
stored page hash, and uh,

00:06:35.528,00:06:38.465
process with invalid code sign
flags will be killed by kernel.

00:06:38.465,00:06:43.803
A good question, when we need to
verify a page hashes? So there

00:06:43.803,00:06:47.874
is a macro "vm_fault_enter()"
uh, "need_cs_validation" from,

00:06:47.874,00:06:52.846
uhm, vm... "vm_fault". It say
that page need to be validation

00:06:52.846,00:06:55.782
if it's, uh, going to be
writable it belongs to a code

00:06:55.782,00:07:00.553
signing object, it's, uh, been
mapped to user space, so

00:07:00.553,00:07:05.525
basically it will be validated
any interest in time. Few words

00:07:05.525,00:07:09.596
on how code sign enforcement
works. So Apple uses special,

00:07:09.596,00:07:13.700
uhm... kernel extension called
"AMFI", Apple Mobile File

00:07:13.700,00:07:17.771
Integrity, which register
AMFI-hook, which register mark

00:07:17.771,00:07:22.242
hooks, and like there is a huge
set of hooks. Uhm, just a few

00:07:22.242,00:07:26.379
example of them, like:
"mpo_vnode_check_exec" uh, which

00:07:26.379,00:07:29.316
set, uh, flags CS_HARD and
CS_KILL for a process, which

00:07:29.316,00:07:34.321
means its process should, hmm,
not allow to load invalid pages

00:07:34.321,00:07:37.857
and should be killed if it
becomes invalid. [pause] A big

00:07:37.857,00:07:41.661
picture, how the code sign
enforcement works. So here we

00:07:41.661,00:07:46.232
have a process in the user land
that called, uh, "syscall" or,

00:07:46.232,00:07:49.569
uh, "MACF trail". The
corresponding sysent, uh, this

00:07:49.569,00:07:53.173
first one, function from a
"sysent" called it, it calls out

00:07:53.173,00:07:58.211
to a MAC framework which check
Is there any, uhm, policy models

00:07:58.211,00:08:01.915
requested to hook particular
functionality? Next we called

00:08:01.915,00:08:06.353
for AMFI which check for a code
signature. If the code signature

00:08:06.353,00:08:10.724
type is adhoc, uhm, they're
looking for CDHash at, uh,

00:08:10.724,00:08:15.161
kernel advanced hash. If it's
not ad hoc we, uh, send out to

00:08:15.161,00:08:19.699
AMFID which is in user land,
which use "libmis.dylib" to

00:08:19.699,00:08:24.137
validate the cms_blob. So a
great question "Why we need all

00:08:24.137,00:08:29.008
this info, right?" Uhm, before I
go into problem statement, a few

00:08:29.008,00:08:31.878
words about the function
hooking. So I use function

00:08:31.878,00:08:35.648
hooking a lot, uhm, in my work
for adding the new security

00:08:35.648,00:08:39.419
features such as data at rest
encryption, uh, by hooking

00:08:39.419,00:08:43.056
low-level, open-close write
functions. It's really useful

00:08:43.056,00:08:46.993
for debugging third-party code;
logging and tracing API calls;

00:08:46.993,00:08:50.363
even could be used for code
deobfuscation. Uh, all this time

00:08:50.363,00:08:55.001
I was use it, industry known
method called interposing. Uh,

00:08:55.001,00:08:57.570
this is how it works. So,
starting from where I stand,

00:08:57.570,00:09:01.408
it's not libvert. Apple decided
to implement a special segment

00:09:01.408,00:09:05.345
in macro files, for, uh, special
for dynamic linker usage. The

00:09:05.345,00:09:09.182
segment calls "LinkEdit" it, it
consists information about, uhm,

00:09:09.182,00:09:13.753
process of linking and binding
symbols, during dynamic linkage.

00:09:13.753,00:09:17.557
It relies on, uh, special
command called "DYLD_INFO" uh,

00:09:17.557,00:09:21.027
which serves as table of content
for LinkEdit, and, tsh, here

00:09:21.027,00:09:24.264
what we can see LinkEdit.
"Rebasing info" which contain

00:09:24.264,00:09:28.034
rebasing opcodes, "Bind info"
opcodes required for import

00:09:28.034,00:09:32.238
symbols, uh, "lazy bind info",
"weak bind info", symbol binding

00:09:32.238,00:09:35.208
for for lazy and weak, uhm,
symbols correspondingly; and

00:09:35.208,00:09:38.678
"Export info". There is a great
article about how it works by

00:09:38.678,00:09:42.348
John Tourtellott website, so if
you're interested please take a

00:09:42.348,00:09:46.319
look. [pause] So, as I say it
use special opcodes, here's

00:09:46.319,00:09:50.089
looks like. Uh, these opcodes,
are used by DYLD binder

00:09:50.089,00:09:54.227
function, during dynamic, uh,
linkage. And we can reuse this

00:09:54.227,00:09:58.631
information and update, uhm,
bind addresses to point to our

00:09:58.631,00:10:02.235
functions. So, basically we can,
uh, intercept and hook

00:10:02.235,00:10:06.773
functions. This is how
interposing works. [pause] Uh,

00:10:06.773,00:10:09.509
few words about
"dyld_shared_cache". So what is

00:10:09.509,00:10:13.580
it? Uh, starting from iOS 3.1,
Apple, uh, move all the

00:10:13.580,00:10:15.748
frameworks and libraries to one
big file called the shared

00:10:15.748,00:10:18.551
cache. It removed all the
original files from disk, and I

00:10:18.551,00:10:19.953
think they use it for
performance and security

00:10:19.953,00:10:24.958
reasons. Uh, it's going lowered
to each process space, it's, uh,

00:10:27.327,00:10:31.397
have a, uh, ASLR slide which is
randomized per device reboot.

00:10:31.397,00:10:37.370
[pause] Uhm... Previously, uh,
in iOS 8, uh, Apple use, uh,

00:10:37.370,00:10:41.641
special, d... uh, bind stops in
"dyld_shared_cache". So,

00:10:41.641,00:10:44.844
basically, during dynamic
linkage the stop address will be

00:10:44.844,00:10:49.015
updated. Uhm, but, starting from
iOS 9 they start to break local

00:10:49.015,00:10:54.220
aid, uh, function of says just
inside the hash. So, the uhm,

00:10:54.220,00:10:57.524
like, bind stop it's not using
it anymore. And, it, it was a

00:10:57.524,00:11:00.026
big, a really big problem for
me. So, basically, interposing

00:11:00.026,00:11:02.896
is not working, uhm, also,
offsets are hardcoded and, eh,

00:11:02.896,00:11:06.733
so, what, what we can do is
that... cause, uh, our project

00:11:06.733,00:11:09.602
heavily rely on the function
hooking. So, I start, maybe we

00:11:09.602,00:11:13.306
can use, uh, trampolines. So
remember there is a technique,

00:11:13.306,00:11:17.744
to, uh, hook a functions which
based on direct memory

00:11:17.744,00:11:21.381
overwrite, so... Here's an
example of we want to hook the

00:11:21.381,00:11:25.084
function A, uh, we overwrite
just few instruction of function

00:11:25.084,00:11:30.557
A with the jump to function B.
And, uh, redirect, uh, execution

00:11:30.557,00:11:35.028
vector. In the case if you want
to skip a hook, we can save the

00:11:35.028,00:11:39.766
original, stolen instruction in,
uhm, allocated memory, execute

00:11:39.766,00:11:44.804
them first and then jump to,
uhm, point in, uh, function A

00:11:44.804,00:11:48.041
that executed just after jump.
So, basically, we reconstruct

00:11:48.041,00:11:52.245
all function A, uh, instructions
and executed without a hook. So,

00:11:52.245,00:11:57.450
yea, trampolines may work, uhm,
but as we remember there are

00:11:57.450,00:12:01.955
memory protections on iOS that
not allowed to change, uhm,

00:12:01.955,00:12:04.991
memory regions. So... for write
to trampoline the region should

00:12:04.991,00:12:08.161
be writable and how we can
change, uh, executable region to

00:12:08.161,00:12:12.999
be writable. Well, even if you
can do that, how swith... how to

00:12:12.999,00:12:16.202
switch it back to be executable?
And, uh, the main question,

00:12:16.202,00:12:19.372
there is a code sign check, on,
on a page load how we can bypass

00:12:19.372,00:12:24.010
it. So, I start playing with,
uhm, memory allocations and have

00:12:24.010,00:12:27.647
an idea "What if we can allocate
a new memory region, with

00:12:27.647,00:12:31.117
readable, writable permissions,
just on the same address where

00:12:31.117,00:12:36.255
the executable region is?".
[pause] So, long story short we

00:12:36.255,00:12:38.791
can use "mmap", with, uhm, "MAP
ANON", "MAP_PRIVATE" and

00:12:38.791,00:12:42.061
"MAP_FIXED" flags, overwrite
executable region with readable/

00:12:42.061,00:12:45.198
writable, uh, copy original
content back, and yea... We get,

00:12:45.198,00:12:49.869
uh, writable memory. Uh, how we
can switch it back to be

00:12:49.869,00:12:52.939
executable? Well, that's easy.
Uhm, as its, ANON_MEM...

00:12:52.939,00:12:57.443
ANON_MEMORY we can use, we can
just use "mprotect" syscall for

00:12:57.443,00:13:02.015
that. And, uh, sounds like a
plan... We can, take, uh,

00:13:02.015,00:13:07.553
function pointer, get, uhm...
page address pointer for... uh,

00:13:07.553,00:13:10.456
function is located. Copy
original page content to some

00:13:10.456,00:13:15.395
temporary buffer, mmap new
readable/ writable page over;

00:13:15.395,00:13:18.297
uh, copy original content back,
write the trampoline, switch it

00:13:18.297,00:13:22.201
to, to be executable, and... we
got killed by code sign! So,

00:13:22.201,00:13:27.206
codesign is still a problem...
Is there any ways to bypass it?

00:13:27.206,00:13:30.576
Uh, well, I start playing with
codesign implementation in, uh,

00:13:30.576,00:13:34.380
in XUML, as you remember, page
hash got checked on a page

00:13:34.380,00:13:37.817
fault. So I have an idea, what,
what if we can prevent a page

00:13:37.817,00:13:42.522
fault, maybe we can prevent a
codesign check. I found API,

00:13:42.522,00:13:46.092
like mlock, so if you look in a
page it will be not triggered

00:13:46.092,00:13:51.064
for a page fault and there is no
codesign check. Here is how full

00:13:51.064,00:13:55.168
attack looked like... Uh, we get
a function pointer, get page

00:13:55.168,00:13:58.071
base, copy page content to temp
buffer, uh, allocate a new

00:13:58.071,00:14:02.675
readable/ write page over, the,
original one. Copy page content

00:14:02.675,00:14:06.446
back, look in the page, write in
the trampoline code and

00:14:06.446,00:14:09.449
protection page to be
executable. So it completely

00:14:09.449,00:14:12.919
solve my problem with a function
hooking, and even this technique

00:14:12.919,00:14:17.623
was used later in public yellow
jail break. [pause] But I want

00:14:17.623,00:14:21.194
to go deeper. So I started
playing with uh, a dynamic

00:14:21.194,00:14:24.697
linker, uh, remember dynamic
linkers a part of a process...

00:14:24.697,00:14:27.734
and it's responsible for mapping
segments in a memory, loading

00:14:27.734,00:14:30.670
code signature blob from disk,
and even forcing the kernel to

00:14:30.670,00:14:34.941
do the actual codesign check. It
rely on, uh, "fcntl" syscall,

00:14:34.941,00:14:39.512
for loading code signatures so
if it can, overwrite or hook

00:14:39.512,00:14:43.850
fcntl, we can prevent code
signature load from disk.

00:14:43.850,00:14:47.186
[pause] The next interesting guy
is "xmmap", uh, dynamic linker

00:14:47.186,00:14:52.158
use it for, as a wrapper for x,
xmmap, for mapping the segments.

00:14:52.158,00:14:57.130
So, idea is if it can hook
xmmap, and lock, mlock, all the

00:14:57.130,00:15:01.534
executable regions during the
mapping we can prevent the, uh,

00:15:01.534,00:15:04.670
the codesign check. This is
basically how "cs_bypass" was

00:15:04.670,00:15:09.675
born, uh, we hook fcntl and
return -1 to prevent code

00:15:11.778,00:15:15.748
signature loading. The next is
we hook in xmmap, mlock all the

00:15:15.748,00:15:18.818
regions it has executable
permissions, and there is just

00:15:18.818,00:15:22.088
step number three, "dlopen"
unsigned code. [pause] Uhm, this

00:15:22.088,00:15:25.925
technique was open sourced by,
uh, a guy Lookout udesco, and is

00:15:25.925,00:15:30.530
available on GitHub so you can
check it. Uhm, now it's demo

00:15:30.530,00:15:35.535
time! [pause] So... I have a few
apps here. Uhm..., first

00:15:40.573,00:15:43.409
checking how this exploit works,
let's start from one called

00:15:43.409,00:15:46.612
"unsigned code". So what we have
inside unsigned code folder?

00:15:46.612,00:15:51.617
Uhm, mfile and actually make
file. The IO is just a simple

00:15:53.719,00:15:57.456
program that dump in the log
"I'm unsigned code", running in

00:15:57.456,00:16:02.395
your computer, page nearby and
terminate the process. Uhm...

00:16:04.530,00:16:07.834
[pause]. So, uhm, here's how the
make file look like, as we see

00:16:07.834,00:16:14.006
there is no codesign step in a
make file, we can build it, and,

00:16:14.006,00:16:17.944
uh, try to run in our non
jailbroken device. To prove that

00:16:17.944,00:16:22.949
there is no codesign, uhm..., on
a file, I use the "O-tool" and

00:16:22.949,00:16:28.487
looking for lc code signature.
As you see, it's not found.

00:16:28.487,00:16:34.227
[pause] Uh, so, it should, it
should dump, uh, unsigned code

00:16:34.227,00:16:37.063
right on, right on your
computers. For testing that I

00:16:37.063,00:16:42.635
have a iPad mini, which is non
jail broken 9.2.1, which have a

00:16:42.635,00:16:46.239
cs_bypass, loader here that use
mlock exploit and, uh,

00:16:46.239,00:16:50.243
continuously check for, uhm,
shared document folder for any

00:16:50.243,00:16:54.347
markup files, execute them. So
what I'm gonna do, I am

00:16:54.347,00:17:01.153
uploading my unsigned code to
shared folder... [pause] And,

00:17:01.153,00:17:06.158
run iOS cs_log. To get, uh, uh,
ns log dump. [pause] There's a

00:17:09.395,00:17:14.400
bunch of logs [pause] So, yea,
if you run cs_bypass it will

00:17:16.636,00:17:21.540
dl_open the unsigned code. Yea,
the process got terminated,

00:17:21.540,00:17:25.144
because we returned "zero" but
we have in, uhm, syslog,

00:17:25.144,00:17:29.181
"unsigned code run in your
computers" nearby it. [pause]

00:17:29.181,00:17:33.552
The next example is more
interesting, uh, it's called a

00:17:33.552,00:17:36.455
"Flappy bird", it is a game that
was pulled from App Store a few

00:17:36.455,00:17:42.061
years ago. I have my copy,
uhm... I decrypted, and removed,

00:17:42.061,00:17:46.799
uh, codesign from a file and I'm
gonna install it on, on

00:17:46.799,00:17:50.970
non-jailbroken iPad. [pause]
Again, to prove that it's not

00:17:50.970,00:17:54.073
signed I use the O-tool to check
for lc_code signature. [pause]

00:18:03.082,00:18:06.852
[keyboard sounds] Yip, there is
not code signature here. [pause]

00:18:06.852,00:18:11.857
So, the next step is to upload
to shared documents to device...

00:18:21.567,00:18:26.339
[audience noise] [pause] And...
you run cs_bypass. [pause] Oh!

00:18:26.339,00:18:30.309
We get a Flappy Bird game... So
it's fully, functional as the

00:18:30.309,00:18:33.779
the original one, uhm, yea, I'm
not that good at Flappy bird,

00:18:33.779,00:18:36.949
and we are running out of
time... [laughter] So I will...

00:18:36.949,00:18:41.487
I will switch to the next slide.
As the final words I wanna tell

00:18:41.487,00:18:45.358
how the future codesign attacks
may look like. First of all, the

00:18:45.358,00:18:49.695
hide executable segment. So,
the, it is... it is idea based

00:18:49.695,00:18:53.499
on overlapping executable
segment with non-executable, so

00:18:53.499,00:18:57.603
we're basically, hide it from,
from a kernel. This stuff is not

00:18:57.603,00:19:01.640
executable. [pause] This attack
was heavily used by TayG and

00:19:01.640,00:19:05.411
Pangu jailbreaks, uhm, but look
like starting from iOS 9, Apple

00:19:05.411,00:19:09.849
really harden it in, uh, in dyld
so... I haven't seen any attacks

00:19:09.849,00:19:13.719
anymore. Next one is the hook
dyld functions it is the same

00:19:13.719,00:19:16.956
attack that I just show you.
With cs_bypass, so if we can

00:19:16.956,00:19:21.527
hook or, uh, redirect dynamic
linker function we can control

00:19:21.527,00:19:24.964
how the dynamic linker maps
segments. We can hide a segment

00:19:24.964,00:19:29.535
from, uh, codesign check. And
last but not least, uh, hook or

00:19:29.535,00:19:34.173
update libmis functions. So
"libmis" is a helper in, uhm, in

00:19:34.173,00:19:38.844
the user land, which help AMFID
to check, uh, cms_blob, check,

00:19:38.844,00:19:43.716
uh, provision profiles and so
on. If you can update or hook

00:19:43.716,00:19:48.054
the functions we can win, uhm,
codesign bottle in user land.

00:19:48.054,00:19:51.323
This technique was heavily used
by Evasion 7 and Pengu 9

00:19:51.323,00:19:57.630
jailbreaks. [pause] Uhm, yea...
I think we're just in time, so

00:19:57.630,00:20:02.601
if you get, questions, catch me
downstairs or follow me on

00:20:02.601,00:20:08.074
Twitter. [pause] Yea, I think
that's all. [applause] >> Thank

00:20:08.074,00:20:10.743
you! [applause]