Rooted and jailbroken devices: what they mean for fraud, and what to do about them.

Root detection and jailbreak detection tell you that the phone running your app has been opened up by its owner, which removes some of the protections your app quietly relies on. The signal is a reason to look closer, not proof of fraud, and the real work is the decision: what your app should do when it finds one.

This explainer covers what rooting and jailbreaking are, what Fingerly’s native SDKs and server genuinely report, where on-device checks fall short, and a policy for acting on the answer. For the wider landscape of emulators, clones and tampering, see the mobile app fraud playbook.

#What are rooted and jailbroken devices?

Rooting an Android phone and jailbreaking an iPhone both mean gaining control that the manufacturer deliberately withholds. The owner, or whoever prepared the device, can then read and change parts of the system that apps normally cannot, install tools that hook into other apps, and hide their own presence.

Many people do this for innocent reasons: customisation, research, or a developer who tests on their own phone. Fraudsters do it because a modified device lets them change what an app sees, fake a location, bypass in-app checks and automate actions. The same state, two very different owners.

#Why does it matter for app fraud?

Because your app runs in an environment the user controls, and on a rooted or jailbroken device that control reaches the system itself. Anything the app reports can be altered, and anything it stores can be read. That matters most where a fraud pays: account takeovers from a compromised phone, reward farming, promo abuse, and payments and transfers made in a mobile banking or wallet app.

This is mobile app security in the practical sense. You cannot make a hostile device safe, but you can know when you are on one and adjust what you allow.

#What do the Fingerly SDKs actually detect?

The native SDKs report raw observations, and the server derives the findings and scores them with your weights. Today that includes the following.

• Android: a rooted device. The SDK also checks for a short fixed list of well-known root, hooking and cloning packages. It reports only whether they are present, never the names of other apps on the phone, and it never asks for permission to list every installed app.
• iOS: a jailbroken device, including rootless jailbreaks. You can also let the SDK check for well-known jailbreak apps by declaring their URL schemes, and it then reports only how many answered. With none declared, the report says it could not ask, so a zero is never read as nothing found.
• Both platforms: an emulator or simulator, instrumentation attached to the app, intercepted traffic, a failed app integrity check, and a device that looks provisioned for bulk use.
• Attestation: hardware-backed attestation on Android 7.0 and newer, and App Attest on iOS 14 and newer on a real device. A failed check raises the tampering finding, and the attestation state is recorded as attested, not attested or failed.

Fingerly recognises an app install by a random install ID the SDK keeps for the app, never by the phone’s hardware. The device checks above are used to detect jailbreaks, emulators and similar, not to identify a person.

#How reliable are root and jailbreak checks?

Reliable enough to inform a decision, never enough to decide alone. Tools exist whose purpose is to hide a rooted or jailbroken state from apps, and an on-device check can be fooled by something that controls the device. A report that says a device is clean from a phone that is not under your control is a claim, not a fact.

This is why Fingerly sends the app’s observations to the server, which makes every decision, and why hardware attestation matters: a key held in the device’s security hardware vouches for the app, and the server checks the proof itself. A device that offers no proof is not proven guilty, and a modified app can still forge everything outside the attestation. Attestation raises the cost of forging a report. It does not make forgery impossible.

#Is every rooted device a fraud risk?

No. Tinkerers, developers and security researchers run rooted phones and jailbroken phones, and refusing all of them turns away some of your most engaged users. Weight the signal by what the user is doing, and combine it with the rest of the evidence.

A rooted device that has used the same account for a year, on a familiar network, is a different case from a rooted device that is new, in an emulator, behind a proxy, and opening its fifth account today. Fingerly’s signals are weighted and additive for exactly this reason, so no single one has to carry the verdict.

#What should your app do when it finds one?

Decide by action, not by device. Reading an article on a jailbroken phone carries no risk; moving money from one does. A starting policy, to tune on your own traffic:

• Browsing and low-stakes actions: allow, and record the finding.
• Signup and reward claims: allow with verification, and withhold benefits until it passes.
• Login on a device the account has never used: ask for a second factor.
• Payouts, transfers and new payees: step-up authentication, or manual review for larger amounts.
• Rooted or jailbroken together with instrumentation, intercepted traffic or an emulator: refuse the sensitive action, and tell the customer to contact support.
• Unattested devices: do not treat them as modified. Require attestation on a key only once every device you serve can provide it.

On the server, read the stored event by request ID with a secret key and check that it exists, is recent, matches the action and has not been used before. Never read an absent score as clean: it is absent both when a request was not scored and when your key hides it.

#How do you roll it out without losing legitimate users?

Observe first. Log what each decision would have been for a week or two, look at who it would have affected, and adjust the weights before you enforce anything. Start with the gentle responses such as verification, keep an appeal route and a support path, and publish plainly what your app will not do on a modified device so that no one is surprised. If identification fails or the device cannot attest, decide with less information, not with a refusal.