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).
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
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
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.
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
