Skip to content

android-analysis.adoc

Latest commit

 

History

History
167 lines (115 loc) · 7.87 KB

android-analysis.adoc

File metadata and controls

167 lines (115 loc) · 7.87 KB

attributes.adoc

How to Use Android Analysis?

Tai-e supports analyzing Android APKs. Android analysis is implemented as a plugin of the pointer analysis framework. To analyze Android programs, users need to run pta with Android mode enabled, and Android-specific modeling is then enabled automatically.

This design allows Android analysis to directly reuse the capabilities and implementations provided by the pointer analysis framework, including various context-sensitivity and heap-abstraction techniques, as well as the handling of complex language features such as reflection. It also makes Android analysis work naturally with Tai-e’s existing taint analysis plugin. For details on pointer-analysis options and taint-analysis configuration, see Pointer Analysis Framework and Taint Analysis.

Our Android analysis is also described in the following ICSE 2025 paper: PacDroid: A Pointer-Analysis-Centric Framework for Security Vulnerabilities in Android Apps.

Currently, Tai-e’s Android analysis mainly models the following Android framework semantics:

  • lifecycle and callback semantics

  • inter-component communication (ICC)

  • several misc framework behaviors that affect object propagation

This document aims to help users quickly start Android analysis in Tai-e and gain an overall understanding of the Android semantics currently supported.

Enabling Android Analysis

Android analysis can be enabled with a small set of options. In most cases, you only need to do the following two steps.

Step 1: Fetch Required Submodules

Before running Android analysis, make sure that the following submodules have been fetched:

  • java-benchmarks

  • android-benchmarks

You can fetch them in the project root directory by running:

git submodule update --init --recursive

These submodules provide the libraries and benchmark APKs used by the examples below. Some taint-analysis examples below also use configuration files from android-benchmarks. Depending on your network environment, fetching these submodules may take some time.

Step 2: Run pta in Android Mode

To analyze an APK, provide the APK path, enable Android mode, and run pta. For example:

-cp android-benchmarks/suite/DroidBench/apk/Lifecycle/ActivityLifecycle1.apk -am -a "pta=cs:ci"

Here:

  • -cp specifies the target APK.

  • -am enables Android mode.

  • -a "pta=…​" runs pointer analysis, which in turn automatically enables Android analysis.

If needed, users may additionally specify -ajs / --android-jars to override the default Android platform directory. The default value is android-benchmarks/android-platforms, which is expected to contain Android platform jars organized by API level, as in a standard Android SDK platform directory. Users may pass either such an SDK platforms/ directory or the compatible directory provided by android-benchmarks.

This example does not enable taint analysis, but it already enables Android lifecycle, callback, and ICC modeling. If you further want to run taint analysis on Android programs, see Using Android Analysis with Taint Analysis below.

Note
 In Android mode, Tai-e automatically infers the target Java version from the APK and automatically enables phantom references. It also applies the following Android-related default options to pta:

  • implicit-entries:false

  • distinguish-string-constants:app

  • propagate-types:[reference,int,long,double,char,float]

Note
 During world building, Tai-e may report some frontend warnings. This is expected in Android mode: Tai-e preloads a small set of Android-related basic classes, and classes that are unavailable may be treated as phantom classes. Such warnings do not necessarily indicate that the analysis has failed.

Using Android Analysis with Taint Analysis

This section explains how Android analysis works together with taint analysis.

Android analysis is most commonly used together with taint analysis. Android analysis itself is built on the pointer analysis framework, and Tai-e’s existing taint analysis plugin is built on the same framework. Therefore, when users want to perform taint analysis on Android programs, they can naturally reuse the taint-analysis capabilities already provided by Tai-e, such as the source / sink / transfer configuration mechanism. Android analysis further complements these capabilities with Android framework semantics, such as lifecycle, callback registration, asynchronous execution, and ICC communication. This helps connect source, sink, and intermediate propagation paths more soundness in Android apps.

Running Taint Analysis on Android Programs

If you want to run taint analysis on Android programs, the usage is similar to ordinary Java programs: provide taint-config in the pta options:

-cp <path/to/app.apk> -am -a "pta=...;taint-config:<path/to/taint-config.yml>;..."

For example, you can use the following DroidBench APK and test configuration from this repository:

-cp android-benchmarks/suite/DroidBench/apk/Callbacks/Button1.apk -am -a "pta=cs:ci;taint-config:android-benchmarks/suite/taint-config.yml"

Available Taint Configurations

The current Android tests in this project use the following ready-to-use configurations:

  • android-benchmarks/suite/taint-config.yml

  • android-benchmarks/suite/real-world/taint-config-real-world.yml

The first configuration is used by the micro-benchmark suites under suite/, including DroidBench, ICC-Bench, UBCBench, and extra-icc. The second configuration is used by the suite/real-world collection, whose APKs are collected from TaintBench and UBCBench, and manually labeled to contain real taint flows.

For the semantics and syntax of taint configurations, please refer to How to Use Taint Analysis?.

What Android Behaviors Are Currently Modeled?

This section summarizes the Android behaviors currently modeled by the implementation.

Lifecycle and Callbacks

Tai-e extracts information from the APK manifest, layout files, resource files, and Android callback configuration, and uses it to supplement analysis entry points. The current coverage mainly includes:

  • lifecycle methods of Application, Activity, Service, BroadcastReceiver, and other components

  • Android framework callbacks

  • callback / fragment / view information declared in layout XML files

  • dynamically registered `BroadcastReceiver`s

  • dynamically added `Fragment`s

The goal of this modeling is to make the analysis see Android framework dispatch behaviors that are not triggered by ordinary Java calls.

Inter-Component Communication (ICC)

Tai-e currently models several common ICC scenarios, including:

  • startActivity(…​)

  • startActivityForResult(…​) and its reply path

  • sendBroadcast(…​)

  • startService(…​)

  • bindService(…​)

  • Intent / IntentFilter attribute matching

  • Messenger-based communication and partial AIDL-related object propagation

The analysis combines explicit/implicit Intent, manifest-declared `intent-filter`s, and filter information of dynamically registered receivers to infer possible target components.

Other Common Android Framework Behaviors

Besides lifecycle and ICC, the current implementation also models several common Android framework behaviors that significantly affect points-to propagation, for example:

  • SharedPreferences and its listener callbacks

  • Handler

  • AsyncTask

  • several map-like Android containers, such as Intent extras and Bundle

The purpose of this modeling is to reduce information loss caused by common Android framework behaviors, especially asynchronous or framework-mediated behaviors.