## 4 mobiDOM Design
### Data Repairer  
The OS-level malware may corrupt data stored in the victims mobile device. For example, it can overwrite the local data with garbage data or simply delete them. However, the delete operation [15] in the system level usually only leads to the deletion of the corresponding metadata in the file system and the actual data are not deleted. Therefore, a reliable manner for the malware to corrupt data would be overwriting the data with something else. Towards data restoration after malware attacks, our key observation is that the mobile device usually uses flash storage, which follows a unique out-of-place update strategy; due to the out-of-place update, the original data corrupted by the malware would be temporarily preserved in the flash memory and could be extracted for data recovery after attacks. Especially, the FTL usually maintains a table keeping track of mappings between data stored in the flash memory and that viewed by the OS. For example, in Figure 5(a), for data \(D\), the FTL maintains a mapping \(p\) between its address in the OS and its address in the flash memory. After the malware corrupts data \(D\) by overwriting it with garbage data \(D^{\prime}\), the garbage data \(D^{\prime}\) will be stored in a new flash memory address due to the out-of-place update feature, and the FTL will change the mapping from \(p\) to \(p^{{}^{\prime}}\) (Figure 5(b)). Therefore, if we can restore the current mapping \(p^{{}^{\prime}}\) to the old mapping \(p\), the data \"corrupted\" by the malware can be restored. There are three issues that need to be addressed toward a robust data recovery after the malware attack: (1) After the malware corrupts data at the OS level, the data (e.g., \(D\)) stored at the flash blocks will be invalidated, and the garbage collection (GC) [16, 17] may reclaim those blocks, rendering the data irrecoverable. (2) The old mapping \(p\) may be deleted by the FTL before the data recovery is performed. (3) The user stays at the user level, and may not be able to control the data repairer upon data recovery. In the following, we will discuss our strategies to address each of the three issues. **Malware detection-aware garbage collection**. To prevent the GC from reclaiming those flash blocks that store the data invalidated by the malware, we utilize a malware detection-aware GC strategy (Figure 7). Especially, we divide the time into epochs, and the GC will be performed periodically at the end of each epoch; before the GC functions and reclaims flash blocks filled with invalid data, it will first check with the malware detector, and the flash blocks will be reclaimed only if there is no malware detected at this point (otherwise, the GC will be frozen until the data recovery is invoked and successfully conducted). Another issue is that when the malware starts to function, the malware detector may not be able to detect it instantly. Therefore, there is a potential detection delay. To compensate this delay, the GC on a flash block should be delayed accordingly. Fortunately, in our malware detection experiments (Section 6.1), the detector can detect the malware after around 30 I/Os, which indicates that the delay is very subtle. Figure 6: Mappings between the OS view and the flash memory view. Figure 7: Malware detection-aware garbage collection. **Ensuring recoverability of the old mappings**. As the flash storage performs the out-of-place update, an immediate strategy is to prevent the GC from reclaiming flash blocks storing invalid mappings so that after the malware attacks, the old mapping \(p\) can be extracted from the flash memory. This solution ensures the recoverability of old mappings, but localizing the old mappings corresponding to a certain historical version would be difficult. In addition, retaining all the historical mappings may incur a large storage overhead. Another strategy is to back up the most recent version of the mappings at the end of an epoch if the malware detector does not detect any malware (Figure 8).