POST /referral/claimBlockedEmulated phone, one of 22 on one PC
- Android emulator, no real sensors
- Desktop graphics in a phone
- Linked to 21 referral accounts
Detection
An emulator is software that imitates a phone on a desktop computer, most often an Android device, so apps and mobile websites run as if on a real handset. Fraud teams run dozens of instances at once to fake new phones for every account. Kavra spots the desktop behind the phone by checking sensors, hardware and network against the device claimed.
POST /referral/claimBlockedEmulated phone, one of 22 on one PC
A mobile emulator is a program that runs a virtual phone inside a desktop computer. The best-known kind emulates Android: the operating system boots in a window, apps install from an app store or a file, and a mouse stands in for a finger. Some are official developer tools. Others are built for playing mobile games on a PC and ship with features for running many phones side by side.
Apple's iOS Simulator is a related but narrower tool. It runs only on a Mac, inside Apple's developer tools, and runs apps built for testing rather than regular App Store apps. That limits it for abuse inside iOS apps, but it can still load mobile websites in a Safari that reports itself as an iPhone. Desktop browsers also have a mobile preview mode that changes screen size and user agent. That is not a full emulator, but fraudsters use it the same way: to look like a phone without owning one.
The three are easy to mix up. They leave different traces.
| Emulator | Virtual machine | Real device farm | |
|---|---|---|---|
| What it fakes | A phone, on a desktop | A computer, on a server or PC | Nothing: real phones, one operator |
| Hardware underneath | Desktop processor and graphics, simulated phone parts | Virtual hardware of the same kind as the host | Genuine phone hardware |
| Typical target | Mobile apps and mobile websites | Desktop websites and web apps | Apps that check for real devices |
| Cost per extra device | Almost nothing: another instance | Low: another clone | High: another handset |
| Main tells | Missing or flat sensors, desktop graphics, no carrier | Virtual graphics, generic hardware, cloud network | Many phones, one location, one behavior |
| Learn more | This page | Virtual machines | Device farms |
An emulator farm is one or a few desktops running many virtual phones at once, controlled by scripts.
A multi-instance manager starts dozens of Android phones on one machine, each cloned from a prepared image with the target app installed.
The operator changes the model name, device IDs, phone number, location and language of each instance, so every one claims to be a different handset.
Each instance gets its own mobile or residential proxy to look like a phone on a carrier network. See residential and mobile proxies.
Macros or automation tools tap through signup, request the SMS code, enter referral codes and claim offers, identically on every instance.
Instances are reset or recreated. Each new run shows up as a phone your app has never seen before.
Mobile-first businesses often trust the app more than the website. Emulators exist to exploit that trust at desktop prices.
An emulator can copy the model name of any phone. Copying the physics of a real phone in someone's hand is much harder.
No motion sensors, or readings that are flat, repeated or perfectly still. A real phone in a hand is never completely still.
A desktop processor architecture or desktop graphics chip behind a device that claims to be a mid-range Android phone.
Always plugged in, always the same level, or no battery at all. Real phones drain, charge and vary.
The claimed model, screen size, pixel density and system build do not line up with how that handset ships.
A phone with no carrier, on home broadband or a datacenter, or on a proxy whose location disagrees with its settings.
Taps with no pressure or contact size, pixel-perfect positions and swipes that move like a mouse drag.
Older emulators were obvious: a generic model name, a telltale build tag, a fixed phone number. Modern gaming emulators and fraud tooling change all of these, and root-level tools can rewrite almost any value an app asks for. Checks that read one property and compare it to a list are defeated in a single update.
What operators cannot easily fake is a coherent physical device. Sensors, battery, graphics, processor, touch input and network all have to agree with each other and with the model claimed. Across twenty instances on one PC, they also tend to agree with each other far too well. Detection that compares layers, and links instances that share an underlying machine, holds up when single checks fail.
Emulators are everyday tools. App developers and QA teams test on them constantly. Gamers play mobile titles on a PC for a bigger screen and a keyboard, and in some markets that is a large share of a game's audience. Some people use an emulator for accessibility or to run an app that has no desktop version.
Blocking every emulator would lose those customers. A better policy separates being an emulator from pretending not to be one, and weighs both against the action.
How Kavra helps
Kavra analyzes 3,000+ data points on every visit, in your mobile website and through native iOS and Android SDKs, and tells your backend when a phone is not a phone.
In-app checks see device details a web page cannot, so emulated handsets are caught inside your app as well as on your mobile site.
Sensors, power, graphics, processor and touch input are compared with each other and with the claimed model.
Many phones that share one underlying desktop are grouped as one actor, so a farm shows up as a cluster, not as strangers.
An instance that resets and returns with new IDs is kept as the same actor with each rotation counted.
Kavra measures real exit IPs of commercial mobile and residential proxies, so a fake carrier connection does not pass as a real one.
Emulators are weighed, not auto-blocked. Set rules per action and let honest gamers and developers keep playing and testing.
FAQ
Something else? Talk to our team.
Yes. An app can read far more than a web page: sensors, battery, hardware, system build and how touches arrive. Emulators differ from real phones on many of these at once. Tools that spoof one value, such as the model name, rarely fix the rest, so an in-app SDK that compares them catches most emulated devices.
No. Android emulators are legal and widely used by developers, testers and gamers. Using one to break a service's terms, for example creating many accounts to claim referral rewards or faking a location, can lead to bans, withheld rewards and in some cases fraud claims. The tool is neutral; the use decides.
They use multi-instance emulator managers that start dozens of virtual Android phones on one PC, each cloned from a prepared image. Scripts or macros then tap through the same flow in every instance, while each one exits through its own proxy. The result looks like many new phones in many places.
Yes. Emulators let the user set any location, and the app receives it as if it came from GPS. That is why location alone should never be trusted. Compare it with the network, timezone, language and the device's own history. A phone in one city on a proxy from another, with no motion at all, is a strong warning.
Often. The iOS Simulator runs on a Mac, so the page is really rendered by a desktop with Mac graphics and no phone sensors, even though it reports an iPhone. Screen, graphics, touch and motion details reveal that mismatch. Most iOS app abuse uses real devices instead, which is where device farm detection comes in.
Usually not. You would lose developers, testers and gamers who play on PC, and a determined operator would move to real phones anyway. Detect emulators, then decide per action: allow browsing and play, and step up or refuse at signup rewards, referrals, promos and withdrawals when the emulator also hides what it is.
Run Kavra on your own traffic in observe-only mode. No risk to your customers, and a clear report of the fraud it finds.