AntiHunter Command & Control Pro

AntiHunter Command & Control PRO is the companion operations platform for the AntiHunter SIGINT mesh network. Flash your AntiHunter detection nodes with the AntiHunter builds, then connect them here to orchestrate the entire perimeter defense mission. The Command Center ingests every heartbeat, target hit, triangulation update, and vibration alert from the mesh, renders nodes and geofences on a live map, automates scan/baseline/triangulation workflows, and drives alarm cues, exports, and audit trails.

Firmware note: The companion firmware for mesh detection nodes lives in lukeswitz/AntiHunter. Flash those builds to your field hardware before connecting them to this Command Center.

Early Release: This is a beta build. Expect stability issues, breaking changes, and evolving features.

Security disclosure: The platform has not undergone formal penetration testing or hardening for Internet-exposed deployments. Run it on trusted networks only, behind your own perimeter controls, until a full security review is complete.

Table of Contents

1. Overview
2. Core Features
3. Key Highlights
4. Digital Detection, Scanning & Triangulation
5. Drone Awareness & FAA Enhancements
6. UI Modules at a Glance
7. Architecture
8. Security & Hardening
9. Repository Layout
10. Installation
11. Scripted — Linux / macOS
12. Scripted — Windows 10/11
13. Docker
14. Manual
15. Configuration
16. Database & Migrations
17. Running the Stack
18. Updating an Existing Deployment
19. Building for Production
20. Production Deployment
21. Serial Hardware & Meshtastic Sniffer
22. Useful Scripts
23. Operations & Maintenance
24. Troubleshooting
25. Legal Disclaimer

Overview

AntiHunter Command & Control PRO turns raw radio/mesh telemetry into actionable situational awareness. The application keeps track of nodes, devices, and geofences, allows operators to launch complex detection sequences, and streams alerts through a tone-aware alarm engine. Everything is multi-site aware and backed by Prisma/PostgreSQL for durability.

Core Features

Key Highlights

Digital Detection, Scanning & Triangulation

• Digital detections: Meshtastic-like frames are parsed in real time and normalized into inventory entries with vendor/OUI resolution. The detector renders RSSI, timestamps, and raw payloads so analysts can confirm legitimacy.
• Scanning workflows: Command presets fire scan/baseline/deauth/randomization pipelines against nodes, with FOREVER protections and audit trails. Operators can schedule sweeps, chain commands, and monitor acknowledgements/results inside the console.
• Tracking: Every detection updates the live map with trails, heading vectors, RSSI pulses, and site-specific coloration. Inventory rows store the location history so you can pivot from console <-> map <-> export seamlessly.
• Triangulation: Multi-node detection events feed the triangulation engine, capturing angle-of-arrival data set by the nodes. Results surface in the Targets module with exports for external tooling (e.g., CSV/GeoJSON) and can be reviewed in the map view as overlays.
• Exports & auditing: Scan logs, triangulation snapshots, and detection histories are exportable from their respective modules, ensuring mission reporting and post-op analysis are one click away.

Drone Awareness & FAA Enhancements

Drone Tracker & Inventory Drawer

• The live map now spawns a Drone Tracker & Inventory drawer whenever a telemetry frame arrives. The drawer lists every tracked drone/operator pair on a single line, shows the current heading (cardinal string), operator details, FAA metadata, and exposes map focus buttons for each entry.
• Clicking a drone or operator on the map re-opens the drawer if it was dismissed. Hostile rows pulse red, neutral/friendly rows pick up their site colors, and Unknown defaults to the new blue palette so status is immediately obvious.
• Status changes (Friendly / Neutral / Hostile) are committed through PATCH /api/drones/:id/status and reflected everywhere (map markers, drawer rows, Socket.IO events, MQTT federation). The UI guards against race conditions so you can keep toggling a status even while telemetry continues to stream.
• Set DRONES_RECORD_INVENTORY=true (see Configuration) to automatically mirror every drone detection into the Inventory module; clearing inventory now flushes the drone cache and removes map markers until fresh telemetry arrives.

