Department InformatikTechnical Reports / ISSN 2191-5008

Andreas Kurtz, Andreas Weinlein, Christoph Settgast, Felix Freiling

DiOS: Dynamic Privacy Analysis of iOSApplications

Technical Report CS-2014-03

June 2014

Please cite as:

Andreas Kurtz, Andreas Weinlein, Christoph Settgast, Felix Freiling, “DiOS: Dynamic Privacy Analysis of iOS

Applications,” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Reports,

CS-2014-03, June 2014.

Friedrich-Alexander-Universität Erlangen-NürnbergDepartment Informatik

Martensstr. 3 · 91058 Erlangen · Germany

www.cs.fau.de

DiOS: Dynamic Privacy Analysis of iOSApplications

Andreas Kurtz, Andreas Weinlein, Christoph Settgast, Felix FreilingDept. of Computer Science, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany

dios@i1.cs.fau.de

Abstract—We present DiOS, a practical system toperform automated dynamic privacy analysis of iOSapps. DiOS provides a highly scalable and fully auto-mated solution to schedule apps from the official AppleApp Store for privacy analysis to iOS devices. Whileapps are automatically executed, user interaction issimulated using random and smart execution strategies,and sensitive API calls as well as network connectionsare tracked. We evaluated the system on 1,136 of themost popular free apps from the iOS App Store andfound out that almost 20% of all investigated apps aretracking users’ locations on every app start, one thirdof all accesses to users’ address books are attributed toapps from the social network category and almost halfof all apps are tracking users’ app usage behavior byincorporating tracking and advertising libraries.

I. INTRODUCTION

A. Motivation

Mobile devices have become an integral part ofour daily life and business. Not only do they provideconnectivity to friends and colleagues at any timeand (almost) any place, they are also used to storeand manage large amounts of personal data such asimages, videos and emails. One major reason for thesuccess of smartphones are the manifold opportunitiesgained from their expandability by third-party mobileapplications (apps).

However, with the increasing amount of apps offeredin central marketplaces, the risk of apps that arepotentially harmful to a user’s privacy rises. Privacyconcerns do not necessarily refer only to the secrecy ofapplication data, such as documents and emails, butthey also refer to contextual data that a smartphonecontinuously produces through its sensors for location(GPS), acceleration, video (camera) and audio (micro-phone). Since most phones are usually switched onand carried along with the person, the collected datagives a deep insight into the life of the smartphoneowner, and is therefore highly privacy relevant.

Because of this relevance, the information availableon smartphones has attracted more and more attentionfrom the advertising industry and cybercriminals. Therehave been numerous reports on privacy violations ofdifferent forms (even for Apple products [1], [2]),whereas most of them however were discovered byaccident or after intensive manual analysis work. Sincemanual analysis does not scale to the vast amountof apps that are developed every day, automatedsolutions for detecting privacy leaks are in highdemand. Furthermore, since the entire smartphonefield is changing rather quickly, it is important tocontinuously investigate the privacy implications ofusing smartphones so that users and society can reflecton (self) regulation.

B. Related Work

Related work in dynamic software analysis is mainlyfocused on desktop operating systems [3]–[5]. Dueto several circumstances like, e.g., different executionplatforms, most known techniques are not applicable tomobile devices. However, there have been several stud-ies focusing on the analysis of mobile apps, althoughmost of them dealing with Android.

Enck et al. [6] were the first to present TaintDroid,a system for monitoring Android apps for privacyviolations at runtime. Later, TaintDroid was incor-porated in various other analysis solutions such asAppsPlayground [7] or Mobile-Sandbox [8]. However,TaintDroid (and all other existing solution that arebased upon it) are limited to the Android platformand do not support analyzing native code. As codein iOS is directly executed on the hardware withoutany abstraction layer or virtual machine, those existingsolutions are not applicable for iOS-based dynamicanalysis. Moreover, compared to the vast amountof Android-related analysis [9]–[13], relatively fewstudies have been conducted in the field of Apple iOS.This might be attributable to the fact that iOS is a

closed system that provides hardly any interfaces, andinformation about internals generally need to be reverseengineered.

Szydlowski et al. [14] discussed general challengesof dynamically analyzing iOS apps. Within a prototypeimplementation, they tracked sensitive API calls us-ing debugger breakpoints and tried to automaticallyexplore an app’s user interface (UI) via VNC by recog-nizing image patterns. In general, the practicability ofthese approaches is questionable due to performanceimpacts that are to be expected and, as the authorsadmit, due to the inaccuracy of this approach to handlenon-uniform user interfaces.

Joorabchi and Mesbah [15] propose iCrawler, a toolthat explores an app’s UI and generates a model ofdifferent UI states to facilitate reverse engineering ofiOS apps. Although the achieved coverage of theirnavigation technique looks promising when applied ona few open-source apps, it does not support simulationof any advanced gestures or external events. Moreover,the technique used by iCrawler is only applicable tostandard UI elements, and, most notably, iCrawler hasnot been designed to perform privacy analysis.

Within PiOS, Egele et al. [16] employ data flowanalysis and slicing techniques to detect whether aniOS application leaks sensitive data. As of this writing,the results published within the PiOS study are thefirst and yet only large-scale analysis results on theprivacy landscape of iOS apps. However, contrary toour approach PiOS is based on static analysis andprone to shortcomings such as statically resolvingmessage destinations. So overall, there appears to existno publicly scrutinizable solution for dynamic privacyanalysis of iOS apps to date.

C. Contributions

We wish to improve the state of the art in iOSprivacy analysis by introducing DiOS. To the best of ourknowledge, DiOS is the first fully automated scalablesolution to perform dynamic privacy analysis of iOSapps.

As apps from the official Apple App Store arecompiled for ARM only (and protected by Apple digitalrights management), and there exists no emulator forthe iOS platform, DiOS schedules apps from Apple’sApp Store for dynamic privacy analysis to physical iOSdevices. The analysis throughput scales almost linearlywith the number of iPhones added to the system. Withonly four such devices we were able to dynamically

analyze more than 500 apps a day (depending on thedesired level of detail).

DiOS allows for structured exploration and navi-gation of an app’s UI by leveraging the automatedUI testing support provided by the official Appledevelopment tools. Originally, this feature was intendedto simplify UI tests during an app’s developmentphase. However, we successfully reverse engineeredthe inner workings to retrofit even existing App Storeapps to make use of Apple’s UI automation features[17]. This allowed us to investigate several robust UIexploration strategies that simulate user interactionand thus optimize an app’s UI coverage. We show thatour automatic interface navigation achieves comparablehigh coverage results to manual app usage.

One of the core features of DiOS is its pluggablearchitecture. While apps are automatically executedand user interaction is simulated using smart executionstrategies, any analysis component can be integratedeasily. To demonstrate its practicability and reliability,we analyzed 1,136 top free apps from the iOS AppStore and tracked privacy-related API calls as well asnetwork connections.

To summarize, this report makes the followingcontributions:• We present a fully automated dynamic analysis

platform for iOS apps.• We present a way to automatically purchase apps

from the official iOS App Store and to schedulethem to physical iOS devices for large-scale privacyanalysis.

