VIRUS BULLETIN www.virusbtn.

com

Covering the
global threat landscape

DYLIB HIJACKING ON OS X attacker’s library before the legitimate DLL and blindly load
it into the context of the vulnerable application.
Patrick Wardle
Synack, USA This is illustrated in Figures 1 and 2, where a vulnerable
application (Figure 1) is hijacked by a malicious DLL that
has been planted in the primary search directory (Figure 2).
(This paper was presented at CanSecWest 2015.)
DLL hijacking is a well known class of attack which was
always believed only to affect the Windows OS. However,
this paper will show that OS X is similarly vulnerable to
dynamic library hijacks. By abusing various features and
undocumented aspects of OS X’s dynamic loader, attackers
need only to ‘plant’ specially crafted dynamic libraries to
have malicious code automatically loaded into vulnerable
applications. Using this method, such attackers can perform
a wide range of malicious and subversive actions, including
stealthy persistence, load-time process injection, security Figure 1: Loading the legitimate system DLL.
software circumvention, and a Gatekeeper bypass (affording
opportunities for remote infection). Since this attack
abuses legitimate functionality of the OS, it is challenging
to prevent and unlikely to be patched. However, this
paper will present techniques and tools that can uncover
vulnerable binaries as well as detect if a hijacking has
occurred.

BACKGROUND
Before detailing the dynamic library (dylib) hijacking attack Figure 2: Loading the attacker’s malicious DLL.
on OS X, dynamic link library (DLL) hijacking on Windows
will briefly be reviewed. As the two attacks are conceptually DLL hijacking attacks initially gained notoriety in 2010
quite similar, examining the well-understood Windows attack and quickly grabbed the attention of both the media and
can help in gaining an understanding of the former. malicious attackers. Also known as ‘binary planting’,
‘insecure library loading’ or ‘DLL preloading’, the discovery
DLL hijacking on Windows is best explained by Microsoft:
of this vulnerability is often attributed to H.D. Moore [2, 3].
‘When an application dynamically loads a dynamic link However, the NSA was actually the first to note this flaw,
library (DLL) without specifying a fully qualified path 12 years prior to Moore, in 1998. In the NSA’s unclassified
name, Windows tries to locate the DLL by searching ‘Windows NT Security Guidelines’, the organization both
a well-defined set of directories. If an attacker gains describes and warns of DLL hijacking:
control of one of the directories, they can force the
‘It is important that penetrators can’t insert a “fake”
application to load a malicious copy of the DLL instead
DLL in one of these directories where the search finds it
of the DLL that it was expecting.’ [1]
before a legitimate DLL of the same name.’ [4]
To reiterate, the default search behaviour of the Windows
To an attacker, DLL hijacking affords many useful scenarios.
loader is to search various directories (such as the
For example, such attacks can allow a malicious library to
application’s directory or the current working directory)
stealthily be persisted (without modifying the registry or
before the Windows system directory. This can be
other components of the OS), privileges to be escalated, and
problematic if an application attempts to load a system
even provides the means for remote infection.
library via an insufficiently qualified path (i.e. just by its
name). In such a scenario, an attacker may ‘plant’ a malicious Malware authors were fairly quick to realize the benefits of
DLL (the name of which matches that of the legitimate DLL hijacking. In a blog post entitled ‘What the fxsst?’ [5],
system DLL) in one of the primary search directories. With Mandiant researchers described how they had uncovered
this malicious DLL in place, the Windows loader will find the various unrelated malware samples all named ‘fxsst.dll’.

MARCH 2015 1
 VIRUS BULLETIN www.virusbtn.com

Figure 3: Carberp abusing a DLL hijack to bypass UAC.

Upon closer inspection, they found that the samples were Specifically, the research sought to answer the question:
all exploiting a DLL hijacking vulnerability in the Windows could an attacker plant a malicious OS X dynamic library
shell (Explorer.exe), that provided a stealthy method of (dylib) such that the OS’s dynamic loader would load
persistence. Specifically, as Explorer.exe was installed in it automatically into a vulnerable application? It was
C: \Windows, planting a library named fxsst.dll in the same hypothesized that, much like DLL hijacking on Windows,
directory would result in the persistence of the malicious such an attack on OS X would provide an attacker with a
DLL as the loader searched the application’s directory before myriad of subversive capabilities. For example, stealthy
the system directory where the legitimate fxsst.dll lived. persistence, load-time process injection, security software
Another example of malware using a DLL hijack can be circumvention, and perhaps even ‘remote’ infection.
found within the leaked source code for the banking trojan It should be noted that several constraints were placed
‘Carberp’ [6]. The source code shows the malware bypassing upon this undertaking. First, success was constrained
User Account Control (UAC) via a DLL hijack of by disallowing any modification to the system – except
sysprep.exe (see Figure 3). This binary is an auto-elevated for the creation of files (and if necessary folders). In
process, meaning that it requires no UAC prompt to gain other words, the research ignored attack scenarios that
elevated status. Unfortunately, it was found to be vulnerable required the subverting of existing binaries (e.g. patching)
to a DLL hijacking attack and would load a maliciously or modifications to existing OS configuration files (e.g.
planted DLL (named cryptbase.dll) into its elevated process ‘auto-run’ plists, etc.). As such attacks are well known and
context [7]. trivial both to prevent and to detect, they were ignored. The
These days, DLL hijacking on Windows is somewhat research also sought a method of hijack that was completely
uncommon. Microsoft was swift to respond to attacks, independent of the user’s environment. OS X provides
patching vulnerable applications and detailing how others various legitimate means to control the environment in
could avoid this issue (i.e. simply by specifying an absolute, a manner that could coerce the loader to load malicious
or fully qualified path for imported DLLs) [8]. Moreover, libraries automatically into a target process. These
OS-level mitigations were introduced, which if enabled via the methods, such as setting the DYLD_INSERT_LIBRARIES
SafeDllSearchMode and/or CWDIllegalInDllSearch registry environment variable, are user-specific and, again, well
keys, stop the majority of DLL hijackings generically. known and easy to detect. As such, they were of little
interest and were ignored.
The research began with an analysis of the OS X dynamic
DYLIB HIJACKING ON OS X linker and loader, dyld. This binary, found within /usr/bin,
It has always been assumed that dynamic library hijacking provides standard loader and linker functionality including
was a Windows-only problem. However, as one astute finding, loading and linking dynamic libraries.
StackOverflow user pointed out in 2010, ‘any OS which As Apple has made dyld open source [10], analysis was
allows for dynamic linking of external libraries is fairly straightforward. For example, reading the source code
theoretically vulnerable to this’ [9]. It took until 2015 for provided a decent understanding of dyld’s actions as an
him to be proved correct – this paper will reveal an equally executable is loaded and its dependent libraries are loaded
devastating dynamic library hijack attack affecting OS X. and linked in. The following briefly summarizes the initial
The goal of the research presented here was to determine steps taken by dyld (focusing on those that are relevant to the
whether OS X was vulnerable to a dynamic library attack. attack described in this paper):

