Hardware-Assisted Transparent Tracing and Debugging on ARM
Total Page：16
File Type：pdf, Size：1020Kb
IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 14, NO. 6, JUNE 2019 1595 Hardware-Assisted Transparent Tracing and Debugging on ARM Zhenyu Ning and Fengwei Zhang Abstract— The existing malware analysis platforms leave artifacts on instruction execution semantics that could be detectable fingerprints such as uncommon string properties in detected by malware [14]. QEMU, signatures in Android Java virtual machine, and artifacts To address this challenge, researchers study the mal- in Linux kernel profiles. Since these fingerprints provide the malware a chance to split its behavior depending on whether the ware on bare-metal devices via modifying the system analysis system is present or not, the existing analysis systems are software [2]–[4], [7] or leveraging OS APIs [8], [15] to not sufficient to analyze the sophisticated malware. In this paper, monitor the runtime behavior of malware. Although bare- we propose NINJA, a transparent malware analysis framework metal based approaches eliminate the detection of the emu- on the ARM platform with low artifacts. NINJA leverages a lator or hypervisor, the artifacts introduced by the analysis hardware-assisted isolated execution environment TrustZone to transparently trace and debug a target application with the help tool itself are still detectable by malware. Moreover, privileged of performance monitor unit and embedded trace macrocell. malware can even manipulate the analysis tool since they run These hardware features help NINJA to achieve transparency in the same environment. How to build a transparent mobile while avoiding heavy performance overhead. NINJA does not malware analysis system is still a challenging problem. modify system software and is OS-agnostic on the ARM platform. This transparency problem has been well studied in the We implement a prototype of NINJA (i.e., tracing and debugging subsystems), and the experimental results show that NINJA is traditional x86 architecture, and similar milestones have been efficient and transparent for malware analysis. An improved fast made from emulation-based analysis systems [16], [17] to system restoration mechanism is also designed to facilitate the hardware-assisted virtualization analysis systems [18]–[20], continuous malware analysis. and then to bare-metal analysis systems [21]–[24]. However, Index Terms— ARM, transparent, tracing and debugging. this problem still challenges the state-of-the-art malware analy- sis systems. We consider that an analysis system consists of an Environ- I. INTRODUCTION ment (e.g., operating system, emulator, hypervisor, or sand- ALWARE on the mobile platform exhibits an explosive box) and an Analyzer (e.g., instruction analyzer, API Mgrowth in recent years, and a variety of tools have tracer, or application debugger). The Environment provides the been proposed for malware detection and analysis [1]–[8]. Analyzer with the access to the states of the target malware, However, sophisticated malware, which is also known as and the Analyzer is responsible for the further analysis of evasive malware, is able to evade the analysis by collecting the states. Consider an analysis system that leverages the the artifacts of the execution environment or the analysis tool, emulator to record the system call sequence and sends the and refuses to perform any malicious behavior if an analysis sequence to a remote server for further analysis. In this system, system is detected. the Environment is the emulator, which provides access to the As most of the existing mobile malware analysis system call sequence, and both the system call recorder and systems [1], [5], [6] are based on emulation or virtu- the remote server belong to the Analyzer. Evasive malware can alization technology, a series of anti-emulation and anti- detect this analysis system via anti-emulation techniques and virtualization techniques [9]–[11] have been developed to evade the analysis. challenge them. These techniques show that the emula- To build a transparent analysis system, we propose three tion or virtualization can be detected by footprints like string requirements. Firstly, the Environment must be isolated. Oth- properties, the absence of particular hardware components, erwise, the Environment itself can be manipulated by the and performance slowdown. The hardware-assisted virtual- malware. Secondly, the Environment exists on an off-the- ization technique [12], [13] improves the transparency of the shelf (OTS) bare-metal platform without modifying the soft- virtualization-based systems; however, this approach leaves ware or hardware (e.g., emulation and virtualization are not). Manuscript received April 23, 2018; revised September 30, 2018; accepted Although studying the anti-emulation and anti-virtualization November 16, 2018. Date of publication November 22, 2018; date of current techniques [9]–[11], [14] helps us to build a more transpar- version March 7, 2019. This work was supported by the National Science ent system by fixing the imperfections of the Environment, Foundation under Grants OAC-1738929 and IIS-1724227. The associate editor coordinating the review of this manuscript and approving it for publication we consider perfect emulation or virtualization is impracti- was Prof. Chip-Hong Chang. (Corresponding author: Zhenyu Ning.) cal due to the complexity of the software. Instead, if the The authors are with the Computer and Systems Security Laboratory, Environment already exists in the OTS bare-metal platform, Department of Computer Science, Wayne State University, Detroit, MI 48202 USA (e-mail: [email protected]; [email protected]). malware cannot detect the analysis system by the presence of Digital Object Identifier 10.1109/TIFS.2018.2883027 the Environment. Finally, the Analyzer should not leave any 1556-6013 © 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. 1596 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 14, NO. 6, JUNE 2019 detectable footprints (e.g., files, memory, registers, or code) capable of studying kernel- or hypervisor-level malware. to the outside of the Environment.AnAnalyzer violating this The tracing subsystem exhibits a low performance over- requirement can be detected. head. Our evaluation results show that the instruction In light of the three requirements, we present NINJA,1 a tracing and system call tracing are immune to timing transparent malware analysis framework on ARM platform attacks. based on hardware features including TrustZone technology, This paper is an extended version of [28] published in Performance Monitoring Unit (PMU), and Embedded Trace USENIX Security 2017. Based on that work, we implement a Macrocell (ETM). We implement a prototype of NINJA that fast restoration mechanism to facilitate the continuous malware embodies a trace subsystem with different tracing granularities analysis. We also improve the functionality and usability of and a debug subsystem with a GDB-like debugging protocol the trace and debug subsystem. The main differences between on ARM Juno development board. Additionally, hardware- these two versions are summarized as follows: based traps and memory protection are leveraged to keep the • use of system registers transparent to the target application. We improve previous fast restoration mechanism with The experimental results show that our framework can trans- selective memory restoration, runtime file system switch- parently monitor and analyze the behavior of the malware ing, and complete context recovery. The selective memory restoration and runtime file system switching help to samples. Moreover, NINJA introduces reasonable overhead. We evaluate the performance of the trace subsystem with improve the performance of system restoration while the several popular benchmarks, and the result shows that the complete context recovery mitigates the incompleteness overheads of the instruction trace and system call trace are of previous restoration systems. • less than 1% and the Android API trace introduces 4 to 154 This paper introduces data address trace in the trace times slowdown. subsystem which allows analysts to learn the target In addition, as the malware sample may tamper the current memory address of memory read/write instructions. The system state, which can lead to an inaccurate analysis result of data address trace is helpful in many different use cases the next sample, a fast restoration mechanism is required for such as fast restoration (see Section V-E), dynamic taint continuous malware analysis. Previous restoration mechanisms analysis [29], and inferring encryption keys [30]. • either require a system reboot [24] or require special hard- The usability of trace subsystem is improved via introduc- ware components [22], [25]. We also implement a prototype ing address range and process ID filters. These filters help of an improved fast restoration mechanism which leverages analysts to focus on the interested processes and memory TrustZone and ETM data address trace to selectively restore addresses, and greatly reduce the noise in the trace result. memory and Network File System (NFS) to swap file system Moreover, we add six more stepping modes for step-by- for speeding up the restoration. The experiments show that our step debugging including speculative-execution-related fast restoration mechanism can restore the system in 0.029s to stepping that may help analyze recent Meltdown [31]