• We present a novel and robust approach to performautomated UI exploration of iOS apps and explorethe merits of different UI execution strategies.

• Finally, we present the results of a large-scaledynamic privacy analysis of 1,136 iOS apps fromApple’s App Store.

As we wish to enable other researchers to advancethe field of iOS application security based on ourframework, the full source code of DiOS, as well asvideos demonstrating DiOS in action, are available fromour project site: https://www1.cs.fau.de/dios/ .

D. Roadmap

This report is structured as follows: In Section II,we provide relevant background information on AppleiOS, its basic security concepts and the UI Automationfeature. In Section III, we explain the basic architectureof the DiOS analysis framework as well as the chal-lenges we had to overcome to automatically initiate app

purchases and to simulate user interaction. Moreover,we present different execution strategies integrated intoDiOS for automated UI exploration. In Section IV, weexplain the experimental setup and discuss the resultsof our large-scale privacy analysis. Finally, we describethe limitations of DiOS and conclude in Section V.

II. BACKGROUND INFORMATION

A. Apple iOS Operating System

iOS (previously iPhone OS) is an operating systemused on mobile devices by Apple. iOS is derived fromApple’s desktop operating system OS X. While somecomponents of the iOS kernel are open-source, due tohistorical reasons, the main parts of the iOS operatingsystem are closed and information on it is not publiclyavailable.

The functionality of the iOS operating system can beextended by applications (so-called apps). Those appscan be build using a software development kit (SDK)based on the programming language Objective-C. Inorder to interact with the underlying operating system,iOS provides an extensive application programming in-terface (API) organized in several different abstractionlayers. While lower layers provide fundamental systemservices on which all apps rely on, the higher-levellayers provide object-oriented abstractions for lower-level constructs.

Most of the iOS system interfaces are provided inspecial packages, so-called frameworks. A frameworkconsists of a dynamic shared library and correspondingresources (such as header files). Frameworks providethe relevant interfaces needed to build software for theiOS platform. Basically, there are two types of frame-works: public frameworks that are recommended byApple to build third-party apps and private frameworksthat are restricted to be used by iOS and its systemapps only.

B. iOS Security Concepts

The security concept of the iOS system is funda-mentally based on its closed nature. Starting from theboot-up process all involved components are crypto-graphically verified to ensure their integrity and toestablish a trusted execution environment. This in turnallows only code providing a valid signature to beexecuted. Consequently, also third-party apps need tobe signed with personalized certificates issued by Apple.

Those third-party apps are usually distributed viathe App Store, a digital marketplace maintained byApple. Although the main purpose of the App Store

was to provide users with a service to browse anddownload apps, it also serves as a unique securityfeature compared to other more open mobile softwareplatforms like Android. From the beginning, every apphas to pass through an approval process by Apple.Among other tests, this vetting process attempts tospot malicious apps and to admit only those appsthat are not harmful to users’ privacy. Although, thisvetting process is a good security design decision at afirst glance, there have been reported several cases inwhich it failed to reveal apps that intentionally accessedpersonal data [18].

Besides the trusted execution environment and thepromised gain in security derived from the App Storeapproval, there are plenty of other security featuresprovided by the iOS operating system itself [19]. Whilemost of these security features are under the hood andintroducing each of them would exceed the scope ofthis introduction, we only point out the most relevant.First, all third-party apps run isolated within a sandboxand are restricted from accessing other apps’ processesand data. If an app needs to access shared dataoutside its sandbox, it is limited to using the API andservices provided by iOS. Access to certain sensitiveAPI methods requires a user’s consent. For instance,when an app tries to access a user’s current locationfor the first time, the user is asked for permission once.All privacy-relevant API methods and the related accessmodalities will be described in Section IV-B in moredetail.

C. Jailbreaking

In the past, flaws in the chain of trust and softwarevulnerabilities in the iOS operating system repeatedlylead to different ways to install custom firmwareimages and to remove the limitations imposed byApple. This process is often referred to as jailbreaking.One of the main implications of jailbreaking is thatit provides root access to the iOS operating systemand enables installation and execution of additionalsoftware. Signing apps with an Apple-issued certificateis no longer required.

D. Objective-C

As all iOS apps are written in the Objective-Clanguage and an understanding of the basic conceptsof Objective-C is required to comprehend certain DiOSprinciples and limitations, this section outlines the mostrelevant characteristics of Objective-C.

1) Message Passing: One of the fundamental conceptsof the object-oriented programming model of Objective-C is based on message passing. Whenever a method isinvoked, a message is sent to an existing object instance.The core of that messaging concept is provided bythe objc_msgSend function, which is part of theObjective-C runtime environment. This function servesas a central dispatcher and routes messages betweenexisting objects. This dispatcher function takes at leasttwo parameters: The first parameter holds a pointerto the instance of the class to which the message isdirected (the receiver), while the second argument isthe method to be invoked (identified by a selector,which is a simple string representing the name ofthe method). In the end, the dispatcher function mayreceive a variable list of arguments that are passed tothe receiving method implementation.

2) Reflection: Another important characteristic ofthe Objective-C language is reflection, which is widelyknown as the ability of a computer program to modifyits behavior at runtime. For this, the Objective-Cruntime provides a low-level API to interact withthe underlying runtime system. By using this API itis possible to query the runtime for information onthe running application which gives detailed insightsinto its inner structure, like available classes, methoddefinitions and instance properties, without the needfor having access to the source code. Moreover, thisAPI offers ways to not only derive information on anapplication’s inner workings, but also to manipulate itat runtime. For instance, the runtime provides functionsto add new classes and methods, or to rewrite existingmethod implementations. In the following sections,these characteristics of the Objective-C runtime are thebasis for comprehensive and efficient dynamic analysisof iOS applications.

E. API Hooking

In order to intercept calls to the iOS API, an appfirst needs to be extended with additional code. Thiscan be accomplished by using the environment variableDYLD_INSERT_LIBRARIES which advises the dy-namic linker to load a specific library into an app’saddress space at start-up.

During initialization, the injected library needs toreroute the app’s control flow using runtime patchingtechniques. In the case of hooking Objective-C methods,the runtime is instrumented to replace the implemen-tation of specific Objective-C messages. If calls to Cfunctions should be intercepted, the replacement needs

to be accomplished at a lower level. For this, it isrequired to inject jump instructions that reroute anapp’s control to a dedicated replacement procedurewhich also resides in the injected library. To not inferwith the normal execution flow it is vital to backup thereplaced instructions to a custom memory location andto execute them before jumping back to the invokingroutine.

In iOS, the most practicable way to hook librarycalls is by making use of MobileSubstrate [20]. Mo-bileSubstrate is a framework that facilitates runtimepatches to system functions and consists of two parts:the MobileLoader and the MobileHooker. First, theMobileLoader integrates itself into an app using thelinker environment variable and then loads all dynamiclibraries from a specific location. Afterwards, the Mo-bileHooker is responsible for replacing specific systemfunctions and to install the actual hooks.

F. UI Automation

With the release of iOS 4, Apple introduced a featurefor automated UI testing within its app developer tools.This allows developers to automate UI tests, which areeither implemented in JavaScript, or are recorded usinga built-in recording function. The resulting test scriptssimulate user interaction while an app is running ona connected device using the UI Automation API [17],which in turn is based on the iOS Accessibility API, aprogramming interface to make an app’s elements suchas buttons, input fields etc. usable to visually impairedpeople.

