axplorer

axplorer (Android explorer) is a static analysis tool to study Android's application framework's internals. It generates high-precision call-graphs for middleware services that are subsequently analyzed via control-flow slicing. As one of the results, axplorer can generate very accurate Android API to permission mappings.

Note: As for now we haven't released the source code yet, due to time constraints that prevent us from publishing well written and documented code.

Android Permission Mappings

For the API levels 16 (4.1) - 25 (7.1) we currently provide three different mappings (SDK, Application Framework, and ContentProviders).
For the SDK and framework mapping, the presence of multiple permissions does not necessarily mean that all permissions are required to execute the method. Often, permissions are only required for specific input arguments or execution paths. Hence, axplorer reports the upper threshold (a more fine-grained path-sensitive analysis is currently not available).

Current shortcomings:

• Maps for SDK/Framework >23 might be incomplete due to the fact that parts of the permission checking have been moved to the AppOpsManager (runtime permission checks). This requires some additional anaylsis which we have not implemented yet.
• Maps are currently missing APIs with permissions checked in native code (Camera, etc.). We hope to provide these soon.

Application Framework Mapping

The framework permission mapping includes any permission-protected, public method/API of the application framework that is accessible via inter-process communication (IPC). Apps might bypass the Android SDK to directly access these methods.

<method signature> :: <permission> [,<permissions>]

Android SDK Mapping

The SDK mapping includes the documented API that requires at least one permission. The documented API comprises everything the app developer is supposed to use when implementing against the SDK.

<method signature> :: <permission> [,<permissions>]

ContentProvider Mapping

The ContentProvider (CP) mappings includes any system ContentProviders that protect read/write operations on the entire CP or paths thereof with permissions (e.g. contact content provider). The mapping follows the template below (derived from Content-Provider Basics.

content:// <path|pathPrefix|pathPattern:<path*>> [R|W|RW|grant-uri-permission]

There exist four different invariants:

1. content:// [R|W|RW]
2. content:// [grant-uri-permission]
3. content:// <path|pathPrefix|pathPattern:<path*>> [R|W|RW]
4. content:// <path|pathPrefix|pathPattern:<path*>> [grant-uri-permission]

Example (invariant 1)

• com.android.providers.contacts.CallLogProvider content://call_log [R] android.permission.READ_CALL_LOG
• com.android.providers.contacts.CallLogProvider content://call_log [W] android.permission.WRITE_CALL_LOG

Example (invariant 3):

• com.android.bluetooth.opp.BluetoothOppProvider content://com.android.bluetooth.opp path:/btopp [RW] android.permission.ACCESS_BLUETOOTH_SHARE

Example (invariant 3+4):

• com.android.providers.downloads.DownloadProvider content://downloads pathPrefix:/all_downloads/ [grant-uri-permission]
• com.android.providers.downloads.DownloadProvider content://downloads pathPrefix:/all_downloads [RW] android.permission.ACCESS_ALL_DOWNLOADS
• com.android.providers.downloads.DownloadProvider content://downloads pathPrefix:/my_downloads [RW] android.permission.INTERNET
• com.android.providers.downloads.DownloadProvider content://downloads pathPrefix:/download [RW] android.permission.INTERNET

Permission Statistics

Number of permissions per API level by permission protection level.
API levels:
API 16 (Android 4.1, 4.1.1), API 17 (Android 4.2, 4.2.2), API 18 (Android 4.3), API 19 (Android 4.4), API 21 (Android 5.0), API 22 (Android 5.1), API 23 (Android 6.0), API 24 (Android 7.0), API 25 (Android 7.1)

Abbreviations:
signature (sig), development (dev), privileged (priv), installer (inst), preinstalled (pre)

Manifest files

The manifests directory contains the original AndroidManifest files for the framework (named: AndroidManifest-$APILEVEL.xml) and all system apps within the AOSP release.

Scientific publication

Abstract
In contrast to the Android application layer, Android's application framework's internals and their influence on the platform security and user privacy are still largely a black box for us. In this paper, we establish a static runtime model of the application framework in order to study its internals and provide the first high-level classification of the framework's protected resources. We thereby uncover design patterns that differ highly from the runtime model at the application layer.

We demonstrate the benefits of our insights for security-focused analysis of the framework by re-visiting the important use-case of mapping Android permissions to framework/SDK API methods. We, in particular, present a novel mapping based on our findings that significantly· improves on prior results in this area that were established based on insufficient knowledge about the framework's internals. Moreover, we introduce the concept of permission locality to show that although framework services follow the principle of separation of duty, the accompanying permission checks to guard sensitive operations violate it.

Paper
For technical details and evaluation results, please refer to our publication:

On Demystifying the Android Application Framework: Re-Visiting Android Permission Specification Analysis
Usenix Security 2016