Moatgator Runtime
Know when your app is under attack, and decide what happens.
Runtime checks inside the app detect hostile environments and respond the way your policy says: monitor, warn, block or end the session.
Detection that lives inside your app.
Root, emulators, debuggers, hooking and tampering are how most mobile fraud starts. Runtime looks for them while the app is running, and your policy decides the response.
- Monitor, warn, block or end the session, per detection
- Policies versioned in your repo
- Every detection starts in monitor mode
What Runtime detects
01
Root and jailbreak
su binaries, root managers, writable system partitions and jailbreak artifacts, where the protections of the operating system are gone.
02
Emulators and virtual devices
Emulator and virtualization fingerprints, the setup behind device farms that automate abuse at scale.
03
Hooking and instrumentation
Frida server and gadget, Xposed and similar frameworks rewriting the behavior of your app while it runs.
04
Debuggers and tracing
Debuggers and tracers attached to the running app, and debuggable builds circulating in the wild.
05
Tampering and repackaging
Signature mismatches, modified code and re-signed copies of your app running on someone else's device.
06
Policy and remote control
Choose the response per detection and, on supported plans, change it with a signed remote policy, without a new release.
From first build to enforcement
- 1
Define policy as code
Declare what to detect and how to respond in moatgator.yml, reviewed in a pull request like any other change.
- 2
Start in monitor mode
The app reports what it would have done and takes no action, so you see the real-world impact before you enforce anything.
- 3
Enforce with confidence
Move each detection to warn, block or end session. Turn one off remotely with a signed policy if it ever misfires.
runtime: # monitor | warn | block | end_session mode: monitor detect: root_jailbreak: warn hooking: block # Frida, Xposed debugger: block emulator: warn tamper: end_session remote_policy: signed # no release neededDetection catalog
The signals Runtime evaluates, grouped by the attack they point to.
Environment
- Root and jailbreak indicators
- Emulators and virtual devices
- Unsafe device state
Instrumentation
- Frida server and gadget
- Xposed and similar frameworks
- Hooked system functions
Debugging
- Attached debugger
- Process tracing
- Debuggable builds
Integrity
- Signature verification
- Modified application code
- Re-signed and repackaged copies
Screen and input
- Overlays on sensitive screens
- Accessibility-service abuse
- Screen capture and recording
- Remote-access tools
Frequently asked questions
Does Runtime need an SDK?
No SDK to integrate. The checks are added to your build by the pull request, and the policy lives in moatgator.yml.
What does monitor mode mean?
The app reports what it would have done but takes no action, so you can see the real-world impact before you enforce anything.
What happens when a detection fires?
Your policy decides: log it, warn the user, block the action or end the session. Every event is also reported to Pulse with context.
Can I change a policy without releasing a new version?
Yes. A signed remote policy lets you turn a detection down or off without shipping a new build.
Does it detect Frida?
Yes: Frida server and gadget, and the hooking of functions in your process. No single detection is perfect, which is why Runtime layers several signals and pairs with Shield.
Which detections does each plan include?
The free plan includes five detections in monitor and warn modes. Paid plans include all detections in every mode, and Scale and Enterprise add Pix Shield.
Ready to protect your app?
Start free, or tell us what you need.