FAA Registry Integration

• The Config -> FAA Registry card can download and parse the public ReleasableAircraft.zip archive from the FAA (https://registry.faa.gov/database/ReleasableAircraft.zip). Uploading the ZIP (or just MASTER.txt) populates the local lookup cache.
• When the Command Center has internet access, it also performs on-demand lookups using the uasdoc API (https://uasdoc.faa.gov/listDocs/{RID}) through a throttled background queue. Results are cached for FAA_ONLINE_CACHE_TTL_MINUTES (default 60) and each RID/MAC lookup is rate-limited via FAA_ONLINE_LOOKUP_COOLDOWN_MINUTES (default 10).
• FAA matches update the drawer, map tooltips, and websocket/MQTT payloads automatically, so operators always see the craft and registrant names even after a restart.

Drone Geofence Breach Alarms

• Geofences now evaluate drone positions in addition to ground nodes. Tripping a perimeter raises a dedicated Drone Geofence Breach alarm level with its own sound slot on the Config -> Alarms page.
• While a breach is active the impacted geofence keeps its configured color but pulsates to draw attention, and the Drone Tracker drawer highlights the offending aircraft.

Flight Trails, Operators, and Persistence

• Each drone and operator pin now uses the same status-driven palette, includes heading vectors, and draws a historical trail so you can reconstruct the approach path.
• The backend keeps only one copy of each drone snapshot in memory and debounces writes to the database, preventing the persistence flood that previously occurred when running simulators or high-rate feeds.
• MQTT federation has been updated to publish only local drones and to retry failed subscriptions with exponential backoff, ensuring remote sites receive telemetry even across flaky links.

Simulator-Driven Testing

• scripts/drone-simulator.cjs posts fully formatted mesh lines to /api/serial/simulate, bootstraps a node, and streams drone telemetry (drone + operator positions) every 5 s. Supply an ADMIN JWT via --token to drive end-to-end tests without field hardware—see Useful Scripts for usage.
• The simulator supports real RID/MAC lists, adjustable speeds, and node/operator geometry. Because it mirrors the on-air payload format, every downstream parser (inventory, FAA lookup, alarms, MQTT) exercises the exact same code path you get from the live mesh.

Mesh-Based Target Tracking

• How operators start tracking: promote a detection to a target, open the Targets page, and hit the Track button. You will be prompted for the tracking duration (10‑600 seconds). While a session is active the target row, map marker, and map overlay blink purple so the operator can see the estimation envelope in real time.
• What happens on the mesh: the command fan-outs to every node in the selected mesh/site. Each node reports periodic RSSI hits (and GPS lat/lon if available) for the MAC you selected. The backend’s TargetTrackingService ingests those detections inside a 45‑second sliding window, normalises each MAC, and weights the contribution from every node by RSSI strength. Direct GPS fixes from the triangulation nodes earn a higher weight, while simple RSSI-only hits are scaled by a BLE/WiFi path-loss model.
• Estimation algorithm: every batch of detections produces an intermediate centroid (great-circle average). We keep track of contributors, distance spread, total weight, and sample count so the operator sees where the “probable” device position sits. Successive estimates are smoothed to avoid jitter, and a persistence gate ensures we only write to the database every ~15 seconds or once the estimate moves ~8 metres. Confidence is clamped between 0–1 and reflects both RSSI strength and node diversity; single-node sightings never exceed the floor.
• Why antenna consistency matters: the algorithm assumes each node's antenna gain, orientation, and cable length are roughly the same. If one node has a wildly different antenna the RSSI weighting becomes biased and the centroid will drift toward that node. Always field the same antenna cut/length and mount height when you want high-confidence estimates.
• Mesh density expectations: tracking is most accurate inside the convex hull of the mesh. You can still “track” a MAC outside the mesh, but the estimate will hug the nearest node because it only has one line of bearing. The more evenly spaced your omni nodes are, the more believable the interpolation becomes. Think of it as RSSI-based trilateration rather than precise GNSS.
• Spacing guidance: plan for at least ~50 m spacing between nodes. Tighter spacing boosts confidence and reduces dilution of precision; wider spacing works, but the estimator has less overlap between coverage lobes and will “snap” toward the loudest node.
• Limitations & reflections: this is an estimation tool. It does not account for multipath reflections, terrain shielding, buildings, or antenna tilt. Treat the purple overlay as a probable region, not a guaranteed fix—obstacles and RF noise will widen the true uncertainty.

Alert Automation & Integrations

• Custom Alerts module: build rules that match MACs, OUI prefixes, SSIDs, channels, RSSI windows, or inventory devices. Each rule controls its own alarm level, optional audible, and map styling (color, icon, blink, label). Promotions from Inventory drop straight into rule criteria so analysts can set up a watch list in seconds.
• Alert Event Log: the Alerts nav rail contains an Event Log page that mirrors Config’s layout—dark rail on the left, stacked cards on the right—so you can filter, search, and acknowledge past alert hits without leaving the module.
• Webhook engine: alert matches, inventory updates, node telemetry, and raw serial traffic can fan out to HTTPS endpoints with optional mutual TLS (CA bundle + client cert/key) and HMAC signatures. Hooks are configured under Config → Webhooks with inline testing, per-event subscription toggles, and automatic delivery logging.
• Secure runtime: webhook dispatchers let you disable TLS validation for lab setups or enforce full-chain verification in production. Client certificates and private keys are stored encrypted in the database, and Prisma migrations now cover inventory update events plus serial/raw tap targets.
• Operator UX: the Alerts, Config, and Addons pages now share the same shell (sidebar buttons outside the card, stacked sections within) so the experience is consistent no matter which subsystem you configure.

Sentinel Command Console & Attack Telemetry

• Sentinel lifecycle commands: the Console can arm/disarm the passive WiFi attack detector per node with SENTINEL_ON / SENTINEL_OFF, pull its live state with SENTINEL_STATUS, switch between SENTINEL_MODE:scan (channel-hopping) and SENTINEL_MODE:defend (AP-channel pinned), and persist auto-start across reboots with SENTINEL_BOOT:on / SENTINEL_BOOT:off.
• Detector groups & tuning: GROUP:<name>:<on|off> enables or disables a whole detector family per node (dos, rogue, recon, physical, mesh, or all); DETECT_CFG:<json> pushes tunable detector thresholds (JSON, ≤180 chars) and DETECT_CFG_GET reads the node's active configuration back over mesh.
• Incident log: INCIDENTS[:<count>] (count 1-200) requests the node's Sentinel incident ring buffer over mesh; INCIDENTS_CLEAR wipes it.
• Mesh de-dup controls: CONFIG_DEDUP_TTL:<0-3600> sets the cross-scan MAC de-dup TTL (seconds), CONFIG_SESSION_DEDUP:<0|1> toggles per-session de-dup, and MESH_DEDUP_CLEAR flushes the de-dup cache.
• Erase authorization: CONFIG_ERASE_PSK:<key> (1-64 chars) sets the pre-shared key that gates erase/factory-reset commands, and FACTORY_RESET:<FULL|CONFIG|DATA>:<credential> factory-resets a single targeted node against that credential.
• Attack telemetry ingest: the backend now parses Sentinel WiFi attack detections (<nodeId>: <TYPE>:<fields>) covering rogue-AP attacks (evil-twin, OWE-downgrade abuse, karma/MANA candidate + confirmed), credential-harvesting activity (PMKID forge/harvest, EAPOL bait, handshake capture, KRACK), flood/DoS activity (deauth flood/forge/AP-targeted, beacon flood/forge, auth flood, assoc-sleep, SAE DoS, probe floods and their behavioral/AP-targeted variants), recon and physical-layer abuse (SSID confusion, FragAttacks, generic recon, attacker-hunt, PHY jamming), and Pwnagotchi beacon fingerprints -- plus mesh-guard intrusion alerts (self-spoof, mesh flood, command injection), baseline DEVICE_DISAPPEARED events, and RemoteID relay frames (