pith. sign in

arxiv: 1906.10238 · v1 · pith:G227HGWAnew · submitted 2019-06-24 · 💻 cs.CR

Mapping System Level Behaviors with Android APIs via System Call Dependence Graphs

Bin Zhao This is my paper

Pith reviewed 2026-05-25 16:58 UTC · model grok-4.3

classification 💻 cs.CR
keywords Android securitysystem call dependence graphspermission abusemalware detectionAPI mappingsystem callsmobile security
0
0 comments X

The pith

System Call Dependence Graphs map evadable Android APIs to unavoidable system behaviors.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes building graphs of dependent system calls to connect Android APIs with the system-level actions they trigger. Apps can avoid calling sensitive APIs but must still execute the underlying system operations, so the graphs trace those operations back to the responsible APIs. A reader would care because the method offers a route to detect apps that abuse permissions by concealing their API usage. The work presents itself as the first to create such mappings and reports that it identifies abuse effectively while adding almost no performance cost.

Core claim

By constructing System Call Dependence Graphs from system-level behaviors, the approach maps those behaviors to the Android APIs that produce them, even when apps evade direct API calls. This provides the first such mapping and supports identification of potential permission-abusing applications.

What carries the argument

System Call Dependence Graphs, which capture dependencies between system calls to associate behaviors with specific Android APIs.

If this is right

  • Apps that skip sensitive API calls can still be traced through their system calls.
  • Permission abuse becomes detectable without depending solely on visible API invocations.
  • The detection adds almost negligible performance overhead to monitored applications.
  • System behaviors serve as reliable indicators where direct API evidence is absent.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The graphs could be integrated into runtime monitors that flag hidden behaviors during app execution.
  • Similar dependence-graph techniques might extend to mapping behaviors on other mobile platforms.
  • Pairing the method with static analysis of declared permissions could raise overall detection rates.

Load-bearing premise

System-level behaviors cannot be avoided by apps while sensitive Android APIs can be evaded.

What would settle it

Running an app that performs a sensitive system operation yet produces no matching system calls or incorrect API mappings in the constructed graphs.

Figures

Figures reproduced from arXiv: 1906.10238 by Bin Zhao.