2 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

1. As any new process is started, the kernel sets the is wrapped in a try/catch block to detect dylibs that fail to
user-mode entry point to point to __dyld_start load.
(dyldStartup.s). This function simply sets up the stack
then jumps to dyldbootstrap::start(), which in turn calls
the loader’s _main().
2. Dyld’s _main() function (dyld.cpp) invokes link(),
which then calls an ImageLoader object’s link() method
to kick off the linking process for the main executable.
3. The ImageLoader class (ImageLoader.cpp) exposes
many functions that dyld calls in order to perform
various binary image loading logic. For example,
the class contains a link() method. When called, this
invokes the object’s recursiveLoadLibraries() method to
perform the loading of all dependent dynamic libraries.
4. The ImageLoader’s recursiveLoadLibraries() method
determines all required libraries and invokes the
context.loadLibrary() function on each. The context
object is simply a structure of function pointers that
is passed around between methods and functions. The
loadLibrary member of this structure is initialized with
the libraryLocator() function (dyld.cpp), which simply Figure 4: Error logic for dylib load failures.
calls the load() function.
Unsurprisingly, there is logic to throw an exception (with a
5. The load() function (dyld.cpp) calls various helper message) if a library fails to load. Interestingly though, this
functions within the same file, named loadPhase0() exception is only thrown if a variable named ‘required’ is set
through to loadPhase5(). Each function is responsible to true. Moreover, the comment in the source code indicates
for handling a specific task of the load process, such as that failure to load ‘weak’ libraries is OK. This seems to
resolving paths or dealing with environment variables indicate that some scenario exists where the loader is OK
that can affect the load process. with missing libraries – perfect!
6. After loadPhase5(), the loadPhase6() function Digging deeper into the loader’s source code revealed
finally loads (maps) the required dylibs from the file where this ‘required’ variable is set. Specifically,
system into memory. It then calls into an instance of the doGetDependentLibraries() method of the
the ImageLoaderMachO class in order to perform ImageLoaderMacho class parses the load commands
Mach-O-specific loading and linking logic on each dylib. (described below) and sets the variable based on whether
With a basic understanding of dyld’s initial loading logic, or not the load command is of type LC_LOAD_WEAK_
the research turned to hunting for logic that could be abused DYLIB.
to perform a dylib hijack. Specifically, the research was Load commands are an integral component of the Mach-O
interested in code in the loader that didn’t error out if a dylib file format (OS X’s native binary file format). Embedded
wasn’t found, or code that looked for dylibs in multiple immediately following the Mach-O header, they provide
locations. If either of these scenarios was realized within various commands to the loader. For example, there are load
the loader, it was hoped that an OS X dylib hijack could be commands to specify the memory layout of the binary, the
performed. initial execution state of the main thread, and information
The initial scenario was investigated first. In this case, it about the dependent dynamic libraries for the binary. To
was hypothesized that if the loader could handle situations view the load commands of a compiled binary, a tool such as
where a dylib was not found, an attacker (who could MachOView [11] or /usr/bin/otool (with the -l command-line
identify such situations) could place a malicious dylib in flag) can be used (see Figure 6).
this presumed location. From then on, the loader would The code in Figure 5 shows the loader iterating over all the
now ‘find’ the planted dylib and blindly load the attacker’s load commands within a binary, looking for those that specify
malicious code. a dylib import. The format of such load commands (e.g.
Recall that the loader calls the ImageLoader class’s LC_LOAD_DYLIB, LC_LOAD_WEAK_DYLIB, etc.) can
recursiveLoadLibraries() method to both find and load all be found in the mach-o/loader.h file.
required libraries. As shown in Figure 4, the loading code

MARCH 2015 3
 VIRUS BULLETIN www.virusbtn.com

Figure 5: Setting the ‘required’ variable (src file?).

Figure 6: Dumping Calculator.app’s load commands with MachOView.

imported via LC_LOAD_WEAK_DYLIB are optional (i.e.

‘weak’). In the case of the former (LC_LOAD_DYLIB),
an exception will be thrown if the required dylib is not
found, causing the loader to abort and terminate the process.
However, in the latter case (LC_LOAD_WEAK_DYLIB), the
dylib is optional. If such a ‘weak’ dylib is not found, no harm
is done, and the main binary will still be able to execute.

Figure 7: The format of the LC_LOAD_* load commands.

Figure 8: Attempting to load a ‘weak’ dylib (LC_LOAD_
For each dylib that an executable was dynamically linked
WEAK_DYLIB).
against, it will contain an LC_LOAD_* (LC_LOAD_DYLIB,
LC_LOAD_WEAK_DYLIB, etc.) load command. As the This loader logic fulfilled the first hypothetical hijack
loader code in Figures 4 and 5 illustrates, LC_LOAD_DYLIB scenario, and as such, provided a dylib hijack attack on OS X.
load commands specify a required dylib, while libraries Namely, as illustrated in Figure 9, if a binary specifies a weak

4 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

