Minecraft

Minecraft uses game_id = 6. The integration is in local development. It targets Minecraft 1.20 and later through adapters for specific platforms and versions. This does not establish compatibility with every 1.20+ server.

Check the readiness matrix before installation. There is no production release or universal JAR for all loaders yet.

Server components

The Java project is separate from the existing Rust extension:

Component	Purpose
com.ozprotect.core	Lifecycle, player identity and Network protocol
com.ozprotect.anticheat	Server observations and evidence collection for review
com.ozprotect.ext.*	API for independent extensions
Bukkit/Spigot/Paper adapter	Connects the core to server events and commands
Forge/NeoForge/Fabric adapters	Separate artifacts and native verification of exact versions in the readiness matrix

The default Bukkit artifact targets Spigot API 1.20.4-R0.1-SNAPSHOT and is verified on Paper 1.20.4 build 499. A separate minimum-API variant targets exact Spigot API 1.20-R0.1-20230612.113428-32, Java 17; it preserves the default artifact and passed Paper 1.20 build 17 and native Spigot 1.20.1 build 3871. The latter was source-built through official BuildTools 201 and identifies as 3871-Spigot-d2eba2c-3f9263b.

These are three specific runtime targets, not every Bukkit/Spigot/Paper 1.20+ release. Standalone CraftBukkit, Spigot 1.20.0, other releases and hybrid servers are unverified. api-version: '1.20' does not replace runtime verification. Unmodified vanilla without a plugin/loader API and Folia are unsupported. See exact Java/loader versions in the matrix.

Separate minimum mod targets also passed native private linking/actual SSO and ban/unban/stable-ID/history: Forge 1.20/46.0.14, Fabric 1.20/Loader 0.16.10/API 0.83.0+1.20 and legacy NeoForge 1.20.1/47.1.106. The latter compiles against net.neoforged:forge:1.20.1-47.1.106, uses old net.minecraftforge events and remains a separate JAR from Forge and modern NeoForge.

The next Bukkit Java 21/API 1.20.6 boundary and exact Paper 1.20.6 build 151 are source-prepared only (f789366), with XML/JS/PowerShell static checks. They have no build/runtime proof, are not verified targets and do not replace the current JAR.

An anti-cheat observation alone does not prove a violation. Server evidence needs review in the context of latency, server conditions and the modpack; current evidence collection does not constitute a complete universal anti-cheat.

Connecting to Network

The server adapter connects to the authenticated Socket.IO /server namespace. Transport path: /socket, mode: WebSocket without polling. This is Socket.IO, not an arbitrary WebSocket connection. The ozProtect team supplies the address and server credentials; panel language does not determine the Network address.

The authenticated connection determines the project and server. A player-supplied project_id cannot change that scope. Minecraft authentication mode and the authenticity of player UUIDs remain the game server's responsibility: mapping a UUID to an ID does not prove account ownership.

UUID and persistent player ID

Before sending player events, the adapter calls player.minecraft2steam_id:

{"uuid":"550e8400-e29b-41d4-a716-446655440000","name":"Player"}

Example response for authenticated project 498:

{
  "status": "success",
  "response": {
    "steam_id": "2004980000000000001",
    "player_id": "2004980000000000001",
    "uuid": "550e8400-e29b-41d4-a716-446655440000",
    "project_id": 498,
    "game_id": 6
  }
}

Network persists (project_id, UUID) → player_id in game_player_ids. The 19-digit ID is 2 | project_id (5 digits) | sequence (13 digits). The central primary database allocates the sequence; it is not a UUID hash.

• Store and send the ID as a string, without converting it to a JavaScript Number.
• The same UUID in the same project receives its saved ID. Another project has a separate identity.
• Do not allocate IDs independently on each server or delete mappings while related history exists.
• Use the returned ID in existing steam_id fields for connections, checks, bans, mutes, chat, reports and history.
• users.uuid retains its legacy account-linking meaning; the Minecraft UUID is stored separately.

For an offline player command, call player.getIdentity on the same authenticated connection:

{"steam_id":"2004980000000000001"}

The response contains the original uuid. Address the Minecraft command to that UUID. Resolving another project's ID is forbidden.

A Minecraft profile carries id_kind: minecraft, game_id: 6 and steam: false in its compatible profile object. The UUID is exposed separately as info.minecraft_uuid. Steam authentication, VAC, Steam statistics and Rust inventory do not apply to this ID; unknown data must not be replaced with invented values. Real Steam player IDs remain unchanged.

