AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly

In recent years, stealthy Android malware has increasingly adopted sophisticated techniques to bypass automatic detection mechanisms and harden manual analysis. Adversaries typically rely on obfuscation, anti-repacking, steganography, poisoning, and evasion techniques to AI-based tools, and in-memory execution to conceal malicious functionality. In this paper, we investigate WebAssembly (Wasm) as a novel technique for hiding malicious payloads and evading traditional static analysis and signature-matching mechanisms. While Wasm is typically employed to render specific gaming activities and interact with the native components in web browsers, we provide an in-depth analysis on the mechanisms Android may employ to include Wasm modules in its execution pipeline. Additionally, we provide Proofs-of-Concept to demonstrate a threat model in which an attacker embeds and executes malicious routines, effectively bypassing IoC detection by industrial state-of-the-art tools, like VirusTotal and MobSF.

💡 Research Summary

The paper “AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly” investigates the use of WebAssembly (Wasm) modules as a novel obfuscation vector for Android malware. The authors begin by outlining the growing sophistication of Android malware, which now employs a range of techniques such as code obfuscation, anti‑repacking, steganography, adversarial attacks against AI‑based detectors, and in‑memory execution. Traditional static and dynamic analysis tools focus on the DEX bytecode, native JNI libraries, permissions, and known signatures, leaving a blind spot for binary formats that are not part of the conventional Android toolchain.

The paper provides a thorough technical background on Android APK composition (Manifest, assets, DEX files, native libraries) and on the WebAssembly ecosystem (specifications, compilation toolchains like clang‑wasm, emscripten, and runtimes such as V8, SpiderMonkey, Wasmtime, Wasmer, WasmEdge, wasm3, and the Android‑specific WasmAndroid). It explains how Android’s WebView component embeds a lightweight Chromium engine, enabling HTML/JavaScript rendering inside a native app. Crucially, the authors describe the three‑way bridge: Java/Kotlin ↔ JavaScript ↔ Wasm. A WebView loads an HTML page that executes JavaScript; the JavaScript uses the WebAssembly JavaScript API (WebAssembly.instantiateStreaming) to fetch and instantiate a .wasm module; the module’s exported functions are then invoked from JavaScript, which can call back into the Android side via addJavascriptInterface or evaluateJavascript, or through JNI’s RegisterNatives mechanism. This chain allows a malicious payload to reside entirely inside the Wasm binary, invisible to tools that only inspect DEX or native .so files.

Two Proof‑of‑Concept (PoC) implementations are presented. PoC‑1 embeds a malicious routine (e.g., privilege escalation, SMS sending, encrypted C2 communication) inside a Wasm module. The module is loaded through a WebView‑JavaScript bridge, and the malicious logic is executed via exported Wasm functions called from JavaScript. All strings, API identifiers, and control flow are compiled into Wasm bytecode, so static analysis sees no suspicious literals. PoC‑2 demonstrates a more sophisticated scenario where the Wasm module contains its own encryption/decryption engine, dynamically generating network payloads and file system operations at runtime. Both PoCs were submitted to VirusTotal and MobSF; the services classified them as clean or benign, confirming that current commercial scanners lack Wasm‑aware detection capabilities.

The authors analyze why existing tools fail. Most Android malware scanners do not extract or disassemble .wasm files; they lack signatures for Wasm bytecode and do not monitor the WebView‑JavaScript‑Wasm interaction. Moreover, Wasm’s sandboxed memory model hides linear memory contents from conventional static analysis, while the JIT/AOT compilation performed by modern runtimes can obscure the original source code further.

To mitigate this emerging threat, the paper proposes a multi‑layered defense strategy: (1) Extend APK analysis pipelines to extract .wasm assets, convert them to the textual .wat representation using tools like wabt, and perform control‑flow and data‑flow analysis on linear memory and function tables. (2) Instrument WebView to log JavaScript‑Wasm bridge calls, flagging anomalous import/export patterns, excessive memory allocations, or calls to privileged Android APIs. (3) Integrate Wasm‑specific plugins into static analysis frameworks (e.g., MobSF) that generate feature vectors from Wasm metadata (function signatures, import counts, memory size) for machine‑learning classifiers. (4) Advocate for OS‑level policy enhancements that treat Wasm modules as first‑class security artifacts, enforcing a least‑privilege model and requiring explicit permission declarations for host imports.

The paper concludes that WebAssembly is rapidly becoming a first‑class component in Android hybrid applications (Flutter, Unity, React Native) and that its adoption opens a new attack surface for malware authors. Future work includes systematic collection of real‑world Android malware samples that use Wasm, vulnerability research on Wasm runtimes (e.g., CVE‑2023‑41880 in wasmtime), and development of robust, scalable Wasm‑aware detection mechanisms. By exposing the feasibility of Wasm‑based obfuscation and demonstrating concrete evasion of industry‑standard scanners, the study provides a critical foundation for the next generation of mobile malware defense research.