WHY MOBILE BANKING AND PAYMENT APP SECURITY NEED EMULATOR DETECTION?
-
INTRODUCTION
Using an emulator for the mobile operating system to execute and analyze the targeted application is a common first step in attacks against mobile banking and payment apps. Using an Android or iOS emulator is typically the initial step for an attacker, regardless of their goals—reversing the code, attaching a debugger, tampering with the program, etc. Also check detect emulators with web device fingerprinting
Therefore, stopping the protected program from operating in an emulator (simulated environment) is a key function of Runtime program Self-Protection (RASP) techniques. Effective emulator detection must be in place before a mobile app can be made to operate on an emulator.
We’ll find that there are several methods for identifying emulators, but there are also a lot of them available and growing. Several efficient methods for detecting Android emulators are examined in this article.
-
POPULAR ANDROID EMULATORS
- Android Studio’s emulator
- Andy
- ARChon
- Bluestacks
- Droid4X
- Genymotion
- KoPlayer
- MEmu
- Nox
- PrimeOS
- Remix OS Player
- Xamarin
- You Wave
- Arc Welder
- Droid Dolphin
- Bouncer
- Bare Droid
-
POPULAR IOS EMULATOR
- Smart face
- I Padian
- Appetize.io
- App.io
- Mobi One Studios
- Air iPhone
- X Code
- Remoted iOS simulator
-
ANDROID EMULATOR DETECTION TECHNIQUES
An emulator, virtual machine, hypervisor, and simulator are not the same thing. An emulator, which is typically quite sluggish, “emulates” the entire system, including the processor, in software. For virtualization to work, a physical CPU is needed in a virtual computer. A hypervisor is positioned “between” an emulator and a virtual machine. As implied by the name, a simulator functions more like a “stub” system that mimics than emulates.
The behavior and functionality of the original operating system are faithfully recreated by an emulator. Nevertheless, traces of it can still be found. Such artifacts can be found in the file system, network, or hardware, and their presence is the basis for the majority of emulator detection approaches.
4.1 BUILD VALUES
It may be easy to check for an emulator by reading the build values.
Programmatically, Android allows access to all of the following values, which frequently indicate the existence of an emulator:
- Build. FINGERPRINT
- Build. MANUFACTURER
- Build. MODEL
- Build. BRAND
- Build.DEVICE
- Build. PRODUCT
4.2 HARDWARE-BASED DETECTION
Examining hardware discrepancies can help identify the existence of an emulator. An emulator will also yield an IMEI check value of “000000000000000.” Similarly, the IMSI check, and so on, may be performed.
4.3 NETWORKING ENVIRONMENT CHECKS
Numerous clues that an emulator is present can be found on a network. The network cards’ MAC addresses could have certain values.
-
CONCLUSION
Beyond what we have covered here, there exists a plethora of other methods for detecting emulators.
Identifying an emulator within an Android or iOS environment is not the most challenging task for a RASP system in isolation. However, with the variety of emulators available and the resulting large margin of error, which can lead to significant False Acceptance Rates or significant False Reject Rates, it might be challenging. A mobile emulator detector may provide more accurate findings if machine learning is used on top of the tests.