import that is not found, an attacker can place a malicious Dyld will iterate over an rp->paths vector, dynamically
dylib in this presumed location. From then on, the loader will building paths (held within the ‘newPath’ variable) which are
‘find’ the attacker’s dylib and blindly load this malicious code then loaded via the loadPhase4() function. While this does
into the process space of the vulnerable binary. seem to fulfil the requirement of the second hijack scenario
(i.e. dyld looking in multiple locations for the same dylib), a
closer examination was required.
The comment on the first line of dyld’s source in Figure
10 mentions the term ‘@rpath.’ According to Apple
documentation, this is a special loader keyword (introduced
in OS X 10.5, Leopard) that identifies a dynamic library as
a ‘run-path-dependent library’ [12]. Apple explains that a
Figure 9: Hijacking an application via a malicious ‘weak’ run-path dependent library ‘is a dependent library whose
dylib. complete install name (path) is not known when the library
Recall that another hijack attack was hypothesized if a is created’ [12]. Other online documentation such as [13]
scenario existed where the loader searched for dynamic and [14] provides more detail, describing the role of these
libraries in multiple locations. In this case, it was thought that libraries and explaining how the @rpath keyword enables:
an attacker would be able to place a malicious dylib in one ‘frameworks and dynamic libraries to finally be built only
of the primary search directories (if the legitimate dylib was once and be used for both system-wide installation and
found elsewhere). It was hoped that the loader would then embedding without changes to their install names, and
find the attacker’s malicious dylib first (before the legitimate allowing applications to provide alternate locations for a
one), and thus naively load the attacker’s malicious library. given library, or even override the location specified for a
deeply embedded library’ [14].
On OS X, load commands such as LC_LOAD_DYLIB
always specify a path to the dynamic library (as opposed While this feature allows software developers to deploy
to Windows, where just the name of the library may be complex applications more easily, it can also be abused to
provided). Because a path is provided, dyld generally does perform a dylib hijack. This is true since in order to make use
not need to search various directories to find the dynamic of run-path-dependent libraries, ‘an executable provides a list
library. Instead, it can simply go directly to the specified of run-path search paths, which the dynamic loader traverses
directory and load the dylib. However, analysis of dyld’s at load time to find the libraries’ [12]. This is realized in code
source code uncovered a scenario in which this generality did in various places within dyld, including the code snippet that
not hold. was presented in Figure 10.

Looking at the loadPhase3() function in dyld.cpp revealed Since run-path dependent libraries are relatively novel and
some interesting logic, as shown in Figure 10. somewhat unknown, it seemed prudent to provide an example
of building both a legitimate run-path-dependent library and a
sample application that links against it.
A run-path-dependent library is a normal dylib whose install
name is prefixed with ‘@rpath’. To create such a library in
Xcode one can simply set the dylib’s installation directory to
‘@rpath’, as shown in Figure 11.

Figure 11: Building a run-path-dependent library.

Once the run-path-dependent library was compiled,

examination of the LC_ID_DYLIB load command (which
Figure 10: Loading ‘rpath’ dependent libraries. contains identifying information about the dylib) showed the

MARCH 2015 5
 VIRUS BULLETIN www.virusbtn.com

run-path of the dylib. Specifically, the ‘name’ (path) within command with the run-path-dependent dylib tells the loader,
the LC_ID_DYLIB load command contained the dylib’s ‘I depend on the rpathLib dylib, but when built, I didn’t know
bundle (rpathLib.framework/ Versions/A/rpathLib), prefixed exactly where it would be installed. Please use my embedded
with the ‘@rpath’ keyword (see Figure 12). run-path search paths to find it and load it!’
The run-path search paths that were entered into the
‘Runpath Search Paths’ list in Xcode generated LC_RPATH
load commands – one for each search directory. Dumping
the load commands of the compiled application revealed
the embedded LC_RPATH load commands, as shown in
Figure 15.

Figure 12: ‘@rpath’ embedded in the dylib’s ‘install name’

(path).
Building an application that linked against a
run-path-dependent library was fairly straightforward as well.
First, the run-path-dependent library was added to the ‘Link
Binary With Libraries’ list in Xcode. Then a list of run-path
search directories was added to the ‘Runpath Search Paths’ Figure 15: The embedded run-path search paths (directories).
list. As will be shown, these search directories are traversed
by the dynamic loader at load time in order to locate the With a practical understanding of run-path-dependent dylibs
run-path-dependent libraries. and an application that linked against one, it was easy to
understand dyld’s source code which was responsible for
handling this scenario at load time.
When an application is launched, dyld will parse the
application’s LC_LOAD_* load commands in order to load
and link all dependent dylibs. To handle run-path-dependent
libraries, dyld performs two distinct steps: it extracts all
embedded run-path search paths and then uses this list to find
and load all run-path-dependent libraries.
Figure 13: Linking in a @rpath’d dylib and specifying the
run path search paths. In order to extract all embedded run-path search paths, dyld
invokes the getRPaths() method of the ImageLoader class.
Once the application was built, dumping its load commands This method (invoked by the recursiveLoadLibraries()
revealed various commands associated with the run-path method) simply parses the application for all LC_RPATH
library dependency. A standard LC_LOAD_DYLIB load load commands. For each such load command, it extracts the
command was present for the dependency on the run-path- run-path search path and appends it to a vector (i.e. a list), as
dependent dylib, as shown in Figure 14. shown in Figure 16.

Figure 14: The dependency on the @rpath’d dylib.

In Figure 14, note that the install name (i.e. path) to the
run-path-dependent dylib is prefixed with ‘@rpath’ and
matches the name value from the LC_ID_DYLIB load
command of the run-path-dependent dylib (see Figure 12). Figure 16: Extracting and saving all embedded run-path
This application’s embedded LC_LOAD_DYLIB load search paths.

6 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

With a list of all embedded run-path search paths, dyld can The astute reader will recognize that this loader logic opens
now ‘resolve’ all dependent run-path-dependent libraries. up yet another avenue for a dylib hijack attack. Specifically,
This logic is performed in the loadPhase3() function in if an application is linked against a run-path-dependent
dyld.cpp. Specifically, the code (shown in Figure 17) checks library, has multiple embedded run-path search paths, and the
to see if a dependent library’s name (path) is prefixed with the run-path-dependent library is not found in a primary search
‘@rpath’ keyword. If so, it iterates over the list of extracted path, an attacker can perform a hijack. Such a hijack may
run-path search paths, replacing the ‘@rpath’ keyword in the be accomplished simply by ‘planting’ a malicious dylib into
import with the current search path. Then it attempts to load any of the primary run-path search paths. With the malicious
the dylib from this newly resolved directory. dylib in place, any time the application is subsequently run,
the loader will find the malicious dylib first, and load it
blindly (see Figure 19).

Figure 19: Hijacking an application via a malicious ‘@rpath’

