AntiSkidAC 1.0.6.1 Administrator Guide
Documentation version: 1.0.6.1

WHAT ANTISKIDAC DOES
AntiSkidAC is a Forge/NeoForge multiversion client-integrity and modpack-verification system. It verifies installed mods and versions, physical mod JAR BLAKE3-256 hashes, required/prohibited-mod policy, explicitly managed files/directories, platform versions, and known cheat/runtime-injection indicators. It supports live policy/config reload and an explicitly reviewed hash-update workflow.

CONFIGURATION FILES
All paths below are under config/antiskidac/ unless a configured filename overrides a policy default.
- antiskidac.cfg: main Forge settings on 1.6.4/1.7.10/1.8.9/1.12.2.
- antiskidac.toml: main NightConfig settings on 1.16.5/1.18.2/1.20.1/1.21.11.
- approved_mod_hashes.json: approved physical mod JAR hashes.
- platform_components.json: accepted Minecraft/Forge platform component versions.
- required_mods.json: required mod IDs.
- banned_mods.json: prohibited mod IDs and indicators.
- managed_paths.json: local authoring definitions on a client, and authoritative expected hashes on a server.
- client-mod-hashes.txt: generated client manifest/hash export.
- HOW_TO_USE.txt: this first-run administrator guide.
Reviewed hash candidates are held in server memory, not trusted or persisted as a candidate file. Inspect them with /antiskidac hashupdates.

QUICK START
1. Install AntiSkidAC on the server and required clients.
2. Launch once to create config/antiskidac/ settings and this guide.
3. Press F8 and review MOD HASHES; use REGENERATE TXT or COPY ALL JSON.
4. Put reviewed hashes in the server approved_mod_hashes.json.
5. Configure required_mods.json and banned_mods.json.
6. If external content needs protection, add local entries to managed_paths.json.
7. Open F8 -> MANAGED PATHS and choose REFRESH HASHES.
8. COPY JSON ENTRY or COPY ALL JSON to obtain server-ready expected hashes.
9. Put the authoritative JSON policy files in the server config/antiskidac/ directory.
10. Run /antiskidac reload (permission level 3), or restart.
11. Connect an updated test client and check /antiskidac status.

VERSION-NATIVE TOOLS
All versions provide MOD HASHES and MANAGED PATHS views. The REGENERATE TXT, REFRESH HASHES, COPY PATH and server-command controls described below apply to 1.7.10, 1.8.9 and 1.12.2.
On 1.6.4 and 1.16.5 onward, the native terminal has MOD HASHES, MANAGED PATHS, AUTHOR PATH and HOW TO USE tabs. Use PREVIOUS/NEXT to browse entries or the complete bundled guide. REFRESH scans the local installation and configured paths. COPY ALL copies approved-mod or successful managed-path policy JSON for the current view; COPY HASH copies the full selected digest, and COPY ENTRY copies a manifest diagnostic entry or a successful managed-path policy entry. Failed or unscanned managed entries cannot be copied as policies.
Refresh writes client-manifest.json (complete identities/classifications/digests), client-mod-hashes.txt (pure approved-policy JSON), client-managed-paths.json and client-platform-components.json.
In AUTHOR PATH, enter a relative file/directory path and choose COPY FILE POLICY or COPY DIRECTORY POLICY; rename the generated managed-content key when combining targets. No copied/exported value is automatically approved.
These adapters use /antiskidac reload for main-config changes; policy JSON still reloads automatically after two stable observations. Pending challenges capture their deadline; reload revalidation sends fresh challenges. Restart after changing scanner bootstrap or policy filenames.
Their runtime heartbeats use a fresh server challenge per scan. Legacy brand/payload violation scoring, violations/reset commands, verbose diagnostic switches and dedicated antiskidac.log output are unsupported on these adapters. Normal verification summaries go to the loader log.
1.6.4 has no Netty pipeline signal. Modern known-class/registry probes are best effort and may not see isolated loader/module classes.
Forge 1.6.4 runs on Java 8 with stock ASM 4.1. Its production JAR, including common and embedded dependencies, uses Java 7-compatible bytecode. No launcher ASM replacement is required.

MOD HASHING
F8 shows local hash generation above the manifest in singleplayer and multiplayer. The large amber notice tracks discovery, mod-source processing and final preparation; its bar counts loader sources (several may share one JAR). Discovery and preparation use an animated indicator. The list updates automatically and the notice collapses to green LOCAL MANIFEST READY, including for an empty completed manifest. Red failure notices contain no file details; use REFRESH or REGENERATE TXT to retry. Local completion does not mean the server accepted verification.