1 var localTarget = UITarget.localTarget();

2 localTarget.frontMostApp().mainWindow.tabBar().buttons()["Recipes"].tap();

3 localTarget.frontMostApp().mainWindow.tabBar().buttons()[0].tap();

Listing 1: UI Automation test script to automaticallytap the recipes button in Figure 1

To understand how automatic exploration of an userinterface works, it is first necessary to understand anapp’s internal user interface structure. Therefore, figure1a shows a sample app consisting of a navigation bar atthe top, a table view to display the actual contents, anda tab bar at the bottom edge of the screen to changecontent selection by tapping one of the two buttons.All of these elements are internally represented withina hierarchy as illustrated in Figure 1b. At the top ofthe element hierarchy is the UITarget class which

(a) Sample recipes app

UIANavigationBar (Unit Conversion)

UIAWindow UIATableView

UIAStaticText (Unit Conversion)

UIATableCell (Weight)

UIATableCell (Temperature)

UIAApplication

UIATarget

UIATabBar

UIAButton (Recipes)

UIAButton (Unit Conversion)

UIAElement (Weight)

UIATableCell (Temperature)

(b) Hierarchy of the user interface elements displayed in Figure1a

Fig. 1: Basic user interface of a sample app and itsinternal representation of the element hierarchy [21].

is a high-level representation of the iOS device. Therunning app is the frontmost app and can be accessed,as well as any other user interface elements, from anUI Automation test script as shown in Listing 1. Forexample, in order to tap the recipes button, the pathto the selected node has to be stated. Array elementscan either be accessed by name or by index.

One limitation of UI Automation is that access tothe element hierarchy is only available for standardUI elements or custom elements that have explicitlybeen made accessible using the Accessibility API. Withthe goal of automated app exploration in mind, thisdrawback can be neglected for several reasons: Mostof the apps available in the App Store comply with theiOS Human Interface Guidelines [22] by Apple, whichencourage developers to only build apps consistent withiOS standards. This includes a uniform style and resultsin a preferred use of standard UI elements. If an app isnot offering accessibility support, as it is e.g. often thecase with games, information on the displayed elementscannot be extracted. However, UI Automation can stillbe used, as it allows simulation of several gestures atany specific point on the screen without knowing the

actual element hierarchy. Apart from touch gestures,UI Automation has also the ability to simulate externalevents like changes to the location, device orientation,volume etc. Moreover, UI Automation provides a wayto handle alert messages to ensure that alerts do notinterfere while an app is automatically executed.

As described in more detail later, the automatic UIexploration within DiOS is heavily based on this UIAutomation feature. Although intended to be used dur-ing app development and testing only, we successfullyreverse engineered the UI Automation components toretrofit even existing App Store app’s to make use ofit. This provides us with a clean interface to explorean app’s internal element hierarchy, which in fact isrepresented by an element tree, and it even allows usto simulate user interaction in a convenient and robustway.

III. DIOS FRAMEWORK

In the following, we present the design of DiOS(Section III-A) and describe how we met some of themajor challenges within iOS-based dynamic analysis,such as to automatically initiate app purchases fromApple’s App Store (Section III-B), to simulate userinteraction to connected devices (Section III-C) or todeal with alert messages (Section III-D). Afterwards,we present different execution strategies integrated intoDiOS for automated UI exploration (Section III-E) andevaluate the framework’s scalability and performance(Section III-F).

A. System Architecture

Basically, the DiOS system consists of three majorparts as illustrated in Figure 2: a backend that ismainly used as central data storage, a worker used asconnecting link between the backend and any numberof attached iOS devices, and several client componentsrunning on the connected iOS devices. Each of thesecomponents will be explained in more detail withinthe following sections.

1) Backend: The Backend is the main component ofDiOS and is responsible for centralized data storage.It holds configuration data such as App Store accountcredentials (to automatically purchase apps) and statusinformation on available iOS analysis devices. Further-more, it archives all app binaries of recent analysis andprocesses analysis results reported back from the iOSdevices. To browse the App Store, DiOS provides a web-based interface that uses RSS feeds provided by Apple[23] to retrieve information on available apps and

<<device>>

Backend Server

Backend

Database<<device>>

HostWorker

<<device>>

Client (iOS Device)

Controller

Broker

Executor

Analyzer

Scheduler<<TCP/IP>>

0..*1

find Jobs for Device<<HTTP (REST)>>

<<TCP/IP>><<USB>>

1 0..*

<<TCP/IP>>

initiate Actions<<HTTP (REST)>>

save Results<<HTTP (REST)>>

Fig. 2: Architectural overview of the DiOS framework. Components on the right-hand side are executed onattached iOS devices.

app charts. A scheduler ensures that selected apps areautomatically installed and executed on available iOSdevices. The backend component was implemented inPython and provides a web service interface to enableany other DiOS component to access its data.

2) Worker: The main task of the Worker is toestablish a physical link between all available iOSdevices (that are connected to the worker via USB)and the backend. This intermediate layer was mainlyintroduced for scalability reasons, as DiOS supportsmultiple worker instances. Whenever a new device isconnected to a worker for the first time via USB, it isautomatically set up and registered with the backend.Afterwards, the worker constantly polls the backend forpending jobs and, on demand, initiates app installationsand app launches on the connected iOS devices. Theworker component was implemented in Python. Tofacilitate communication via USB the worker useslibimobiledevice [24], a software protocol library tonatively communicate to iOS devices.

3) Client: As the DiOS model is based on executingand analyzing running apps on connected iOS devices,several client components are required. These clientcomponents running on the iOS devices are explainedin more detail in the following.

• The Controller is the frontmost client componentthat receives instructions from the worker such aspurchasing apps from the App Store, installingand executing apps and delegating automaticUI exploration to the executor component. Thecontroller is implemented in Objective-C and isintegrated into SpringBoard (the standard applica-tion that manages the iOS home screen) via libraryinjection. During initialization of the controllerlibrary an HTTP web server is spawned providing

a REST-based web service interface to the workercomponent. Further, on-device communicationbetween all involved client components is realizedusing the distributed notification concept of iOS[25].

• The Executor is responsible for exploring an app’suser interface and for simulating user interac-tion. For this, several execution strategies wereimplemented which provide different granularitylevels of UI exploration (Section III-E). To separateautomation code from the actual app code, theexecutor was implemented as iOS backgrounddaemon and makes use of the UI Automation API[17] (Section III-C).

• The Analyzer is the core of DiOS’ plugin archi-tecture. All available analyzer components areloaded into an app’s address space at startupand are responsible for performing the actual appanalysis. By default, DiOS provides a basic analyzerthat tracks access to privacy-related API calls andcollects network packages.

• The Broker is a static library that simplifies thedevelopment of DiOS analyzer plugins. It receivesnotifications from the controller and provides aclean interface to report analysis results to thebackend.

B. Automated App Purchase and Installation

