Detection · live

Backdoor scanner

The backdoor scanner audits the resources actually running on your server. It runs off-path on a schedule, so it never blocks gameplay; findings land in the dashboard for operator review. The deeper companion to the always-on Server analytics view.

What it protects against

The realistic threat is a malicious resource: dropped via a compromised dependency, included as a copy of a paid resource from a leak, or shipped by a member of the team who shouldn't have commit access. The scanner doesn't try to perfectly classify every resource as good or bad — it surfaces ones that look statistically off, and lets the operator decide.

How the scan works

Each finding has to survive three layers before it surfaces. The full architecture is on the False positives page; the short version for this scanner is:

Pattern detection on every started resource, run on the FiveM server itself. Fast, by design noisy.
Whitelist-first filter — hits inside known-clean frameworks (ESX, QBCore, ox-/qb-family, pma- and similar add-ons) and inside config files are filtered, unless the pattern belongs to the always-suspicious class (code execution, obfuscation, hardcoded exfiltration endpoints, anti-AC tampering).
In-house AI severity grading on the surviving findings, classifying them into low / medium / high severity. Outage is fail-silent — findings reach the dashboard with a "grading…" badge and you can act before grading completes.

The grading runs on our own EU GPU server. Repeated snippets from standard frameworks are cached: the first time we grade an ESX or QBCore snippet, it's cached for every subsequent customer who hits the same snippet. That's also why the SHA-256 snippet-hash corpus matters — see the page on false positives for what we keep and what we don't.

Modes

The scanner is alert-only today: it never disables or removes a resource. Verdicts land in the dashboard and (if configured) post to a Discord webhook. The mode column therefore describes how strongly an alert is surfaced, not what gets executed.

Mode	Behavior
`observe`	Findings are written to the audit log and the dashboard's Resource hygiene tab. No notifications.
`score`	Same as observe, plus a Discord-webhook notification if a webhook is configured. Useful for operators who want to be paged on findings.
`enforce`	Reserved. The scanner does not yet take automatic action against a resource — that will require explicit opt-in and a review queue.

Verdicts

Verdict	What it means
`cleared`	Resource passed the scan. Either it's on the curated framework whitelist, or its content didn't match anything that survived all three filtering layers.
`high_risk`	The scan surfaced patterns strong enough to warrant operator review and the in-house severity grading classified them as elevated. Action stays manual — we don't auto-disable resources.
`whitelisted`	Operator (or hoaxeye) marked this resource trusted. Whitelist entries are visible in the audit log with the reason.

Auto-alert on risk crossing

When a resource crosses into the high_risk bucket, the dashboard surfaces a banner at the top of the Resource hygiene tab. Edge-triggered (one alert per crossing, not per scan), with a one-hour cooldown to avoid spam during noisy scan windows. This works in tandem with the always-on Server analytics view, which tracks the same resource over time without the deeper backdoor-pattern pass.

Cadence & scope

03:00 – 05:00 UTC

Scan window

Daily slot inside which a server's scan can fire. Picked to land outside peak hours for the EU/NA player base.

3 days

Per-server cooldown

A server is not re-scanned until ~72 hours have passed since its last completed scan, so we don't pile up redundant work.

started resources

Scope

Only resources currently in a started state at scan time. Stopped resources are skipped — they can't backdoor anything that isn't running.

0 / 59 resources

Recent clean run

Smoke run on a representative test server (59 started resources). Zero findings — the expected outcome for clean servers under the current design.

Methodology: the clean-run number is from a real test server, not a synthetic benchmark. With a real backdoor planted in a framework resource as a validation, the same pipeline cleanly detected it at high severity.

False-positive history

The scanner went through three iterations to get to its current shape. The numbers below are real, not aspirational — measured on the same 59-resource representative test server across all three iterations.

Iteration 1Plain pattern matching

50 findings · ~100% FP

Iteration 2Framework whitelist + refinement

20 findings · ~100% FP on helpers

Iteration 3 (current)Always-suspicious split + AI grading

✓ 0 findings · planted backdoor still detected at high severity

Bar width is proportional to false-positive count. The current iteration produces zero findings on a clean server while still cleanly detecting a planted backdoor.

First iteration — plain pattern matching. Ran patterns against every started resource on a representative test server. Result: ~50 findings, every single one a false positive against framework internals (the same APIs frameworks use legitimately also appear in malicious code). Lesson: pattern matching without resource context is unusable on FiveM.
Second iteration — framework whitelist plus pattern refinement. Curated framework list filtered the obvious noise; broad-fire patterns were tightened. Result: ~20 findings, all helper or asset patterns inside framework resources or config files (imports, file I/O, base64-embedded assets). Lesson: a whitelist alone isn't enough.
Third iteration (current) — always-suspicious split plus config-file filter plus AI grading. Patterns that are suspicious anywhere (code execution, obfuscation, hardcoded exfiltration, anti-AC tampering) survive the whitelist. Patterns that are only suspicious outside frameworks/configs get filtered there. In-house AI grades the survivors. Result: 0 findings on the same 59-resource test server, with a real planted backdoor cleanly detected at high severity.

If a custom resource you ship is repeatedly flagged, the right answer is to whitelist it explicitly via the dashboard — not to disable the scanner. Whitelist entries are audited; they don't go missing on you. See False positives for the bigger picture.

Operator recommendation

All server types: leave the scanner running on the default cadence. Subscribe its Discord webhook to a private operator channel — not a public channel — so findings are visible to the team without leaking which signals fired.
Custom-resource-heavy stacks: on the first run, expect to whitelist a handful of internal resources. Use the audit-log entries as your changelog — they tell future you why a given resource was trusted.
See Server setup for the whitelist workflow in the dashboard, and Server analytics for the always-on companion view.