Android Permission Model

Android’s security model is primarily enforced through a permission-based mechanism. Applications must declare the permissions they require in their AndroidManifest.xml, which are then requested at install time (pre-Android 6.0) or dynamically at runtime (Android 6.0+). Runtime permissions provide more granular user control, but privileged system applications can still leverage hidden or internal permissions that are inaccessible to normal third-party apps.

To access such privileged capabilities in this research, a dedicated privacypeek.xml file was placed at /system/etc/permissions/ through the Magisk module template. This file grants com.iamcod3x.privacypeek access to critical system-level APIs:

<?xml version="1.0" encoding="utf-8"?>
<permissions>
  <privapp-permissions package="com.iamcod3x.privacypeek">
    <permission name="android.permission.GET_APP_OPS_STATS"/>
    <permission name="android.permission.PACKAGE_USAGE_STATS"/>
    <permission name="android.permission.READ_PRIVILEGED_PHONE_STATE"/>
    <permission name="android.permission.INTERACT_ACROSS_USERS"/>
  </privapp-permissions>
</permissions>

These permissions allow Privacy Peek to access fine-grained application usage statistics, privileged telephony state, and cross-user interactions—capabilities that are normally reserved for system-level processes.

Rooting and Magisk Capabilities

Root access is a prerequisite for bypassing Android’s default application sandboxing. This research leverages Magisk v24.3, configured with:

• RAMDISK: Enabled
• Zygisk: Enabled
• SELinux Kernel Status: Permissive

Magisk provides a systemless rooting mechanism, enabling the injection of additional permissions, modules, and binaries without altering the system partition. This flexibility makes it ideal for building reproducible instrumentation frameworks.

Existing Monitoring Tools

Prior work such as PrivacyDashboard attempted to provide visibility into Android app permissions. However, these tools exhibit significant limitations:

• Limited monitoring scope (permissions only, without file access behaviors).
• Lack of ongoing development (last update over three years ago).
• Restricted to visible permission states, with no kernel-level instrumentation.

These limitations motivated the development of a deeper, kernel-assisted monitoring solution that extends beyond manifest declarations.

Linux Fanotify for System-Level Monitoring

Linux provides several file monitoring APIs (inotify, dnotify, fanotify), of which fanotify is the most suitable for system-wide auditing. Unlike inotify, which operates at a file-descriptor level, fanotify allows monitoring of all file system operations globally, including access, modification, creation, and deletion events.

However, fanotify is not enabled by default in most Android kernels. To overcome this, a custom kernel was built with the following configurations enabled:

CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y

The modified kernel source was derived from ViP3R-KERNELs (OnePlus 3T, MSM8996 platform), ensuring compatibility with Android 11 (LineageOS(MicroG)) and newer devices.

This kernel-level enhancement enables FaNoMonitor, the custom binary developed in this work, to capture and log file system activities in real time, complementing Privacy Peek’s permission tracking capabilities.

The design of Privacy Peek and its associated monitoring framework was guided by several key goals to ensure practicality, completeness, and extensibility.

Operate on Real Devices

Unlike emulator-based studies that may not reflect real-world conditions, this research is conducted on physical devices:

• OnePlus 3T — LineageOS with MicroG, Android 11, Kernel 3.18.
• Xiaomi Onclite (Redmi 7) — Ethereal OS, Android 14, Kernel 4.9.

Both devices are rooted with Magisk, enabling system-level monitoring capabilities.

Comprehensive App Coverage

The framework is designed to enumerate and analyze all installed applications, both official apps from trusted sources and modded/pirated apps from unverified origins. This inclusive scope ensures meaningful comparisons between the two ecosystems.

Permission and File-Access Visibility

The system captures:

• Declared and runtime-granted permissions.
• File-system operations (create, read, modify, delete).
• Logs linked to app identities (UID/PID) for traceability.

Extensibility for Future Enhancements

The architecture is designed with extensibility in mind. A future enhancement under development involves integrating AI-driven behavioral watchers capable of flagging apps that exhibit suspicious or shadow activity beyond their declared scope. This forward-looking design ensures that Privacy Peek can evolve alongside the dynamic Android threat landscape.

Together, these design goals establish the foundation for the System Architecture described in the next section.

The architecture of Privacy Peek is designed to integrate seamlessly with rooted Android devices, leveraging both privileged system access and kernel-level monitoring to provide comprehensive visibility. The system consists of four primary components and a log collection pipeline.

System Components

• Privacy Peek (System App) — Installed as a privileged app via Magisk, responsible for listing all installed apps and managing the UI.
• Permission XML Injection — A special permission configuration file placed in /system/etc/permissions/ grants hidden system permissions (e.g., GET_APP_OPS_STATS, PACKAGE_USAGE_STATS).
• FaNoMonitor Binary — A custom Linux fanotify-based logger that records file operations (create, read, modify, delete) across all apps.
• Log Collection Pipeline — Mechanism for storing, filtering, and presenting captured events in a structured format.

Interaction Flow

