Verification and Security

Verification and Security

Join verification flow

1. The server sends verification settings and requests the client's mod/pack report.
2. The client scans JARs directly inside its mods/ directory, reading Fabric metadata where available, and hashes those JARs. It also reports selected resource packs and their hashes.
3. The report includes Defixus version and client Minecraft version. The server first requires the exact same Defixus version string as its own.
4. The server checks Defixus integrity and applies its whitelist, blacklist, and graylist policy.
5. Blacklist entries and graylist mismatches cause a kick. Unknown mods/packs warn unless the corresponding kick-unapproved-* setting is enabled. Successful joins, warnings, and violations update statistics and may generate Discord alerts.

The server gives the client a timeout to respond. If a Java client cannot receive Defixus custom payloads or does not respond, it is kicked. Recognized Bedrock players can bypass this request when Geyser integration identifies them.

Policy precedence

Mods: Defixus integrity/version handling is special-cased; otherwise the server checks blacklist, whitelist, graylist, then unknown-mod policy. Whitelisted mods are accepted by ID without matching their JAR bytes. Graylisted mods must match the server's reference hash. Recognized libraries may be allowed through library-bypass.

Resource packs: Built-in/system and mod-provided pack exceptions are handled first, followed by blacklist, whitelist, graylist, and unknown-pack policy. Graylist mismatches are rejected. Pack changes are also evaluated when received while connected; unapproved activations warn or kick according to policy.

Operator and moderator bypasses occur after the client has reported the required matching Defixus version. They skip ordinary mod/pack verification, but do not bypass the Defixus version requirement. Pack-change UI blocking is a separate client-side setting.

Hashes

Mod and pack fingerprints use SHA-256. Graylist hashes are computed from server-supplied reference files. Ordinary JAR/ZIP files are hashed from their bytes; directory packs are hashed from their files in normalized relative-path order.

Defixus uses a canonical JAR-entry fingerprint for its own integrity check, excluding only the SHA-256 hash table to avoid a self-referential digest. The cross-version allowlist is hard-coded.

The client/server cross-Minecraft exception applies only when the reported Defixus version matches and the client Defixus hash equals the known hash for its reported Minecraft version. It does not change Fabric's Minecraft dependencies.

What this does not guarantee

• A matching hash shows that reported bytes match a known reference; it does not prove that the runtime client behaves honestly, so use also a real-time behavior-like anti-cheat, like Vulkan.
• Whitelist-by-ID intentionally does not enforce a particular file build. Use graylists when exact file integrity is required.
• UI blocking is an enforcement aid, not a defense against modified clients or direct manipulation of local resource-pack state.
• Defixus is not a general movement/combat/runtime gameplay anti-cheat and cannot promise absolute behavior-like cheat prevention.

For strict modpacks, distribute trusted client files, use graylists for exact required artifacts, explicitly review the built-in whitelist/library bypass, and test enforcement before enabling kick settings.