2 min read

Why Emulator Detection is Essential for Mobile Banking and Payment App Security

Why Emulator Detection is Essential for Mobile Banking and Payment App Security

Attacks on mobile banking and payment applications frequently begin with the use of an emulator for the mobile operating system, where the targeted application is run and analysed. Whether the attacker wants to reverse the code, attach a debugger, tamper with the application, etc., the first step is usually to use an Android or iOS emulator.

MASC Product sheet

An important role of Runtime Application Self-Protection (RASP) mechanisms is, therefore, to prevent the protected application from running inside an emulator (simulated environment). To prevent a mobile app from running on an emulator, effective emulator detection must first be in place.

There are many ways to detect emulators, as we will see, but there are also a large number of such emulators on the market and counting. This article explores several effective Android emulator detection techniques.

Android and iOS Emulators

Popular Android Emulators

  • Android Studio’s emulator
  • Andy
  • ARChon
  • Bluestacks
  • Droid4X
  • Genymotion
  • KoPlayer
  • MEmu
  • Nox
  • PrimeOS
  • Remix OS Player
  • Xamarin
  • YouWave
  • ArcWelder
  • DroidDolphin
  • Bouncer
  • BareDroid

Popular iOS Emulators

  • Smartface
  • iPadian
  • Appetize.io
  • App.io
  • MobiOne Studios
  • Air iPhone
  • XCode
  • Remoted iOS simulator

Android Emulator Detection Techniques

There are differences between an emulator, a virtual machine, a hypervisor, and a simulator. An emulator, ‘emulates’ the whole system, including the processor, in software (which means that it is often very slow). A virtual machine relies on a real CPU to perform virtualization. A hypervisor sits “in between” a virtual machine and an emulator. A simulator acts more as a ‘stub’ system that mimics rather than emulates (hence the name). 

Read White Paper

There is no official API in iOS or Android to detect an emulator. Therefore, several proprietary checks have to be done by the RASP system. 

An emulator reproduces, with great fidelity, the behavior and functioning of the original operating system. But it still has artifacts that betray its presence. Most emulator detection techniques are based on the presence of such artifacts, which can be located in the file system, in the network, or in the hardware.

Build Values

Reading the build values may be a quick test to check for an emulator. 

All the following values can be accessed programmatically on Android, and they often contain proof of the presence of an emulator:

  • Build.FINGERPRINT
  • Build.MANUFACTURER
  • Build.MODEL
  • Build.BRAND
  • Build.DEVICE
  • Build.PRODUCT

Here are different default values for several popular emulators: BlueStacks, GenyMotion, Andy, YouWave, and ARCWelder. 

RASP-emulator

By themselves, these values can create a simulator fingerprint. 

Hardware-based Detection

It is possible to detect the presence of an emulator by looking at inconsistencies with the hardware. The following table gives an overview of such possibilities. For each emulator, we list the default values. By using our table with known values of a real device, we can eventually decide if we are dealing with an emulator or not 

Hardware-Based-Detection-Emulator-DetectionTable

Additionally, an IMEI check will return a value of ‘000000000000000’ for an emulator. The same can be done with the IMSI check, etc.

Networking Environment Checks

A network can give a lot of hints that an emulator is present. The MAC addresses of the network cards may have specific values. Additionally, an analysis of TTL (Time to Live/Hop limits) values can also give some clues, as shown in the following table:

Emulator

TTL

RealDevice

TTL

BlueStacks

109

Galaxy S3

52

GenyMotion

111

Galaxy Note 3

53

Andy

109

Galaxy Note 8.0

64

YouWave

111

Vega Racer 3

53

ARC Welder

111

LG G3

49

 

Conclusion

There are many more emulator detection techniques available than we've described here.

Detecting an emulator in an Android or iOS context is not the most difficult challenge for a RASP system, per se. However, it may prove difficult because of the number of different emulators and hence, an important margin of error, that create important False Acceptance Rates or important False Reject Rates. Using Machine Learning on the top of the checks might also aid in getting more accurate results from a mobile emulator detector

Read White Paper

References and Further Reading

  • Read more articles about application security for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more
  • Internet Security Threat Report, Volume 24 (February 2019), by Symantec Corporation 
  • MASC Mobile App Security Core (2019), Web page by Cryptomathic