1. The test device runs a rooted ROM with Magisk.
2. Privacy Peek is installed as a system app via Magisk.
3. On first launch, the app requests root privileges in order to:
   • Copy FaNoMonitor binary into /data/data/com.iamcod3x.privacypeek/files/.
   • Execute FaNoMonitor in the background.
4. FaNoMonitor continuously logs system-wide file access events into /data/data/com.iamcod3x.privacypeek/files/FaNoMonitor.log.
5. Privacy Peek LogReaderActivity parses the log file and filters events per application basis, ensuring that logs are presented in a meaningful and readable format rather than a raw dump.
6. The user interface provides:
   • Per-app event logs.
   • Data usage (Upload/Download) split across Wi-Fi and Mobile Data.

This modular architecture allows the system to function reliably on multiple Android versions and custom ROMs, while ensuring extensibility for future components such as AI-driven activity monitoring.

The implementation phase focused on integrating Privacy Peek and FaNoMonitor within a rooted Android environment to enable real-time monitoring of application behavior. Two test devices were configured to ensure reproducibility across different Android versions.

Devices and Operating Systems

• Xiaomi Onclite (Redmi 7) — Ethereal OS, Android 14, Kernel 4.9
• OnePlus 3T — LineageOS with MicroG, Android 11, Kernel 3.18

Both devices were rooted using Magisk v23.4 (Zygisk = enabled, SELinux = permissive) to allow system-level modifications without altering the read-only system partition.

Integration Steps

1. Installing Privacy Peek as a System App
   A Magisk module template was created to place the com.iamcod3x.privacypeek APK under /system/priv-app/PrivacyPeek/. This grants it elevated privileges normally reserved for pre-installed system apps.
2. Injecting Permission XML
   The following file was added at /system/etc/permissions/privacypeek.xml to expose privileged APIs to Privacy Peek:

   <permissions>
     <privapp-permissions package="com.iamcod3x.privacypeek">
       <permission name="android.permission.GET_APP_OPS_STATS"/>
       <permission name="android.permission.PACKAGE_USAGE_STATS"/>
       <permission name="android.permission.READ_PRIVILEGED_PHONE_STATE"/>
       <permission name="android.permission.INTERACT_ACROSS_USERS"/>
     </privapp-permissions>
   </permissions>

3. Compiling and Deploying FaNoMonitor Binary
   The FaNoMonitor binary was compiled with Android NDK (target API 30) using gcc –static to ensure compatibility across both devices. After deployment, it resides in /data/data/com.iamcod3x.privacypeek/files/ and executes with root privileges via su –c ./faNomonitor {targetUid} {Sock} .
4. Runtime Integration
   On first launch, Privacy Peek requests superuser permission, copies the binary if absent, and starts it in background service mode. The logs produced are continuously parsed by LogViewerActivity for real-time display within the app.

Sample Log Format

The FaNoMonitor binary outputs structured logs capturing the timestamp, process UID/PID, and file-operation details. Example excerpt:

[759399613000|PID=6846|UID=10166|PROC=com.iamcod3x.privacypeek|PATH=/system/app/CaptivePortalLogin/CaptivePortalLogin.apk|TYPE=OPEN|PKG=com.iamcod3x.privacypeek]
[1759399613000|PID=6846|UID=10166|PROC=com.iamcod3x.privacypeek|PATH=/system/app/CaptivePortalLogin/CaptivePortalLogin.apk|TYPE=ACCESS|PKG=com.iamcod3x.privacypeek]

These logs are filtered within Privacy Peek on a per-application basis, allowing detailed inspection without overwhelming the user with raw event dumps.

With Privacy Peek and FaNoMonitor integrated, the data collection phase focused on systematically capturing permission usage and file-access behavior across both official and modified (modded) applications. The goal was to establish a reproducible framework capable of differentiating behavioral patterns under real device conditions.

Data Sources

• Static Permission Data: Extracted from the Android Manifest of each installed app, including all declared permissions and protection levels.
• Runtime Permission Requests: Captured via Privacy Peek’s instrumentation of AppOpsManager and UsageStatsManager APIs.
• File-System Activity Logs: Streamed from the FaNoMonitor.log file, generated in real time through fanotify hooks on monitored devices.

Collection Process

1. Each app on the test devices (both official and modded variants) was launched sequentially using an automated shell script.
2. During execution, FaNoMonitor recorded file read/write/create/delete events while Privacy Peek tracked runtime permission invocations.
3. Collected logs were synchronized daily to a local analysis workstation using adb pull commands.
4. Data normalization scripts (Python) converted the raw logs into structured JSON entries for aggregation and comparison.

Data Schema

Each record in the dataset followed a normalized schema enabling cross-app comparison in a given time frame:

{
  "timestamp": "2025-09-22T14:37:04Z",
  "app_package": "com.spotify.music",
  "uid": 10123,
  "action": "WRITE",
  "file_path": "/storage/emulated/0/Android/data/com.spotify.music/files/logs/event.log",
  "permission_invoked": "android.permission.WRITE_EXTERNAL_STORAGE",
  "network_state": "WIFI"
}

Analysis Pipeline

Post-collection, the dataset was analyzed using a combination of shell scripts and Python utilities. The following analysis dimensions were applied:

