# VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics
## 2 Background
### Just-in-Time Memory Forensics (JIT-MF)
While the makeup of each container is the same, different sensitive apps are hosted in different containers, to maintain the application sandbox protections that Android offers between apps out-of-the-box. Figure 4: Overview of the VEDRANDO architecture. In the following sections, we describe how JIT-MF drivers were used to allow for the timely collection of artefacts from memory (**R1**) that can contribute to the stealth attack steps of a benign app hijack, while ensuring extensibility (**R2**) by moving away from app-specific JIT-MF drivers that render the technique infeasible at a large scale. We also describe how our solution leverages app-level virtualization, to remove the need for app repackaging, yet still functions on stock Android devices (**R3**). Finally, we illustrate and describe the complete setup of the enhanced Android EDR, along with implementation considerations. #### 4.1.1 Infrastructure-Centric JIT-MF Drivers

We recall research in previous work [25] that laid the groundwork for the feasibility of JIT-MF driver development by addressing the limitation that requires JIT-MF drivers to be specific to the targeted app and attack scenario at hand. This limitation meant that JIT-MF driver development required app reverse-engineering, which rendered the development process of JIT-MF driver development impractical. The JIT-MF driver development process must be practical to ensure our solution is feasible (addressing **R2**). Infrastructure-centric JIT-MF drivers render the JIT-MF driver development process feasible by ensuring that a single JIT-MF driver can remain relevant across app versions and stay functional across different applications. The overarching idea of this type of JIT-MF driver calls for a modified driver development approach that leverages the common subset of the applications' codebase that interacts with commonly-used infrastructure, rather than a application-specific codebase, for _Trigger_points_ and _Evidence_objects_ selection. As shown in Figure 5, the underlying infrastructure is generally more stable and widespread across different applications and versions, allowing infrastructure-based JIT-MF drivers to remain usable across different applications and versions (unlike application-specific drivers, which need to be developed from scratch for every application and version). A crucial step for infrastructure-centric JIT-MF driver development involves identifying the key application events that may be hijacked and the commonly used, readily-available infrastructure that enables these events [25]. Figure 5: JIT-MF drivers leveraging application-specific codebase versus JIT-MF drivers leveraging common underlying infrastructure-interfacing code, which is expected to be more stable across versions (App A v1, v2) and applications (App A, B). Different color codes signify application-specific codebases, whereas the same-colored codebases reflect common APIs across applications and versions [25]. #### 4.1.2 Android App-Level Virtualization

We extended the VirtualApp framework [40] to develop an enhanced container that collects artefacts in a timely manner from the memory of plugin apps that run inside it. The new VirtualApp container contains an additional library, to serve as the JIT-MF driver runtime, implemented using Frida's Gadget shared library ([[https://frida.re/docs/gadget/](https://frida.re/docs/gadget/)]([https://frida.re/docs/gadget/](https://frida.re/docs/gadget/)) accessed on 30 June 2023), and JIT-MF drivers are implemented as Javascript code interpreted by that library. Sensitive stock Android apps that require monitoring and logging of artefacts from memory due to the potential for hijack are placed inside external storage and picked up by the VirtualApp container to be installed as plugin apps. The JIT-MF driver runtime is loaded when the plugin app starts, which enables the timely collection of artefacts from the plugin app memory (addressing **R1**) without requiring app repackaging, thus also addressing **R3**.