Technical Analysis of the Pegasus Exploits on iOS

API functions, 32stage2 calls a subroutine (identified in this report as initialize) that in turn
calls several o<strong>the</strong>r subroutines, each <strong>of</strong> which is responsible for loading additional API functions
in addition to performing various startup tasks.
The grouping <strong>of</strong> <strong>the</strong> API functions being loaded (in terms <strong>of</strong> which API functions are loading by
which Stage 2 functions) and <strong>the</strong> inclusion <strong>of</strong> multiple API functions being loaded multiple times
suggests that <strong>the</strong> API loading is specific to individual components or operations <strong>of</strong> <strong>the</strong> Stage 2
binary. For instance, as discussed later, a pair <strong>of</strong> functions are responsible for decompressing
<strong>the</strong> jailbreak files, changing <strong>the</strong>ir permissions via chmod, and positioning <strong>the</strong> files in <strong>the</strong> correct
location on <strong>the</strong> victim’s iPhone. The API functions responsible for <strong>the</strong>se operations are all
loaded by a self-contained function. The loading function only loads those API functions that are
necessary for <strong>the</strong> described operations, and <strong>the</strong> APIs are not shared with any o<strong>the</strong>r part <strong>of</strong> <strong>the</strong>
Stage 2 system.
The analysis <strong>of</strong> Stage 2 was also made somewhat easier given <strong>the</strong> heavy use <strong>of</strong> debug logging
throughout <strong>the</strong> binary. Calls to <strong>the</strong> logging sub-system generally reference <strong>the</strong> original file
names used by <strong>the</strong> exploit developers. The presence <strong>of</strong> this debugging code discloses <strong>the</strong>
presence <strong>of</strong> at least <strong>the</strong> following individual modules (or subsystems):
1. fs.c - Loads API functions related to file and file system management such as ftw,
open, read, rename, and mount
2. kaslr.c - Loads API functions such as IORegistryEntryGetChildIterator,
IORegistryEntryGetProperty, and IOServiceGetMatchingService that
relate to finding <strong>the</strong> address <strong>of</strong> <strong>the</strong> kernel using a vulnerability in <strong>the</strong>
io_service_open_extended function
3. bh.c - Loads API functions that relate to <strong>the</strong> decompression <strong>of</strong> next stage payloads and
<strong>the</strong>ir proper placement on <strong>the</strong> victim’s iPhone by using functions such as
BZ2_bzDecompress, chmod, and malloc
4. safari.c - Loads API functions such as sync, exit, and strcpy that are used for
clearing Safari cache files and terminating <strong>the</strong> Safari process. This cleanup is required
for <strong>the</strong> case where we succeed and exit cleanly, as <strong>the</strong> Safari crash cleanup (described
in <strong>the</strong> Stage 1 writeup) will never occur.
These artifacts suggest that <strong>the</strong> Stage 2 binary is based on a modular design philosophy or, at
<strong>the</strong> very least, is made up <strong>of</strong> various library source code files that are ultimately tied toge<strong>the</strong>r to
form <strong>the</strong> Stage 2 binary. The various components that make up <strong>the</strong> Stage 2 exploit were likely
designed to be reused across multiple iOS exploit chains.
Environment Setup and Platform Determination
After initialize completes, Stage 2 calls a function that specifies a global callback function
that is used whenever Stage 2 terminates due to an error. Based on <strong>the</strong> filename supplied in <strong>the</strong>
writeLog, most likely <strong>the</strong> function is an assert-style callback.
Page 13