## 1 Introduction  
We have been witnessing a surge of malware on mobile devices in the past few years [1]. The malware intrudes into a victim's mobile device, stealing personally private or even mission-critical data, corrupting the local storage [2], or controlling the victim's entire device. In particular, there is one type of strong malware that is able to compromise the entire operating system of the device, obtaining the kernel privilege. This type of \"OS-level\" malware is extremely difficult to combat, since it can easily subvert any traditional anti-malware software or tools running in the user/kernel space [3, 4, 5, 6, 7, 8] by leveraging its high privilege. It would be challenging or even impossible to design a common defense strategy that can combat any OS-level malware as the malware today is highly heterogeneous. In this work, we focus on a special type of OS-level malware that always corrupts data stored in the victim mobile device, i.e., the _data corruption malware_. This type of malware includes ransomware that encrypts the user data, making it inaccessible to the user, or any computer virus, trojan horse, etc., which first steals the user data by retrieving it from the victim device and sending it to a remote server, and then deleting it from the device. The data corruption malware we consider here is assumed to be able to obtain the kernel privilege by compromising the OS. To combat the data corruption malware in the mobile devices, one strategy would be ensuring that the data being corrupted are always recoverable after the malware attack. To achieve this guarantee, our design contains two components: (1) a malware detection component (i.e., _malware detector_), which can detect the presence of data corruption malware timely, and (2) a data recovery component (i.e., _data repairer_), which can restore the external storage to a good historical state once the malware is detected and removed. The design rationale of each component is as follows:  
**Malware detector**. To enable malware detection, we can monitor the system activities in real-time, and once abnormal activities happen, the malware detection will make a decision and inform the user (e.g., via a manager at the user level) if it reaches a \"malware detected\" decision. It turns out that the malware detection cannot simply run in the normal execution environment of the device to avoid being compromised by the OS-level malware. In addition, the user-level manager, which interacts with both the end users and the malware detection, should not be compromised by the OS-level malware either. Therefore, a key idea for a secure malware detector design is to place both the malware detection and the manager in an execution environment that is isolated from the regular OS and, hence, the OS-level malware. Compared to traditional personal computers, mobile computing devices today are equipped with unique hardware features: (1) They usually use ARM processors that have reduced circuit complexity and low power consumption. ARM processors have an integrated _TrustZone_, which is a hardware security feature in any Cortex-A processor (built on the Armv7-A and Armv8-A architecture) and Cortex-M processor (built on the Armv8-M architecture). TrustZone enables the establishment of a trusted execution environment that is hardware separated from the normal insecure execution environment. (2) They typically use flash storage media instead of hard disk drives (HDD) for external storage. For example, smartphones, tablets, and IoT devices extensively use microSD, eMMC, or UFS cards. Different from HDDs, flash memory exhibits different physical nature and traditional file systems built for HDDs cannot directly be used on them. To bridge this gap, a new flash translation layer (_FTL_) is usually incorporated into the flash storage media to transparently handle the unique nature of flash, exposing an HDD-like interface externally.