As the amount of Android malware grows, it follows every step of its Windows counterparts when it comes to techniques used to evade emulators used for dynamic analysis.
In this blog post, we’ll show some of those anti-emulator techniques.
An emulator is hardware or software that allows one computer (the host) to imitate another computer (the guest). It typically allows the host system to run software or use peripheral devices designed for the guest system. In security, it’s a handy way to test malware behavior — which is why the malware creators want to disrupt it.
Anti-emulation techniques are found in many different Android malware families, one being the recent Android Adload adware found in Google Play.
With that, here are six common anti-emulator techniques SophosLabs discovered:
1. Check telephony services information
Emulator detecting is all about spotting the difference between the environment that the emulator and real device provide. Firstly, the deviceID, phone number, IMEI, and IMSI would be different on an emulator than on a real device. The Android.os.TelephonyManager class provides methods to get the information. Applications can use the methods in this class to determine telephony services and states, and access some types of subscriber information, and register a listener to receive notification of telephony state changes. For example, it can use getLine1Number to get the phone number on line 1. On an emulator, it would be 1555521 with emulator’s port number. If the port number is 5554, the return value will be 15555215554.
Andr/RuSms-AT uses this code to detect the emulator:
2. Check build info
We’ve found multiple malware families checking the build info to determine if it’s running on an emulator. For example, this banker malware has the following anti-emulator code (click to enlarge):
The strings are encrypted. After decrypting, it’s checking this:
ctx.getSystemService(“phone”).getDeviceId().equals(“000000000000000”)
Build.MODEL.contains(“google_sdk”)
Build.MODEL.contains(“Emulator”)
Build.MODEL.contains(“Android SDK”)
Build.FINGERPRINT.startsWith(“generic”)
Build.FINGERPRINT.startsWith(“unknown”)
Build.MODEL.contains(“Android SDK built for x86”)
Build.MANUFACTURER.contains(“Genymotion”)
Build.BRAND.startsWith(“generic”) && Build.DEVICE.startsWith(“generic”)
The function above is called by a broadcast receiver. In the app manifest, this receiver is defined to receive android.intent.action.BOOT_COMPLETED and android.intent.action.SCREEN_ON. That means it’s called every time the phone is booted and awoken from sleep. It’s a common place for malware to launch their malicious actions. But as showed below, this malware won’t do anything if the emulator checking function returns “True.”
3. Check system properties
Another way is to check system properties. Some system properties on an emulator are different from those on real devices. For example, device brand, hardware and model. This table shows some of the system property values on an emulator:
|
Property |
Value indicates emulator |
|
ro.bootloader |
Unknown |
|
ro.bootmode |
Unknown |
|
ro.hardware |
Goldfish |
|
ro.product.model |
Sdk |
|
ro.product.device |
Generic |
|
ro.product.name |
Sdk |
4. Check presence of emulator related files.
This is another technique found in malware samples. They check if QEMU (Quick Emulator) or other emulator-related files exist. For example this piece of code is found in a Andr/Pornclk variant.
5. Check debugger and installer
This one is not an anti-emulator but its purpose is also to obstruct the dynamic analysis. Like this skinner adware reported by checkpoint, it uses Debug.isDebuggerConnected() and Debug.waitingForDebugger() to check if a debugger exists. More interesting, it also gets the installer using getInstallerPackageName and sees if it’s installed by Google Play (com.android.vending). So if you install the program to a device with adb, like most analysts do, the application won’t work.
6. Time bomb
This is another way many malware/adware families hide themselves from dynamic analysis. After installation, they await a certain time until they start their activities. For example, the configuration file below has been seen in an adware sample:
“settings”: {
“adDelay”: 180000,
“firstAdDelay”: 86400000,
“unlockDelay”: 2,
“bannerDelay”: 180000,
“bannerPreDelay”: 10000,
“bannersPerDay”: 25
},
firstAdDelay is the millisecond until the first advertisement is delivered, 24 hours in this case. This can prevent the user from getting suspicious as well.
We believe Android malware and adware writers will continue to weave anti-emulation techniques into their code, as they have had a fair degree of success in doing so thus far. Security companies must match them with better detection methods.
Reference:
https://github.com/strazzere/anti-emulator
http://blog.checkpoint.com/2017/03/08/skinner-adware-rears-ugly-head-google-play/