• Permission–Behavior Correlation: Mapped declared permissions to actual file operations to identify unused or over-privileged permissions.
• Official vs. Modded Comparison: Compared the operational footprint of identical app pairs to detect excessive file access or hidden I/O operations.
• Network Context Correlation: Segregated activity under WIFI and MOBILE conditions to highlight data exfiltration risk patterns.

The processed results formed the empirical foundation for subsequent evaluation and visualization, where each app’s behavior could be examined through Privacy Peek’s UI or exported for further offline analysis.

While Privacy Peek successfully demonstrates deep system-level monitoring on Android, several limitations define the scope and applicability of this research.

Root Access Dependency

The entire framework depends on root privileges and Magisk integration to operate at the system level. This setup is not feasible for stock or unmodified devices, restricting real-world deployment to developers, security researchers, or advanced users with rooted environments.

Android Platform Specificity

The current implementation targets Android’s Linux-based kernel, specifically versions with fanotify support enabled. This limits portability to other mobile ecosystems such as iOS or HarmonyOS, which do not expose equivalent kernel hooks.

Kernel Configuration and Fanotify Granularity

Although fanotify provides effective visibility into file operations, its granularity is limited to file-descriptor level events. Operations involving direct I/O or memory-mapped file access may not trigger fanotify events, resulting in partial observability. Moreover, since fanotify is disabled in most stock kernels, a custom kernel build is required.

Dataset and Behavior Variability

The analysis is based on a dataset of 42 initial applications and two rooted devices. While this dataset is representative of both official and modded ecosystems, broader validation across larger and more diverse app sets is required to establish stronger statistical significance.

User-Level Usability

Due to its technical setup and requirement for permissive SELinux mode, the framework is not intended for regular end-users. Future iterations may integrate a read-only monitoring layer to enhance accessibility and usability.

The current version of Privacy Peek establishes a solid foundation for monitoring app permissions and file-access patterns. Several enhancements are planned to expand its analytical capabilities and automation potential.

AI-Based Anomaly Detection

A major goal is to integrate a lightweight on-device AI module capable of detecting anomalous app behaviors. Using log patterns and permission usage frequency, the AI could classify apps as normal, overprivileged, or potentially malicious without requiring manual inspection.

Network Traffic Correlation

Combining permission and file-access data with network monitoring (via tcpdump or libpcap) will enable end-to-end tracing of sensitive data flows. This could reveal whether certain modded apps perform background data exfiltration through covert channels.

Scalable Dataset Expansion

Future experiments will expand to a dataset of 500+ applications, maintaining a 50:50 ratio between official and modded variants. This scale will enhance statistical reliability and support category-wise risk scoring (e.g., games, finance, productivity, media).

User-Facing Visualization Tools

A web-based or mobile dashboard could provide interactive charts and per-app privacy insights, allowing users to compare permission footprints across categories. This will make Privacy Peek useful beyond the research environment.

Kernel Module Optimization

Optimization of the FaNoMonitor binary and fanotify hooks for newer kernel versions (5.x and above) is planned to reduce performance overhead and ensure compatibility with next-generation Android devices.

Privacy Peek presents a reproducible and transparent framework for analyzing Android applications’ permission usage and file-access behaviors under real-world, rooted device conditions. By bridging kernel-level fanotify monitoring with application-layer permission tracking, the system provides visibility that is otherwise inaccessible through conventional sandboxing or static analysis tools.

The comparative study between official and modded apps demonstrated that unauthorized modifications frequently introduce unnecessary permission requests and hidden file operations, posing potential privacy threats. These findings highlight the importance of user awareness and the necessity for stricter app store vetting mechanisms.

This research lays the groundwork for continued exploration of behavioral monitoring on mobile devices and forms the basis for a follow-up study: “Hidden Risks in Pirated App Ecosystems: A Comparative Analysis of Permissions, Storage Access, and Runtime Behavior.”

A. Example Log Snippet (Sanitized)

{
  "timestamp": "2025-09-28T14:45:23Z",
  "package": "com.example.modplayer",
  "operation": "WRITE",
  "path": "/storage/emulated/0/Android/data/.temp/cache123.tmp",
  "networkState": "WIFI_ON",
  "uid": 10342
}

B. Example CSV Schema

timestamp,package,operation,path,networkState,uid

C. Device Setup Commands

# Enable Magisk module mount
adb push magisk_privacypeek.zip /sdcard/
adb shell magisk --install-module /sdcard/magisk_privacypeek.zip

# Set SELinux to permissive mode
adb shell setenforce 0

# Run FaNoMonitor binary
adb shell su -c "/data/data/com.iamcod3x.privacypeek/files/FaNoMonitor &"

# Fetch generated log file
adb pull /data/data/com.iamcod3x.privacypeek/files/FaNoMonitor.log ./logs/

D. Notes on Data Sanitization

All recorded file paths and package names included in this publication have been sanitized to remove personally identifiable information (PII). The logs are shared solely for structural and methodological reference.

1. Android Developers. “App permissions best practices.” developer.android.com
2. Fanotify Main Page. man7.org
3. Rushikesh Kamewar, Privacy Dashboard