Root and jailbreak detection without a black-box verdict

Collect the exact artifacts that were observable, preserve unavailable values, and let a calibrated backend interpret them with account and action context.

Inspect os_integrity fields Integration guide

Model detection as evidence

Root and jailbreak checks run inside an attacker-controlled client. A modified environment can hide files, intercept APIs, or change return values. Treat every hit as an observation and every miss as uncertainty, not proof that the device is safe.

Outcome	Meaning	Backend treatment
`success` with a path	The path was observable during collection.	Preserve the exact value and collection context.
`success` with an empty array	The check ran and found no matching items.	Do not translate it into trusted.
Optional field omitted	The value could not be read or does not exist on this platform.	Keep it missing.
`error` or `timeout`	Collection did not produce usable data.	Measure separately from a negative observation.

Android raw observations

The integrity probe can return discovered root-management or cloaking packages, artifact paths, dangerous system properties as exact key=value strings, writable system locations, mapped libraries, hook classes, suspicious stack frames, Frida threads, injector pipes, and debugger state. Modern catalogs cover Magisk, KernelSU, APatch, resetprop, Xposed-style hooks, Substrate-style hooks, and Frida artifacts.

A generic utility such as BusyBox is not converted into a root verdict. The SDK returns the concrete path or package observation so your backend can apply a documented interpretation.

iOS raw observations

On iOS the probe can report jailbreak and rootless-jailbreak paths, URL-scheme observations, suspicious environment variables, loaded dyld images, unexpected parent process context, writable locations, executable encryption state when available, reverse-engineering ports, and known bypass artifacts. Catalog entries include modern Dopamine, palera1n, TrollStore, ElleKit, and Frida families.

Sandbox and OS restrictions make many values unavailable on stock devices. Unavailable values are omitted rather than synthesized as false.

Collect a purpose-bound profile

import { consentFor, DeviceIntel } from "react-native-device-risk-signals";

const deviceIntel = new DeviceIntel({
  sessionId: actionId,
  consent: consentFor([
    "application",
    "os_integrity",
    "runtime",
  ]),
});

const event = await deviceIntel.collect();
// Send through your existing authenticated API client.

Collect close to the protected action. Use a short-lived server-created action ID and keep the SDK event separate from authenticated account identity.

Use the observations on the backend

Validate the stable event envelope and freshness.
Preserve the complete raw event and independent probe outcomes.
Join it to server-known account, session, action, and historical context.
Measure distributions and false positives on supported physical devices.
Introduce any policy only after calibration, monitoring, review, and recovery paths exist.

See the backend ingestion guide for Django, FastAPI, Express, and Go examples.

What this cannot prove

No client-side technique guarantees detection of every modified device.
No single path, package, port, or class proves malicious intent.
A clean observation does not establish device identity or integrity.
The SDK does not replace server-verified platform attestation.
The SDK does not calculate a risk score or make a blocking decision.