Figure 1
Figure 1. Figure 1: Architecture of Android System for declaring a manifest file, a set of XML elements and attributes for declaring and accessing resources, a set of intents, and a set of permissions that Android applications can request (e.g., READ_EXTERNAL_STORAGE), as well as permission enforcements included in the Android system. Android applications and system services are all implemented in Java [15]. They access to th… view at source ↗
Figure 2
Figure 2. Figure 2: An Example of application calling APIs and binder in Android system. The upper left [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Architecture of mapping system level behavior with Andr [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Architecture of camera services in Android system. [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: SCDGs obtained from CameraTest process. 6.2.3 Mapping System Level Behavior with Android APIs To map the system level behavior with Android APIs, Android’s logcat is introduced in our experiments. Android’s logcat collects logs for various applications and portions of the system, where the CameraTest and mediaserver are both included. Based on the timestamps in the system call traces, Android APIs and the … view at source ↗
Figure 6
Figure 6. Figure 6: Mapping between SCDGs and Android APIs. 6.2.4 Performance Evaluation We discuss the performance of our system in two metrics: memory usage and startup time. Memory Usage. We use Android’s own API to measure the memory usage by calling the meminfo. The average memory usage is 1.2% of total memory usage. This memory usage can be considered very small. CPU usage measurement is obtained in Android’s Monitoring… view at source ↗
read the original abstract

Due to Android's open source feature and low barriers to entry for developers, millions of developers and third-party organizations have been attracted into the Android ecosystem. However, over 90 percent of mobile malware are found targeted on Android. Though Android provides multiple security features and layers to protect user data and system resources, there are still some over-privileged applications in Google Play Store or third-party Android app stores at wild. In this paper, we proposed an approach to map system level behavior and Android APIs, based on the observation that system level behaviors cannot be avoided but sensitive Android APIs could be evaded. To the best of our knowledge, our approach provides the first work to map system level behavior and Android APIs through System Call Dependence Graphs. The study also shows that our approach can effectively identify potential permission abusing, with almost negligible performance impact.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes an approach to map system-level behaviors to Android APIs using System Call Dependence Graphs (SCDGs), based on the observation that behaviors cannot be avoided while sensitive APIs can be evaded. It claims to be the first such work and asserts that the method can effectively identify permission abuse with almost negligible performance impact.

Significance. If the SCDG-to-API mapping proves reliable and the negligible-overhead claim holds under controlled measurement, the work could strengthen dynamic analysis for detecting over-privileged or evasive malware on Android by linking unavoidable low-level traces to high-level API usage. The absence of any reported quantitative validation (precision, recall, false-positive rates, or baselines) in the abstract leaves the practical significance undetermined.

major comments (2)
  1. [Abstract, §4] Abstract and §4 (Evaluation): the claim that the approach 'can effectively identify potential permission abusing' is unsupported by any reported metrics, ground-truth experiment, or comparison; no precision/recall figures, false-positive rates, or baseline detectors are supplied, making the effectiveness assertion unanchored.
  2. [§3] §3 (SCDG Construction and Mapping): the core attribution step assumes SCDGs uniquely identify the responsible API, yet the text does not describe a controlled experiment that isolates individual API invocations, records their SCDGs, and measures attribution accuracy; overlapping call patterns from Binder, libc, or native code are not addressed, risking ambiguous mappings.
minor comments (2)
  1. [Abstract] The abstract states 'to the best of our knowledge' without citing prior SCDG or system-call-to-API mapping literature; a brief related-work paragraph would clarify novelty.
  2. [Abstract, §4] Performance impact is described only qualitatively ('almost negligible'); any timing or resource measurements should be reported with concrete numbers and experimental setup.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed comments. We address each major point below and describe the revisions planned for the next version of the manuscript.

read point-by-point responses

  1. Referee: [Abstract, §4] Abstract and §4 (Evaluation): the claim that the approach 'can effectively identify potential permission abusing' is unsupported by any reported metrics, ground-truth experiment, or comparison; no precision/recall figures, false-positive rates, or baseline detectors are supplied, making the effectiveness assertion unanchored.

    Authors: We agree that the current abstract and §4 do not supply quantitative metrics (precision, recall, FPR, or baselines) to support the effectiveness claim for permission-abuse identification. The manuscript's primary contribution is the SCDG-based mapping technique itself. In the revision we will (1) qualify the abstract claim and (2) expand §4 with a ground-truth evaluation that reports precision, recall, and comparison against baseline detectors. revision: yes

  2. Referee: [§3] §3 (SCDG Construction and Mapping): the core attribution step assumes SCDGs uniquely identify the responsible API, yet the text does not describe a controlled experiment that isolates individual API invocations, records their SCDGs, and measures attribution accuracy; overlapping call patterns from Binder, libc, or native code are not addressed, risking ambiguous mappings.

    Authors: We accept the observation that §3 lacks an explicit controlled experiment isolating individual API calls and quantifying attribution accuracy, and does not discuss potential overlaps from Binder, libc, or native code. The revised manuscript will add such an experiment to §3, including accuracy measurements and explicit treatment of ambiguous call patterns. revision: yes

Circularity Check

0 steps flagged

No circularity; approach is observational with no derivations or fits

full rationale

The provided abstract and description contain no equations, parameters, self-citations, or derivation chains. The core claim is an empirical mapping method based on the observation that system behaviors cannot be avoided while APIs can. No load-bearing step reduces to its own inputs by construction, fitting, or self-citation. This matches the default expectation of a non-circular paper; the reader's score of 2.0 is consistent with absence of circular elements.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review supplies no information on free parameters, background axioms, or newly postulated entities.

pith-pipeline@v0.9.0 · 5659 in / 1095 out tokens · 25971 ms · 2026-05-25T16:58:49.397352+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

2 extracted references · 2 canonical work pages

  1. [1]

    Security Enhanced (SE) Android: Bringing Flexible MAC to Android,

    Smalley, S. and R. Craig (2013) “Security Enhanced (SE) Android: Bringing Flexible MAC to Android,” in NDSS ’13 20th Annual Network and Distributed System Security Symposium. [11] Google Android Developers, “Android Security Overview,” http://source.android.com/devices/tech/security/. [12] Google Android Developers, “System Permissions,” http://developer....

    work page 2013

  2. [2]

    What is API Level?

    Android Developers, “What is API Level?” http://developer.android.com/guide/topics/manifest/uses-sdkelement.html#ApiLevels. [28] Enck, W., P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth (2010) “TaintDroid: An Information-flow Tracking System for Realtime Privacy Monitoring on Smartphones,” in Proceedings of the 9th USENIX Confere...

    work page doi:10.1109/tifs.2018.2879302 2010