The F8 MOD HASHES page displays every discovered source and a compact B3 value. Select an entry and COPY HASH/COPY ENTRY, choose COPY ALL JSON for approved_mod_hashes.json JSON, or REGENERATE TXT for config/antiskidac/client-mod-hashes.txt. This works before connecting to a server; do not deliberately fail verification to discover baseline hashes. Review the export, then add the approved values to the server's approved_mod_hashes.json and reload. Any change to the physical JAR bytes produces a different BLAKE3-256 hash.

MANAGED PATHS
Managed paths protect explicitly selected content outside mod JARs, such as handmadeguns_Packs, Flan, mcheli, scripts, selected config files, resourcepacks, or shaderpacks. Nothing is scanned unless it is configured.

type "file" hashes one file. type "directory" recursively hashes the exact directory tree into one canonical BLAKE3-256 hash. Editing or adding a file, removing it, or renaming/moving it changes the directory hash. Timestamps and ordinary filesystem metadata do not affect it.

Local authoring entry (expectedHash may be omitted):
{
  "hmg-packs": {
    "path": "handmadeguns_Packs",
    "type": "directory"
  }
}

Server-ready output:
{
  "hmg-packs": {
    "path": "handmadeguns_Packs",
    "type": "directory",
    "expectedHash": "<computed BLAKE3-256 hash>"
  }
}

The local authoring config only selects what to hash. Server-authoritative policy requires expectedHash. A client's local expectedHash cannot override server enforcement.

MANAGED PATHS GUI
Open F8 -> MANAGED PATHS while disconnected if desired.
- REFRESH HASHES scans the current local definitions.
- COPY HASH copies the selected complete BLAKE3-256 value.
- COPY PATH copies its relative path.
- COPY JSON ENTRY copies one server-ready object.
- COPY ALL JSON copies a complete server-ready managed_paths.json.
Status Local means no local expectedHash was supplied; Match/Mismatch compares a supplied local expectation; Missing means the relative target does not exist; Scan Failed reports an unsafe path, symlink, I/O, or other scan failure. Only successful scans are exportable. This workflow prepares valid server JSON without first connecting to the server.

UPDATING PACK CONTENT
1. Update handmadeguns_Packs (or another managed target).
2. Launch Minecraft and open F8 -> MANAGED PATHS.
3. REFRESH HASHES and copy the updated JSON/hash.
4. Replace the server managed_paths.json value.
5. Run /antiskidac reload.
6. Old-content clients now fail; updated clients pass.
For a live server already enforcing an old hash, the reviewed candidate workflow below is an alternative.

LIVE CONFIG RELOAD (1.7.10, 1.8.9, 1.12.2)
/antiskidac reload parses and applies runtime config and all policy files. Live-safe settings include enforcement modes, logging, client requirement/heartbeat/handshake timing, unknown/hash-update policy, and reload/revalidation behavior. Next-check/challenge settings include recurring recheck timing and modlistChallengeTimeoutTicks. The timeout unit is ticks; each challenge captures its original timeout and deadline. Reloaded values apply only to newly issued challenges, including periodic checks.

Startup-only settings are client scanner/bootstrap switches and the five policy filename settings; restart after changing them. Runtime reload intentionally preserves these startup-only values.

POLICY RELOAD
With livePolicyReload enabled, metadata changes that remain stable for two scheduled checks trigger an automatic reload. /antiskidac reload performs the same validated policy replacement manually. All files are parsed before one snapshot is activated. Malformed or unreadable policy never replaces the last-known-good active snapshot.

REVIEWED HASH CANDIDATES
Candidates help review a legitimate mod JAR update or managed-directory update while a server still has the old approved hash. Enable allowKnownModHashUpdates, inspect /antiskidac hashupdates, then explicitly run /antiskidac hashupdate accept <policy-key> <candidate-hash> or ... reject .... Candidates still fail normal enforcement, are never automatically trusted, and require explicit acceptance. Use the local GUI/export—not rejection—as the normal baseline authoring workflow.

RESOURCEPACK / SHADER EXAMPLE
A server can manage the entire resourcepacks or shaderpacks directory to reject added or modified packs. The tradeoff is exactness: any extra personal pack changes the directory hash and fails verification. Hashing a pack proves its filesystem content only; AntiSkidAC does not attest that the pack or shader is actively selected.

