A scanner should withstand scrutiny.
The client is treated as untrusted input, staff destinations stay on the backend, and public releases remain disabled until signing and verification material are ready.
Trust boundaries
The portable client asks the backend for a short-lived scanner capability, verifies the associated signed rule pack, gathers bounded local observations only after consent, and submits a structured report. The backend validates that report and, for the authorized disclosed policy, produces a minimized Discord staff notification.
Notification credentials and staff-channel destinations are never compiled into or supplied to the downloadable scanner. Discord delivery is enabled only on the backend for the authorized policy and is disclosed before consent. The client contacts the scanner API, not Discord.
An optional NVIDIA NIM review is also backend-only and runs only when the request-specific disclosure says it is enabled. The backend sends only normalized bounded current mod JAR names, version and loader identifiers, and absent-now JAR references—never raw latest.log lines—and treats model output as untrusted advisory context for manual review.
The automatically issued scanner capability is not a cryptographic binding between the selected local JVM and a live Minecraft server session. V3.0 keeps those two trust claims separate and cannot use the API capability alone to produce a session-level clean conclusion.
Release integrity
A production download is enabled only when its manifest is explicitly marked ready, uses the canonical release URL and stable semantic version, and has a valid SHA-256 digest and UTC signing time. An Ed25519 signature must authenticate all of that metadata against one pre-approved public key pinned by the site.
- Use only the download published on this domain.
- Compare the executable's SHA-256 value before running it.
- Confirm the displayed signing key ID and release timestamp.
- The site verifies the signed release statement before exposing the download.
- Reject messages or unofficial mirrors that offer “special” scanner builds.
- The separately labeled staging EXE is unsigned and not a production release; verify its displayed hash.
The V3.0 preview explicitly enables a signed legacy ungoverned prerelease pack containing only nonmatching informational plumbing rules. Pack signing authenticates those test rules but is not production rule governance. Production-shaped rule publication still requires private authorized-positive and legitimate near-match dossiers, provenance, independent approvals, expiry, and rollback metadata. The staging exception does not weaken the production governance or release gates.
Implemented design controls
Collection begins only after the player reads the disclosure and affirmatively consents.
The client verifies the selected pack locally; production additionally rejects rules without the required governance evidence.
V3.0 requires one corroborated JVM and pins its PID lifetime, Java image, canonical game root, version, reviewed launch class, and declared classpath. A renamed host additionally needs an exact graphics-window PID and adjacent loader-visible jvm.dll.
At most 64 current-user Windows Recycle Bin facts expose only a normalized JAR basename and UTC move time. Retained deleted-file content is not opened, recovered, hashed, or uploaded; collector coverage is supplemental and non-verdict-gating.
Collectors enforce scope, count, byte, and duration budgets.
Partial or failed inspection cannot be represented as fully complete.
Staff summaries omit raw files, paths, credentials, and unrestricted evidence.
Only a bounded latest.log tail is parsed; raw lines are discarded after normalized facts are extracted.
NIM receives normalized bounded identifiers only after request-specific disclosure and consent.
Findings inform a review and are not automatic moderation commands.
Known limits
A user-space integrity scanner cannot prove that a computer has never run a cheat, reliably reconstruct deleted files, or defeat every form of tampering. Runtime access can also be limited by Windows permissions, process lifetime, antivirus software, or unsupported launchers.
V3.0 requires exactly one same-user JVM with an exact validated game root, safe version, reviewed launch class, and validated declared JAR classpath. It pins the process lifetime, parent, Java image, and root identity; ambiguity, PID/root reuse, and a helper or decoy JVM fail closed. Runtime and bounded window hints are supporting provenance only and cannot select a target alone.
The selected JVM's reduced command line is used locally to validate the root, launch tuple, declared classpath, and -javaagent/-agentpath signals. Raw command lines, agent options, paths, process IDs, and nonmatching hashes stay local. The quick scan does not read raw target environment variables or arbitrary effective JVM properties; completed coverage applies only to the declared bounded command-line and loader-visible scope. Live game/server-session association is reported separately, so a completed self-service device review remains unbound and cannot become session-level clearance.
Runtime checks hash the selected Java image, validated declared agent files, and Toolhelp-visible on-disk modules. They do not inspect process memory or guarantee detection of manually mapped, memory-only, modified-in-memory, already-unloaded, kernel, or hardware-assisted cheats. Likewise, a latest.log reference to a JAR absent now is not proof of deletion, and its log time is not a deletion timestamp.
Recycle Bin mod history is not universal deleted-file history. It does not cover Shift+Delete, an emptied bin, or another user's Recycle Bin. A reported move time says only when Windows recorded that item entering the current user's bin; it does not prove the JAR was loaded or used, cheating, or an evasion attempt. Partial or unavailable supplemental history does not gate the core deterministic verdict.
The staging backend uses a bounded in-memory Discord delivery queue rather than a durable outbox. It can retry a failed case when the same completion is submitted again, but a host restart or prolonged destination outage can still lose a pending staff message. Durable delivery is a production-launch requirement.
Report a security concern
Report suspected vulnerabilities privately through MaghrebSMP's official staff channels. Include the affected version, impact, and minimal reproduction details; do not include player data or active credentials.
A dedicated security address and response policy are production-release requirements. Review the privacy boundary for data-handling details.