AntiSkidAC 1.0.3 Administrator Guide
Documentation version: 1.0.3

WHAT ANTISKIDAC DOES
AntiSkidAC is a Forge 1.7.10 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.
- 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/antiskidac.cfg 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.

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
/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 may not traverse symlinks.

SECURITY MODEL
Server policy is authoritative; client authoring policy is not trusted. Nonce-bound challenges prevent simple stale-response replay, 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.
