Smart mobile devices are becoming the main vessel of personal privacy information. While they carry valuable information, data erasure is somehow much more vulnerable than was predicted. The security mechanisms provided by the Android system are not flexible enough to thoroughly delete sensitive data. In addition to the weakness among several provided data-erasing and file-deleting mechanisms, we also target the Android OS design flaws in data erasure, and unveil that the design of the Android OS contradicts some secure data-erasure demands. We present the data-erasure flaws in three typical scenarios on mainstream Android devices, such as the data clearing flaw , application uninstallation flaw , and factory reset flaw . Some of these flaws are inherited data-deleting security issues from the Linux kernel, and some are new vulnerabilities in the Android system. Those scenarios reveal the data leak points in Android systems. Moreover, we reveal that the data remanence on the disk is rarely affected by the user’s daily operation, such as file deletion and app installation and uninstallation, by a real-world data deletion latency experiment. After one volunteer used the Android phone for 2 months, the data remanence amount was still considerable. Then, we proposed DataRaider for file recovering from disk fragments. It adopts a file-carving technique and is implemented as an automated sensitive information recovering framework. DataRaider is able to extract private data in a raw disk image without any file system information, and the recovery rate is considerably high in the four test Android phones. We propose some mitigation for data remanence issues, and give the users some suggestions on data protection in Android systems.

Since vulnerabilities in Linux kernel are on the increase, attackers have turned their interests into related exploitation techniques. However, compared with numerous researches on exploiting use-after-free vulnerabilities in the user applications, few efforts studied how to exploit use-after-free vulnerabilities in Linux kernel due to the difficulties that mainly come from the uncertainty of the kernel memory layout. Without specific information leakage, attackers could only conduct a blind memory overwriting strategy trying to corrupt the critical part of the kernel, for which the success rate is negligible.

A huge number of Android applications are bundled with relatively independent modules either during the development or by intentionally repackaging. Undesirable behaviors such as stealthily acquiring and distributing user's private information are frequently discovered in some bundled third-party modules, i.e., advertising libraries or malicious code (we call the module tumor payload in this work), which sabotage the integrity of the original app and lie as a threat to both the security of mobile system and the user's privacy.

To protect Android app from malicious reproduction or tampering, code obfuscation techniques are introduced to increase the difficulty of reverse engineering and program understanding. Current obfuscation schemes focus more on the protection of the meta information over the executable code which contains valuable or patented algorithms. Therefore, a more sophisticated obfuscator is needed to improve the protection on the executable code. In this paper we propose SMOG, a comprehensive executable code obfuscation system to protect Android app. SMOG is composed of two parts, an obfuscation engine and an execution environment. The obfuscation engine is at software vendor's side to conduct the obfuscation on the app's executable code, and then release the obfuscated app to the end-user along with an execution token. The execution environment is setup by integrating the received execution token, which endows the Android Dalvik VM the capability to execute the obfuscated app. SMOG is an easily deployed system which proves fine-grained level protection. The obfuscated app generated by SMOG could resist static and dynamic reverse engineering. Moreover, the benchmark result shows SMOG only costs about 5% more performance in dispatching the incoming bytecode to the proper interpreter.