PaperlayerView exact revision on arXiv

Source-linked AI summary

Don't Trust the Super-App: A Case Study of Russia's Max

Richa Priyanka, Aaron Ortwein, Joel Reardon, Michael Specter, Piyush Kumar Sharma, Roya Ensafi

arXiv:2609.11814v1cs.CRcs.CY

TL;DR

Super-app security research has largely trusted the host, despite its privileged position and growing role in sensitive services. Using reverse engineering and instrumentation of MAX, this paper shows that super-apps can silently mediate mini-app interactions, and argues for OS-level constraints, transparency, and isolation.

  • Problem

    Prior work largely treats super-apps as trustworthy intermediaries, leaving the consequences of an adversarial host insufficiently examined.

  • Method

    The paper uses detailed instrumentation and reverse engineering of MAX to analyze a super-app host’s capabilities under a threat model involving malicious or coerced behavior.

  • Results

    MAX can silently act as a man-in-the-middle for mini-app interactions through screen capture, storage access, JavaScript injection, network mediation, and authentication control.

  • Takeaways & Limitations

    Because these capabilities follow from the super-app architecture, mobile operating systems and app stores should add constraints, transparency, auditability, and isolation.

  • Takeaways & Limitations

    The analysis assumes benign mini-apps and a victim who uses the super-app normally with at least one mini-app installed.

Abstract

from arXiv · show

Super-apps, an emerging mobile architecture, host third-party mini-apps inside a single app, allowing users to access diverse services. A decade of security research on the super-app ecosystem has all assumed super-apps to be a trusted intermediary. We argue this implicit trust is difficult to justify: China's WeChat is already shown to passively track its user's activity across mini-apps at extraordinary scale; Russia's MAX's parent company is reported to be deeply entangled with the state prosecution of online speech; and Iran's Bale was reported to be functioning in the world's longest internet shutdown due to its state-backed support. In this paper, we show how malicious super-apps have undeniable capabilities to silently undermine the security and privacy of mini-apps and users without leaving any trace. Using MAX as an example, we show how it can capture mini-app UI, read and write mini-app local storage, inject arbitrary JavaScript into a mini-app's runtime, mediate mini-app network traffic, and control authentication context in ways that can enable silent user impersonation. Sadly, these capabilities manifest themselves in any super-app because of the architectural privileges granted to them by design. We argue that mobile OS and app store interventions are urgently needed to close this architectural blind spot before it is further exploited.

1 Introduction

The paper challenges the assumption that super-apps are trusted intermediaries by analyzing how MAX can actively undermine mini-app security and user privacy. It argues these capabilities arise from super-app privileges by design and require mobile OS and app-store intervention.

  • 1 Introduction: Prior research largely treats super-apps as trusted OS-like intermediaries, leaving active host abuse insufficiently examined.The paper identifies this implicit trust as increasingly difficult to justify amid government pressure on digital platforms.
  • 1 Introduction: MAX is an urgent case because Russia has made it a state-backed gateway to essential services, while its parent company is tied to prosecution of online speech.The paper presents Russia’s trajectory as a potentially exportable blueprint for digital authoritarianism.
  • 1 Introduction: MAX can silently capture mini-app screens, access local storage, inject JavaScript, mediate network traffic, and control authentication context.These capabilities allow the host to act as a man-in-the-middle for mini-app interactions without user alerts.
  • 1 Introduction: The identified attacks do not require exploiting vulnerabilities: they follow from architectural privileges granted to super-apps and therefore generalize beyond MAX.Android treats the super-app and its mini-apps as one trust principal, without mechanisms to constrain or audit the host.
  • 1 Introduction: The paper recommends OS and app-store measures including network and background-execution controls, transparency, auditability, and architectural isolation.These measures aim to let mini-apps establish trust independently of the super-app.

2 Background

