4 min read

Stay Ahead of Emulator-Based Attacks: Securing Mobile Banking Apps in 2025

Stay Ahead of Emulator-Based Attacks: Securing Mobile Banking Apps in 2025

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. 

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

There are many ways to detect emulators, as discussed below. However, there are also many 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 
  • Bluestacks
  • Genymotion
  • MEmu
  • Nox
  • PrimeOS
  • Xamarin
  • DroidDolphin
  • LDPlayer9
  • Tencent GameLoop
  • NetEase MuMu Player
  • Bliss OS (Android-x86)
  • Waydroid

 Popular iOS Emulators 

Compared to Android, Apple tightly controls their ecosystem making emulators easy to detect. 

  • Smartface 
  • Corellium
  • iPadian (1)
  • Appetize.io
  • Xcode Simulator
  • Remoted iOS simulator

Note 1 – iPadian is not a true emulator; it only mimics the iOS UI and cannot run actual iOS apps, often misleading users.

Android Emulator Detection Techniques 

Let's first clarify the 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).  

SECURING MOBILE BANKING APPS WITH MASC

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

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

Build Values for ANDROID 

Reading build values is a quick method 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

The table below shows default build values for popular emulators.: LDPlayer 9, MuMu Player X, Bliss OS, Waydroid and BlueStacks X.  

Build Field 

Emulator 

LDPlayer 9 

MuMu Player X 

Bliss OS 

Waydroid 

BlueStacks X 

BOARD 

android_x86 

mumu_x86 

x86_64 

qcom 

bst_x86 

BOOTLOADER 

unknown 

unknown 

bliss 

unknown 

unknown 

BRAND 

generic_x86 

mumu 

android_x86 

google 

BlueStacks 

CPU ABI 

x86 

x86 

x86_64 

arm64-v8a 

x86 

HOST 

buildserver 

mumu-build 

bliss-host 

waydroid-container 

bst-build-host 

DEVICE 

generic 

mumu_x86 

bliss_x86_64 

raven 

bst_x86 

HARDWARE 

vbox86 

mumu 

android_x86_64 

raven 

bst 

MANUFACTURER 

unknown 

NetEase 

Bliss 

Google 

BlueStacks 

MODEL 

LDPlayer 

MuMu 

Bliss-Device 

Pixel 6 

BlueStacks X 

PRODUCT 

full_x86 

mumu_x86 

bliss_x86_64 

raven 

bst_x86 

RadioVersion 

unknown 

unknown 

unknown 

unknown 

unknown 

 

By themselves, these values can create a simulator fingerprint. This information may also be modified to fool any attempt to fingerprint. The emulators Bliss OS, Waydroid and LDPlayer 9 allow for extensive system value spoofing (deep spoofing). BlueStacks X is the most limited. 

Build values for iOS 

Reading certain system values on iOS can help determine if the app is running on a simulator instead of real hardware. Apps can query these values using Objective-C or Swift APIs to detect simulators (e.g., App Store restrictions, anti-tampering, DRM). 

Key Identifiers for Detection: 

  • TARGET_OS_SIMULATOR 
  • Compile-time flag that is true when the app is built for the iOS simulator
  • UIDevice.model
  • Return "iPhone" on real devices, but often returns "iPhone Simulator" in simulators. 
  • uname() (via sysctl)
  • On a real device, machine returns values like "iPhone14,2)
  • In simulators, it often returns "x86_64" or "arm64" (depending on Apple Silicon or Intel Mac)
  • NSProcessInfo().environment ["SIMULATOR_DEVICE_NAME"]
  • This variable exists only in a simulator environment
  • NSBundle.mainBundle.path(forResoruce: "embedded", orType: "mobileprovision")
  • Present on real devices only (contains provisioning profile). Absent in simulator.

Examples of system field differences: 

Field / API 

Real Device 

iOS Simulator (Xcode) 

UIDevice.model 

iPhone 

iPhone Simulator 

uname().machine 

iPhone 14.2 

X86_64 / arm64 

SIMULATOR_DEVICE_NAME 

(not present) 

iPhone 14 Pro (for example) 

TARGET_OS_SIMULATOR 

False 

True  

mobileprovision present? 

Yes 

No 

 

Hardware-based Detection 

It is possible to detect the presence of an emulator by identifying inconsistencies in hardware features. 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 Feature 

LDPlayer 9 

MuMu Player X 

Bliss OS 

Waydroid 

BlueStacks X 

Camera 

No 

No 

Yes 

Yes* 

No 

Bluetooth 

No 

No 

Yes 

Yes* 

No 

Microphone 

Yes 

Yes 

Yes 

Yes 

Yes 

GPS 

No 

No 

Yes 

Yes* 

No 

AccelerationSensor 

Yes 

Yes 

Yes 

Yes 

Yes 

TemperatureSensor 

No 

No 

Varies 

No 

No 

Compass 

No 

No 

Yes 

Yes 

No 

Gyroscope 

Yes 

Yes 

Yes 

Yes 

Yes 

NFC 

No 

No 

Yes 

No 

No 

 

For entries marked with an asterisk (e.g., Yes*), the feature may be available depending on configuration or host system integration 

Evolving Emulator Detection Requires Smarter Defenses 

As mobile app security continues to evolve, so too do the capabilities of emulators and simulators. Our analysis of the Android and iOS ecosystems shows: 

  • Android emulators are becoming increasingly sophisticated, with stealth features that can mask build values, spoof hardware, and even bypass environment checks. 
  • iOS simulators, while more restricted, still expose detectable patterns — especially through system flags, architecture identifiers, and missing entitlements. 

These techniques highlight a crucial reality: basic detection methods are no longer enough. Reliance on static values like build fingerprints or model names offers limited resilience against attackers who now leverage advanced tools like Magisk, rooted containers, or custom virtual environments. 

This is where Cryptomathic MASC (Mobile App Security Core) delivers real value. 

MASC provides layered, runtime protection that goes far beyond basic checks: 

  • Detects and reacts to emulator behaviour dynamically — not just through static signatures. 
  • Validates integrity of the execution environment across both Android and iOS platforms.
  • Supports real-time threat responses, from session lockdown to telemetry alerts. 

While some organisations may attempt to build in-house emulator detection and runtime protection, the reality is that replicating MASC’s layered, cross-platform security would require extensive expertise, significant ongoing maintenance, and constant adaptation to emerging threats. 

Cryptomathic MASC eliminates these challenges by offering a proven, continuously updated security core — engineered by specialists, battle-tested across industries, and designed to evolve ahead of attackers. 

As threats grow in sophistication, security must be embedded at the core of your app — not bolted on after deployment. With MASC, financial and payment apps gain the resilience needed to defend against emulator-based fraud, reverse engineering, and unauthorized automation. 

Emulators may evolve — but your defences can stay ahead. 

Explore how Cryptomathic MASC can future-proof your mobile app security strategy. 

MASC DATA SHEETS

Tier 1 European Bank – Mobile Banking App

To meet customer demand, a large European bank launched a feature-rich mobile banking app for their retail customers. 

Read the case study