Synthesis for Developing Apps on Mobile Platforms

Jeff Foster

University of Maryland, College Park

Armando Solar-Lezama

Massachusetts Institute of Technology

Schedule for session

¤ Jeff Foster and Armando Solar-Lezama, Overview of current plans and work

¤ Thibaud Hottelier, Programming By Demonstration: But what if the user is fallible?

¤ Joel Galenson, CodeHint demo

2

Android Popularity

¤ Android — most popular smartphone platform ¤  70.1% of the market in 4Q12 ¤  850K Android apps on Google Play

(Apr. 2013) ¤  40 billion apps downloaded (Apr. 2013)

¤ Apps can be distributed by anyone ¤  Easy to install app from any site

¤ Android makes a good research platform

3

The Android Platform

¤ A software stack for mobile devices ¤  Operating system, middleware & key applications

¤ Use Android SDK to create applications ¤  Libraries & development tools

¤ Lots of documentation ¤  http://developer.android.com

¤ (Thanks to Adam Porter for the next batch of slides)

Android Architecture

http://developer.android.com/guide/basics/what-is-android.html

Dalvik Virtual Machine

¤ Applications typically written in Java ¤  Do not run in a standard Java virtual machine

¤ dx program transforms java classes into .dex-formatted bytecodes

¤ Bytecode executed in Dalvik Virtual Machine

¤ Applications typically run in their own processes, inside their own instance of the the Dalvik VM

Dalvik Virtual Machine (cont.)

¤ Dalvik VM designed to run on a handset ¤  Slow CPU

¤  Little RAM ¤  e.g., 64Mb total, ~10Mb available at runtime

¤  No swap space

¤  Limited battery life

Dalvik Design Choices

¤ Register- rather than stack-based ¤  More compact .dex files

¤  More efficient execution

¤ One .dex file for multiple classes ¤  More compact .dex files

¤ Modified garbage collection to improve memory sharing

¤ Optimizations applied at installation time

Application Framework

¤ Window Manager ¤  Manages top-level window’s look & behavior

¤ View system ¤  lists, grids, text boxes, buttons, etc.

¤ Content Providers ¤  Inter-application data sharing

¤ Activity Manager ¤  Application lifecycle and common navigation stack

Application Framework (cont.)

¤  Package manager ¤  Manages application packages

¤  Telephony manager ¤  State of telephony services

¤  Resource Manager ¤  Manages non-code resources: strings, graphics, and layout files

¤  Location manager ¤  Access to system location services

¤  Notification Manager ¤  Notify users when events occur

Applications

¤ Standard apps include: ¤  Home – main screen

¤  Contacts – contacts database

¤  Phone – dial phone numbers

¤  Browser – view web pages

¤  Email reader – Gmail & others

¤ Your App!

Building an Application

See: developer.android.com/guide/developing/building/index.html

Running an Application

¤ By default, each application: ¤  assigned a unique Linux user ID

¤  executes in its own Linux process

¤ By default, each process runs its own Dalvik virtual machine

¤ Android manages process creation & shutdown ¤  Starts process when any of the application's code needs to

be executed

¤  Shuts down when process is no longer needed and system resources are required by other applications

Application Components

¤ An App can have multiple entry points ¤  i.e., not just main() method

¤ App comprises components that the system can instantiate and run as needed

¤ Several key component classes, discussed next

Activity

¤ Primary class for interacting with user ¤  Usually implements a focused task

¤  Usually Involves one screenful of data

¤ Typically supports one thing a user can do ¤  View an email message

¤  Show a login screen

¤ Applications can include several activities

Activity Stack

16

developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html

Service

¤ Runs in the background to perform long-running or remote operations

¤ Does not have a visual user interface

BroadcastReceiver

¤ Component that listens for broadcast announcements (events) ¤  Events implemented as Intent instances

¤ Does not have a visual user interface

Content Providers

¤ Store & retrieve data across applications

¤ Uses database-style interface

¤ Example ¤  Contacts

Other Interesting Things on Android

¤  Intents — interprocess communication mechanism ¤  Also used to start up new Activities

¤ Fragments — layout for tables vs. phones

¤ Permissions — protects sensitive capabilities

20

Tools for Android

¤ We’ve been doing some work on Android security

¤ As a result, we’ve built up several tools for working with Android apps

¤ To explain those tools, brief aside into this other research

21

Permissions on Android

22

¤ Permissions associated with resources and OS features ¤  Internet, GPS, telephony, …

¤ Permissions granted at install time ¤  once granted, apps can use such

permissions any way they want

Finer-grained Permissions

¤ Goal: Introduce finer-grained permissions ¤  E.g., Gasbuddy has full access to Internet

¤  But only needs access to gasbuddy.com

¤ Benefits of finer-grained permissions ¤  Help app developers

