Mobile apps routinely collect and transmit personal data in ways that are difficult for users, developers, and regulators to verify. Permissions can reveal what an app can access, and privacy policies can claim what an app should do, yet neither reliably shows what data is actually collected and where it is sent during real use.
A new analysis framework called mopri aims to reduce that gap by combining static and dynamic analysis into a modular workflow that can produce report-ready results. The framework targets one of the most persistent problems in mobile privacy enforcement: confirming real-world data flows at scale without building custom tooling for every investigation.
Static analysis gives early signals, not proof
Many privacy reviews begin with static analysis of an Android app package (APK). This can reveal permissions requested by the app and identify embedded third-party libraries such as advertising SDKs, telemetry tools, or analytics components.
Requested permissions are often treated as indicators of risk because they can imply access to contacts, photos, location, camera, or device identifiers. Library detection can also show whether an app includes known trackers.
Yet, static results are only partial. Permissions may never be used in runtime code paths, and libraries can be present without being invoked. Static analysis also misses cases where data is accessed indirectly or through system behavior that does not require explicit permissions.
Mopri incorporates static analysis mainly to establish a baseline: what the app package contains, what access it requests, and what third-party code it ships with. In its prototype implementation, it extracts permissions and tracking libraries using tools from the Exodus Privacy Project, then enriches the results with descriptions from Android permission documentation and tracker metadata from the Exodus database.
Dynamic analysis is closer to ground truth
Dynamic analysis focuses on what the app does during execution, especially what it transmits over the network. For privacy investigations, outbound traffic is often the most actionable evidence, since it can show both the destination and the content being sent.
The challenge is that app traffic is commonly encrypted with TLS. Analysts often rely on man-in-the-middle (MITM) interception, where the app is tricked into accepting a custom root certificate so the proxy can decrypt and record HTTPS sessions.
Apps increasingly defend against MITM using certificate pinning, which causes the app to reject traffic interception even if a root certificate is installed. Analysts may respond by patching the APK or using dynamic instrumentation to bypass the pinning logic at runtime. Both approaches can fail depending on the app’s implementation.
Mopri’s design treats these obstacles as expected operating conditions. The framework includes multiple traffic capture approaches so investigators can switch methods when an app resists a specific setup.
A modular pipeline built around real app interaction
The core design goal of mopri is a pipeline that automates setup, recording, enrichment, and reporting without forcing the analyst to manually stitch together tools.
The prototype is implemented as a web application with a backend pipeline. Users start an analysis through a setup wizard that collects metadata, accepts an uploaded app package, and allows selection of static and dynamic modules. For dynamic analysis, the user chooses whether to run the app on a rooted physical Android device connected over USB or in an Android emulator.
During the dynamic phase, the app is launched and the user manually interacts with it. This is a deliberate choice. Manual interaction can trigger workflows that automated UI fuzzing may miss, and it reduces the risk of apps detecting automated behavior.
To support traceability, mopri records the screen during the analysis. In the interactive report, network requests are displayed alongside the recorded video so analysts can correlate visible app actions with traffic events.
Multiple traffic capture options to handle TLS and pinning
The mopri prototype includes four traffic recording configurations based on two main approaches.
The first uses a MITM proxy setup based on mitmproxy, routing app traffic through a VPN tunnel and optionally applying a certificate pinning bypass using Frida and published hooking scripts. The decrypted traffic is stored in HAR format, which is widely used for HTTP request analysis.
The second approach captures raw packets directly on the device using PCAPDroid, then attempts to extract TLS session keys using FriTap so encrypted traffic can be decrypted after collection. This method can still capture metadata even when decryption fails, and it can record recipients for non-HTTP protocols due to its packet-level visibility.
Tests referenced in the framework development showed that MITM decryption succeeded in some cases where TLS key extraction failed, reinforcing the need to support both options.
Enrichment focuses on attribution and sensitive payloads
Raw network logs are difficult to interpret without enrichment. Mopri adds contextual information to recorded traffic in two areas: identifying who received the data, and identifying what sensitive information may have been transmitted.
For attribution, recipient IP addresses and domains are enriched using IPWhois geolocation and hosting lookups. Domains are matched against DuckDuckGo’s Tracker Radar dataset to associate endpoints with known tracking entities. The system also checks domains against privacy blocklists commonly used in DNS filtering and ad blockers to provide an early classification signal.
For payload analysis, mopri attempts to decode common encoding formats such as URL encoding, JSON nesting, Base64, and gzip compression. It then applies pattern matching against known device attributes collected during the analysis session, such as the advertising ID and other device characteristics that are frequently transmitted.
The prototype also incorporates Tweasel’s adapter-based approach for decoding specific known tracker payload formats, allowing deeper extraction for a limited set of endpoints.
Remaining gaps include iOS and deeper non-HTTP inspection
The mopri prototype currently targets Android and supports APK and XAPK formats. Expanding to iOS remains an open challenge, especially for static analysis and emulation support.
Other gaps include deeper inspection of non-HTTP traffic, more advanced sensitive data detection beyond string matching, and workflows that allow analysts to provide user-entered data for correlation. The prototype also relies on rooted devices for some workflows, which limits use in many enterprise environments.
Even with those limitations, mopri reflects a broader move toward privacy tooling that treats mobile app auditing as an operational pipeline problem. Privacy enforcement often fails because technical verification is slow, inconsistent, and difficult to reproduce. A modular analysis framework that can adapt to new TLS behaviors, new SDKs, and changing mobile platforms could make app privacy investigations more routine and less dependent on custom setups.