A     Overview of EmuDetLib

We have developed a flexible emulation-detection library (EmuDetLib). The detection techniques in this library can be broadly classified into five categories (refer Table 1): (i) Unique device information, (ii) Sensors’ reading, (iii) Device state information, (iv) GPS information, and (v) Distributed detection.

A.1    Unique Device Information:

As many Android devices are smartphones, Android provides a comprehensive API that includes the interfaces to query telephony information along with unique data per device like IMEI, IMSI, and phone number. These details may help in identifying a device uniquely. For example, on querying Device ID (IMEI) from an emulator, it returns all ‘0’, which is unrealistic and indicates that the device is an emulator. Similarly, other information related to a SIM card like SIM serial number, phone number, and IMSI can reveal the identity of the underlying platform, i.e., whether the platform is emulated or not.

To hide the emulated platform against the emulation-detection based on the unique device information, a sandbox designer can supply more realistic data when queried by an App. Most of the dynamic analysis framework such as CuckooDroid, Droidbox, and MobSF provide similar anti-emulation-detection measures by feeding-in realistic device information. However, a smart malware author can analyze this data and find that they are static (fixed) to successfully detect the underlying platform.

A.2    Sensors’ Reading:

Today’s smartphones have various sensors for different purposes that can be broadly classified into two categories—motion sensors and environmental sensors. The motion sensors help to detect the motion on a device. Such sensors can measure the acceleration, magnetic field, rotation, and others along the three dimensions, i.e., X, Y, and Z, which indicates that the smart-phone user has made some motion. Similarly, the environmental sensors observe the changes in the operating environment so that an App can alter its behavior based on the readings. For example, a light sensor provides the luminosity information of the environment which can be used by a smart-phone to adjust the display brightness.

For an Android App, the use of these sensors do not require any permission and an App can take full advantage of these sensors. As the data observed on these sensors fluctuate continuously, this insight can be used to detect the underlying emulated environment. A recent example of sensor-based detection is the observation of TrendMicro where malware (in Play Store) make use of the motion-detection feature to evade the dynamic analysis [1]. This is an indicator that the dynamic analysis framework on the play store is not secure against the advanced emulation-detection techniques.

Identifying such sophisticated malware is not trivial; hence, we have incorporated sensor-based detection functionalities in our library for emulation-detection. Our library provides the detection mechanism based on the motion sensors as well as on the environmental sensors.

A.3    Device State Information:

In reality, a device state gets changed due to some internal/external events such as changes in telephony signal strength, battery power, and incoming SMS/Calls. However, such state changes behavior is missing in an emulated environment. Therefore, information related to a device state can also be queried by malware to detect the emulated environment as described below:

(i) Telephony signal: As the signal strength of the telephony system cannot remain constant for a long time, malware can observe such information over a period. The malware can flag the underlying operating environment as emulated if it finds that the signal strength is constant.

(ii) Battery power: Similar to the telephony signal, the battery power’s strength which is the standard behavior of every mobile device. If such behavior is absent, and battery power remains constant, it indicates that the operational machine is virtual.

(iii) Incoming SMS/call: A malware can register a notification for every incoming SMS/Call, and wait for the event. In an emulated environment, malware may not observe such an event and will thus remain dormant without performing any malicious activities.

A.4    Using the GPS Location Information:

GPS (Global Positioning System) is also a sensor and the malware can use similar methods (as explained above) that are used for other sensors to detect emulated platforms. However, the emulation-detection based on the GPS is somewhat different from other sensors, as explained below.

