Security Overview

Security Overview

ModSeeker combines server-side policy checks with reports from Hidder's native component. These controls protect the verification exchange and help reject altered or invalid reports.

How a connection is checked

1. Hidder announces itself and its protocol version to the server.
2. If launcher verification is enabled, the server requests a fresh signed challenge response carrying the detected launcher label.
3. If mod verification is enabled, Hidder collects the mod report, signs it and encrypts it for that server.
4. ModSeeker validates the response and applies the selected mod and launcher rules before releasing the verification hold.

The two policies remain configurable. See Verification Modes for which steps run with each setting combination.

Disconnecting ends that verification session. A new connection starts a fresh exchange.

The main protections

Protection	Purpose
Fresh challenges and request identifiers	Bind responses to the current verification request.
Signed responses	Let ModSeeker validate that the response uses the client identity it recognizes and has not been changed after signing.
Encrypted mod reports	Protect report contents in transit to the intended server.
Native collection and integrity checks	Collect mod metadata from JAR bytes and check Hidder's native/Java components before completing protected operations.
Bounded message handling	Reject malformed, oversized or inconsistent reports.
Administrative access controls	Restrict commands by permission and the GUI by a temporary access link and request checks.

In advanced mode, approved SHA-512 hashes distinguish exact mod file contents. A recognized Hidder signature does not by itself approve every reported mod; the server's policy still decides that.

Official Hidder builds also apply compiler obfuscation to the native library. Custom builds use the options chosen by their builder. These measures help resist tampering; they do not establish that a player-controlled system is trustworthy. Use server-side gameplay checks for cheating behavior, and keep normal authentication and permissions in place.

What data is reported?

Data	When used
Mod IDs and versions, including declared bundled entries	Mod verification.
SHA-512 hashes of reported mod JARs	Advanced mod verification.
Detected launcher label, or unknown	A requested launcher challenge; ModSeeker requests it when launcher verification is enabled.
Presence, version and verification metadata	The relevant connection checks.

Hidder reads JARs and launcher signals locally. Its reports do not upload JAR contents, local paths, raw process details or hardware IDs. Resource-pack and shader-pack reporting are not v3 features.

The reports go to the connected Minecraft server through its existing connection. Server administrators can read them. ModSeeker logs mod lists by default and can send the configured Discord Alerts, including player identity information on join. Hidder has no separate telemetry service.

ModSeeker also queries Modrinth for mod searches, version metadata and approved-file hashes. To identify an unapproved file, it can send that file's SHA-512 hash to Modrinth for a name lookup. Name-based whitelist additions can use Paper's player-profile lookup.

Operating the server safely

Keep server and custom-build private keys backed up privately. Grant administrative permissions and verification bypasses only to the intended identities. Use HTTPS for GUI access over untrusted networks and treat its access link as a temporary credential.

For a suspected vulnerability, describe the impact privately to the maintainer before posting reproduction details publicly. The issue-report checklist in FAQ and Support explains what to redact from ordinary support reports.