In order to enable large-scale analysis of iOS apps,the process of automatically purchasing apps from theApp Store and downloading them to connected iOSdevices is a key part of the DiOS client components.However, so far app purchasing is limited to officialapps provided by Apple only and not available toany third-party implementations. Therefore, we reverse

engineered the official iOS App Store app to find outhow to initiate store purchases from the DiOS controllercomponent in an automatic fashion.

Thereby, it turned out that the private StoreServicesframework is used to purchase any available storeproducts. In more detail, first a SSPurchase objectis initialized. This object is supplied with informationon the related store account to be used for thepurchase and several additional buying parameters1

which include the bundle identifier of the actual app.Finally, a SSPurchaseRequest object is initializedto deliver the purchase request object to the App Storeand to start the download process.

In this context, a major challenge was to properlyhandle authentication forms, as a purchase requires auser to enter his or her App Store credentials. We foundout that these credentials were cached in memory andcould be re-used without any additional user confirma-tion in iOS version 5 and below. Thus, it was sufficientto set the property setNeedsAuthenticationto false before submitting the request. However,this behavior has changed with the release of iOSversion 6 where cached credentials now expire atirregular intervals and therefore require to be re-entered. Therefore, we instrumented the alert handlingsystem of DiOS (see Section III-D) to automaticallysubmit store credentials to enable fully automatedpurchases.

C. Co-Opting the UI Automation Service

As mentioned above, Apple’s UI Automation featurewas intended to support automated UI testing duringdevelopment. From within the Apple developer tools,JavaScript-based test scripts can be recorded in orderto automatically navigate an app through previouslydefined paths. In order to retrofit even existing AppStore apps to make use of Apple’s UI automationfeatures, we reverse engineered its inner workings.

We found a script agent running on the iOS deviceresponsible for parsing the received test scripts and fortranslating them into Objective-C method invocations.The related Objective-C methods are provided withinthe private UIAutomation.framework, an on-device counterpart of the publicly available JavaScriptAPI [17]. This private framework is not part of theoperating system itself and needs to be extracted from

1Information required to automatically fill in an app’s buyingparameters can be obtained by scraping its HTML description fromthe App Store when iTunes-iPhone is provided within theHTTP user agent request header.

the iOS developer image, a toolset which is restrictedto iOS developers and loaded onto an iOS device on-demand. The reverse engineering of the UI Automationframework was facilitated by the fact that its methodstructure is almost equivalent to its official JavaScriptcounterpart.

After reconstructing the internal Objective-C API, wewere able to leverage the UI Automation framework toautomatically inspect an app’s user interface at runtimeand to simulate any user interaction or trigger externalevents, without requiring any developer tools or anapp’s source code.

D. Dealing with Alerts

iOS provides different kinds of alerts in order todisplay notifications or to ask users for basic deci-sions. As these alerts would interrupt the automaticexecution of an app, proper alert handling was alsoa notable challenge. To solve this, the DiOS Executor(see Section III-A) was extended by an AlertManager.This AlertManager is registered as callback via theUIAutomation framework and is automatically invokedwhenever an alert rises. For maximum flexibility, theAlertManager delegates further processing of an alertto several AlertHandlers depending on an alert’s origin(system vs. app-specific).

In consequence, system alerts or unsolved app-specific alerts are processed by a GenericAlertHandler.Usually, this handler results in pressing an alert’s defaultbutton. However, a few special cases have emerged thatrequire special treatment. For instance, whenever anapp tries to access certain privacy-related API methodsthat requires a user’s consent, the GenericAlertHandlerexplicitly grants access by pressing the “allow” button.Another special case was observed within apps thatask users at startup to rate their app experiences or todownload affiliated apps. Pressing the default buttonwould forward the user to the App Store app, whileredirecting back to the original app may result in aninfinite loop, pending execution between these twoapps. To avoid those behaviors, we implemented ablacklist of button names (like rate, evaluate, try etc.)that are to be avoided.

In contrast, app-specific alerts are treated individuallydepending on the the selected execution strategy.These strategies will be explained within the followingsections in more detail.

E. Execution Strategies

To automatically navigate through an app’s userinterface and to simulate user interaction, the followingthree different execution strategies have been inte-grated into DiOS.

1) Open-Close Execution: The most basic executionstrategy within DiOS launches an app for a definedduration. After a few seconds (15s by default) the appis suspended to the background by simulating a tapon the iOS device’s home button. Again, five secondslater the app is resumed for another 15 seconds untilexecution is finally terminated. Apart from handlingalerts by pressing the default button no other userinteraction is simulated. Therefore, the results of thisstrategy later serves as a baseline reference to measurethe advance of the competing approaches.

2) Random Execution: Moreover, DiOS provides arandom execution strategy that utilizes Apple’s UIAutomation framework to execute randomly chosenevents, from pressing the home-button, changing adevices orientation or location, shaking the device, oradjusting the volume, to tapping on a random screenposition or performing any advanced gestures. However,compared to common Android-based UI automationapproaches [7], [8], DiOS does not rely on issuingrandom events only, but considers an app’s actualuser interface in certain ways: If an app provides anynavigation bars, from time to time, a random buttonof these navigation elements is pressed intentionally toavoid the risk of being stuck to sub views. Moreover, toallow the simulated user interaction to be as realisticas possible, the random events were weighted andcan be freely adjusted. Thus, the event of tapping arandom screen position, e.g., is ten times more likely tooccur than changing a device’s orientation. Using thisapproach we aimed to effectively maximize an app’scoverage without the need for exploring the actual UIin detail.

3) Smart Execution: The third execution strategyimplemented within DiOS examines the actual userinterface in great detail. For this, it explores theavailable UI elements on every screen and keeps trackof already executed UI paths. This enables targetednavigation through an app’s user interface, whileavoiding repeated execution of already visited contents.

In order to (re-)recognize different UI states of anapp, it is necessary to define criteria to determine thesimilarity of two views. Thereby, a view is defined asan abstract description of an ordered set of different UIelements (buttons, textfields etc.) that are arranged on

the screen in a certain way. Within DiOS we define twoviews as being equivalent if and only if the followingconditions are met:

1) The element hierarchy is identical.2) The following identifiers of each hierarchy el-

ement are identical: UIAutomation class name,UIKit class name, UIAutomation class name ofthe parent element.

In practice, this abstraction provides a reliableway to determine UI equivalence within iOS and todifferentiate UI states without considering any variableUI elements (like label/button names, values). Tokeep track of all available app views, we modeled thedifferent UI states as nodes within a directed graph. Therelated UI elements that lead to specific UI states arerepresented by edges within that graph. This modelallows a targeted and efficient navigation betweendifferent views. Whenever all available elements of aview have been examined and successfully executed,the model is searched for pending elements in otherUI states. Finally, we calculate the shortest path toefficiently navigate to that view.

In more detail, the following steps are performedwhenever a view is entered. At the beginning, theelement hierarchy of this view is retrieved using theUIAutomation framework. Afterwards, the state modelgraph is searched for the current view using the UIequivalence criteria described above. In case the currentview is not available within the state model, it is addedto the graph. Subsequently, a non-processed element israndomly chosen from the current view, any availableinput fields are filled using default data and the elementis executed.

