## 1 Introduction
Leveraging the unique hardware features of mobile devices, our design of the malware detector is: first, we integrate the malware detection into the FTL. Such a design is advantageous because: (1) the OS-level malware will not be able to subvert the malware detection located in the FTL, which is isolated by the flash storage hardware and remains transparent to the OS; and (2) the data corruption malware usually needs to perform I/Os on the external storage, and such I/Os may exhibit some unique behaviors that can be observed in the FTL as confirmed in our experiments using real-world malware samples. Second, to prevent the user-level manager from being subverted by the OS-level malware, we separate its functionality and move the critical component into the \"trusted execution environment\" (i.e., a secure world) established by TrustZone. In this way, the manager is secure and is able to work with the malware detection in the FTL correctly. In addition, to prevent the malware from noticing the communication between the malware detection (in the FTL) and the manager (in the TrustZone), we leverage steganography so that the manager and the malware detection can communicate stealthily via the regular I/Os performed on the external storage. **Data repairer. ** To enable restoration of external storage after malware attacks, a key question would be finding out those original data before the malware corrupts them. Our observation is that: the flash memory performs an out-of-place update [9], and therefore, any delete/overwrite operations issued by the malware will not immediately delete data from the underlying flash memory; instead, the data will just be invalidated and removed later by a garbage collector running in the FTL. This observation makes it possible to enable data recovery after malware attacks by extracting the invalidated data from the raw flash memory. However, the garbage collector will eventually reclaim the flash memory space, which stores the invalidated data, and once this happens, the original data deleted by the malware will be irrecoverable. To resolve this challenge, we take advantage of the designed malware detector. Specifically, we divide the time into epochs, and if the malware detector does not detect any malware by the end of an epoch, it will inform the garbage collector to reclaim the flash memory space that holds invalid data (i.e., the garbage collector will not reclaim the flash memory space until the end of each epoch and after being notified of no malware); if the malware detector detects any malware, the garbage collector will be frozen immediately, and the invalid data (which have not yet been deleted by the garbage collector) will be extracted from the flash memory to restore the external storage. The resulted system design, mobiDOM, is the first full-fledged defense for mobile devices that can combat the data corruption malware even if the malware can compromise the entire OS. Compared to our conference version [10], the major differences are: (1) We have incorporated a malware-aware garbage collector that only reclaims flash memory space occupied by the invalid data if the malware is not detected. On the contrary, reference [10] uses the original garbage collector incorporated with the FTL, which may delete the data invalidated by the malware and, hence, cannot ensure data recovery after malware detection. (2) We have proposed the first complete framework that can defend against the OS-level data corruption malware. The framework includes both a malware detection and a data repairer component. Especially, the data repairer component allows restoring the external storage back to a good historical state after detecting the malware. On the contrary, reference [10] only supports malware detection, lacking the capability of data restoration. (3) We have provided experimental results for the newly added component. **Contributions.