¤  improve apps’ robustness against security exploits

¤  attest to apps’ proper usage of permissions

¤  Help users ¤  understand how apps use permissions

¤ Also, aim to do this without changing platform

23

Example Finer-grained Permissions

24

¤  Internet è InternetURL(d) ¤  InternetURL(gasbuddy_com)

¤ GPS è TruncatedLoc(d) ¤  Resolution up to distance d

¤ Phone state è PhoneState(p) ¤  PhoneState(UniqueID)

Our Tool Chain

¤  RefineDroid infers how permissions are used in the app

¤  Redexer/Dr. Android retrofits the app with fine-grained permissions

¤  Mr. Hide enforces fine-grained permissions at runtime 25

RefineDroid

Redexer/ Dr. Android

Mr. Hide services

Process boundary

org.apk

enh.apk

runtime install time

RefineDroid

¤  infers how permissions are used ¤  string analysis to search URL-like strings

¤  constant propagation to determine key parameters to privileged APIs ¤  e.g. for system settings:

26

Cursor c = getContentResolver().query( uri , projections , selection , ...);

int index = c.getColumnIndex(ContactsContract.PhoneLookup.NUMBER);

String id = c.getString (index );

TelephonyManager tm =(TelephonyManager) getSystemService(Context.TELEPHONY SERVICE);

String id = tm.getDeviceId();tm. listen (new PhoneStateListener() {...},PhoneStateListener.LISTEN CALL STATE);

Uri uri = Uri.parse (‘‘ my ringtone.mp3’’);RingtoneManager.setActualDefaultRingtoneUri(

this , RingtoneManager.TYPE ALARM, uri);String path = uri . toString ();Settings .System.putString(getContentResolver (),Settings .System.RINGTONE, path);

(a) Contacts (b) Phone state (c) System settings

Figure 3: Typical idioms detected by RefineDroid

popular apps from Google Play, and how many fine-grainedpermission are needed to replace each standard permissionin these apps.

3.1 Inferring Fine-grained PermissionsTo answer these questions, we developed RefineDroid, a

static analysis tool that analyzes an app’s Dalvik bytecodeto infer which of our fine-grained permissions are used bythat app. In particular, RefineDroid infers which networkdomains are accessed, i.e., InternetURL(d) permissions (cat-egory 1); which contact columns are used, i.e., ContactCol(c)permissions (category 2); which phone states are read, e.g.,for ReadPhoneState(p) permissions (category 4); and whichsystem settings are written, e.g., for WriteSettings(s) per-missions (also category 4). We believe RefineDroid is exten-sible to other category 1, 2, and 4 permissions.

RefineDroid does not infer usage of LocationBlock, since itand other category 3 permissions require an understandingof the sensor fidelity necessary for proper functioning of anapp. For example, it would not be useful to employ Loca-tionBlock in a navigation app, whereas it may be useful foran app that locates the nearest 5 post o�ces. In Section 6,we find that LocationBlock provides acceptable results forseveral popular apps.

RefineDroid’s analysis contains three major components.First, it includes a simple string analysis that determineswhat strings matching a particular pattern occur in thestring pool in the bytecode, e.g., what URL-like strings arementioned. Second, RefineDroid includes a mapping fromAndroid API calls to their necessary privileges, taken fromthe publicly available data of the Stowaway project [15].Third, RefineDroid implements constant propagation for in-tegers and strings [1] so that we can determine what stringsmay be passed to key parameters of privileged methods, e.g.,what name might be passed to Settings.System.putString().Our constant propagation analysis is a standard dataflowanalysis, augmented to precisely track the e↵ects of String-Builder.append, String.concat and Uri.<init>, as many appsuse these methods to manipulate the strings we must track.

Technical Details. RefineDroid infers the four permissiongroups mentioned above as follows. Note that below we de-scribe code patterns for each permission at the source level,but RefineDroid actually operates on Dalvik bytecode.InternetURL(d). RefineDroid collects all URL-like strings

appearing in the apk’s string pool and assumes those corre-spond to domains used by the app. Here by URL-like, wesimply mean that a standard URL parser accepts it as valid.ContactCol(c). Figure 3(a) gives some sample code that

queries the contacts database. First the code derives a cur-sor from one of several URIs for the contacts database. Then

specific columns are retrieved from the cursor by calling itsgetString() method with an index number, which is typicallydetermined by a call to getColumnIndex(), as shown in thefigure. Thus, to find which contact columns are accessed,RefineDroid uses constant propagation to find indices passedto getColumnIndex().ReadPhoneState(p). Figure 3(b) shows sample code that