One shortcoming of the smart execution approach isthe time needed to perform the numerous calculationsat the beginning of each transaction. In practice, thesecalculations require approximately five seconds (oniPhone 4 hardware). In exceptional cases, especiallywithin complex user interfaces, the iterations may takelonger. There are several reasons for this: On the onehand, complex views may contain a large numberof (hidden) elements and processing these elementstakes some time, mainly caused by architectural issues.On the other hand, the time delay is increased bylong response times of the UIAutomation frameworkto provide information on the element hierarchy. Weaddressed these issues by implementing concurrencycontrol and shifting the element analysis into separatedispatch queues.

F. Framework Evaluation

The main objective of DiOS was to provide a systemfor large-scale privacy analysis of iOS apps from theofficial Apple App Store. Within this section we evaluateand discuss the scalability of the overall system as wellas the effectiveness of the three different executionstrategies. Therefore, we analyzed the top 50 free appsof each of the 23 available App Store categories (asof May 10, 2013). We downloaded these 1,136 apps(duplicate entries were removed) and analyzed themusing different execution strategies.

1) Scalability: The architecture of DiOS was chosento be as scalable as possible. This is particularly given bythe loose coupling of the involved components. WhileDiOS is based on executing apps on physical devices(iPhones), the analysis throughput scales almost linearlywith the number of iPhones added to the system.

During our experiments, the required time to down-load2 an averaged size app, to install it on a connecteddevice and to remove it after successful execution wasaround three to four minutes. Given that constant timelapse of 3.5 minutes, the overall analysis time per appsolely depends on the chosen execution time. Thus,running an app for five minutes, e.g., using smartexecution strategies, the overall analysis takes 8.5minutes to complete. This results in a throughput ofseven apps per hour, or 169 apps per day. In orderto increase the throughput, DiOS allows to add anynumber of iOS devices. Thus, to analyze 1,000 apps perday which is approximately the number of submittedapps to the App Store [26], only 6 analysis devices arerequired.

2) Method Coverage: One major drawback of dy-namic analysis in general is that its detection abilitieshighly depend on the achieved code coverage. Thecode coverage again is affected by proper simulationof UI events, particularly in the context of highlyinteractive mobile apps. If an app performs sensitiveAPI calls within a sub-branch that requires specificUI interaction to be executed this event might bemissed, increasing the risk of false negatives. This iswhy accurate simulation of user interaction is a keypart of any UI-driven dynamic analysis system.

In order to compare the different execution strategiesprovided by DiOS, we instrumented the Objective-Cruntime to track all method invocations and for each

2The time calculations are based on an app’s average file size of20 MB, downloaded using a high-speed internet connection of >500KB/s.

execution strategy measured the amount of invokedapp methods. Although method coverage is knownto be a weak coverage criteria in systematic softwaretesting, it has proven to be a suitable benchmark tocheck DiOS’ execution strategies against each other.Compared to other platforms like Android where amid-layer (Dalvik VM) can be instrumented to measurethe coverage, iOS apps are executed on the hardwaredirectly. Measuring the coverage on a basic block orinstruction level might produce more significant resultsbut is considered to be impractical within large-scaleanalysis due to performance impacts.

a) Tracing Method Invocations: As noted above,every method invocation in Objective-C results in oneor more messages to the objc_msgSend runtimefunction. By utilizing the Objective-C runtime wewere able to intercept all messages to that centraldispatcher and to retrieve a clear trace of all methodinvocations. In detail, we replaced the implementationof the objc_msgSend function in order to log theCPU registers R0 and R1 which hold a pointer to thereceiving class instance and the name of the callingmethod at this stage. As the logging procedure itselfmodifies the CPU registers as well as the stack, itis essential to preserve the current execution statewithin the prologue of the replacement function. Onassembly level, we allocated an alternate stack withinheap memory and copied the values of the main CPUregisters including the Link Register to this alternatestack. Following this, we logged the related registervalues into a database, resolved the associated classname of the receiving instance and restored the mainstack before continuing normal execution. To focus onapp-specific method invocations only, we enumeratedall classes and methods of each running app using theObjective-C runtime API. Using this approach we wereable to precisely determine the amount of invokedObjective-C app methods.

b) Comparison of Execution Strategies: We evalu-ated the achieved method coverage of each executionstrategy within several experiments. Therefore, weexecuted each of the above mentioned 1,136 App Storeapps using the open-close, the random and the smartexecution strategy. In each case, the execution timewas limited to three minutes, except one additionaltest run using the smart execution strategy for anotherfive minutes.

The experimental results are shown in Figure 3a.While starting an app without any further user interac-tion (Open-Close Execution), 13 % of all available app

methods were accessed. By simulating random events(Random Execution) for three minutes, the averagecoverage rate was increased to 17 %. Compared tothat, three minutes of running an app using SmartExecution achieved an average method coverage ofonly 16 %, while executing an app for five minutesusing Smart Execution further increased the coverageto 18 %. When comparing the results by category, weobserved various differences. While some apps like, e.g.,Weather apps achieve a higher coverage due to thesynchronization of weather data during start up, socialnetworking apps often could not progress past theinitial welcome screen due to missing login credentials.

It is notable that within a three minute executiontime frame, simulating random events achieves highercoverages than driving an app’s user interface smartly.There are several reasons for this: First, random execu-tion already takes an app’s UI state into account as theevents are weighted and it preferably tabs navigationbar buttons. Therefore, it should be considered rather ahybrid of random and smart execution. Second, SmartExecution takes a long time to examine an app’s userinterface via UI Automation and to maintain the UI statemodel. This is why we supposed a strong dependenceon the execution time. In order to study the actualimpact of the execution time, we selected 67 apps fromour sample set and executed them for additional 30minutes. The selection was mainly based on those appsat which the coverage has improved by 5 % withinfive minutes of Smart Execution. By running theseselected apps for additional 30 minutes using SmartExecution, we observed an average method coverageof 23 %. This represents an average increase of 9 % perapp compared to the initial Open-Close Execution (seeFigure 3b).

Although we observed an increase in coverage byraising the execution time, we still found the overallcoverage relatively low (< 30%). This is why weinvestigated the actual amount of invoked app methodswhen an app is used manually. Therefore, we randomlyselected 23 apps (one of each category) and executedeach of them by hand for five minutes. We tried tocover as much UI elements as possible, while trackingthe amount of invoked app methods. We observed anaverage method coverage of around 27.3 % after threeminutes and 29.4 % after five minutes. Our resultsindicate that even within ordinary app usage, theachieved code coverage reaches a saturation pointat around 30 %. We noticed that most of the idlemethods are provided by view controllers, libraries

and obsolete testing routines which are either invokedwithin certain conditions only or not used at all. Atleast, it was not possible to invoke these methods bybrowsing the user interface for five minutes by hand.These results underline the strengths of our automaticUI exploration techniques that achieve comparable highcoverage results.

