Verisoul Mobile SDK Signals
Last updated: May 25, 2026
Mental Model for Mobile SDK Signals:
Data (raw facts the device tells us) → Risk Signals (interpretations we derive, grouped by risk factor) → Scores (aggregated 0–100 risk numbers used in decisioning).
How to read this page
Layer | What it is | Example |
|---|---|---|
Data | Raw facts collected from the device - actively or passively. | Screen size, OS version, GPS coordinates |
Risk Signals | Booleans/enums derived from raw data, grouped by risk factor. | VPN tunnel, mock location, emulator |
Scores | 0–100 risk numbers per category, combining many signals. | Device Risk, Location Risk, Automation Risk |
Direct integrations with Apple and Google
We have direct integrations with Apple and Google and operate them on your behalf to get hardware-backed data from the OEMs. We validate hardware, app installation validity, and device uniqueness from the OEM data.
This is the foundation that makes Verisoul's mobile SDK more trustworthy than fingerprinting-only vendors. We talk directly to the OS-level attestation services Apple and Google provide, and we hold device identity in OS-protected storage. We operate these on your behalf and have our own extremely high rate limits.
Apple — App Attest
Apple's hardware-backed attestation. The Secure Enclave produces a cryptographic key tied to this app on this physical device. Verisoul validates the assertion against Apple's servers, so we can be sure the app binary hasn't been tampered with and is running on a genuine Apple device. Guaranteed hardware validity.
Apple — DeviceCheck
Apple's lighter-weight per-device flag system. Two bits of state Apple persists for us about a device — survives reinstalls. Useful for marking devices we've seen abuse from previously. Pairs with App Attest for device validation.
Apple — IDFV stored in Keychain
identifierForVendor is Apple's per-vendor device ID (fingerprint). We pin it in the iOS Keychain, which persists across app deletes/reinstalls on the same device — defeating the most common reset attack.
Google — Play Integrity API
Google's equivalent attestation. Validates the app (Play-recognized, correct cert), the device (basic / strong hardware integrity), and the account (licensed). The strongest available MEETS_STRONG_INTEGRITY verdict means the device passed Google's hardware-backed checks. Validates hardware.
Data
Raw facts collected from the device each session. Everything below is observed by the SDK without interpretation. Where a field exists on both platforms we list it once under iOS + Android (both).
Device Hardware
Field | Platform | What it is |
|---|---|---|
OS version | Both | The reported operating system version string (e.g., iOS 26.3.1, Android 15). |
SDK version | Both | The Verisoul Mobile SDK version embedded in the app. |
Is simulator / emulator | Both | Whether the device reports itself as a simulator (iOS) or emulator (Android). |
Device ID | Both | Stable device identifier. On iOS this is IDFV pinned in the Keychain. On Android this is the combination of App Set ID and Android ID. |
Screen height | Both | Viewport height of the device's screen. |
Screen width | Both | Viewport width of the device's screen. |
GPU | Both | The reported GPU (e.g., Apple A18 GPU). Strong hardware fingerprint. |
System memory | iOS | Total physical RAM available on the device. |
Brand | Both | The manufacturer brand (e.g., Xiaomi, Samsung, Google). On iOS this is always Apple — on Android it varies and is central to device-tampering checks. |
Model | Android | The hardware model (e.g., CMA-LX1) |
Display name | Android | The build display name (e.g., AP3A.240905.015.A2). Identifies the specific OEM/carrier build. |
Build board | Android | Hardware board identifier (e.g., citrine). Cross-checks against brand and model to detect spoofed builds. |
Device Features
Field | Platform | What it is |
|---|---|---|
Biometric enabled | iOS | Whether Face ID / Touch ID (iOS) or fingerprint / biometric auth (Android) is enrolled on the device. |
Assistive touch | Both | OS-level accessibility feature for users who have trouble with normal touch input. |
Debugger | Both | Whether a debugger is currently attached to the app process. |
Developer Settings | Both | Detects potential tampering or development while app is open. |
Device Status
Field | Platform | What it is |
|---|---|---|
Battery state | iOS | Charging, unplugged, full, or unknown. |
Battery level | iOS | Current charge level from 0.0 to 1.0. |
Brightness | iOS | Current screen brightness from 0.0 to 1.0. |
Active processor count | iOS | Number of CPU cores currently active. |
Low power enabled | iOS | Whether low-power / battery-saver mode is turned on. |
System uptime | Both | Time elapsed since the device last booted. |
Thermal state | iOS | Nominal, fair, serious, or critical — how hot the device is running. |
Orientation | Both | Portrait or landscape. |
Boot count | Android | Lifetime reboot count for the device. |
Boot reason | Android | The recorded reason for the device's most recent reboot. |
User Number | Android | Typically 0 - anything else often indicates app cloning |
File Directory Dot Count | Android | Higher than normal values can indicate app cloning or virtualization. |
Device Location & Timezone
Field | Platform | What it is |
|---|---|---|
GPS coordinates | Both | Latitude and longitude, when the user has granted location permission. |
Locale region code | Both | The configured region (e.g., US, CA, FR). |
Languages | Both | The user's preferred system languages, in order. |
Daylight savings | iOS | Whether DST is currently in effect for the device's timezone. |
Auto timezone | Android | Whether the device is configured to set its timezone automatically. Manual settings are a common indicator of spoofing. |
Simulated Location | Both | Detects if location coordinates are being simulated by mock location or software. |
Network
Field | Platform | What it is |
|---|---|---|
Connection type | Both | WiFi, cellular, or none. |
Remote endpoint | Both | The remote address of the active network route. |
device_proxy_configured | Both | Detects presence of proxy at the device networking level. |
OEM Validation
Field | Platform | What it is |
|---|---|---|
App Attest available | iOS | Whether Apple's App Attest is supported on this device. Required for the strongest iOS trust signal. |
DeviceCheck available | iOS | Whether Apple's DeviceCheck is supported on this device. Required for Apple-persistent device reputation. |
App recognition verdict | Android | Confirms whether Google sees the app as the genuine Play Store binary. |
App licensing verdict | Android | Confirms the install is legitimate. |
Device recognition verdict | Android | Google's hardware-backed device verdicts. |
Risk Signals
Signals derived from the data that indicate risky activity or behavior.
Emulator, Jailbreak & Root
Is the device a real, untampered physical phone?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
iOS simulator or jailbreak |
| iOS device is a simulator, jailbroken, has a debugger attached, or shows clear jailbreak/sandbox-tampering indicators. | Strong evidence that this is not a normal, untampered iPhone. |
Android emulator, root, or tampered build |
| Android device is rooted, an emulator, or carries a known test-keys / debug build fingerprint, or its network interfaces match an emulator signature. | The strongest indicator that this isn't a real, untampered Android device. Fraud farms run almost exclusively on these. |
OEM App Integrity
Is the app binary running on this device the one we shipped, and was the install legitimate?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
iOS app integrity failed |
| Apple App Attest verification failed or DeviceCheck returned an invalid token. | Apple itself is telling us this isn't the genuine app on a genuine device — or there's no way to cryptographically prove it. |
Android app not Play-recognized |
| Play Integrity does not recognize the app as the genuine Play-distributed package/certificate/version. | Indicates a repackaged, sideloaded, tampered, or non-production APK. |
Android app not licensed |
| Play Integrity account/app licensing verdict is not licensed. | Indicates the install may not be legitimate for the Google account/device context. |
Android device integrity failed |
| Play Integrity does not return expected device integrity verdicts. | Indicates the device failed Google’s integrity checks, often due to emulator, root, bootloader, or unsupported integrity state. |
Android strong integrity missing |
| Device does not return | The device may still be usable, but lacks the strongest hardware-backed integrity proof. |
VPN / Proxy Tunnel
Is the user's network origin being hidden or manipulated?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
VPN or tunnel active |
| Device appears to be routing traffic through a VPN, tunnel, private relay, or similar network path. | The visible IP may not reflect the user’s true network origin. Common in geo-fraud, multi-account abuse, and bot infrastructure. |
Active Proxy configured |
| A manual proxy, HTTP proxy, or automatic proxy configuration appears to be enabled. | Traffic may be routed through an interception or masking point, which is common in scraping, automation, and MITM setups. |
Reported network doesn't match actual routing |
| The device claims one network type (WiFi or cellular) but the actual routing disagrees. | Suggests an overlay tunnel or virtualized network — common in emulator farms and tethered VPNs. |
Anomalous active routing interface |
| Active routing uses an unusual or unexpected interface category for the device state. | May indicate deliberate traffic redirection through a tunnel, VPN, proxy, relay, or virtual interface. |
Location Spoofing
Is the claimed location believable?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
Location Simulated |
| iOS or Android reports that the location data is software-simulated. | Direct evidence of GPS spoofing — common in promo abuse, geo-restricted services, and account-region fraud. |
Low GPS accuracy |
| Reported GPS accuracy is poor (e.g., >50m). | Unreliable on its own and often correlates with indoor/cellular-only location, spoofers, or stale fixes. |
IP geolocation doesn't match device GPS |
| IP geolocation and device GPS disagree significantly. | One of them is misrepresenting where the user actually is. |
Stale GPS reading |
| The GPS timestamp is far older than the session. | A cached or replayed location, not a live reading. |
Timezone doesn't match GPS region |
| The device timezone doesn't match the GPS region. | A device set to one region but physically located elsewhere — common in spoofed accounts and bot setups. |
Device Farm Signals
Is this device part of a fleet running many automated sessions?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
Implausible uptime |
| Uptime values fall outside human-reasonable bounds — never reboots, or impossible jumps between sessions. | Real users restart their phones occasionally. Farms either keep devices permanently powered or reset them constantly. |
Abnormal reboot profile |
| The device has rebooted an unusual number of times relative to its age and uptime. | Common in reset farms that wipe and re-image devices between accounts. |
Low/no sensor data or spatial movement. |
| Motion sensors (accelerometer, gyro, magnetometer) report no variance across the session. | Real phones are touched, picked up, and tilted constantly. A flat signal means the device is sitting in a rack or running headless. |
Stationary behavior |
| No XYZ motion across an extended session, even though the user is supposedly active. | Same as above — devices in farms don't move. |
Device Tampering
Does the device's reported identity make internal sense, or is it pretending to be something it isn't?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
iOS hardware or environment anomaly |
| iOS device reports internally inconsistent hardware, GPU, memory, screen, uptime, process, network, or sandbox/environment characteristics. | A genuine iPhone should have internally consistent hardware and OS behavior. Mismatches suggest spoofing, instrumentation, or nonstandard runtime. |
Android device anomaly |
| Build fingerprint, board, product, model, manufacturer, ABI, or release-key/test-key metadata is internally inconsistent or suspicious. | Suggests a spoofed device fingerprint or an imported device that wouldn't normally exist in this market. |
Device characteristic mismatch |
| Reported identity (model, brand) doesn't internally agree with other characteristics — GPU class, screen dimensions, sensor list, memory. | A genuine iPhone 16 reports a specific screen and an Apple A18 GPU. If those don't match, the model string is spoofed. |
Hardware / location mismatch |
| Hardware/OEM/carrier/locale combination is unusual or implausible. | Suggests a spoofed device or location fraud. |
Auto Time is disabled |
| User has turned off automatic timezone or auto time matching. | May indicate location spoofing or device tampering. |
App Cloning / Virtual App
Is the app running inside a normal install, or inside a clone container?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
App running inside a clone or virtual container |
| App is running inside a clone / dual-space / virtual-app container (Parallel Space, DualSpace, etc.). | These containers let one device run multiple copies of the app simultaneously, each with separate identities — a textbook multi-accounting setup. |
Developer Settings & Debuggers
Is the device in a state suitable for tampering, scripting, or interception?
Signal | Signal Name | What | Why it's risky |
|---|---|---|---|
Developer or Debugger settings enabled |
| ADB debugging is on, developer settings are enabled. | Required surface area for ADB control, USB debugging, mock locations, and most on-device tampering. |
Scores
Scores are 0–100 where higher = riskier. Each combines multiple risk signals with weights and outputs reason codes so analysts can see what fired.
Device Risk
Question: Is this a trustworthy, real, untampered device?
Heaviest contributors: simulator/jailbreak/root, hardware anomalies, build anomalies, device characteristic mismatches.
App Integrity Risk
Question: Is the app binary running on this device the one we shipped?
Heaviest contributors: App Attest / DeviceCheck failures, Play Integrity app/device/account failures, app cloning.
Network Risk
Question: Is the user hiding or manipulating their network origin?
Heaviest contributors: VPN/tunnel, proxy, routing mismatch, unusual active interface, server-side IP intelligence.
Location Risk
Question: Is the claimed location believable?
Heaviest contributors: simulated location, stale/low-accuracy GPS, IP/GPS mismatch, timezone/GPS mismatch.
Automation Risk
Question: Is a real human using this device, or is it scripted?
Heaviest contributors: flat sensors, stationary behavior, abnormal uptime/reboot profile, emulator/root/debugger signals.
Identity / Account Linkage Risk
Question: Is this device/account relationship suspicious?
Heaviest contributors: many accounts per device, many devices per account, reinstall linkage, clone/virtual-app indicators.
Glossary
App Attest — Apple's hardware-backed attestation that proves an app binary is genuine and running on a real Apple device.
DeviceCheck — Apple's per-device two-bit flag store, persisted by Apple across reinstalls.
IDFV —
identifierForVendor. Apple's per-vendor device ID. Verisoul pins it to the iOS Keychain so it survives reinstalls.Keychain — iOS's encrypted credential store. Entries persist across app deletes/reinstalls on the same device.
Play Integrity — Google's attestation API. Returns verdicts on app, device, and account integrity.
MEETS_STRONG_INTEGRITY — The highest Play Integrity device verdict. Hardware-backed.
App Set ID — Google's per-developer-account device identifier. Stable across apps from the same developer.
Android ID — Per-(device, app-signing-key, user) identifier on Android.
utun / ipsec interfaces — iOS tunnel interfaces. Their presence usually indicates a VPN or system tunnel.
App cloning — Running a second copy of an app inside a virtual-space sandbox (Parallel Space, DualSpace, etc.). Detected via filesystem path patterns.
Mock location — A GPS location injected by software rather than read from the GNSS receiver.
Sensors flat — A session where motion sensors report identical or zero values throughout — a strong indicator of automation.