Skip to content
STIMSMITH

Anti-emulation

Concept WIKI v1 · 6/7/2026

Anti-emulation refers to techniques that detect the presence of a CPU or system emulator, typically to evade dynamic analysis and monitoring frameworks that rely on emulation. It is used both by malware authors (to hide malicious behavior from emulator-based analysis) and, as demonstrated by the Examiner work, by security researchers as a built-in capability of inconsistency-based detection between real devices and emulators.

Definition

Anti-emulation is the practice of identifying, fingerprinting, or otherwise discriminating against a software-based CPU or device emulator so that code executing on the emulator behaves differently from code executing on real hardware. It is a detection-avoidance technique most commonly associated with malware analysis resistance, but the term is also used to describe the deliberate (ab)use of hardware/software behavioral gaps to reveal an emulated environment.

Motivations

Dynamic analysis frameworks, fuzzers, and malware sandboxes frequently rely on CPU emulators (e.g., QEMU, Unicorn, Angr) because emulators provide fine-grained instruction tracing, full-system monitoring, and cross-platform scalability that hardware-based tracing (such as ARM ETM) cannot match [839351e1]. The implicit assumption of these tools is that an instruction's effect on the emulator is identical to its effect on the physical CPU. When that assumption breaks, two classes of problems arise:

  1. Defensive anti-emulation by malware. Malware probes for emulator-specific artifacts and, if detected, suppresses its malicious behavior, reducing the effectiveness of dynamic analysis.
  2. Offensive/analytical anti-emulation by researchers. The same behavioral gaps can be weaponized or studied to confirm that a sample is being run in an emulator.

Anti-emulation in Android Malware

In the Android ecosystem, anti-emulator techniques are a documented detection-avoidance measure. Malware programs attempt to identify the emulator and hide their activities from analysis tools built on top of emulators. Comparative studies have shown that dynamic feature extraction performed directly on a real Android device captures features that emulator-based extraction misses, and that roughly 24% more apps can be successfully analyzed on-device than in an emulator. Across multiple machine-learning classifiers, on-device dynamic analysis also yielded better detection performance than emulator-based dynamic analysis [arxiv:1703.10926].

Anti-emulation via Inconsistent ARM Instructions

The Examiner system (ASPLOS '22) systematically located inconsistent instructions—ARM instructions whose observable behavior differs between a real device and a CPU emulator (QEMU)—by generating 2,774,649 representative instruction streams using a symbolic execution engine for the ARM Architecture Specification Language (ASL) and differentially testing them across ARMv5, ARMv6, ARMv7-a, and ARMv8-a hardware against QEMU [arxiv:2105.14273, 839351e1, 2c03fcdd].

The paper explicitly identifies anti-emulation as one of three security applications built on top of the discovered inconsistencies, alongside emulator detection and anti-fuzzing [2c03fcdd]. By (ab)using an inconsistent instruction, a program can:

  • Detect that it is running inside a CPU emulator rather than on real hardware, and
  • Refuse to exhibit monitored behavior, thereby undermining dynamic analysis frameworks that emulate the program [2c03fcdd].

The root causes of these exploitable inconsistencies are twofold: undefined implementation choices in the ARM architecture manual and implementation bugs in emulators such as QEMU [arxiv:2105.14273, 839351e1]. The Examiner work reported the discovery of 12 emulator bugs (four of which were confirmed and patched by QEMU developers) affecting commonly used instructions such as BLX and STR [839351e1, 2c03fcdd].

Implications

Anti-emulation has practical consequences for both attackers and defenders:

  • For malware analysts: Emulator-based sandboxes and dynamic analysis pipelines must account for instructions that diverge from hardware behavior, since malware can use these as tripwires.
  • For emulator developers: Patching inconsistencies reduces the surface available for anti-emulation but does not eliminate it, because a portion of the gaps stem from architecturally undefined behavior rather than implementation defects.
  • For defenders: Real-device dynamic analysis sidesteps a large class of anti-emulation triggers, which is the empirical justification for the on-device detection approach studied in the EMULATOR vs REAL PHONE work [arxiv:1703.10926].

LINKED ENTITIES

2 links
Examiner: Automatically Locating Inconsistent Instructions between Real Devices and CPU Emulators for ARM MENTIONS
inconsistent instructions USES

CITATIONS

6 sources
6 citations
[1] Anti-emulation is one of three security applications (alongside emulator detection and anti-fuzzing) that the Examiner system builds on top of inconsistent ARM instructions to demonstrate the practical impact of emulator/real-device divergence. Examiner: Automatically Locating Inconsistent Instructions between Real Devices and CPU Emulators for ARM
[2] Software-based CPU emulation is widely adopted by dynamic analysis frameworks (e.g., QEMU, Unicorn, Angr) and by fuzzers (e.g., AFL's QEMU mode, Unicornfuzz, FirmAFL, HALucinator) because it offers full instruction tracing, runtime instrumentation, and cross-OS portability, in contrast to hardware tracing which is limited by small on-chip trace buffers such as the 64KB ETB on the Juno board. Examiner: Automatically Locating Inconsistent Instructions between Real Devices and CPU Emulators for ARM
[3] Undefined implementation in the ARM architecture manual and implementation bugs in emulators are the two major root causes of inconsistent instructions, and the authors reported 12 emulator bugs (some in commonly used instructions like BLX) discovered via this differential testing approach. Examiner: Automatically Locating Inconsistent Instructions between Real Devices and CPU Emulators for ARM
[4] Sophisticated Android malware employ anti-emulator techniques to detect emulators and hide malicious behavior, and countermeasures against anti-emulation are increasingly important in Android malware detection. EMULATOR vs REAL PHONE: Android Malware Detection Using Machine Learning
[5] On-device (real-device) dynamic analysis of Android malware extracts more effective features than emulator-based analysis, successfully analyzes approximately 24% more apps, and yields better machine-learning detection performance across the studied classifiers. EMULATOR vs REAL PHONE: Android Malware Detection Using Machine Learning
[6] Differential testing of 2,774,649 representative ARM instruction streams against QEMU and real devices across ARMv5/v6/v7-a/v8-a located 155,642 inconsistent instruction streams covering 30% of instruction encodings and 47.8% of instructions, and the authors build three security applications—emulator detection, anti-emulation, and anti-fuzzing—on top of them. Automatically Locating ARM Instructions Deviation between Real Devices and CPU Emulators