Riot vs. Virtual Machine
I bring to your attention the translation of the article Rage Against the Virtual Machine .
Anti-virus companies, mobile application stores and security researchers use techniques based on dynamic code analysis to detect and analyze mobile malicious applications. This article presents a wide range of counter-analysis techniques that can be used by malicious applications to bypass dynamic analysis in emulated Android platform environments.
The detection heuristics presented in this article cover three different categories based on (i) static properties, (ii) dynamic information from sensors, and (iii) the intricacies of the Android emulator on virtual machines. To assess the effectiveness of the presented methods, they were included in samples of real malicious applications and sent to publicly available dynamic analysis systems, after which alarming results were obtained. It was found that all the tools and services are vulnerable to most of our techniques evading analysis. Even trivial techniques, such as checking the IMEI value, are sufficient to bypass some of the existing dynamic analysis environments. Possible countermeasures have also been proposed to improve the sustainability of current dynamic analysis tools against attempts to evade analysis.
The popularity of the Android OS, combined with the openness of this platform, made it an attractive target for attackers [13]. Antivirus vendors and researchers have responded to this growing security concern with services and tools for analyzing malicious applications. Google also created Bouncer [1], a service for automatically scanning and checking malicious applications. Scanning of an application to detect its potentially hidden malicious actions can be based on static [22, 25] and dynamic analysis [14, 17, 19, 28]. Unfortunately, both static and dynamic approaches can be circumvented. With regard to static analysis, researchers have demonstrated a series of techniques that can bypass the current available static analysis tools [30]. As will be shown in this paper, dynamic analysis using emulation to study malicious Android applications is also not perfect. A malicious program can infer whether it is running in an emulated environment, and therefore avoid detection by suspending all malicious activity.
')
In more detail, this article discusses how Android applications can infer that they are running on an emulated ARM processor or on a real device. First, a systematization of possible ways is created to determine the features of the runtime environment using heuristics sets. The heuristics presented in this article cover a wide range of complexity. Most of them are simple and can be prevented by simple changes in the emulated heuristics fraud environment, such as realistic values for static properties, such as the device serial number (IMEI). Others are more reliable because the emulated environment must provide realistic data from mobile sensors, such as an accelerometer. Ultimately, a set of heuristics is presented here, to counteract which requires a number of significant changes in the design of the emulated environment.
To assess the importance of the conclusions made in this article, a set of relevant images of malicious applications was repackaged. Developed heuristics were added to these images and sent to online analysis tools. Oddly enough, all of the tested analysis tools can be circumvented using some of the presented heuristics. Not a single malware analysis service was found that could cope with all of the heuristics tested. In addition, at least 5 of the 12 analysis tools we tested can be circumvented using simple heuristics such as checking the IMEI value. More sophisticated heuristics based on the intricacies of virtual machines could bypass all the tested services except 4. These 4 services do not support the execution of machine code, and thus cannot be used to run our subset of Android applications. Finally, all tested services are vulnerable to heuristics based on information from sensors (sensors).
It is worth noting that existing methods of analyzing malicious applications are easily circumvented by demonstrating the fact that current malicious applications can hide malicious functionality from publicly available services for analyzing malicious applications. A set of countermeasures was proposed in order to make the analysis of Android applications in an emulated environment more resilient to attempts to bypass it.
The counter-analysis techniques that can be used in Android applications to circumvent detection can be divided into three categories: (a) static heuristics based on static information, which always initializes fixed values in emulated environments, (b) dynamic heuristics based on observing the unrealistic behavior of various sensors, and (c) Geurvisor's heuristics, based on incomplete emulation of real equipment. Table 1 provides a brief description of all categories, along with some typical examples.
Table 1. A brief description of the main types of heuristics detection of virtual machines that can be used by mobile malicious applications, along with typical examples
The static set includes heuristics that can be used to detect the emulated environment using presence checks or contained values in unique device identifiers, such as the serial number (device ID), current build version, values in the routing table.
Serial number of the device (device ID). Each smartphone contains an IMEI (International Identifier of Mobile Station Equipment), which is a unique number identifying it in GSM networks. IMEI has already been used by malicious applications in order to prevent analysis using malware detection tools running in emulators [2]. The other mobile identifier is the IMSI (International Mobile Subscriber Identity), which is associated with the SIM card found in the phone. Simple evasion heuristics are based on checking these identifiers, for example, is IMEI equal to null, which is true for the default Android emulator configuration. For reference to this type of heuristics, the abbreviation idH will be used.
Build number. Another way to identify the emulated environment is to check the information associated with the current assembly, extracted from the properties of the system. For example, the Android SDK provides a public Build class that provides information about fields such as PRODUCT, MODEL, and HARDWARE, which can be viewed in order to find out that the application is running in the emulator. For example, the standard Android image in the emulator has the PRODUCT and MODEL field values of google_sdk, and the HARDWARE field value of goldfish. Several heuristics were identified based on such checks, which will be referred to later using the abbreviation buildH .
Routing table Emulated Android devices run by default behind a virtual router with an address space of 10.0.0.2/24, isolated from the network of the target machine. The emulated network interface is configured with an IP address 10.0.2.15. The default gateway and DNS server configurations also contain fixed values. In this paper, network parameters are used as another of the detection heuristics. In particular, the heuristics checks for listening to sockets and establishing a connection (via / proc / net / tcp), and trying to find the port number associated with the addresses 10.0.2.15 and 0.0.0.0. As an indicator of the emulated environment. The reference to this heuristic is abbreviated as netH .
Mobile phones are equipped with various sensors, such as an accelerometer, gyroscope, GPS, gravity sensor, etc. In fact, the output values of these sensors are based on information collected from the environment, and, therefore, realistic emulation is a difficult task. The existence of sensors is the main difference between smartphones and traditional computing systems. The increasing number of sensors on smartphones provides new opportunities for identifying actual mobile devices, and, therefore, identifying differences and finding emulators. For example, there are studies focused on the distinctive features of smartphones based on the flaws and imperfections of sensors [3, 20]. These approaches, based on distinctive features, can be used to detect emulated media.
By default, the Android emulator does not support emulation of device movements in space; This can be achieved through additional sensor simulators [4]. The current Android emulator builds also support the simulation of other types of sensors only partially or not at all. When testing available simulated sensors, it was found that the emulator generates the same values at equal time intervals of 0.8 seconds on average with a slight standard deviation (0.003043 seconds). The distribution function of time intervals between accelerometer events, observed when the Android emulator is running for two minutes, is shown in Figure 1. It was found that this function for the other sensors follows the same pattern. Sensor-based heuristics were implemented using the SensorManager class [5] of the Android API. An Android Activity (application screen) was developed that attempts to register a sensor listener to track its output values using the following approach.
First, the sensor listener is registered. If registration fails, then most likely the execution occurs in an emulated environment (except for the case when the actual device does not support a specific sensor). Otherwise, if the sensor registration was successful, the values of the onSensorChanged callback method are checked, which is called when the sensor values change. If the values of the sensors or the observed time intervals do not change with successive calls to this method, then the application is considered to be running in an emulated environment and the registration of the sensor listener is canceled. Heuristics based on sensors for accelerometer ( accelH ), magnetic field ( magnFH ), rotation ( rotVecH ), approximation ( proximH ) and gyroscope ( gyrosH ) were implemented .
Figure 1. The FRV intervals between accelerometer events observed in a running Android emulator for a few minutes
Switching definitions context QEMU. This heuristic is related to the context switching mechanism in QEMU [26] and the fact that QEMU does not update the value of the virtual command counter (virtual PC) during the execution of each instruction due to performance reasons. Since translated instructions are executed on the target machine, additional instruction is needed to increase the virtual command counter , so it is sufficient and quick to update the virtual command counter only when an instruction that violates linear execution, such as a jump instruction, is executed. This means that if a context switch occurs during the execution of the base unit, it will be impossible to calculate the value of the virtual program counter. Because of this, context switching in the QEMU environment occurs only after the execution of the base unit, and never during its execution.
The proof of this concept has already developed a detection technique QEMU BT , based on the histogram of address flow planning [26]. In non-emulated environments, a wide range of time intervals can be observed when a context switch occurs, because switching can occur at any time, whereas in an emulated environment, a context switch always takes place at a certain time, first of the base unit, since context switching can occur only when complete base unit is complete. This technique was implemented and used in the experiments as another heuristics with the abbreviation BTdetectH . In fig. Figure 2 shows the differences in the context switching time when this heuristic is executed in the Android emulator and on the real device.
Figure 2. To optimize, QEMU does not update the value of the virtual command counter after each instruction is executed, so many of the context switching events that may have occurred are not observed in the emulated environment.
Defining a QEMU by executing self-modifying code. As a second heuristic, a new QEMU detection technique (called xFlowH ) was implemented, based on the fact that QEMU does not track the modification of code pages. The technique is based on the differences in execution threads arising from the execution of the self-modifying code in the emulator and on the real device.
ARM processors contain two different caches, one for accessing instructions (I-Cache) and one for accessing data (D-cache). Harvard architectures (such as ARM) do not provide coherence between data caches and instructions. Therefore, the processor can execute the old (possibly invalid) section of the code after the new one has already been recorded in the main memory. This situation can be resolved by maintaining consistency between these two caches, which can be achieved using two operations: 1) cleaning the main memory, so that the new code in the data cache is mixed into the main memory 2) invalidation of the instruction cache, so that it can now be filled with new data from main memory. In native Android code, this can be done by calling the cacheflush function, which performs the above operations through a system call.
An example of self-modifying (machine) code was implemented, which uses a memory segment with rights to execute and write, which is overwritten several times in a loop with the contents of two different functions f1 and f2, respectively. After each change of the code, the code of this segment is launched, which in turn starts either f1 or f2 . These are two simple functions that both add their name to the end of the global variable string, so that we can conclude about the sequence of function calls. To achieve an alternating sequence of calls, you need to synchronize the caches using the cacheflush call, as described earlier.
This code, together with additional calls for synchronization after each change, was launched on the mobile device and on the emulator with the same results - each launch produced a sequential launch of functions, as defined in the loop. Then, the same experiment was performed, but this time the cacheflash call was excluded . As expected, a random sequence of calls was observed on the mobile device after each launch. Since the caches are not synchronized before each call, the instruction cache may contain outdated instructions, since it was clearly not recognized as invalid (invalid). Interestingly, it was found that this behavior is not observed in the emulator. Instead, the sequence of calls was exactly the same as in the first case, when the caches were matched before each function call. This behavior is expected, since QEMU discards the translated base unit for the previous version of the code, and forwards the new generated code as it tracks changes in the code pages and ensures that the generated code always matches the target instructions in memory [16].
The heuristics described in Section 2 were implemented using the Android SDK. For BTDetecH and xFlowH, Java Native Interface (JNI) was used to run machine code that implements the functionality of each heuristic. A simple Android application (test application) was developed, which performs the proposed heuristics in the background and for each of them collects information about its effectiveness. The collected information is sent to the HTTP server for storage in a local database. In addition, the developed heuristics were included in the set of known malicious Android applications. To do this, we used Smali / Backsmali [7] along with Aptktool [8], which we used to disassemble and reassemble (repacking applications). The inclusion of heuristics in malware was done by inserting Smali Dalvik bytecode generated using a disassembler for each heuristic that was previously extracted from the developed test applications. Each malicious application was modified to contain one of the implemented heuristics, as indicated in Table 2.
First, each original sample was launched in the emulator and on a real device, and its behavior was observed with the help of the logcat command (Android logging system) when launching the main Activiti (application screens), as well as services. Subsequently, changes were made to these components of the application by one of the developed heuristics, which, depending on the results of the heuristics, decided to stop the execution of the component or not.
Table 2. Samples of malicious applications used in the study
The repackaged applications were tested in the simulator and on real devices in order to make sure that malicious behavior occurs only on a real device. It is worth noting that in addition to the above changes in the resulting code of malicious applications, no other additional changes are required in any other parts of the APK files, except for the following cases. The idH heuristic requires the permission READ_PHONE_STATE explicitly declared in the Android manifest file in order to be able to read the status of the phone. For the heuristics BTDetectH and xFlowH, you must create the lib directory in the application root directory containing the required machine code as shared libraries.
This section presents the results of our assessment of the effectiveness of heuristics presented in section 2. Each heuristics was added to a real malicious application and analyzed using various services and dynamic analysis tools. For each case, there was a record of information about which heuristics managed to detect the emulator and which did not. First, the set of malicious programs and dynamic analysis services used in the work is described, followed by a brief overview of our methodology, and at the end, the findings are presented and discussed.
Samples of malicious applications. The detection technique code, using the process described in section 3, has been added to several widely known malicious Android applications. Were used 10 samples from different families of malicious applications with different capabilities, including privilege escalation exploits, confidential information leaks, SMS trojans, and so on. All tested samples are publicly available and are part of the Contagio Minidump [9]. Table 2 summarizes the patterns of malicious applications used along with the heuristics used in each case.
Services dynamic analysis. The services and tools of dynamic analysis used in the assessment are shown in Table 3. Both standalone analysis tools available for download and local use were used, as well as online services that analyze submitted samples online.
Three popular tools for analyzing Android applications were used: DroidBox [10], DroidScope [35], and TaintDroid [21]. All three tools execute an Android application in a virtual environment and produce analysis reports. DroidBox provides information on incoming / outgoing traffic, read / write operations, called services, application permissions bypasses, SMS sent, phone calls made, etc. DroidScope performs profiling of Android applications at the level of OS calls and APIs, and gives an idea of information leaks. TaintDroid is able to efficiently perform system-wide tracking of the flow of data from multiple sources of sensitive data.
Table 3. Tools and services for analyzing malicious Android applications used in our assessment
In addition to stand-alone tools, publicly available online services were also used that can perform dynamic analysis of Android applications, briefly described below. Andrudis [14] performs both static and dynamic analysis of unwanted Android applications. SandDroid analyzes the permissions / components of the application, as well as the detection / classification of its malicious actions. ApkScan provides information including file access, network connections, phone calls, SMS sent, information leaks, and cryptographic activity. VisualThreat provides information covering a wide range of activities, ranging from network activity and data leakage, and ending with the detection of malicious application families with correlated API calls. TraceDroid emulates some actions when analyzing an application, such as user interaction, incoming calls, SMS messages that can detect malicious intentions. CopperDroid [31] is based on QEMU and out of the box can perform dynamic analysis of Android applications (both at the OS level and API). APK Analyzer, ForeSafe and Mobile Sandbox [33] are also dynamic analysis services that investigate mobile malicious applications, following the approaches mentioned in the above mentioned tools.
To assess the effectiveness of the presented heuristics, two different approaches were used. In the first approach, we sent a copy of the application containing all the heuristics described in section 3 to each online service from our set. During the analysis, the application checks the performance of the heuristics, applying them sequentially to determine whether execution is performed in an emulated environment or not. For each checked heuristic, the application sends the result to an HTTP server. After that, you can determine which of the heuristics were effective in identifying a virtualized environment, and which were not.
In order to perform a more realistic analysis and demonstrate how such heuristics can complicate the work of various dynamic analysis tools and not allow them to draw wrong conclusions, consider a different approach. To do this, the existing malicious applications are modified in such a way that they include one heuristic described in section 3 and sent both the original sample and the repackaged into each service. Then, generated reports are collected and compared to find differences in the observed behaviors.
Table 4. The stability of dynamic analysis tools against evasion techniques from virtual machines. “✓” indicates resistance to them, “✗” indicates vulnerability to them, and “JNI NS” indicates a lack of support for JNI (calling machine functions from Java applications)
The results of the effectiveness evaluation are shown in Table 4. The first three lines refer to the offline analysis tools, and the rest to the online analysis services. The following describes the main conclusions based on the collected results.
Conclusion 1. All the studied tools and dynamic analysis services are vulnerable to 5 or more heuristics. As you can see in Table 4, all tested tools can be easily circumvented using only one of the suggested heuristics. In particular, only 6 out of 12 tools are resistant to idH simple static heuristics, which checks the IMEI value of the device. Also, only one analysis service was found, Apk Analyzer, resistant to all presented static heuristics. In addition, all services are vulnerable to dynamic heuristics based on the use of device sensors, as well as hypervisor heuristics that take advantage of the knowledge of the subtleties of the QEMU code generation algorithms. Please note that 4 tools (DroidBox, TaintDroid, ApkScan, Apk Analyzer) do not support the execution of machine code at all, which means that it is impossible to test the effectiveness of hypervisor heuristics on them. This conclusion was made after receiving the exception message when trying a test application to load machine code via JNI. All these messages were included in http requests containing results.
Conclusion 2. All analysis tools failed to draw the correct conclusion about the malicious behavior of repackaged malware samples. A comparison was made of all the reports prepared by hand when studying analysis tools (both offline and online), following our second approach for evaluation, and the observed results are consistent with those related to the first method. , , , , . - , - .
3. - , . - (CopperDroid, Visual Threat APK Analyzer) . , . , , , . , , , , . , , , , .
4. . , , Apk Analyzer , (, «, , »). , , . , , idH buildH, , , . , netH , IP- Android 10.0.2.15 192.168.0.24. , netH , IP- 0.0.0.0, ADB /proc/net/tcp.
, Apk Analyzer , . , , , accelH, Apk Analyzer'a. , , , , Apk Analyzer , .
, , . , Google Bouncer, , , , Google Play, , Android QEMU. Google Bouncer [11]. , Android .
. Android , . , IMEI IMSI, idH, Android. «Telephony Manager» Android, , , QEMU [12]. IMEI IMSI , . buildH, , , , Android. build.prop Android. , Android netH, Apk Analyzer.
. , , , . , Android , , , . (accelH, magnFH, rotVacH, proximH gyroH) . . , , , . , - [4] [23] , Android.
. , QEMU, BTdetectH, Android, ARM x86 , x86. BTdetectH, 2, Android, . , QEMU , . , , , . , QEMU. , , QEMU, Android, (, , ).
. , , , . , ARM [15] , . (QEMU) , BTdetecH xFlowH, , .
. , , . (BTdetecH xFlowH) . , . , - Android, , ; , , .
[30] Android . , . . , Android. [32] , Android, TaintDroid, , . TaintDroid .
, . [29] . , , MSR, , . [34] , . (, , , ), xFlowH.
[27] « », , . , « », , : QEMU BOCHS. [24] DISARM, . , , , , . , x86. , , , Android ( ARM).
This article explored how to get around dynamic analysis using malicious applications aimed at the Android platform. Heuristics of increasing complexity were implemented and tested by including them in samples of real malicious applications that try to hide their presence when analyzed in an emulated environment. All repackaged malware samples were tested in stand-alone analysis tools and publicly available scanning services, and their behavior was examined. Not a single service or tool was found that cannot be ignored by at least a few of the presented heuristics. The work carried out raises important questions about the effectiveness of existing analysis systems for malicious Android applications.For this reason, a number of possible countermeasures have been proposed to improve the resilience of dynamic analysis tools for malicious Android applications against detection of virtual machines.
[1] googlemobile.blogspot.com/2012/02
android-and-security.html.
[2] vrt-blog.snort.org/2013/04/changingimei-provider-model-and-phone.html .
[3] blog.sfgate.com/techchron/2013/10/10
stanford-researchers-discover-alarmingmethod-for-phone-tracking-fingerprintingthrough-sensor-flaws/.
[4] code.google.com/p/openintents/wiki
SensorSimulator.
[5] developer.android.com/reference
android/hardware/SensorManager.html.
[6] bluebox.com/corporate-blog/androidemulator-detection .
[7] code.google.com/p/smali .
[8] code.google.com/p/android-apktool .
[9] contagiominidump.blogspot.com .
[10] code.google.com/p/droidbox .
[11] www.duosecurity.com/blog/dissectingandroids-bouncer .
[12] codepainters.wordpress.com/2009/12/11
android-imei-number-and-the-emulator/.
[13] 99% of all mobile threats target Android devices. www .
kaspersky.com/about/news/virus/2013/99_of_all_
mobile_threats_target_Android_devices.
[14] Anubis/Andrubis: Analyzing Unknown Binaries. http: //
anubis.iseclab.org/.
[15] Arm: Virtualization extensions. www.arm.com
products/processors/technologies/
virtualization-extensions.php.
[16] QEMU Internals. ellcc.org/ellcc/share/doc
qemu/qemu-tech.html.
[17] T. Bläsing, A.-D. Schmidt, L. Batyuk, SA Camtepe, and
S. Albayrak. An android application sandbox system for suspicious
software detection. In MALWARE, 2010.
[18] Bramley Jacob. Caches and Self-Modifying Code. http: //
community.arm.com/groups/processors/blog/2010/
02/17/caches-and-self-modifying-code.
[19] J. Calvet, JM Fernandez, and J.-Y. Marion. Aligot: cryptographic
binary programs. In CCS, 2012.
[20] S. Dey, N. Roy, W. Xu, and S. Nelakuditi. Acm hotmobile 2013
poster: Leveraging
smartphones for fingerprinting . SIGMOBILE Mob. Comput. Commun. Rev., 17 (3),
Nov. 2013.
[21] W. Enck, P. Gilbert, B.-G. Chun, LP Cox, J. Jung, P. McDaniel,
and AN Sheth. Taintdroid: real-time
privacy monitoring system for smartphones. In OSDI, 2010.
[22] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A study of
android application security. In USENIX Security ,, 2011.
[23] L. Gomez, I. Neamtiu, T. Azim, and T. Millstein. Reran: Timingand touch-sensitive record and replay for android. In ICSE, 2013.
[24] M. Lindorfer, C. Kolbitsch, and P. Milani Comparetti. Detecting
environment-sensitive malware. In RAID, 2011.
[25] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. CHEX: Statically Vetting
Android apps for Component Hijacking Vulnerabilities. In CCS,
2012.
[26] F. Matenaar and P. Schulz. Detecting Android Sandboxes. http: //
www.dexlabs.org/blog/btdetect .
[27] R. Paleari, L. Martignoni, GF Roglia, and D. Bruschi. A fistful of
red-pills: how to automatically generate procedures to detect cpu
emulators. In WOOT, 2009.
[28] TH Project. Android Reverse Engineering (ARE) Virtual
Machine. www.honeynet.org/node/783 .
[29] T. Raffetseder, C. Kruegel, and E. Kirda. Detecting system
emulators. In ISC, 2007.
[30] V. Rastogi, Y. Chen, and X. Jiang. Droidchameleon: evaluating
android anti-malware against transformation attacks. In ASIA CCS,
2013.
[31] A. Reina, A. Fattori, and L. Cavallaro. A system call-centric analysis
and stimulation technique to automatically reconstruct android
malware behaviors. In EUROSEC, 2013.
[32] G. Sarwar, O. Mehani, R. Boreli, and D. Kaafar. On the effectiveness
of dynamic taint analysis for protecting against private information
leaks on android-based devices. In SECRYPT, 2013.
[33] M. Spreitzenbarth, F. Freiling, F. Echtler, T. Schreck, and
J. Hoffmann. Mobile-sandbox: Having a deeper look into android
applications. In SAC, 2013.
[34] C. Willems, R. Hund, A. Fobian, D. Felsch, T. Holz, and
A. Vasudevan. Down to the bare metal: Using processor features for
binary analysis. In ACSAC '12, 2012.
[35] LK Yan and H. Yin. DroidScope: Seamlessly reconstructing the
OS and Dalvik semantic views for dynamic Android malware
analysis. In USENIX Security, 2012
Anti-virus companies, mobile application stores and security researchers use techniques based on dynamic code analysis to detect and analyze mobile malicious applications. This article presents a wide range of counter-analysis techniques that can be used by malicious applications to bypass dynamic analysis in emulated Android platform environments.
The detection heuristics presented in this article cover three different categories based on (i) static properties, (ii) dynamic information from sensors, and (iii) the intricacies of the Android emulator on virtual machines. To assess the effectiveness of the presented methods, they were included in samples of real malicious applications and sent to publicly available dynamic analysis systems, after which alarming results were obtained. It was found that all the tools and services are vulnerable to most of our techniques evading analysis. Even trivial techniques, such as checking the IMEI value, are sufficient to bypass some of the existing dynamic analysis environments. Possible countermeasures have also been proposed to improve the sustainability of current dynamic analysis tools against attempts to evade analysis.
1. Introduction
The popularity of the Android OS, combined with the openness of this platform, made it an attractive target for attackers [13]. Antivirus vendors and researchers have responded to this growing security concern with services and tools for analyzing malicious applications. Google also created Bouncer [1], a service for automatically scanning and checking malicious applications. Scanning of an application to detect its potentially hidden malicious actions can be based on static [22, 25] and dynamic analysis [14, 17, 19, 28]. Unfortunately, both static and dynamic approaches can be circumvented. With regard to static analysis, researchers have demonstrated a series of techniques that can bypass the current available static analysis tools [30]. As will be shown in this paper, dynamic analysis using emulation to study malicious Android applications is also not perfect. A malicious program can infer whether it is running in an emulated environment, and therefore avoid detection by suspending all malicious activity.
')
In more detail, this article discusses how Android applications can infer that they are running on an emulated ARM processor or on a real device. First, a systematization of possible ways is created to determine the features of the runtime environment using heuristics sets. The heuristics presented in this article cover a wide range of complexity. Most of them are simple and can be prevented by simple changes in the emulated heuristics fraud environment, such as realistic values for static properties, such as the device serial number (IMEI). Others are more reliable because the emulated environment must provide realistic data from mobile sensors, such as an accelerometer. Ultimately, a set of heuristics is presented here, to counteract which requires a number of significant changes in the design of the emulated environment.
To assess the importance of the conclusions made in this article, a set of relevant images of malicious applications was repackaged. Developed heuristics were added to these images and sent to online analysis tools. Oddly enough, all of the tested analysis tools can be circumvented using some of the presented heuristics. Not a single malware analysis service was found that could cope with all of the heuristics tested. In addition, at least 5 of the 12 analysis tools we tested can be circumvented using simple heuristics such as checking the IMEI value. More sophisticated heuristics based on the intricacies of virtual machines could bypass all the tested services except 4. These 4 services do not support the execution of machine code, and thus cannot be used to run our subset of Android applications. Finally, all tested services are vulnerable to heuristics based on information from sensors (sensors).
It is worth noting that existing methods of analyzing malicious applications are easily circumvented by demonstrating the fact that current malicious applications can hide malicious functionality from publicly available services for analyzing malicious applications. A set of countermeasures was proposed in order to make the analysis of Android applications in an emulated environment more resilient to attempts to bypass it.
2. Techniques of counteracting analysis
The counter-analysis techniques that can be used in Android applications to circumvent detection can be divided into three categories: (a) static heuristics based on static information, which always initializes fixed values in emulated environments, (b) dynamic heuristics based on observing the unrealistic behavior of various sensors, and (c) Geurvisor's heuristics, based on incomplete emulation of real equipment. Table 1 provides a brief description of all categories, along with some typical examples.
Table 1. A brief description of the main types of heuristics detection of virtual machines that can be used by mobile malicious applications, along with typical examples
2.1. Static Heuristics
The static set includes heuristics that can be used to detect the emulated environment using presence checks or contained values in unique device identifiers, such as the serial number (device ID), current build version, values in the routing table.
Serial number of the device (device ID). Each smartphone contains an IMEI (International Identifier of Mobile Station Equipment), which is a unique number identifying it in GSM networks. IMEI has already been used by malicious applications in order to prevent analysis using malware detection tools running in emulators [2]. The other mobile identifier is the IMSI (International Mobile Subscriber Identity), which is associated with the SIM card found in the phone. Simple evasion heuristics are based on checking these identifiers, for example, is IMEI equal to null, which is true for the default Android emulator configuration. For reference to this type of heuristics, the abbreviation idH will be used.
Build number. Another way to identify the emulated environment is to check the information associated with the current assembly, extracted from the properties of the system. For example, the Android SDK provides a public Build class that provides information about fields such as PRODUCT, MODEL, and HARDWARE, which can be viewed in order to find out that the application is running in the emulator. For example, the standard Android image in the emulator has the PRODUCT and MODEL field values of google_sdk, and the HARDWARE field value of goldfish. Several heuristics were identified based on such checks, which will be referred to later using the abbreviation buildH .
Routing table Emulated Android devices run by default behind a virtual router with an address space of 10.0.0.2/24, isolated from the network of the target machine. The emulated network interface is configured with an IP address 10.0.2.15. The default gateway and DNS server configurations also contain fixed values. In this paper, network parameters are used as another of the detection heuristics. In particular, the heuristics checks for listening to sockets and establishing a connection (via / proc / net / tcp), and trying to find the port number associated with the addresses 10.0.2.15 and 0.0.0.0. As an indicator of the emulated environment. The reference to this heuristic is abbreviated as netH .
2.2. Dynamic Heuristics
Mobile phones are equipped with various sensors, such as an accelerometer, gyroscope, GPS, gravity sensor, etc. In fact, the output values of these sensors are based on information collected from the environment, and, therefore, realistic emulation is a difficult task. The existence of sensors is the main difference between smartphones and traditional computing systems. The increasing number of sensors on smartphones provides new opportunities for identifying actual mobile devices, and, therefore, identifying differences and finding emulators. For example, there are studies focused on the distinctive features of smartphones based on the flaws and imperfections of sensors [3, 20]. These approaches, based on distinctive features, can be used to detect emulated media.
By default, the Android emulator does not support emulation of device movements in space; This can be achieved through additional sensor simulators [4]. The current Android emulator builds also support the simulation of other types of sensors only partially or not at all. When testing available simulated sensors, it was found that the emulator generates the same values at equal time intervals of 0.8 seconds on average with a slight standard deviation (0.003043 seconds). The distribution function of time intervals between accelerometer events, observed when the Android emulator is running for two minutes, is shown in Figure 1. It was found that this function for the other sensors follows the same pattern. Sensor-based heuristics were implemented using the SensorManager class [5] of the Android API. An Android Activity (application screen) was developed that attempts to register a sensor listener to track its output values using the following approach.
First, the sensor listener is registered. If registration fails, then most likely the execution occurs in an emulated environment (except for the case when the actual device does not support a specific sensor). Otherwise, if the sensor registration was successful, the values of the onSensorChanged callback method are checked, which is called when the sensor values change. If the values of the sensors or the observed time intervals do not change with successive calls to this method, then the application is considered to be running in an emulated environment and the registration of the sensor listener is canceled. Heuristics based on sensors for accelerometer ( accelH ), magnetic field ( magnFH ), rotation ( rotVecH ), approximation ( proximH ) and gyroscope ( gyrosH ) were implemented .
Figure 1. The FRV intervals between accelerometer events observed in a running Android emulator for a few minutes
2.3. Hypervisor Heuristics
Switching definitions context QEMU. This heuristic is related to the context switching mechanism in QEMU [26] and the fact that QEMU does not update the value of the virtual command counter (virtual PC) during the execution of each instruction due to performance reasons. Since translated instructions are executed on the target machine, additional instruction is needed to increase the virtual command counter , so it is sufficient and quick to update the virtual command counter only when an instruction that violates linear execution, such as a jump instruction, is executed. This means that if a context switch occurs during the execution of the base unit, it will be impossible to calculate the value of the virtual program counter. Because of this, context switching in the QEMU environment occurs only after the execution of the base unit, and never during its execution.
The proof of this concept has already developed a detection technique QEMU BT , based on the histogram of address flow planning [26]. In non-emulated environments, a wide range of time intervals can be observed when a context switch occurs, because switching can occur at any time, whereas in an emulated environment, a context switch always takes place at a certain time, first of the base unit, since context switching can occur only when complete base unit is complete. This technique was implemented and used in the experiments as another heuristics with the abbreviation BTdetectH . In fig. Figure 2 shows the differences in the context switching time when this heuristic is executed in the Android emulator and on the real device.
Figure 2. To optimize, QEMU does not update the value of the virtual command counter after each instruction is executed, so many of the context switching events that may have occurred are not observed in the emulated environment.
Defining a QEMU by executing self-modifying code. As a second heuristic, a new QEMU detection technique (called xFlowH ) was implemented, based on the fact that QEMU does not track the modification of code pages. The technique is based on the differences in execution threads arising from the execution of the self-modifying code in the emulator and on the real device.
ARM processors contain two different caches, one for accessing instructions (I-Cache) and one for accessing data (D-cache). Harvard architectures (such as ARM) do not provide coherence between data caches and instructions. Therefore, the processor can execute the old (possibly invalid) section of the code after the new one has already been recorded in the main memory. This situation can be resolved by maintaining consistency between these two caches, which can be achieved using two operations: 1) cleaning the main memory, so that the new code in the data cache is mixed into the main memory 2) invalidation of the instruction cache, so that it can now be filled with new data from main memory. In native Android code, this can be done by calling the cacheflush function, which performs the above operations through a system call.
An example of self-modifying (machine) code was implemented, which uses a memory segment with rights to execute and write, which is overwritten several times in a loop with the contents of two different functions f1 and f2, respectively. After each change of the code, the code of this segment is launched, which in turn starts either f1 or f2 . These are two simple functions that both add their name to the end of the global variable string, so that we can conclude about the sequence of function calls. To achieve an alternating sequence of calls, you need to synchronize the caches using the cacheflush call, as described earlier.
This code, together with additional calls for synchronization after each change, was launched on the mobile device and on the emulator with the same results - each launch produced a sequential launch of functions, as defined in the loop. Then, the same experiment was performed, but this time the cacheflash call was excluded . As expected, a random sequence of calls was observed on the mobile device after each launch. Since the caches are not synchronized before each call, the instruction cache may contain outdated instructions, since it was clearly not recognized as invalid (invalid). Interestingly, it was found that this behavior is not observed in the emulator. Instead, the sequence of calls was exactly the same as in the first case, when the caches were matched before each function call. This behavior is expected, since QEMU discards the translated base unit for the previous version of the code, and forwards the new generated code as it tracks changes in the code pages and ensures that the generated code always matches the target instructions in memory [16].
3. Implementation
The heuristics described in Section 2 were implemented using the Android SDK. For BTDetecH and xFlowH, Java Native Interface (JNI) was used to run machine code that implements the functionality of each heuristic. A simple Android application (test application) was developed, which performs the proposed heuristics in the background and for each of them collects information about its effectiveness. The collected information is sent to the HTTP server for storage in a local database. In addition, the developed heuristics were included in the set of known malicious Android applications. To do this, we used Smali / Backsmali [7] along with Aptktool [8], which we used to disassemble and reassemble (repacking applications). The inclusion of heuristics in malware was done by inserting Smali Dalvik bytecode generated using a disassembler for each heuristic that was previously extracted from the developed test applications. Each malicious application was modified to contain one of the implemented heuristics, as indicated in Table 2.
First, each original sample was launched in the emulator and on a real device, and its behavior was observed with the help of the logcat command (Android logging system) when launching the main Activiti (application screens), as well as services. Subsequently, changes were made to these components of the application by one of the developed heuristics, which, depending on the results of the heuristics, decided to stop the execution of the component or not.
Table 2. Samples of malicious applications used in the study
The repackaged applications were tested in the simulator and on real devices in order to make sure that malicious behavior occurs only on a real device. It is worth noting that in addition to the above changes in the resulting code of malicious applications, no other additional changes are required in any other parts of the APK files, except for the following cases. The idH heuristic requires the permission READ_PHONE_STATE explicitly declared in the Android manifest file in order to be able to read the status of the phone. For the heuristics BTDetectH and xFlowH, you must create the lib directory in the application root directory containing the required machine code as shared libraries.
4. Experimental evaluation
This section presents the results of our assessment of the effectiveness of heuristics presented in section 2. Each heuristics was added to a real malicious application and analyzed using various services and dynamic analysis tools. For each case, there was a record of information about which heuristics managed to detect the emulator and which did not. First, the set of malicious programs and dynamic analysis services used in the work is described, followed by a brief overview of our methodology, and at the end, the findings are presented and discussed.
4.1. Data and tools
Samples of malicious applications. The detection technique code, using the process described in section 3, has been added to several widely known malicious Android applications. Were used 10 samples from different families of malicious applications with different capabilities, including privilege escalation exploits, confidential information leaks, SMS trojans, and so on. All tested samples are publicly available and are part of the Contagio Minidump [9]. Table 2 summarizes the patterns of malicious applications used along with the heuristics used in each case.
Services dynamic analysis. The services and tools of dynamic analysis used in the assessment are shown in Table 3. Both standalone analysis tools available for download and local use were used, as well as online services that analyze submitted samples online.
Three popular tools for analyzing Android applications were used: DroidBox [10], DroidScope [35], and TaintDroid [21]. All three tools execute an Android application in a virtual environment and produce analysis reports. DroidBox provides information on incoming / outgoing traffic, read / write operations, called services, application permissions bypasses, SMS sent, phone calls made, etc. DroidScope performs profiling of Android applications at the level of OS calls and APIs, and gives an idea of information leaks. TaintDroid is able to efficiently perform system-wide tracking of the flow of data from multiple sources of sensitive data.
Table 3. Tools and services for analyzing malicious Android applications used in our assessment
In addition to stand-alone tools, publicly available online services were also used that can perform dynamic analysis of Android applications, briefly described below. Andrudis [14] performs both static and dynamic analysis of unwanted Android applications. SandDroid analyzes the permissions / components of the application, as well as the detection / classification of its malicious actions. ApkScan provides information including file access, network connections, phone calls, SMS sent, information leaks, and cryptographic activity. VisualThreat provides information covering a wide range of activities, ranging from network activity and data leakage, and ending with the detection of malicious application families with correlated API calls. TraceDroid emulates some actions when analyzing an application, such as user interaction, incoming calls, SMS messages that can detect malicious intentions. CopperDroid [31] is based on QEMU and out of the box can perform dynamic analysis of Android applications (both at the OS level and API). APK Analyzer, ForeSafe and Mobile Sandbox [33] are also dynamic analysis services that investigate mobile malicious applications, following the approaches mentioned in the above mentioned tools.
4.2. Methodology
To assess the effectiveness of the presented heuristics, two different approaches were used. In the first approach, we sent a copy of the application containing all the heuristics described in section 3 to each online service from our set. During the analysis, the application checks the performance of the heuristics, applying them sequentially to determine whether execution is performed in an emulated environment or not. For each checked heuristic, the application sends the result to an HTTP server. After that, you can determine which of the heuristics were effective in identifying a virtualized environment, and which were not.
In order to perform a more realistic analysis and demonstrate how such heuristics can complicate the work of various dynamic analysis tools and not allow them to draw wrong conclusions, consider a different approach. To do this, the existing malicious applications are modified in such a way that they include one heuristic described in section 3 and sent both the original sample and the repackaged into each service. Then, generated reports are collected and compared to find differences in the observed behaviors.
Table 4. The stability of dynamic analysis tools against evasion techniques from virtual machines. “✓” indicates resistance to them, “✗” indicates vulnerability to them, and “JNI NS” indicates a lack of support for JNI (calling machine functions from Java applications)
4.3. Dodge results
The results of the effectiveness evaluation are shown in Table 4. The first three lines refer to the offline analysis tools, and the rest to the online analysis services. The following describes the main conclusions based on the collected results.
Conclusion 1. All the studied tools and dynamic analysis services are vulnerable to 5 or more heuristics. As you can see in Table 4, all tested tools can be easily circumvented using only one of the suggested heuristics. In particular, only 6 out of 12 tools are resistant to idH simple static heuristics, which checks the IMEI value of the device. Also, only one analysis service was found, Apk Analyzer, resistant to all presented static heuristics. In addition, all services are vulnerable to dynamic heuristics based on the use of device sensors, as well as hypervisor heuristics that take advantage of the knowledge of the subtleties of the QEMU code generation algorithms. Please note that 4 tools (DroidBox, TaintDroid, ApkScan, Apk Analyzer) do not support the execution of machine code at all, which means that it is impossible to test the effectiveness of hypervisor heuristics on them. This conclusion was made after receiving the exception message when trying a test application to load machine code via JNI. All these messages were included in http requests containing results.
Conclusion 2. All analysis tools failed to draw the correct conclusion about the malicious behavior of repackaged malware samples. A comparison was made of all the reports prepared by hand when studying analysis tools (both offline and online), following our second approach for evaluation, and the observed results are consistent with those related to the first method. , , , , . - , - .
3. - , . - (CopperDroid, Visual Threat APK Analyzer) . , . , , , . , , , , . , , , , .
4. . , , Apk Analyzer , (, «, , »). , , . , , idH buildH, , , . , netH , IP- Android 10.0.2.15 192.168.0.24. , netH , IP- 0.0.0.0, ADB /proc/net/tcp.
, Apk Analyzer , . , , , accelH, Apk Analyzer'a. , , , , Apk Analyzer , .
5.
, , . , Google Bouncer, , , , Google Play, , Android QEMU. Google Bouncer [11]. , Android .
. Android , . , IMEI IMSI, idH, Android. «Telephony Manager» Android, , , QEMU [12]. IMEI IMSI , . buildH, , , , Android. build.prop Android. , Android netH, Apk Analyzer.
. , , , . , Android , , , . (accelH, magnFH, rotVacH, proximH gyroH) . . , , , . , - [4] [23] , Android.
. , QEMU, BTdetectH, Android, ARM x86 , x86. BTdetectH, 2, Android, . , QEMU , . , , , . , QEMU. , , QEMU, Android, (, , ).
. , , , . , ARM [15] , . (QEMU) , BTdetecH xFlowH, , .
. , , . (BTdetecH xFlowH) . , . , - Android, , ; , , .
6.
[30] Android . , . . , Android. [32] , Android, TaintDroid, , . TaintDroid .
, . [29] . , , MSR, , . [34] , . (, , , ), xFlowH.
[27] « », , . , « », , : QEMU BOCHS. [24] DISARM, . , , , , . , x86. , , , Android ( ARM).
7.
This article explored how to get around dynamic analysis using malicious applications aimed at the Android platform. Heuristics of increasing complexity were implemented and tested by including them in samples of real malicious applications that try to hide their presence when analyzed in an emulated environment. All repackaged malware samples were tested in stand-alone analysis tools and publicly available scanning services, and their behavior was examined. Not a single service or tool was found that cannot be ignored by at least a few of the presented heuristics. The work carried out raises important questions about the effectiveness of existing analysis systems for malicious Android applications.For this reason, a number of possible countermeasures have been proposed to improve the resilience of dynamic analysis tools for malicious Android applications against detection of virtual machines.
[1] googlemobile.blogspot.com/2012/02
android-and-security.html.
[2] vrt-blog.snort.org/2013/04/changingimei-provider-model-and-phone.html .
[3] blog.sfgate.com/techchron/2013/10/10
stanford-researchers-discover-alarmingmethod-for-phone-tracking-fingerprintingthrough-sensor-flaws/.
[4] code.google.com/p/openintents/wiki
SensorSimulator.
[5] developer.android.com/reference
android/hardware/SensorManager.html.
[6] bluebox.com/corporate-blog/androidemulator-detection .
[7] code.google.com/p/smali .
[8] code.google.com/p/android-apktool .
[9] contagiominidump.blogspot.com .
[10] code.google.com/p/droidbox .
[11] www.duosecurity.com/blog/dissectingandroids-bouncer .
[12] codepainters.wordpress.com/2009/12/11
android-imei-number-and-the-emulator/.
[13] 99% of all mobile threats target Android devices. www .
kaspersky.com/about/news/virus/2013/99_of_all_
mobile_threats_target_Android_devices.
[14] Anubis/Andrubis: Analyzing Unknown Binaries. http: //
anubis.iseclab.org/.
[15] Arm: Virtualization extensions. www.arm.com
products/processors/technologies/
virtualization-extensions.php.
[16] QEMU Internals. ellcc.org/ellcc/share/doc
qemu/qemu-tech.html.
[17] T. Bläsing, A.-D. Schmidt, L. Batyuk, SA Camtepe, and
S. Albayrak. An android application sandbox system for suspicious
software detection. In MALWARE, 2010.
[18] Bramley Jacob. Caches and Self-Modifying Code. http: //
community.arm.com/groups/processors/blog/2010/
02/17/caches-and-self-modifying-code.
[19] J. Calvet, JM Fernandez, and J.-Y. Marion. Aligot: cryptographic
binary programs. In CCS, 2012.
[20] S. Dey, N. Roy, W. Xu, and S. Nelakuditi. Acm hotmobile 2013
poster: Leveraging
smartphones for fingerprinting . SIGMOBILE Mob. Comput. Commun. Rev., 17 (3),
Nov. 2013.
[21] W. Enck, P. Gilbert, B.-G. Chun, LP Cox, J. Jung, P. McDaniel,
and AN Sheth. Taintdroid: real-time
privacy monitoring system for smartphones. In OSDI, 2010.
[22] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A study of
android application security. In USENIX Security ,, 2011.
[23] L. Gomez, I. Neamtiu, T. Azim, and T. Millstein. Reran: Timingand touch-sensitive record and replay for android. In ICSE, 2013.
[24] M. Lindorfer, C. Kolbitsch, and P. Milani Comparetti. Detecting
environment-sensitive malware. In RAID, 2011.
[25] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. CHEX: Statically Vetting
Android apps for Component Hijacking Vulnerabilities. In CCS,
2012.
[26] F. Matenaar and P. Schulz. Detecting Android Sandboxes. http: //
www.dexlabs.org/blog/btdetect .
[27] R. Paleari, L. Martignoni, GF Roglia, and D. Bruschi. A fistful of
red-pills: how to automatically generate procedures to detect cpu
emulators. In WOOT, 2009.
[28] TH Project. Android Reverse Engineering (ARE) Virtual
Machine. www.honeynet.org/node/783 .
[29] T. Raffetseder, C. Kruegel, and E. Kirda. Detecting system
emulators. In ISC, 2007.
[30] V. Rastogi, Y. Chen, and X. Jiang. Droidchameleon: evaluating
android anti-malware against transformation attacks. In ASIA CCS,
2013.
[31] A. Reina, A. Fattori, and L. Cavallaro. A system call-centric analysis
and stimulation technique to automatically reconstruct android
malware behaviors. In EUROSEC, 2013.
[32] G. Sarwar, O. Mehani, R. Boreli, and D. Kaafar. On the effectiveness
of dynamic taint analysis for protecting against private information
leaks on android-based devices. In SECRYPT, 2013.
[33] M. Spreitzenbarth, F. Freiling, F. Echtler, T. Schreck, and
J. Hoffmann. Mobile-sandbox: Having a deeper look into android
applications. In SAC, 2013.
[34] C. Willems, R. Hund, A. Fobian, D. Felsch, T. Holz, and
A. Vasudevan. Down to the bare metal: Using processor features for
binary analysis. In ACSAC '12, 2012.
[35] LK Yan and H. Yin. DroidScope: Seamlessly reconstructing the
OS and Dalvik semantic views for dynamic Android malware
analysis. In USENIX Security, 2012
Source: https://habr.com/ru/post/269999/
All Articles