## 5 Analysis Techniques for WebAssembly
### Detecting Vulnerabilities in WebAssembly Binaries
#### 5.2.2 Dynamic Analysis  
**[PERSON] et al.** [PERSON] et al. [54] proposed a taint-tracking technique for detecting vulnerabilities in WebAssembly binaries. They developed a VM that runs in native JavaScript and implemented a taint tracking system that allows the user to monitor the flow of sensitive data through the execution of the WebAssembly binary. To this end, they allocate a tainted label for each allocable byte in the memory section and each variable on the stack. This method allows for taint tracking without modifying the structure of the WebAssembly binary. The authors found that the runtime overhead of this method scales mostly linearly, with an overhead of up to 100%.  
**TaintAssembly**. TaintAssembly [57] is another technique that uses taint-tracking to detect vulnerabilities in WebAssembly binaries. Unlike [PERSON] et al., who developed their own VM, TaintAssembly implemented taint-tracking by modifying the V8 JavaScript engine used in Google Chrome and Node.js [28]. TaintAssembly implements basic taint-tracking functionality for variables of type i32, i64, f32, f64, as well as tainting in linear memory and a probabilistic variant of taint. However, unlike [PERSON] et al.'s approach, the structure of the WebAssembly module must be modified before taint labels can be set for all variables. TaintAssembly was able to achieve a runtime overhead of only 5-12%, which is far less than [PERSON] et al.'s approach.  
**Wasabi**. Wasabi [59] is a general-purpose framework for dynamically analyzing WebAssembly binaries. To this end, Wasabi performs binary instrumentation. Specifically, it inserts calls to analyze functions written in JavaScript into the WebAssembly binary. Then, instruction counting, call graph extraction, memory access tracing, and taint analysis canbe performed at runtime. Wasabi also allows for selective instructions; that is, it only instruments instructions that are relevant for a particular analysis. The authors found the runtime overhead to vary between 2% and 163%, depending on the application and instructions being analyzed.  
**Fuzzm**. Fuzzm [60] is a binary-only fuzzer for WebAssembly that uses the popular AFL [70] framework. Native AFL compiles applications from source code and inserts code to track path coverage. However, since Fuzzm is a binary-only fuzzer, it does not have access to the source code. To provide coverage information for the AFL fuzzer, Fuzzm uses static binary instrumentation to insert code at all branches, generating AFL-compatible coverage information. The authors found that Fuzzm is effective and imposes a low runtime overhead. Additionally, its implementation is not tied to a specific runtime. Fuzzm also implements a canary-based protection mechanism to prevent memory corruption vulnerabilities.  
**WAFL**. WAFL [61] is also a binary-only fuzzer for WebAssembly. It uses the AFL++ [71] framework, a community-driven fork of AFL. To generate coverage for the AFL++ fuzzer, they implement a set of patches to the WAVM [72] runtime. The WAVM runtime uses Ahead-of-time (AOT) compilation, and WAFL also adds lightweight VM snapshots. This makes WAFL performant, in some cases, even outperforming the native AFL x86-64 harnesses compiled from source. However, WAFL is inherently tied to the WAVM runtime, which limits its potential use cases.