Super-apps combine native hosting, web-based mini-apps, and a JavaScript bridge to deliver many services through one application. This consolidation creates commercial and governmental leverage while giving the host extensive visibility and control over mini-app activity.

  • 2 Background: A super-app hosts third-party mini-apps inside one native application, providing shared runtime, permissions, distribution, and services.Mini-apps use web technologies and access device capabilities through host-mediated bridge APIs.
  • 2 Background: Super-app consolidation supports engagement and monetization while also concentrating communications, payments, and public services in a single platform.This concentration can make account blocking a form of partial social exclusion.
  • 2 Background: State-aligned super-apps have emerged across countries amid concerns about monitoring, data collection, and government access.The background discusses Rubika, Bale, Zalo, Paytm, and MAX as examples of this broader pattern.
  • 2 Background: Mini-apps lack independent OS identities, packages, and storage directories, operating within the host’s identity and sandbox.The host manages their fetching, caching, lifecycle, and access to resources such as camera, contacts, location, and storage.
  • 2 Background: The host’s JavaScript bridge mediates mini-app interactions with native device capabilities and can execute JavaScript inside the mini-app WebView.On Android, the host binds native methods into the WebView and can call evaluateJavascript().
  • 2 Background: Prior work has documented passive tracking and privacy over-collection but generally models the super-app as a flawed, trustworthy intermediary rather than an active adversary.This paper instead asks whether the host can actively mediate all mini-app interactions in real time.

3 Methodology

The study analyzes MAX as a potentially adversarial super-app by instrumenting its runtime, capturing communications and bridge activity, and testing interactions across many mini-apps. Its methodology combines regional-build comparison, Frida-based multi-layer capture, protocol decoding, event correlation, and structured storage for analysis.

  • 3 Methodology: The analysis combines MAX instrumentation, runtime execution, raw-data collection, processing, and systematic analysis into a unified pipeline.The pipeline spans Frida instrumentation, traffic tunneling, plaintext logging, binary RPC decoding, event stitching, and SQLite storage.
  • 3 Methodology: The study compares Russian and universal MAX APK builds, finding they are mostly similar except for their cryptographic layers.The Russian build required a Russian egress tunnel because location checks and backend restrictions blocked access from non-Russian IPs.
  • 3.2 Instrumentation: The capture script hooks MAX across TLS, JavaScript bridges, WebViews, sensitive APIs, and network activity to observe mini-app interactions across layers.For TLS, hooks capture plaintext before encryption or after decryption; bridge hooks enumerate JavaScript-callable methods and dispatch activity.
  • 3.3 App Execution & Data Collection: The study exercises 90 mini-apps across healthcare, government, banking, telecom, commerce, education, and tourism under shared device, account, build, and network conditions.Each session covers approximately 8–10 mini-apps to keep logs manageable while enabling repeated observation across service categories.
  • 3.4 Decoding and Correlation: The methodology reverse-engineers MAX’s custom binary RPC protocol, which uses a persistent TLS connection, a 10-byte header, and a MessagePack-encoded body.The Russian and universal builds use different endpoints and TLS stacks, requiring build-specific plaintext capture approaches.

4 Results

MAX’s architecture exposes mini-app interfaces, storage, code, and network activity to the host, enabling silent observation and manipulation of user interactions.

  • 4.1 Control Over Mini-app UI: MAX captured mini-app UI through the host-owned rendered surface, including transient credentials and other visual state.PixelCopy returned valid mini-app UI in 31 of 35 attempts, and captures included credentials entered mid-keystroke.
  • 4.1 Control Over Mini-app UI: Repeated UI capture could reveal masked passwords, typed searches, booking history, and authentication-provider selections without user or mini-app awareness.The authors did not observe MAX using these capture paths during normal use, but the architecture leaves the UI exposed by default.
  • 4.2 Access to Mini-app Local Storage: MAX can read and write mini-app local storage, while bridge-mediated values transit through the host in plaintext.All tested mini-apps used MAX’s bridge for persistence, making the host a plaintext storage broker; observed data included a 38-byte push token and authentication material.
  • 4.3 JavaScript Injection Into Mini-app: MAX injects JavaScript and events into mini-apps, controlling code and data through channels that mini-apps cannot independently authenticate.Injected events share the same response interface as genuine replies, while the channel carries identifiers, storage values, and authentication state.
  • 4.4 Interception of Mini-app Network Activity: MAX mediates mini-app network activity, observing, blocking, rewriting, or injecting requests and reconstructing detailed runtime behavior.The host receives destination URLs, errors, page timings, console logs, and downloaded file bytes, including authentication-related data.

5 Super-apps within Android’s Threat Model

