AntiSkidAC 1.0.5.1 Administrator Guide
Documentation version: 1.0.5.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
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; a pending challenge is compared with the current value, so increasing modlistChallengeTimeoutTicks immediately extends pending and future challenges (decreasing it can expire an older challenge at its next check).

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.
- Verification timeout: for very large packs/directories, increase modlistChallengeTimeoutTicks (ticks) and reload.
- 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.