dylib.
To summarize the findings so far: an OS X system is vulnerable
to a hijacking attack given the presence of any application that:
Figure 17: Searching run-path search directories for
@rpath’d dylibs. 1. Contains an LC_LOAD_WEAK_DYLIB load
command that references a non-existent dylib.
It is important to note that the order of the directories that
or
dyld searches is deterministic and matches the order of the
embedded LC_RPATH load commands. Also, as is shown in 2. Contains both an LC_LOAD*_DYLIB load command
the code snippet in Figure 17, the search continues until the that references a run-path-dependent library (‘@rpath’)
dependent dylib is found or all paths have been exhausted. and multiple LC_RPATH load commands, with the run-
path-dependent library not found in a primary run-path
Figure 18 illustrates this search conceptually. The loader (dyld)
search path.
can been seen searching the various embedded run-path search
paths in order to find the required run-path-dependent dylib. The remainder of this paper will first walk through a
Note that in this example scenario, the dylib is found in the complete dylib hijack attack, then present various attack
second (i.e. non-primary) search directory (see Figure 18). scenarios (persistence, load-time process injection, ‘remote’
infection etc.), before concluding with some possible
defences to counter such an attack.
In order to assist the reader in gaining a deeper understanding
of dylib hijacking, it seems prudent to detail the trials, errors,
and ultimate success of a hijack attack. Armed with this
knowledge it will be trivial to understand attack automation,
attack scenarios, and practical defences.
Recall the previously described sample application
(‘rPathApp.app’) that was created in order to illustrate linking
against a run-path-dependent dylib. This application will be
the target of the hijack.
Figure 18: Dyld searching multiple run-path search A dylib hijack is only possible against a vulnerable
directories. application (that is to say, one that fulfils either of the

MARCH 2015 7
 VIRUS BULLETIN www.virusbtn.com

two previously described hijack conditions). Since the

example application (rPathApp.app) links against a
run-path-dependent dylib, it may be vulnerable to the
second hijack scenario. The simplest way to detect such a
vulnerability is to enable debug logging in the loader, then
simply run the application from the command line. To enable
such logging, set the DYLD_PRINT_RPATHS environment
variable. This will cause dyld to log its @rpath expansions
and dylib loading attempts. Viewing this output should
quickly reveal any vulnerable expansions (i.e. a primary Figure 22: The ‘malicious’ dylib placed in the primary
expansion that points to a non-existent dylib), as shown in run-path search path.
Figure 20.
Unfortunately, this initial hijack attempt failed and the
application crashed miserably, as shown in Figure 23.

Figure 20: The vulnerable (test) application, rPathApp.

Figure 20 shows the loader first looking for a required dylib Figure 23: Success! Then crash and burning.
(rpathLib) in a location where it does not exist. As was
shown in Figure 19, in this scenario, an attacker could plant a The good news, though, was that the loader found and
malicious dylib in this primary run-path search path and the attempted to load the hijacker dylib (see the ‘RPATH
loader will then load it blindly. successful expansion…’ log message in Figure 23). And
A simple dylib was created to act as a malicious hijacker although the application crashed, this was preceded by an
library. In order to gain automatic execution when loaded, informative and verbose exception, thrown by dyld. The
the dylib implemented a constructor function. Such a exception seemed self explanatory: the version of the hijacker
constructor is executed automatically by the operating dylib was not compatible with the required (or expected)
system when the dylib is loaded successfully. This is a nice version. Digging into the loader’s source code revealed the
feature to make use of, since generally code within a dylib code that triggered this exception, as shown in Figure 24.
isn’t executed until the main application calls into it via some
exported function.

Figure 21: A dylib’s constructor will automatically be

executed.
Once compiled, this dylib was renamed to match the target
(i.e. legitimate) library: rpathlib. Following this, the necessary
directory structure (Library/One/rpathLib.framework/
Versions/A/) was created and the ‘malicious’ dylib was
copied in. This ensured that whenever the application was
launched, dyld would now find (and load) the hijacker dylib Figure 24: Dyld extracting and comparing compatibility
during the search for the run-path dependent dylib. version numbers.

8 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

As can be seen, the loader invokes the doGetLibraryInfo() Once again, the exception was quite verbose, explaining
method to extract compatibility and current version numbers exactly why the loader threw it, and thus killed the
from the LC_ID_DYLIB load command of the library that application. Applications link against dependent libraries
is being loaded. This extracted compatibility version number in order to access functionality (such as functions,
(‘minVersion’) is then checked against the version that objects, etc.) that are exported by the library. Once a
the application requires. If it is too low, an incompatibility required dylib is loaded into memory, the loader will
exception is thrown. attempt to resolve (via exported symbols) the required
It was quite trivial to fix the compatibility issue (and thus functionality that the dependent library is expected to
prevent the exception) by updating the version numbers in export. If this functionality is not found, linking fails and
Xcode, and then recompiling, as shown in Figure 25. the loading and linking process is aborted, thus crashing
the process.
There were various ways to ensure that the hijacker
dylib exported the correct symbols, such that it would be
fully linked in. One naive approach would have been to
implement and export code directly within the hijacker
dylib to mimic all the exports of the target (legitimate)
dylib. While this would probably have succeeded, it
seemed complex and dylib specific (i.e. targeting another
Figure 25: Setting the compatibility and current version dylib would have required other exports). A more elegant
numbers. approach was simply to instruct the linker to look elsewhere
for the symbols it required. Of course, that elsewhere was
Dumping the LC_ID_DYLIB load command of the the legitimate dylib. In this scenario, the hijacker dylib
recompiled hijacker dylib confirmed the updated (and now would simply acts as a proxy or ‘re-exporter’ dylib, and as
compatible) version numbers, as shown in Figure 26. the loader would follow its re-exporting directives, no linker
errors would be thrown.

Figure 28: Re-exporting to the legitimate dylib.

Figure 26: Embedded compatibility and current version
numbers. It took some effort to get the re-exportation working
seamlessly. The first step was to return to Xcode and add
The updated hijacker dylib was re-copied into the several linker flags to the hijacker dylib project. These flags
application’s primary run-path search directory. Relaunching included ‘-Xlinker’, ‘reexport_library’, and then the path to
the vulnerable application again showed the loader ‘finding’ the target library which contained the actual exports that the
the hijacker dylib and attempting to load it. Alas, although vulnerable application was dependent upon.
the dylib was now seen as compatible (i.e. the version
number checks passed), a new exception was thrown and the
application crashed once again, as shown in Figure 27.

Figure 29: Required linker flags to enable re-exporting.

These linker flags generated an embedded LC_REEXPORT_

DYLIB load command that contained the path to the target
Figure 27: ‘Symbol not found’ exception. (legitimate) library, as shown in Figure 30.

MARCH 2015 9
 VIRUS BULLETIN www.virusbtn.com

Figure 30: Embedded LC_REEXPORT_DYLIB load