To date, only a few studies have examined theamount of covered code achieved through automaticallybrowsing a mobile app’s user interface. Szydlowski etal. [14] observed a coverage rate of 16 % during thestartup phase of an iOS app. These results are mostlyconsistent with our observations (∼13 %). Gilbert etal. [10] executed nine Android apps using a randomsimulation approach. The authors observed a basicblock code coverage of 40% or lower and also experi-enced the limitations of UI exploration regarding socialnetworking apps, where they measured a coverageof less than 1%. Finally, the authors of the Androidanalysis platform TraceDroid [27] observed a maximumcoverage rate of 33.6 % when applying their solutionto 35 Android apps. Moreover, they found the overallcoverage of stimulating apps manually at a comparablelow level (32.9 %), which again confirms our iOS-basedobservations. Altogether, the observations outlined inthis report provides for the first time key insights intothe amount of covered code by automatically exploringthe user interfaces of a fairly large quantity of real iOSApp Store apps.

IV. LARGE-SCALE PRIVACY ANALYSIS OF IOS APPS

In order to demonstrate the scalability and reliabilityof DiOS we analyzed our selection of 1,136 top freeapps (as of May 10, 2013) for privacy issues. Theprimary goal was to give an overview of privacy-relatedAPI accesses and network communication. Withinthis section, we describe the experimental setup, theprivacy criteria our study was based and the resultswe observed.

A. Experimental Setup

Our analysis was carried out using four iPhone 4devices running iOS 6 which have been prepared witha basic DiOS analyzer component that tracks an app’saccess to privacy-related API methods and its networkcommunication. Within a first experiment we executedeach app using DiOS’ basic Open-Close executionstrategy to establish a baseline reference of privacy-related data that is accessed by only downloading andstarting an app from Apple’s App Store. Within a second

● ●● ●● ●● ●●●●● ● ●●● ● ●● ●● ●● ● ●● ●● ● ●● ●

● ●● ●● ●● ●●● ●●● ● ●● ● ● ●● ●●● ● ●● ●● ●● ●● ●● ●●● ●●● ●● ●●

● ●● ●● ●● ●●● ●● ●● ●● ● ●●● ●●●●● ●● ● ●● ●●● ●● ●●● ●●

● ●● ●● ●● ●● ●● ●●● ●● ● ●● ● ●●● ●● ● ●●● ●● ●● ● ●●●●● ● ●●

Smart (5)

Smart (3)

Random

OpenClose

All

0 10 20 30 40 50 60 70 80Method Converage in %

● ●● ●

●● ●●

● ●

●● ●

Smart (5)

Smart (3)

Random

OpenClose

Weather

0 10 20 30 40 50 60 70 80Method Converage in %

●

●

●

●

Smart (5)

Smart (3)

Random

OpenClose

Social N

etworking

0 10 20 30 40 50 60 70 80Method Converage in %

(a) Amount of invoked app methods by execution strategy grouped by selected categories

● ●●● ●

●●●

● ●●

Smart (30)

Smart (5)

Smart (3)

Random

0 5 10 15 20 25Change of method coverage in % compared with open−close execution results

(b) Change of method coverage by comparing several execution strategies to basic Open-Close Execution

Fig. 3: Comparison of achieved method coverage by executing apps automatically using different executionstrategies.

run using DiOS’ Smart Execution, we determined anydeviation from our baseline reference when apps areexecuted and automatically navigated for five minutes.

B. Analysis Criteria

Within our analysis we were interested in tracking anapp’s access to all personal data available on a mobiledevice such as a user’s contacts, calendars, photos,and hardware sensors like the microphone, camera,accelerometer, GPS etc. Therefore, we extracted all rele-vant API methods and monitored each access. Althoughsome of these methods require a user’s consent to beinvoked, we were interested in tracking them anyway,as excessive access to these data may raise downstreamprivacy issues. Moreover, we compiled a list of the mostpopular advertising and analytic providers for iOS andhooked each specific initialization methods. As mostof those services permanently track a user’s app usagebehavior, we consider them highly privacy-relevant.

In the end, one major advantage of dynamic analysisover static analysis [16] is the ability to easily trackruntime information like network traffic. Thus, we alsomonitored the related iOS methods that are used forHTTP communication.

While implementing our analysis library, we facedseveral challenges of determining the real source of aspecific API access. For instance, system frameworksoften invoke sensitive API within normal operation.Those regular accesses need to be separated frommethod calls originating from an app itself, in orderto avoid false positives. Therefore, we utilized theObjective-C runtime to return a backtrace of the currentcall stack every time a privacy-related method wasinvoked. Thus, we were able to determine the namesof the calling methods, to identify the inquiring codepart and to ignore accesses from system frameworks.

C. Results

The following presentation of our analysis results isdivided into five parts.

1) Personal Data: For obvious reasons, invocationsof API methods providing direct access to personaldata are the most relevant parameters to study pri-vacy implications. Unsurprisingly, we found a user’scalendar most frequently accessed from apps of theproductivity (30 %) and business (20 %) categories, andmost accesses to a user’s photos for apps of the photos& video category (35.4 %). However, it is importantto highlight that almost one third of all accesses to auser’s contacts are attributed to apps from the socialnetwork (29 %) category, followed by travel (19.4 %)and navigation (9.7 %) apps.

Moreover, we revealed that almost 20 % of allinvestigated apps access a user’s location at everystartup. After five minutes of execution, the averageamount increased to 25.6 % (see Figure 4). As expected,most of the location accesses were registered withinapps from the navigation (15.5 %), followed by appsfrom the weather (14 %) category, obviously to displaycontextual data. One in five social networking appsalso accesses a user’s location on every app start. Aprominent example is the official Facebook app thatcollects a user’s position on every launch, without anyobvious usage scenario. This is especially precariousas most phones are usually switched on and carriedalong and, therefore, the collected location data givesa deep insight into users’ habits and personal activities[28].

Finally, accesses to a device’s camera, microphoneand other sensors like the accelerometer are of particu-lar interest, as sensor access is unrestricted within iOS6 and does not require a user’s consent. While accessesto the microphone and the camera, as depicted inFigure 4, are privacy-relevant for obvious reasons, risksassociated with the accelerometer sensor need furtherexplanation. Marquardt et al. [29] demonstrated thatthe data provided by the accelerometer sensor is preciseenough, to allow an app to recover text entered ona nearby keyboard. Though we do not assume thatthis practice is widespread, however, 15.7 % of all appswould be able to make use of this technique.

2) Advertising and Analytic Libraries: A vast majorityof all investigated free apps are using advertising andanalytic services. While the main purpose of advertisingservices is to monetize apps by displaying targeted adsto its users, analytic libraries are meant for providing

detailed statistics on how, when and where an appis used. In detail, we observed that 39.9 % of allinvestigated apps make use of at least one trackingservice. Among these, the services provided by Flurry(21.8 %), Google Analytics (10.2 %) and Google AdMob(7.5 %) where the most prevalent (see Table I). Asalmost every second app uses tracking and advertisingservices provided by either Flurry or Google, thesetracking providers are able to track a user’s behaviorand activities even across apps. This is of particularinterest from a privacy perspective, as providers likeGoogle have the ability to establish a link between adevice’s hardware identifier and the real identity of itsowner. Once authenticated within any Google serviceon an iOS device, Google would be capable of trackinga user’s activities from within all apps, in which theirlibraries are integrated.

TABLE I: Amount of tracking and advertising librariesused within the 1,336 top free apps (reduced to thetop 10 most prevalent libraries).

Library # Apps

Flurry 248 (21.8%)