Private game-account linking

Linking Minecraft to an ozProtect account requires no Steam identity. It binds the account to a persistent project-scoped player identity without changing UUID mapping or game IDs.

1. Sign in to your own ozProtect account through the configured SSO.
2. Join the intended Minecraft server and run /ozp link. Neither OP nor an active checker session is required.
3. The adapter requests a code for the actual connected player's UUID and replies with eight characters privately. The code is not broadcast, logged or sent through extension hooks; a changed connection cannot receive the old player's reply.
4. Submit the code only to the trusted configured account interface. Network account.linkGame accepts code with a personal Bearer token; an expired or spent code cannot create another link. The command does not infer a public website URL.
5. account.getGameLinks lists the caller's links; they persist after reloading the account interface.
6. account.unlinkGame takes project_id and string player_id to remove the caller's own link. Removal denies access through that link without deleting central UUID/ID mapping or player history.

All three HTTP methods use POST /methods/account.<method> on the assigned Network with personal authentication. Minimum Paper 1.20 and Spigot 1.20.1 checks passed actual non-OP private-code → SSO/Bearer redeem/list/replay rejection/unlink without Steam. Native ban, denied login, unban, stable string ID and history were a separate scenario. The other pinned matrix targets also passed private linking. NeoForge 1.20.4 additionally has separate browser link/appeal evidence.

A code proves control of the game identity on that server. An offline UUID alone does not prove online Minecraft account ownership. Use the actual assigned local origin; this workflow establishes no public .com/.ru endpoint or downloads.

Minecraft Checker for Windows

ozl.ozprotect.checker.mc is a separate C#/.NET 8 WPF client and inspection core. The source build requires Windows x64 and the .NET 8 Desktop Runtime; there is no signed installer yet. It is separate from the Rust checker.

1. A moderator creates a Minecraft session in the panel and gives the player the Network address and eight-character code.
2. The player enters the code and connects for session metadata only, then selects a Minecraft directory and explicitly consents to inspection. Connection sends expected_game_id: 6; a matching Network checks the game before device binding, and the client also rejects another game. Process names require separate consent, off by default.
3. The player starts inspection manually. A remote scan.request displays a request and does not start scanning automatically.
4. The pipeline reads mod JAR metadata, version JSON, selected-file SHA-256 inventory and bounded game logs within the directory. Separate consent adds process names/count. Results upload in acknowledged batches through Socket.IO /checker, path /socket.
5. The moderator reviews findings and inspection limits. Cancellation or unreadable files do not mean a clean result.
6. A repeat scan.request opens fresh consent for its exact module scope and resets process opt-in. Unrequested modules remain skipped, read no files and send no findings. An empty list uses the displayed standard scope; unknown modules are rejected without broadening inspection.
7. A duplicate pending request does not reset the consent screen; a request during inspection does not queue another run. A process-only request without separate permission stays on consent. Terminal sessions ignore late scan/chat events and stale ACKs.

Symlinks and junctions are skipped; reads are restricted to the selected directory. The client provides no remote file browser and executes no incoming commands. Separate opt-in collects up to 256 process names and their count; it does not read command lines, memory or the registry. File reads remain in the selected directory. Uploads contain relative paths, SHA-256 hashes, mod metadata and rule evidence; JAR contents and the absolute selected path are not uploaded. Connection metadata includes a random persistent installation ID, app version and OS/architecture details; the ID is not a hardware fingerprint.

Module states are complete, partial, unavailable, cancelled, skipped; process opt-out is skipped, missing mods is unavailable. complete means the bounded module finished, not that the computer is clean. session.refuse sends refusal to the server; the server verdict determines the final screen.

A suspicious filename alone does not prove cheating. Findings are for moderator review and must not automatically ban a player. Inspection cannot guarantee detection of every modified client or prove that cheats were never used.

Before operation

Network migrations are an explicit, reviewable step; starting the backend does not update the schema automatically. Preparing source does not mean a production database has been migrated.

An isolated MySQL fixture is published; the local C# → Network → MySQL path has been verified with synthetic data. Exact Paper/Spigot/Forge/Fabric/NeoForge targets have separate native verification. In f283729, actual WPF handlers/pipeline and C# transport passed local repeat-consent checks with real SSO/panel/Network requests and MySQL, without showing a window or reading a real game directory. Other versions, source-prepared Paper 1.20.6 and real-player/signing/release acceptance remain unproven. See the readiness matrix for verification boundaries and regional plans.