accesses phone state information. The code begins by get-ting a TelephonyManager instance tm. That instance is usedin two di↵erent ways to access phone state. First, the calltm.getDeviceId() retrieves the phone’s IMEI number. Thus,in this and similar cases, RefineDroid determines a permis-sion is needed because a particular method is invoked. Sec-ond, the call to tm.listen() registers a callback that will beinvoked when there are state changes specified by the secondargument to listen(). Thus, for this case, RefineDroid usesconstant propagation to find the values of the second argu-ments to listen() and thereby determine needed permissions.WriteSettings(s). Figure 3(c) gives sample code that writes

to system settings, again in two di↵erent ways. First, thecode uses a RingtoneManager method to change a ringtone.For these cases, RefineDroid relies on method names to de-termine permissions. Next, the code uses Settings.System.putString() to change the ringtone. For this case, Refine-Droid once again uses constant propagation to find the ar-guments to putString() to determine permissions.

Limitations. RefineDroid deliberately performs a best-e↵ortstatic analysis, rather than attempting to be conservative.For example, if RefineDroid cannot determine which contactcolumn index is passed to a particular getString(), then it ig-nores that call, rather than conservatively assuming that allindices are possible. As another example, RefineDroid doesnot track invocations of the methods in some deprecatedAPIs, and it does not track invocations that occur via re-flection or in native code. Thus, RefineDroid may have falsenegatives.As is typical with static analysis, RefineDroid may also

have false positives, e.g., RefineDroid will report a staticallydetected call to a privileged method even if it is dynamicallyunreachable, and it will report a URL-like string even if itis never used to access the network.In Section 6, we report on the use of RefineDroid to infer

Internet domains and contact columns on a test suite of appsfrom Google Play. On these apps we find that RefineDroidproduces useful results with a low rate of false negatives.(Full details in Section 6.)

3.2 Study ResultsWe ran RefineDroid on the top 24 free apps in each Google

Play category as of April 11, 2012, yielding 750 apps in to-

Redexer/Dr. Android

¤ Dalvik Rewriter for Android ¤  injects hidelib.dex

¤  modifies the app’s bytecode to use Mr. Hide

¤  removes Android perms. and adds Mr. Hide perms.

27

input.apk output.apk

classes.dex

manifest.xml

Manifest Rewriter

Bytecode Rewriter

hidelib.dex

Mr. Hide

¤ the Hide interface to the droid environment ¤  services

¤  interact with a client app and resources

¤  client-side library ¤  a drop-in replacement for sensitive APIs

28

app

System.Settings.putString(…) hidelib.Settings.putString(…)

Mr. Hide services

System.Settings.putString(…)

hidelib

Process boundary

Kernel boundary

Sensitive Android APIs

TroyD

¤ Scripted test automation for Android

29

… def test_station click ”Continue” click ”I have a Pandora account” edit (0, ”account@...”) edit(1, ”password...”) click ”Sign In” menu … assert_text ”Antonio Salieri ” … acts = getActivities finish puts acts end

Synthesis to the Rescue

¤ Synthesis for tool developers ¤  Developing these tools introduces challenges that synthesis

can address

¤ Synthesis for expert programmers ¤  Next generation of tools to help transition from checking to

synthesis

¤ Synthesis for the end user ¤  Can every phone user be a developer?

30

Better tools through synthesis

¤ Case Study: SymDroid ¤  Symbolic execution for Dalvik bytecode

¤  Uses µ-Dalvik, an easy-to-analyze representation

¤ Challenges ¤  App code is tightly tied to the Android framework

¤  Framework is big and complex ¤  Symbolic execution of the framework is infeasible

¤  Hand creation of models is brittle and expensive

¤ Can you synthesize a model of Android?

31

Synthesizing an android model

¤  Idea: Multimodal synthesis ¤  Record interactions between framework and application

¤  “Sketch” a high-level view of the model

¤  State high-level properties of the synthesized model

32

Application

Android Framework

Android model as a reactive program

¤  Inputs ¤  External events

¤  Timers, user gestures, ¤  Include method being called + parameters

¤  Application calls ¤  Application return

¤ Outputs ¤  Calls from the framework to the application

¤ Model is not just an FSM ¤  Basic building blocks include FSMs, Stacks, internal

datastructures ¤  User-provided sketch helps guide the choice of building blocks

¤  Leverage known design patterns

33

Synthesis Challenges

¤ Conveying Structure ¤  Sketch is too low level

¤  We need a DSL based on design patterns

¤ Scalability ¤  Early experiments are encouraging

¤  Modularity will be crucial

¤ Client-Synthesis feedback loop ¤  Model should only be as complex as required by the

analysis

34

Synthesis tools for programmers

¤ Build on experience with synthesis tools for frameworks ¤  Prospector, MatchMaker

¤ Key problems ¤  How to describe what you want

¤  How to cope with complexity

¤ Technical directions ¤  Combining Data driven techniques with logic-based

engines

35

Synthesis for End Users

¤ Can we make a programmer of every android user?

36

End