App Hardening for Mobile Banking and Payment Apps: Emulator Detection

by Martin Rupp (guest) on 28. January 2022

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.

Whatever an attacker wants to do: reverse the code, attach a debugger, tamper 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). In order to prevent a mobile app from running on an emulator, effective emulator detection must first be in place.

This article focuses on a variety of techniques for detecting Android emulators.

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!

 

Android and iOS Emulators

Often-used Android emulators include:

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

Commonly used iOS emulators include:

  • 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 can be seen as “in-between” a virtual machine and an emulator. A simulator acts more as a ‘stub’ system that mimics rather than emulate (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 of the 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

Etc.

Here we list the 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. So by using that 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 detection techniques available than have been described here. Detecting an emulator in an Android or iOS context is not per se the most difficult challenge for a RASP system. However, it may prove to be difficult because of the great number of different emulators and hence, an important margin of error, that create important False Acceptance Rate 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

Other Related Articles: # Mobile App Security # MASC # RASP

Want to know how we can help ?

Get in touch to better understand how our solutions secure ecommerce and billions of transactions worldwide.