Super-apps fall outside Android’s ordinary isolation and authorization assumptions because mini-apps share the host’s security context. Consequently, the super-app becomes an unverified trusted computing base with OS-like authority over mini-app execution and data.

  • The architecture lets the super-app screenshot mini-app content, access local storage, inject JavaScript, mediate traffic, and control authentication tokens for impersonation.
  • Android’s multi-party authorization model breaks down because users and the platform cannot independently approve or deny permissions requested by mini-apps.
  • Dynamic loading also defeats Android’s assumption that third-party code is packaged, signed, and reviewed before execution.
  • Mini-apps are not isolated as separate Android applications, so the super-app becomes their runtime, storage, network, and permission mediator.

6 Recommendations

The paper proposes defenses that move trust enforcement beyond the super-app. Its recommendations progress from user transparency and OS-auditable actions to per-mini-app isolation, secure channels, and code attestation.

  • Transparency: The OS should disclose mini-app capture and mediated contexts, while listing installed mini-apps and exposing revocable permissions.
  • Auditability: Tamper-resistant OS logs should record super-app access to mini-app content, storage, and traffic so misbehavior leaves attestable evidence.
  • Architectural redesign: Per-mini-app sandboxes should assign each mini-app a distinct security principal, storage partition, and process boundary.
  • Architectural redesign: OS-mediated secure channels and backend attestation should protect mini-app traffic and verify genuine, unmodified code with signed transparency-logged bundles.

7 Conclusion

A case study of MAX shows that super-apps can silently mediate all mini-app interactions with capabilities that Android does not constrain or audit. The paper therefore calls for mobile OS and app-store defenses rather than treating super-apps as ordinary apps.

  • MAX is architecturally capable of acting as a man-in-the-middle across mini-app interactions, although the study did not observe it actively exploiting these capabilities.
  • Because mini-apps share one Android principal, Android provides no built-in mechanisms to constrain or audit the super-app, leaving users and developers without meaningful defenses.
  • Near-term defenses should strengthen user control over internet access and background execution, while long-term measures should add transparency, tamper-resistant logs, and architectural isolation.

Ethics Considerations

The study addresses ethical risks through controlled testing designed to document MAX’s privacy and security risks without involving real users or probing censorship infrastructure. The researchers used test accounts, a Russian vantage point, and limited traffic.

  • The study follows the Menlo Report and community norms for measurement research while examining risks to MAX users and the broader ecosystem.
  • Researchers generated every interaction with test accounts on devices they controlled and proxied traffic through a Russian vantage point.
  • They avoided triggering Russian censorship systems, probing Russian infrastructure, or generating traffic volumes that could degrade availability.
  • The authors judged risks minimal because no real users were studied and no censorship infrastructure or harmful traffic volumes were involved.

Open Science

The authors release artifacts, instrumentation, capture logs, analysis tooling, and documentation supporting independent inspection of their results. The materials include sanitized data, reviewed UI-capture frames, observed runtime events, and a catalog of MAX mini-apps.

  • The released repository includes sanitized capture logs, collection instrumentation, decoding and analysis tooling, and documentation of artifact structure, requirements, and log formats.The artifacts are available through the authors’ open science repository.
  • A unified Frida script instruments TLS operations, the JavaScript bridge, WebView callbacks, and sensitive Android APIs across Russian and non-Russian MAX builds.The wrapper detects the build, selects the corresponding cryptographic hooks, and writes timestamped capture files.
  • The analysis tooling decodes binary RPC envelopes, correlates event triplets, reassembles connection streams, pairs bridge dispatches with injected responses, and records round-trip latencies.Unmatched injections are retained as host-initiated events.
  • Sanitized session logs provide source data for the reported capabilities across three capture sets and the mini-apps listed in Table 4.The logs can be independently re-parsed using the documented format.
  • The release includes manually reviewed UI-capture frames, a table of observed WebView callbacks and runtime events, and a catalog of observed MAX mini-app names and identifiers.The mini-app catalog preserves collected names, English names, and bot identifiers.
  • The corpus removes identifying account, device, session, authentication, network, and message content while preserving consistent keyed-hash placeholders for repeated values.This preserves analysis-relevant relationships without retaining recoverable underlying secrets.
Loading 2609.11814v1…