command.
However, all was not well. Since the re-export target of the
hijacker dylib was a run-path-dependent library, the name
field in the embedded LC_REEXPORT_DYLIB (extracted
from the legitimate dylib’s LC_ID_DYLIB load command)
began with ‘@rpath’. This was problematic since, unlike Figure 32: Successfully dylib hijacking a vulnerable
LC_LOAD*_DYLIB load commands, dyld does not resolve application.
run-path dependent paths in LC_REEXPORT_DYLIB load
commands. In other words, the loader will try to load executed. Since the malicious dylib contained the correct
‘@rpath/rpathLib.framework/Versions/A/rpathLib’ directly versioning information as well as re-exporting all symbols to
from the file system. This, of course, would clearly fail. the legitimate dylib, all the required symbols were resolved,
The solution was to resolve the embedded ‘@rpath’ path, thus ensuring no functionality within the application was lost
providing the full path of the target library in the LC_ or broken.
REEXPORT_DYLIB load command. This was accomplished
with one of Apple’s developer tools: install_name_tool.
To update the embedded install name (path) in the LC_ ATTACKS
REEXPORT_DYLIB load command, the tool was executed With a solid understanding of dylib hijacking on OS X behind
with the -change flag, the existing name (within the LC_ us, it is now time to illustrate some real-life attack scenarios
REEXPORT_DYLIB), the new name, and finally the path to and provide some practical defences.
the hijacker dylib, as shown in Figure 31.
Advanced adversaries understand the importance of
automating as many components of an attack as possible.
Such automation increases scale and efficiency, freeing the
attacker to focus on more demanding or complex aspects of
the attack.
The first component of the hijack attack that was automated
was the discovery of vulnerable applications. A Python
script, dylibHijackScanner.py (available for download at
[15]), was created to accomplish this task. After gathering
either a list of running processes or all executables on the
file system, the script intelligently parses the binaries’
Figure 31: Using install_tool_name to update the embedded Mach-O headers and load commands. To detect binaries
name (path). that may be hijacked via weak dylibs, the script looks for
LC_LOAD_WEAK_DYLIB load commands that reference
With the path in the LC_REEXPORT_DYLIB load command non-existent dylibs. Automatically detecting binaries that
updated correctly, the hijacked dylib was re-copied into the may be hijacked due to non-existent @rpath’d imports was a
application’s primary run-path search directory, and then little more complex. First, the script looks for a binary with at
the application was re-executed. As shown in Figure 32, this least one LC_LOAD*_DYLIB load command that references
finally resulted in success. a run-path-dependent dylib. If such a load command is found,
To summarize: since the rPathApp application linked against the script continues parsing the binary’s load commands
a run-path-dependent library which was not found in the looking for multiple LC_RPATHs. In the case that both these
initial run-path search directory, it was vulnerable to a dylib prerequisites hold true, the script checks to see whether the
hijack attack. Planting a specially compatible malicious run-path-dependent library import is found in a primary
dylib in the initial search path directory caused the loader to run-path search path. If the library does not exist, the script
load the hijacker dylib blindly each time the application was alerts the user that the binary is vulnerable. Executing the

10 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

scanner script revealed a surprising number of vulnerable at [15]), was created to perform this customization. First,
applications, including (as expected) the vulnerable test the script finds and parses the relevant LC_ID_DYLIB load
application, rPathApp.app. command within the target dylib (the legitimate dylib which
the vulnerable application loads). This allows the necessary
compatibility information to be extracted. Armed with this
information, the hijacker dylib is similarly parsed, until its
LC_ID_DYLIB load command is found. The script then
updates the hijacker’s LC_ID_DYLIB load command with
the extracted compatibility information, thus ensuring a
precise compatibility versioning match. Following this, the
re-export issue is addressed by updating the hijacker dylib’s
LC_REEXPORT_DYLIB load command to point to the
target dylib. While this could have been achieved by updating
the LC_REEXPORT_DYLIB load command manually, it
proved far easier simply to execute the install_name_tool
Figure 33: Automatically detecting vulnerable applications. command.
As can be seen in Figure 33, the scanner script found nearly Figure 34 shows the Python script automatically configuring
150 vulnerable binaries just on the author’s work laptop! a generic hijacker dylib in order to exploit the vulnerable
Interestingly, the majority of vulnerable applications fell into example application, rpathApp.app.
the more complex (from a prerequisite standpoint) ‘multiple
rpath’ category. Due to space constraints, the full list of
vulnerable applications cannot be shown here. However,
Table 1 lists several of the more widespread or well-
recognized applications that were found by the scanner script
to be vulnerable to a dylib hijack.

Application Company Vulnerability

