# VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics
## 2 Background
### Just-in-Time Memory Forensics (JIT-MF)  
JIT-MF [21,23,24] is an experimental technique conceived to be adopted by incident response tools for stock smartphones without breaking any security controls. Rather, given that its primary purpose is to aid device owners in recovering stealth attack steps, it assumes the device owner's collaboration. It tackles the problem of missing evidence in application logs by enabling the enhancement of Android apps with app-specific logging through JIT-MF Drivers that dump evidence from memory, using app instrumentation, to avoid device rooting. These drivers are installed within third-party applications to log additional data from the memory to storage as part of the forensic readiness stage of incident response, without changing the application code beyond hooking. While JIT-MF drivers drive the process of an active collection of app artefacts from memory, as shown in Figure 1, the JIT-MF driver runtime provides any services required by the JIT-MF driver to operate; that is, the ability to register triggers, allow access and retrieval of artefacts from process memory, and move generated output to storage. JIT-MF Drivers have two main properties: _Evidence_objects_ are identified as those application-specific objects whose presence in memory implies the execution of some specific app functionality, possibly a delegated attack step. _Trigger_points_ define which application instructions indicate that _Evidence_objects_ are in memory, and hence when memory dumps should be triggered. Therefore, trigger points are crucial for the timely dumping of evidence objects in memory that could aid in reconstructing stealthy attack steps. Previous works [21,23,24] extensively explored the reliability of JIT-MF from different aspects, including: (i) comparing _trigger_point_ placement in different layers of the Android technology stack; (ii) using different sampling strategies for app stability; and (iii) identifying different methods to for developing a JIT-MF Driver. Figure 1: JIT-MF Concept. JIT-MF Logs  
_Evidence_objects_ in memory retrieved on the invocation of _Trigger_points_ are stored in *.jitmflog files. Taking the case of a stealth messaging hijack attack as an example, attackers aim to send messages through a victim's benign messaging app and immediately delete them, to ensure that the victim remains unaware of the malicious attack step. Benign messaging apps can be enhanced with a JIT-MF driver whose _evidence_object_ is defined as the application-specific _MessageObject_ containing details of the message sent, and the _trigger_point_ can be defined as any operation handling the _MessageObject_. A sample of the resulting *.jitmflog file, is shown in Listing 1, whereby each entry consists of a timestamp of the entry, the event type, and the metadata derived from the evidence object (in this case _MessageObject_) as dumped from the memory at a particular trigger point. The application-specific _MessageObject_ contains the properties that populate a log entry with the necessary information regarding an event. However, identifying this object in the first place is challenging, since (i) application developers may change the properties of this object or even the object name itself when newer versions of the application are released, and (ii) different messaging applications use different _MessageObject_s with different properties. The app-specific nature of JIT-MF drivers makes their development tedious. They require prior app-specific knowledge, typically gained through code comprehension in the case of open-source apps and app reverse engineering when dealing with closed-source apps. Both options are infeasible considering the growing number of apps in Android app play stores. Furthermore, while foregoing the requirement of device rooting, app repackaging does not comply with enterprise standards for use of stock Android apps. ```
1(\"time\",\"time



The proxy layer heavily relies on hooking mechanisms to communicate between Android system services and plugin apps.