TROUBLESHOOTING
- Modified mod JAR: the client's physical JAR hash differs from the approved server hash; install the approved file or review a legitimate update.
- Managed path mismatch: a file was added, removed, renamed, moved, or modified; refresh and compare the intended tree.
- Managed path missing: the configured instance-relative path does not exist on the client.
- Invalid managed_paths.json: fix malformed JSON, an unsupported type, unsafe path, or expectedHash that is not 64 lowercase hexadecimal characters.
- Manifest timeout: increase modlist_verification.modlistChallengeTimeoutTicks on the SERVER and reload. Default 200 ticks = 10 seconds at 20 TPS; range 20–72000 ticks. Forge 1.16.5 uses config/antiskidac/antiskidac.toml. client.clientHandshakeTimeoutSeconds is for a separate runtime report and cannot extend the manifest deadline. Pending challenges retain their original window. Minecraft/Forge network/login timeouts are separate.
- Protocol mismatch: install mutually compatible AntiSkidAC client/server versions.
- Unexpected/prohibited mod: remove content forbidden by banned_mods.json, or correct reviewed server policy.
- Missing required mod: install the required_mods.json entry with its approved version/hash.
- Symlink/unsafe path rejected: managed targets must resolve safely inside the Minecraft instance and must not traverse symlinks; checks are not a race-proof filesystem sandbox.

SECURITY MODEL
Server policy is authoritative; client authoring policy is not trusted. Nonce-bound manifests prevent simple stale-manifest replay; legacy runtime heartbeats still reuse their challenge, and managed paths verify exact configured filesystem content. AntiSkidAC raises the cost of modification and detects ordinary altered clients/content, but no client-side integrity system can be mathematically trusted against an attacker who fully controls and rewrites the client. Server-authoritative gameplay checks remain stronger where available.

ASYNCHRONOUS VERIFICATION AND MESSAGES
Loaded-mod metadata is captured on the client thread; artifact reads, managed-tree enumeration, BLAKE3 hashing, exports and serialization run in bounded background stages. One low-priority disk worker is shared with runtime class-resource verification. Native asynchronous networking receives prepared bytes through a bounded owning-thread handoff. No external HTTP uploader, delta protocol or automatic upload retry is used.

Every server challenge revalidates complete file content. Canonical-path caching only deduplicates reads within that generation, such as several logical mods in one JAR. Size, modification time and file identity detect ordinary concurrent changes but are not cryptographic proof. They never authorize reuse across challenges. Filesystem snapshots are not atomic: a hostile process controlling the client/filesystem can still race reads or forge reports. There is no stronger authentication claim.

client.verificationHashMiBPerSecond optionally caps background reads; 0 is the default and adds no artificial wait. client.verificationDiagnostics enables per-file durations and cycle summaries (bytes, hits/misses, hash time, managed time, prepared payload size, enqueue/completion time, observed queue depth, owner-thread handoff/capture time and failure/cancellation/coalescing counters). On the server, this switch also records the manifest timeout key/value, issue/deadline/observed server ticks and wall timestamps for issue, acceptance, expiry and disconnect. These are development diagnostics; actual frame-time measurements require a running client. The server timeout is unchanged and remains authoritative. Requests coalesce without restarting active remote work. Disconnect cancels/discards the old generation. Threads expire when idle.

Local refresh/export and managed-path authoring are asynchronous. Wait for completion before copying. Periodic challenges update the F8 view without writing exports or logging full hash lists. Complete manifests support at most 1,024 logical mods and 64 managed targets. Updated 1.7.10–1.12.2 peers advertise bounded response framing to pass the native 32 KiB packet ceiling. Old servers receive the original response body when it fits; oversized inventories fail locally instead of being truncated.

Set disconnect text in the existing main configuration's verificationMessages category:
MISSING_REQUIRED_MODS
UNEXPECTED_MODS
MOD_INTEGRITY_MISMATCH
INCOMPATIBLE_VERSION
VERIFICATION_TIMEOUT
INCOMPLETE_VERIFICATION
INVALID_VERIFICATION_RESPONSE
VERIFICATION_TRANSPORT_ERROR
VERIFICATION_INTERNAL_ERROR
VERIFICATION_REJECTED

Defaults refer to installation/server requirements, without assuming a distribution or launcher. Missing, empty or invalid entries fall back to defaults. Use & color codes and line breaks as supported by your config format. Messages are limited to 512 characters and unsafe controls are removed. No placeholders insert client-provided text. The same wording may be assigned to several categories. Run /antiskidac reload to apply wording changes.

A changed digest alone never diagnoses an outdated version. Timeout means no complete valid response arrived in time; the unchanged wire protocol cannot prove whether the client worker failed or the upload was lost. Unexpected native connection loss retains Minecraft's own disconnect reason. The server chooses all enforcement categories; expected/received hashes and exact failing files never enter player messages. Sensitive detail logs are opt-in: existing sensitive-debug switches on 1.7.10–1.12.2, general.verificationSensitiveDiagnostics on other targets. Keep logs private.

Verification HUD
A small native overlay shows checking mod files, sending verification, and awaiting server verification. It uses background stage snapshots and never reads files from rendering. A matching server result clears it; timeout, cancellation and disconnect also clear it. Old servers without the optional result channel cannot confirm completion, so feedback expires without showing success. No filenames, hashes or fabricated progress are displayed.