iCloud Photos Apple rpath import
Xcode Apple rpath import
Word Microsoft rpath & weak import
Excel Microsoft rpath & weak import
Google Drive Google rpath import
Java Oracle rpath import
GPG Keychain GPG Tools rpath import
Figure 34: Automated hijacker creation.
Dropbox (garcon) Dropbox rpath import
Dylib hijacking can be used to perform a wide range of
Table 1: Common vulnerable applications.
nefarious actions. This paper covers several of these,
With an automated capability to uncover vulnerable including persistence, load-time process injection, bypassing
applications, the next logical step was to automate the creation security products, and even a Gatekeeper bypass. These
of compatible hijacker dylibs. Recall that two components of attacks, though highly damaging, are all realized simply
the hijacker dylib had to be customized in order to perform by planting a malicious dylib which abuses legitimate
a hijack successfully. First, the hijacker dylib’s versioning functionality provided by the OS loader. As such, they are
numbers had to be compatible with the legitimate dylib. trivial to accomplish yet unlikely to be ‘patched out’ or even
Second (in the case of the rpath hijack), the hijacker dylib also detected by personal security products.
had to contain a re-export (LC_REEXPORT_DYLIB) load Using dylib hijacking to achieve stealthy persistence is one
command that pointed to the legitimate dylib, ensuring that all of the most advantageous uses of the attack. If a vulnerable
required symbols were resolvable. application is started automatically whenever the system
It was fairly straightforward to automate the customization is rebooted or the user logs in, a local attacker can perform
of a generic dylib to fulfil these two prerequisites. A second a persistent dylib hijack to gain automatic execution of
Python script, createHijacker.py (also available for download malicious code. Besides a novel persistence mechanism, this

MARCH 2015 11
 VIRUS BULLETIN www.virusbtn.com

scenario affords the attacker a fairly high level of stealth. or mail client) may be targeted as well. Alternatively, a
First, it simply requires the planting of a single file – no legitimate vulnerable application could easily be made
OS components (e.g. startup configuration files or signed persistent in a variety of ways (for example registering it as
system binaries) are modified. This is important since such a Login Item, etc.), then persistently exploited. Although this
components are often monitored by security software or are latter scenario increases the visibility of the attack, the attacker
trivial to verify. Second, the attacker’s dylib will be hosted dylib would, of course, prevent any UI from being displayed.
within the context of an existing trusted process, making it Thus, it’s unlikely that the majority of users would notice a
difficult to detect as nothing will obviously appear amiss. legitimate (Apple) binary automatically being started (and
Of course, gaining such stealthy and elegant persistence exploited) in the background.
requires a vulnerable application that is automatically Process injection, or coercing an external process into
started by the OS. Apple’s iCloud Photo Stream Agent loading a dynamic library, is another useful attack scenario of
(/Applications/iPhoto.app/Contents/Library/LoginItems/ dylib hijacking. In the context of this paper, ‘injection’ refers
PhotoStreamAgent.app) is started automatically whenever a to load-time injection (i.e. whenever the process is started)
user logs in, in order to sync local content with the cloud. As as opposed to run-time injection. While the latter is arguably
luck would have it, the application contains multiple run-path more powerful, the former is far simpler and often achieves
search directories and several @rpath imports that are not the same level of damage.
found in the primary run-path search directory. In other
words, it is vulnerable to a dylib hijack attack. Using dylib hijacking to coerce an external process into
persistently loading a malicious dylib is a powerful and
stealthy technique. As with the other dylib hijack attack
scenarios, it does not require any modifications to OS
components or binaries (e.g. patching the target process’s
on-disk binary image). Moreover, since the planted dylib
will persistently and automatically be loaded into the
target process space each time the process is started, an
attack no longer needs a separate monitoring component
Figure 35: Apple’s vulnerable Photo Stream Agent. (to detect when the target process is started, then inject a
malicious dylib). Also, since the attacker simply requires a
Using the createHijacker.py script, it was trivial to configure malicious hijacker dylib to be planted, it neatly side-steps the
a malicious hijacker dylib to ensure compatibility with the complexities of run-time process injection. Finally, as this
target dylib and application. It should be noted that in this injection technique abuses legitimate functionality provided
case, since the vulnerable import (‘PhotoFoundation’) was by the OS loader, it is unlikely to be detected by personal
found within a framework bundle, the same bundle structure security products (which often attempt to prevent remote
was recreated in the primary run-path search directory process injection by monitoring ‘inter-process’ APIs).
(/ Applications/iPhoto.app/Contents/Library/LoginItems/).
With the correct bundle layout and malicious hijacker dylib Xcode is Apple’s ‘Integrated Development Environment’
(renamed as ‘PhotoFoundation’) placed within the primary (IDE) application. It is used by developers to write both
run-path search directory, the loader found and loaded the OS X and iOS applications. As such, it is a juicy target
malicious dylib whenever the iCloud Photo Stream Agent for an advanced adversary who may wish to inject
was started. Since this application was executed by the OS, code into its address space to surreptitiously infect the
the hijacker dylib was stealthily and surreptitiously persisted developer’s products (i.e. as a creative autonomous malware
across reboots. propagation mechanism). Xcode and several of its various
helper tools and utilities are vulnerable to dylib hijack
attacks. Specifically, run-path-dependent dylibs, such as
DVTFoundation are not found in Xcode’s primary run-path
search directories (see Figure 37).
The process injection hijack against Xcode was fairly
straightforward to complete. First, a hijacker dylib was
Figure 36: Hijacking Apple’s Photo Stream Agent for configured, such that its versioning information was
persistence. compatible and it re-exported all symbols to the legitimate
DVTFoundation. Then, the configured hijacker dylib was
As a final note on persistence, if no vulnerable applications are copied to /Applications/Xcode.app/Contents/Frameworks/
found to be started automatically by the OS, any vulnerable DVTFoundation.framework/Versions/A/ (Frameworks/
application commonly started by the user (such as a browser, being the primary run-path search directory). Now, whenever

12 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

into the context of a trusted process, the code will inherit the
process’s trust, and thus the firewall will allow its outgoing
connections.
GPG Tools [17] is a message encryption suite for OS X that
provides the ability to manage keys, send encrypted mail,
or, via plug-ins, enable cryptographic services to arbitrary
Figure 37: Apple’s vulnerable IDE, Xcode. applications. Unfortunately, its products are susceptible to
dylib hijacking.

Xcode was started, the malicious code was automatically

loaded as well. Here, it was free to perform actions such as
intercepting compile requests and surreptitiously injecting
malicious source or binary code into the final products.
As Ken Thompson noted in his seminal work ‘Reflections on
Trusting Trust’ [16], when you can’t trust the build process or Figure 39: GPG Tools’ vulnerable keychain app.
compiler, you can’t even trust the code that you create.
As GPG Keychain requires various Internet functionality (e.g.
to look up keys on keyservers), it’s likely to have an ‘allow
any outgoing connection’ rule, as shown in Figure 40.

Figure 38: Process ‘injection’ via dylib hijacking.

Besides persistence and load-time process injection, dylib

hijacking can be used to bypass personal security products.
Specifically, by leveraging a dylib hijack attack, an attacker Figure 40: Access rule for GPG Keychain.
can coerce a trusted process into automatically loading
malicious code, then perform some previous blocked or Using a dylib hijack, an attacker can target the GPG
‘alertable’ action, now without detection. Keychain application to load a malicious dylib into its
address space. Here, the dylib will inherit the same level
Personal security products (PSPs) seek to detect malicious
of trust as the process, and thus should be able to create
code via signatures, heuristic behavioural analysis, or simply
outgoing connections without generating an alert. Testing
by alerting the user whenever some event occurs. Since
this confirmed that the hijacker dylib was able to access the
dylib hijacking is a novel technique that abuses legitimate
Internet in an uninhibited manner (see Figure 41).
functionality, both signature-based and heuristic-based
products are trivial to bypass completely. However, security Defensive-minded individuals may correctly point out
products, such as firewalls, that alert the user about any that, in this scenario, GPG Keychain’s firewall rule could
outgoing connections from an unknown process, pose more be tightened to mitigate this attack, by only allowing
of a challenge to an attacker. Dylib hijacking can trivially outgoing connections to specific remote endpoints (e.g.
thwart such products as well. known key servers). However, there are a myriad of other
vulnerable applications that may be hijacked to access the
Personal firewalls are popular with OS X users. They often
network in a similarly uninhibited manner. Or, in the case
take a somewhat binary approach, fully trusting outgoing
of the Little Snitch firewall, the inclusion of a system-level
network connections from known processes, while alerting
undeletable firewall rule allowing any connection from
the user to any network activity originating from unknown
any process to talk to iCloud.com endpoints is more than
or untrusted processes. While this is an effective method for
enough for a full bypass (i.e. using a remote iCloud iDrive
detecting basic malware, advanced attackers can trivially
as a C&C server).
bypass these products by exploiting their Achilles heel:
trust. As mentioned, generally these products contain default So far, the dylib attack scenarios described here have all been
rules, or allow the user to create blanket rules for known, local. While they are powerful, elegant and stealthy, they all
trusted processes (e.g. ‘allow any outgoing connection from require existing access to a user’s computer. However, dylib
process X’). While this ensures that legitimate functionality hijacking can also be abused by a remote attacker in order to
is not broken, if an attacker can introduce malicious code facilitate gaining initial access to a remote computer.

MARCH 2015 13
 VIRUS BULLETIN www.virusbtn.com

Figure 41: Bypassing a personal firewall (LittleSnitch) via dylib hijacking.

There are a variety of ways to infect Mac computers, but the

simplest and most reliable is to deliver malicious content
directly to end target(s). The ‘low-tech’ way is to coerce the
user into downloading and installing the malicious content
manually. Attackers creatively employ a range of techniques
to accomplish this, such as providing ‘required’ plug-ins (to
view content), fake updates or patches, fake security tools
(‘rogue’ AV products), or even infected torrents.

Figure 43: Man-in-the-middling a software download.

Readers may be thinking, ‘hey, it’s 2015, most software
should be downloaded via secure channels, right?’
Unfortunately, even today, the majority of third-party OS
X software is distributed insecurely. For example, of the
software found installed in the author’s dock, 66% was
distributed insecurely.

Figure 44: Software (in the author’s dock) that was

Figure 42: Masked malicious content.
distributed over HTTP.
If the user is tricked into downloading and running any of Moreover, further research uncovered that all major third-
this malicious content, they could become infected. While party OS X security products were similarly distributed
‘low tech’, the success of such techniques should not be insecurely (see Figure 45).
underestimated. In fact, when a rogue security program
(Mac Defender) was distributed by such means, hundreds Apple is well aware of these risks, and since version OS X
of thousands of OS X users were infected, with over 60,000 Lion (10.7.5), Mac computers have shipped with a built-in
alone contacting AppleCare in order to resolve the issue security product, named Gatekeeper, that is designed to
[18]. counter these attack vectors directly.

Relying on trickery to infect a remote target will probably The concept of Gatekeeper is simple, yet highly effective:
not work against more computer-savvy individuals. A more block any untrusted software from executing. Behind the
reliable (though far more advanced) technique relies on scenes, things are a little more complex, but for the purposes
man-in-the-middling users’ connections as they download of this discussion, a higher-level overview suffices. When
legitimate software. Due to the constraints of the Mac any executable content is downloaded, it is tagged with a
App Store, most software is still delivered via developer ‘quarantined’ attribute. The first time such content is set to
or company websites. If such software is downloaded run, Gatekeeper verifies the software. Depending on the
via insecure connections (e.g. over HTTP), an attacker user’s settings, if the software is not signed with a known
with the necessary level of network access may be able Apple developer ID (default), or from the Mac App Store,
to infect the download in transit. When the user then Gatekeeper will disallow the application from executing.
runs the software, they will become infected, as shown in With Gatekeeper automatically installed and enabled on
Figure 43. all modern versions of OS X, tricking users into installing

14 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

Conceptually, bypassing Gatekeeper via dylib hijacking

is straightforward. While Gatekeeper fully validates the
contents of software packages that are being executed (e.g.
everything in an application bundle), it does not verify
‘external’ components.

Figure 47: Theoretical dmg/zip that would bypass

Gatekeeper.
Normally this isn’t a problem – why would a downloaded
(legitimate) application ever load relatively external code?
Figure 45: Insecure downloads of major OS X security (Hint: relative, yet external content.)
products. As Gatekeeper only verifies internal content, if an Apple-
signed or Mac App Store application contains a relative
external reference to a hijackable dylib, an attacker can
bypass Gatekeeper. Specifically, the attacker can create (or
infect in transit) a .dmg or .zip file with the necessary folder
structure to contain the malicious dylib in the externally
referenced relative location. When the legitimate application
is executed by the unsuspecting user, Gatekeeper will verify
the application bundle then (as it is trusted, and unmodified)
allow it to execute. During the loading process, the dylib
hijack will be triggered and the externally referenced
malicious dylib will be loaded – even if Gatekeeper is set to
only allow code from the Mac App Store!
Finding a vulnerable application that fulfils the necessary
prerequisites was fairly easy. Instruments.app is an Apple-
signed ‘Gatekeeper approved’ application that expects to be
Figure 46: Gatekeeper in action. installed within a sub-directory of Xcode.app. As such, it
contains relative references to dylibs outside of its application
bundle; dylibs that can be hijacked.
malicious software or infecting insecure downloads (which
will break digital signatures) is essentially fully mitigated.
(Of course, an attacker could attempt to obtain a valid Apple
developer certificate, then sign their malicious software.
However, Apple is fairly cautious about handing out such
certificates, and moreover, has an effective certificate
revocation process that can block certificates if any abuse is
discovered. Also, if Gatekeeper is set to only allow software
from the Mac App Store, this abuse scenario is impossible.)
Unfortunately, by abusing a dylib hijack, an attacker can
bypass Gatekeeper to run unsigned malicious code – even Figure 48: Apple’s vulnerable Instruments app.
if the user’s settings only allow Apple-signed code from the
Mac App Store. This (re)opens the previously discussed attack With a vulnerable trusted application, a malicious .dmg
vectors and puts OS X users at risk once again. image was created that would trigger the Gatekeeper bypass.

MARCH 2015 15
 VIRUS BULLETIN www.virusbtn.com

First, the Instruments.app was placed into the image. Then

an external directory structure was created that contained
the malicious dylib (CoreSimulator.framework/Versions/A/
CoreSimulator).

Figure 50: The finalized malicious .dmg image.

As the malicious dylib was loaded and executed before

the application’s main method, the dylib could ensure that
Figure 49: Malicious .dmg image. nothing appeared out of the ordinary. For example, in this
case where the malicious .dmg masquerades as a Flash
To make the malicious .dmg more ‘believable’, the external installer, the dylib can suppress Instruments.app’s UI, and
files were set to hidden, a top level alias (with a custom icon) instead spawn a legitimate Flash installer.
was created to point to Instruments.app, the background was
changed, and the entire image was made read-only (so that it With the ability to bypass Gatekeeper and load unsigned
would automatically be displayed when double-clicked). The malicious code, attackers can return to their old habits
final product is shown in Figure 50. of tricking users into installing fake patches, updates
or installers, fake AV products, or executing infected
This malicious (though seemingly benign) .dmg file was pirated applications. Worse yet, advanced adversaries with
then ‘deployed’ (uploaded to a public URL) for testing networking-level capabilities (who can intercept insecure
purposes. When downloaded via Safari and then executed, connections) can now arbitrarily infect legitimate software
Gatekeeper’s standard ‘this is downloaded from the Internet’ downloads. Neither have to worry Gatekeeper any more.
message window was initially shown. It is important to note
that this alert is shown for any content downloaded from the
Internet, and thus is not unusual. DEFENCES
Once this message window was dismissed, the malicious Dylib hijacking is a powerful new attack class against OS
code was surreptitiously loaded along with the legitimate X, that affords both local and remote attackers a wide range
application. This, of course, should not have been allowed as of malicious attack scenarios. Unfortunately, despite being
Gatekeeper’s settings were at the maximum (only allow apps contacted multiple times, Apple has shown no interest in
from the Mac App Store) (see Figure 51). addressing any of the issues described in this paper. Granted,

Figure 51: Bypassing Gatekeeper via a dylib hijack.

16 MARCH 2015
 VIRUS BULLETIN www.virusbtn.com

Figure 52: Objective-see’s DHS scanner.

there appears to be no easy fix for the core issue of dylib within countless Apple and third-party applications, this
hijacking as it abuses the legitimate functionality of the OS. attack class opens up a multitude of attack scenarios to both
However, it is the opinion of the author that Gatekeeper local and remote attackers. From stealthy local persistence
should certainly be fixed in order to prevent unsigned to a Gatekeeper bypass that provides avenues for remote
malicious code from executing. infections, dylib hijacking is likely to become a powerful
Users may wonder what they can do to protect themselves. weapon in the arsenal of OS X attackers. And while Apple
First, until Gatekeeper is fixed, downloading untrusted, or appears apathetic toward this novel attack, secure software
even legitimate software via insecure channels (e.g. via the downloads and tools such as DHS can ensure that OS X users
Internet over HTTP) is not advised. Refraining from this will remain secure... for now.
ensure that remote attackers will be unable to gain initial
access to one’s computer via the attack vector described in
this paper. Due to the novelty of dylib hijacking on OS X, it
REFERENCES
is unlikely (though not impossible) that attackers or OS X [1] Secure loading of libraries to prevent DLL
malware are currently abusing such attacks locally. However, preloading attacks. http://blogs.technet.com/cfs-
it can’t hurt to be sure! file.ashx/__key/CommunityServer-Components-
PostAttachments/00-03-35-14-21/Secure-loading-of-
To detect local hijacks, as well as to reveal vulnerable
libraries-to-prevent-DLL-Preloading.docx.
applications, the author created a new application named
Dynamic Hijack Scanner (or DHS). DHS attempts to uncover [2] DLL hijacking. http://en.wikipedia.org/wiki/
hijackers and vulnerable targets by scanning all running Dynamic-link_library#DLL_hijacking.
processes of the entire file-system. The application can be [3] Dynamic-Link Library Hijacking.
downloaded from objective-see.com. http://www.exploit-db.com/wp-content/themes/
exploit/docs/31687.pdf.

CONCLUSION [4] Windows NT Security Guidelines.

http://www.autistici.org/loa/pasky/NSAGuideV2.PDF.
DLL hijacking is a well known attack class that affects the
Windows OS. Until now, OS X was assumed to be immune [5] What the fxsst? https://www.mandiant.com/blog/
to such attacks. This paper countered that assumption, fxsst/.
illustrating a similar OS X attack, dubbed ‘dylib hijacking’. [6] Leaked Carberp source code. https://github.com/
By abusing weak or run-path-dependent imports, found hzeroo/Carberp.

MARCH 2015 17
 VIRUS BULLETIN www.virusbtn.com

[7] Windows 7 UAC whitelist: Proof-of-concept source

code. http://www.pretentiousname.com/misc/W7E_
Source/win7_uac_poc_details.html.
[8] Microsoft Security Advisory 2269637; Insecure
Library Loading Could Allow Remote Code
Execution. https://technet.microsoft.com/en-us/
library/security/2269637.aspx.
[9] What is dll hijacking? http://stackoverflow.com/
a/3623571/3854841.
[10] OS X loader (dyld) source code.
http://www.opensource.apple.com/source/dyld.
[11] MachOView. http://sourceforge.net/projects/
machoview/.
[12] Run-Path Dependent Libraries.
https://developer.apple.com/library/
mac/documentation/DeveloperTools/
Conceptual/DynamicLibraries/100-Articles/
RunpathDependentLibraries.html.
[13] Using @rpath: Why and How. http://www.dribin.
org/dave/blog/archives/2009/11/15/rpath/.
[14] Friday Q&A 2012-11-09: dyld: Dynamic Linking On
OS X. https://www.mikeash.com/pyblog/friday-qa-
2012-11-09-dyld-dynamic-linking-on-os-x.html.
[15] dylibHijackScanner.py & createHijacker.py.
https://github.com/synack/.
[16] Reflections on Trusting Trust.
http://cm.bell-labs.com/who/ken/trust.html.
[17] GPG Tools. https://gpgtools.org/.
[18] Apple support to infected Mac users: ‘You cannot
show the customer how to stop the process’.
https://nakedsecurity.sophos.com/2011/05/24/apple-
support-to-infected-mac-users-you-cannot-show-the-
customer-how-to-stop-the-process.

Editor: Martijn Grooten

Chief of Operations: John Hawes
Security Test Engineers: Scott James, Tony Oliveira, Adrian Luca
Sales Executive: Allison Sketchley
Editorial Assistant: Helen Martin
Consultant Technical Editors: Dr Morton Swimmer, Ian Whalley
© 2015 Virus Bulletin Ltd, The Pentagon, Abingdon Science
Park, Abingdon, Oxfordshire OX14 3YP, England.
Tel: +44 (0)1235 555139. Fax: +44 (0)1865 543153
Email: [email protected]
Web: http://www.virusbtn.com/

18 MARCH 2015