AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly

1. Problem Statement

Android malware increasingly employs sophisticated techniques to evade detection, including obfuscation, anti-repacking, steganography, and AI-evasion strategies. While traditional detection tools (static and dynamic) are effective against standard code transformations, they struggle with emerging binary formats that are not yet integrated into standard analysis pipelines.

The paper identifies WebAssembly (Wasm) as a significant, under-explored blind spot in Android security. Although Android ecosystems increasingly support Wasm via WebViews, hybrid frameworks (Flutter, React Native), and native libraries, most industrial malware detectors (e.g., VirusTotal, MobSF) do not inspect Wasm bytecode. Attackers can leverage Wasm to:

• Hide malicious payloads within a binary format that is opaque to standard static analysis.
• Bypass signature-based detection and behavioral heuristics.
• Execute complex logic (e.g., encryption, data exfiltration) without triggering standard Android API hooks used by dynamic analyzers.

2. Methodology

The authors conducted a feasibility study and threat modeling to demonstrate how Wasm can be embedded and executed within Android applications to conceal malicious functionality.

A. Execution Methodologies

The paper outlines and implements three distinct methods for executing Wasm modules inside an Android APK:

1. WebView-based Execution: The APK loads an HTML page containing JavaScript glue code that instantiates and runs the Wasm module via the embedded Chromium/V8 engine.
   • Pros: High compatibility, minimal integration effort.
   • Cons: High overhead due to the browser event loop and JS bridge; visible to users.
2. Standalone JavaScript Engine: The APK embeds a JS engine (e.g., androidx.JavaScriptEngine or V8) to compile and execute Wasm directly, bypassing the UI/HTML layer.
   • Pros: More controlled environment than WebViews; no UI overhead.
   • Cons: Requires bundling a heavy JS engine; still relies on an intermediate JS layer.
3. Native Runtime (WasmEdge): The APK embeds a native C++ library (specifically WasmEdge) and interacts with it via the Java Native Interface (JNI).
   • Pros: Highest performance, lowest overhead, fine-grained control over the host-guest interface, and no JavaScript dependency.
   • Cons: Requires native integration and careful configuration.

B. Proof-of-Concept (PoC) Development

The authors developed two PoC malware samples to validate the threat model:

1. Ransomware: A sample where the core encryption logic (AES) is compiled into a Wasm module. The Android app acts merely as a loader, delegating the encryption routine entirely to the Wasm binary.
2. Spyware: A sample where the Wasm module hides the malicious payload (specifically the exfiltration URL) but relies on the host Android environment for system calls (e.g., reading files, network requests) via imported functions.

C. Evaluation

The PoCs were compared against:

• Original Malware: Unobfuscated versions.
• Obfuscated Baselines: Samples processed with Obfuscapk (using Class Renaming, Reflection, and String Encryption).
• Detection Tools: Submissions to VirusTotal (VT) and MobSF to measure detection rates and the ability to identify Indicators of Compromise (IoCs).

3. Key Contributions

1. Feasibility Demonstration: Proved that Android applications can seamlessly embed and execute Wasm modules using WebViews, JS engines, or native runtimes like WasmEdge.
2. Threat Model Proposal: Defined a new attack vector where malicious logic is entirely encapsulated within Wasm binaries, rendering traditional static analysis (which focuses on DEX bytecode and strings) ineffective.
3. Empirical Evidence of Evasion: Demonstrated that state-of-the-art industrial tools fail to detect Wasm-based malware, even when the underlying logic is identical to known malware families.
4. Defensive Guidelines: Proposed a detection pipeline for security researchers, including:
   • Scanning for .wasm files and native libraries (e.g., libwasmedge.so).
   • Detecting Wasm signatures (00 61 73 6D) within byte arrays in Java/Kotlin code.
   • Analyzing JNI interactions and dynamic execution hooks (e.g., via Frida).

4. Results

The empirical study yielded significant results regarding detection evasion:

• Ransomware Case:

  • Original Sample: Detected by 27/66 AV engines on VirusTotal.
  • Wasm-Based Sample: Detected by only 7/66 engines.
  • Analysis: The malicious encryption routine was completely absent from the DEX bytecode, residing solely in the Wasm binary. Standard static analyzers missed the logic entirely.
  • Comparison: Obfuscated baselines (using Obfuscapk) were detected by an average of 14 engines, proving Wasm is a more effective obfuscation technique than standard code mangling.

• Spyware Case:

  • Original Sample: Detected by 1 engine (as a PUA) but flagged for the malicious URL (IoC).
  • Wasm-Based Sample: Detected by only 1 engine (as a PUA). The specific malicious URL was not detected because it was hidden inside the Wasm linear memory.
  • MobSF Analysis: While MobSF could detect general behavioral patterns (file reading, network connection) in the spyware, it failed to identify the specific exfiltration URL when hidden in Wasm.

5. Significance and Implications

• Blind Spot in Security: The study highlights a critical gap in mobile security. As Wasm adoption grows in legitimate apps (gaming, cross-platform frameworks), malware authors can weaponize this format to bypass the "signature-matching" and "static analysis" pillars of current mobile defense.
• Limitations of Current Tools: Tools like VirusTotal and MobSF rely heavily on analyzing DEX files and known API call patterns. They lack the capability to decompile and analyze Wasm binaries or trace the data flow between the Android host and the Wasm guest effectively.
• Future Directions: The authors emphasize the need for:
  • Automated pipelines to decompile and analyze Wasm within APKs.
  • Dynamic analysis techniques that hook Wasm runtime APIs (e.g., WasmEdge, V8) to monitor execution.
  • Research into Wasm-specific vulnerabilities within the Android context (e.g., sandbox escapes, memory corruption).

In conclusion, AndroWasm serves as a wake-up call for the mobile security community, demonstrating that WebAssembly is not just a performance tool but a potent vector for stealthy malware that current industrial defenses are ill-equipped to handle.