Google Analytics 116 (10.2 %)

Google AdMob 85 (7.5 %)

Tapjoy 64 (5.6 %)

Chartboost 35 (3.0 %)

Testflight 29 (2.6 %)

Localytics 20 (1.8 %)

Mixpanel 10 (0.9 %)

MobileAppTracker 9 (0.8 %)

Apsalar 8 (0.7 %)

TABLE II: Top 10 of the most frequently requesteddomains ordered by the number of apps.

Domain # Apps # Requests

flurry.com 257 (23.15 %) 588 (5,41 %)

facebook.com 155 (13.96 %) 377 (3,47 %)

admob.com 127 (11.44 %) 157 (1,44 %)

apple.com 75 (6.76 %) 164 (1,51 %)

tapjoyads.com 65 (5.86 %) 216 (1,99 %)

crashlytics.com 63 (5.68 %) 63 (0,58 %)

ioam.de 62 (5.59 %) 174 (1,60 %)

amazonaws.com 40 (3.60 %) 141 (1,30 %)

chartboost.com 37 (3.33 %) 91 (0,84 %)

googleadservices.com 37 (3.33 %) 148 (1,36 %)

5.2 %

15.7 %

7.6 %

10.3 %

3.6 %

7.7 %

0.4 %

3.2 %

19.2 %

25.6 %

1.8 %

2.9 %

0.9 %

4.4 %

0.6 %

0.9 %

Accelerometer

Audio Input

Camera

Social Network Acc

Location

Contacts

Photos

Calendar

0% 10% 20%App ratio

Execution StrategyOpenCloseSmart (5)

Fig. 4: Amount of apps accessing sensitive API during startup compared to five minutes of Smart Execution.

3) Network Communication: We found 77.7 % of allinvestigated apps communicating via HTTP within thefirst 30 seconds after startup. Almost two third (71.2 %)of all communication is unencrypted. Furthermore, wenoticed that a large part of all mobile communicationis attributed to advertising networks. In detail, almostone fifth (18.7 %) of all requests are addressed toonly a limited number of domains, mostly servers ofadvertising services, as presented in Table II. Moreover,it is worth mentioning that almost 14 % of all appsunder review are transmitting data to Facebook’sservers. Again, these figures confirm the dominanceand omnipresence of mobile advertising.

D. Discussion

As our results demonstrate, mobile advertising hasbecome well-established in recent times. While mobiledevices provide a suitable platform for target-orientedadvertising, least because of their tight integration inour daily lives, the privacy concerns are obvious. Thisis why Apple introduced new privacy controls withthe release of iOS 7 such as eliminating access toseveral hardware identifiers like the Unique Device ID(UDID) or the Wi-Fi MAC address. Though given thelong history of tracking identifiers in iOS, it remainsto be seen if deprecating the UDID and eliminating

the Wi-Fi MAC address is sufficient to push developersto use Apple’s preferred software-based advertisingidentifiers. We presume no significant changes in ashort-term, as advertisers had enough time to correlatea user’s hardware identifier with self-defined trackingcookies. With regard to other privacy aspects of iOS, weobserve a self-contradictory development. While appsare supposed to ask a user for permission to access themicrophone since iOS 7, the camera is still accessiblefrom any app without any restrictions. This still allowsany app to take pictures and to transfer them off thedevice without users consent and knowledge.

For the moment, the main goal of our study wasto demonstrate the practicability of DiOS. Therefore,we focused on the amount of sensitive API methodsaccessed upon launch and compared the results to a fiveminute execution run of each app. We noticed that mostof the privacy-related APIs are called within the firstseconds after an app is launched. We assume that evenapps with malicious intents behave in the same way, asfrom a psychological perspective it is reasonable thatusers might be more willing to grant permission straightafter the initial startup, being curious about whether anapp delivers what it promises. However, future studiesmust provide evidence on this assumption.

V. SUMMARY AND FUTURE WORK

With the exploding number of third-party apps avail-able in the Apple App Store the risk of malicious appsaccessing personal information rises. This developmentdemands for automated analysis solutions in order tofacilitate empirical studies on the security and privacylandscape of iOS mobile apps.

To address this need, we presented DiOS, a fully-automated dynamic analysis solution for large-scaleanalysis of iOS apps. DiOS features a scalable frame-work, to schedule apps from the App Store to anynumber of connected iOS devices. We proposed anovel approach to exercise an app’s user interface andto simulate user interaction as realistic as possible.We evaluated different execution strategies providedby DiOS and showed that the coverage rate of ourautomatic UI exploration approaches is comparablyhigh as within common manual app usage.

To demonstrate the practicability and reliability ofDiOS, we utilized its plugin architecture and analyzed1,136 of the most popular free apps from the AppStore. We tracked access to sensitive API methods andmonitored related network activities. We found outthat almost 80% of all observed apps send and receivedata within the first seconds after launch (two thirdof it unencrypted). Almost half of all apps are sharingdata with statistic and tracking libraries and thereforeaccess hardware identifiers in order to reliably trackusers. As only few tracking providers are prevalent in ahigh percentage of apps, user’s might be tracked acrossapps. These results are consistent with past studies[16].

In addition, our results indicate a significant privacyproblem within the current iOS permission model.Many apps take advantage of the fact that a user’spermission to access selected personal data is requiredonly once. This effect can be observed especially withinaccess to location services: One in every five appsaccesses the current location on every app launch.Once granted an app like, e.g., Facebook permission tointentionally access location services (e.g. in order todisplay nearby restaurants) it will track a user’s currentposition on every future app start without any furthernotifications.

Future Work: One shortcoming of DiOS’ automa-tion capabilities is the missing handling of registrationand authentication forms. Therefore, future versions ofDiOS might provide features to fill in forms in a context-sensitive way and to request manual assistance when

the method coverage of an app under review does notincrease although different execution strategies havebeen applied.

A major drawback of the DiOS analyzer is its missingability to determine if accesses to privacy-related APIreally constitute a privacy leak. Implementing tainttracking on the closed-source iOS (where apps areexecuted natively compared to other platforms) wouldrequire either a full system emulation [30] or binaryinstrumentation [31], [32]. In general, taint trackingas well as detecting malware or vulnerabilities in nativecode that are only exploited in certain trigger conditionswas far beyond the scope of the DiOS analysis platform.In our opinion this remains a research topic even apartfrom mobile malware. In fact, DiOS opens the doors forsuch new iOS based research questions and providesa solid basis for future work (not least because of itspluggable architecture).

Therefore, apart from taint tracking, a next stepwould be to extend the DiOS analyzer to detect moresubtle techniques of malicious apps. Recently, Han etal. [18] demonstrated a prototype malware app foriOS that was mainly based on dynamically loadingprivate frameworks at runtime. This is where dynamicanalysis techniques, like those provided by DiOS, aremore suitable than static analysis approaches [16].

One general limitation of all existing approachesto perform large-scale analysis of iOS apps from theofficial App Store is its jailbreak dependency. Regardlessif an app is analyzed statically [16] or dynamically, ajailbreak is required to defeat Apple’s FairPlay digitalright management technology in order to decrypt anapp’s code at runtime. Although, most of the DiOS clientcomponents currently require a jailbreak, the majorityof our techniques could be re-used on non-jailbrokendevices, as our automation is mainly based on standardtools provided by Apple. Solely the analyzing featuresof DiOS would have to be revised in order to placehooks not at runtime, but by modifying an app’s binary.

