# VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics
## 2 Background
### Just-in-Time Memory Forensics (JIT-MF)
However, the format of the content inside the activity field differed from one forensic source to another, both across sources and in the case of app-specific logs and JIT-MF logs, and even across apps. Rather than parsing each log type individually for each app and forensic source, we used derived features, in the form of log entry amounts per feature grouped by a time window. _Feature 1_ represents the discrepancy in the log entry amount between that produced by all forensic sources (excluding JIT-MF logs) and the amount found in JIT-MF logs. _Feature 2_ represents the total amount of log entries collected from all sources of the events collector component. _Features 3_ represents the log entry amount collected from JIT-MF logs. _Features 4-9_ represent the log entry amounts collected from each distinct forensic source (excluding JIT-MF). While Table 1 shows that a typical collection involves retrieving multiple forensic sources, only five were populated during the case study (e.g., no connectivity data were reported). _Features 10-14_ represent the log entry amounts collected from JIT-MF logs with distinct SQL statements. Since the JIT-MF logs in these case studies were generated using an SQLite JIT-MF-based driver, log entries included SQL statements which process the message object (as shown in Listing 2). The SELECT, INSERT, REPLACE, UPDATE and DELETE SQL statements \begin{table}
\begin{tabular}{l l l} \hline \hline
**Method** & **Feature** & **Description** \\ \hline ARIMA\_PLUS & Feature 1 & Discrepancy between the amount of JIT-MF logs and other logs \\ \hline \multirow{6}{*}{K-Means, PCA, Autoencoder} & Feature 2 & Total amount of logs \\ \cline{2-3}  & Feature 3 & Amount of JIT-MF logs \\ \cline{2-3}  & Feature 4–9 & Amount of logs per forensic source \\ \cline{2-3}  & Feature 10 & Amount of JIT-MF logs related to Data Retrieval (SELECT) \\ \cline{2-3}  & Feature 11 & Amount of JIT-MF logs related to Data Insertion (INSERT) \\ \cline{2-3}  & Feature 12 & Amount of JIT-MF logs related to Data Replacement (REPLACE) \\ \cline{2-3}  & Feature 13 & Amount of JIT-MF logs related to Data Update (UPDATE) \\ \cline{2-3}  & Feature 14 & Amount of JIT-MF logs related to Data Deletion (DELETE) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: List of features used for anomaly detection model generation, as implemented in Algorithm 1. The time units used for each model generated are described in Table 6.

can be considered to reflect app functionality related to the processing of the message object. We considered the amount of logs containing a specific SQL statement a feature. The models in Table 6 were generated based on the features described. Two models were created for each combination of anomaly detection methods and features or feature sets (in the case of K-means, PCA, and Autoencoder). In the case of Google BigQuery's ARIMA_PLUS, log entries were automatically grouped in sixty-second time windows. For ARIMA_PLUS we used two different feature normalization properties (Standard Scaler and Min Max Scaler ([[https://cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-preprocessing-functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-preprocessing-functions)]([https://cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-preprocessing-functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-preprocessing-functions))), whereas for K-means, PCA, and Autoencoder we aggregated and counted events every thirty (30s) and sixty (60s) seconds. Each model in Table 6 was created for every targeted app in the case study. Anomalies were detected depending on the model used and the threshold set. ARIMA_PLUS is a univariate time-series model that uses a single feature to detect anomalous data points across historical data.