Android provides rich APIs to perform various tasks, one such API gives the power to generate a mock location that can be used by an App to introduce a fake location when queried. An Android App requires ACCESS_MOCK_LOCATION permission to use the mock location API. The other source for geo-location is BTS ID. Android provides API to query BTS ID, and we can get its geo-location by using publicly/commercially available services (https://opencellid.org). Hence, the geo-location-based emulation-detection technique only works when one of the following conditions is satisfied: (i) there is no change in the geo-location of the device, (ii) the mock location API is used to set the geo-location of the device, or (iii) BTS geo-location is not collaborating with the GPS location.

Detection in case of condition (i) is easy; since we do not see any changes in geo-location, we can directly infer that a device is an emulator. However, exploiting (ii) or (iii) condition is non-trivial as fluctuating GPS data can be a result of fake location App or real change in location. Detecting emulation in the (ii) condition requires a mechanism to differentiate between real location data and mock location data. In contrast, the (iii) condition assumes that the distance between GPS location and BTS geo-location can not be more than x meters. The value of x may differ depending on the density of the area where BTS is located.

The Location module of the Android framework provides explicit methods to differentiate the location data w.r.t. its source i.e. whether the data is a mock location or a real GPS device reading. Malware can use this method to detect emulation platforms. However, this check may fail if the mock location generation App is either closed or running as a service. In this scenario, the Location module returns the GPS data (probably set by a fake location App executing before) without the fake location indicators. Therefore, the mock location detection feature provided by the Location module doesn’t help and requires a more fine-grained mechanism to differentiate mock locations from real location data.

Another possible approach to be sure about the location data being fake is to identify active Apps that can generate fake location information. As discussed earlier, a fake location generation App requires special ACCESS_MOCK_LOCATION permission. Upon querying the package manager, we can get a list of the Apps and services that have been granted this permission and subsequently checking them against the list of running processes. If we find a running App or service, then we can say that the current location is most probably fake and can consider it to be an emulated environment.

Algorithm 1 detects such Apps and returns true or false based on the status of the fake location Apps currently executing on the device (if any). The algorithm queries the android package manager for the permissions granted to individual Apps, and identifies those with the ACCESS_MOCK_LOCATION permission. If at least one App/service is active with the permission, the algorithm returns true.

A.5    Distributed Emulation-detection:

So far, we have discussed the emulation-detection techniques that can be employed by a stand-alone App to detect the emulated environment. Nowadays, most Apps require communication with a centralized server to share their status or get new information. To identify a device uniquely at the server, an App typically generates a unique ID called an AppID. Apart from the AppID, a smartphone also contains device-related unique IDs namely IMEI, IMSI, SIM Serial number, and others. This information can also help in identifying a device uniquely at the server as explained below.

It is trivial to see that a slightly different malware in terms of its signature can be generated easily by changing its package name, altering the function name and variable naming convention, or by introducing dummy code while retaining the overall functionality and the server address. Such malware can communicate the unique device information to a remote server to identify the emulated environment remotely. In this situation, the emulation-detection can happen at the server by querying the device information from the connected devices. If a server detects that multiple devices have identical information (expected to be unique), it can flag those devices as emulated environment. As this emulation-detection is carried out in the context of multiple connected devices, we classify this detection technique as a distributed emulation-detection.

To detect emulation using the distributed emulation-detection mechanism, we need a server where the emulation-detection mechanism is deployed. A candidate emulation-detection procedure that can be deployed on the centralized server is described in Algorithm 2. As shown in the emulation-detection algorithm, the devices identified as an emulated platform are added to the blocked device list. The server can execute this detection process either on a new device connection request or on every request received from the client. On detection of the emulated device, the server can either stop serving the client or can notify the client about the emulation-detection.

A.6    Ethical Concern

EmuDetLib is designed for malware analysts, vulnerability assessment and penetration testing (VAPT) engineers, and in general, cybersecurity researchers who are interested in checking vulnerabilities in emulator-driven dynamic analysis framework. However, there is a concern that such a library might also be misused by unethical hackers for finding vulnerabilities in already released popular analysis frameworks and use the knowledge to bypass the dynamic analysis process. We also note that this ethical concern is often present in all research publications that present a VAPT tool or disclose a vulnerability in products.

B     Results

B.1    Evaluation of existing framework against Real Malware

Table 2 shows the classification of real malware in terms of their emulation-detection capability and the evaluation of anti-emulation-detection measures of existing dynamic analysis framework against the real malware.

B.2    Code snippet from BatterySaverMobi

References