In summary, we believe that apart from trackingdown rogue apps and malware, reviewing well-knownand popular apps for permission misusage is at least asimportant. However, along both avenues, much remainsto be explored.

REFERENCES

[1] A. Thampi. Path uploads your entire iPhone addressbook to its servers. http://mclov.in/2012/02/08/path-uploads-your-entire-address-book-to-their-servers.html.

[2] J. Leyden. D’OH! Use Tumblr on iPhone or iPad, give yourpassword to the WORLD. http://www.theregister.co.uk/2013/07/17/tumblr_ios_uncryption/.

[3] M. Egele, T. Scholte, E. Kirda, and C. Kruegel, “A survey onautomated dynamic malware-analysis techniques and tools,”ACM Computing Surveys (CSUR), vol. 44, no. 2, p. 6, 2012.

[4] C. Willems, T. Holz, and F. Freiling, “Toward automateddynamic malware analysis using cwsandbox,” Security &Privacy, IEEE, vol. 5, no. 2, pp. 32–39, 2007.

[5] H. Yin, D. Song, M. Egele, C. Kruegel, and E. Kirda,“Panorama: capturing system-wide information flow for mal-ware detection and analysis,” in Proceedings of the 14th ACMconference on Computer and communications security. ACM,2007, pp. 116–127.

[6] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel,and A. Sheth, “TaintDroid: An Information-Flow TrackingSystem for Realtime Privacy Monitoring on Smartphones.” inOSDI, vol. 10, 2010, pp. 255–270.

[7] V. Rastogi, Y. Chen, and W. Enck, “AppsPlayground: automaticsecurity analysis of smartphone applications,” in Proceedingsof the third ACM conference on Data and application securityand privacy. ACM, 2013, pp. 209–220.

[8] M. Spreitzenbarth, F. Freiling, F. Echtler, T. Schreck, andJ. Hoffmann, “Mobile-sandbox: Having a deeper look intoAndroid applications,” in Proceedings of the 28th Annual ACMSymposium on Applied Computing. ACM, 2013, pp. 1808–1815.

[9] C. Zheng, S. Zhu, S. Dai, G. Gu, X. Gong, X. Han, and W. Zou,“Smartdroid: an automatic system for revealing ui-basedtrigger conditions in android applications,” in Proceedingsof the second ACM workshop on Security and privacy insmartphones and mobile devices. ACM, 2012, pp. 93–104.

[10] P. Gilbert, B.-G. Chun, L. P. Cox, and J. Jung, “Vision:automated security validation of mobile apps at app markets,”in Proceedings of the second international workshop on Mobilecloud computing and services. ACM, 2011, pp. 21–26.

[11] P. Gilbert, B.-G. Chun, L. Cox, and J. Jung, “Automatingprivacy testing of smartphone applications,” Technical ReportCS-2011-02, Duke University, Tech. Rep., 2011.

[12] L. K. Yan and H. Yin, “Droidscope: seamlessly reconstructingthe os and dalvik semantic views for dynamic androidmalware analysis,” in Proceedings of the 21st USENIX SecuritySymposium, 2012.

[13] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, “Crowdroid:behavior-based malware detection system for android,” inProceedings of the 1st ACM workshop on Security and privacyin smartphones and mobile devices. ACM, 2011, pp. 15–26.

[14] M. Szydlowski, M. Egele, C. Kruegel, and G. Vigna, “Chal-lenges for dynamic analysis of iOS applications,” in OpenProblems in Network Security. Springer, 2012, pp. 65–77.

[15] M. E. Joorabchi and A. Mesbah, “Reverse engineering iOSmobile applications,” in Reverse Engineering (WCRE), 201219th Working Conference on. IEEE, 2012, pp. 177–186.

[16] M. Egele, C. Kruegel, E. Kirda, and G. Vigna, “PiOS: DetectingPrivacy Leaks in iOS Applications.” in NDSS, 2011.

[17] Apple Inc. UI Automation JavaScript Reference.http://developer.apple.com/library/ios/#documentation/DeveloperTools/Reference/UIAutomationRef/.

[18] J. Han, S. M. Kywe, Q. Yan, F. Bao, R. Deng, D. Gao,Y. Li, and J. Zhou, “Launching Generic Attacks on iOS withApproved Third-Party Applications,” in Applied Cryptographyand Network Security. Springer, 2013, pp. 272–289.

[19] Apple Inc. iOS Security. [Online]. Available: http://images.apple.com/iphone/business/docs/iOS_Security_Oct12.pdf

[20] J. Freeman. Mobile Substrate. http://www.cydiasubstrate.com.

[21] Apple Inc. Instruments User Guide: Automating UITesting. [Online]. Available: http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UsingtheAutomationInstrument/UsingtheAutomationInstrument.html

[22] ——. iOS Human Interface Guidelines. [Online].Available: http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html

[23] ——. iTunes RSS Feed Generator. https://rss.itunes.apple.com.

[24] libimobiledevice. http://www.libimobiledevice.org.[25] Apple Inc. NSDistributedNotificationCenter. [Online].

Available: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSDistributedNotificationCenter_Class/Reference/Reference.html

[26] 148Apps.biz: App Store Metrics: Count of Application Sub-missions. http://148apps.biz/app-store-metrics/?mpage=submission.

[27] V. van der Veen, H. Bos, and C. Rossow, “Dynamic Analysisof Android Malware,” 2013.

[28] J. Krumm, “A survey of computational location privacy,”Personal and Ubiquitous Computing, vol. 13, no. 6, pp. 391–399, 2009.

[29] P. Marquardt, A. Verma, H. Carter, and P. Traynor, “(sp)iPhone:decoding vibrations from nearby keyboards using mobilephone accelerometers,” in Proceedings of the 18th ACMconference on Computer and communications security. ACM,2011, pp. 551–562.

[30] E. Bosman, A. Slowinska, and H. Bos, “Minemu: theworld’s fastest taint tracker,” in Proceedings of the14th international conference on Recent Advances inIntrusion Detection, ser. RAID’11. Berlin, Heidelberg:Springer-Verlag, 2011, pp. 1–20. [Online]. Available:http://dx.doi.org/10.1007/978-3-642-23644-0_1

[31] K. Hazelwood and A. Klauser, “A dynamic binaryinstrumentation engine for the ARM architecture,” inProceedings of the 2006 international conference on Compilers,architecture and synthesis for embedded systems, ser. CASES’06. New York, NY, USA: ACM, 2006, pp. 261–270. [Online].Available: http://doi.acm.org/10.1145/1176760.1176793

[32] P. Saxena, R. Sekar, and V. Puranik, “Efficient fine-grainedbinary instrumentationwith applications to taint-tracking,”in Proceedings of the 6th annual IEEE/ACM internationalsymposium on Code generation and optimization, ser. CGO’08. New York, NY, USA: ACM, 2008, pp. 74–83. [Online].Available: http://doi.acm.org/10.1145/1356058.1356069