Add 12x recon payload, 1x general payload, and 1x deploy tool for quick redeploy after firmware update

[brent-mills-engineering]

Summary

Contributes 13 new Shark Jack Display payloads (12 recon, 1 general) plus a
host-side deploy helper. This is purely additive: none of these paths exist in
the current repo, so no existing files are modified.

All tested on firmware 1.0.1

• Most payloads were tested on a local router with mixed ethernet and wifi network spread across 3 VLANs
• Direct Host Profiler payload was tested against a Clockwork Pi UConsole and a Lenovo Thinkpad
• Remote Debug Bridge payload was tested using a GCE VM in GCP
• Deploy Shark script was tested on two SharkJackDisplay models on both 1.0.0 and 1.0.1.
• Net Map Explorer artifacts can be visualized using dot or mmdc

Added

Path	Category	What it is
payloads/library/general/remote_debug_bridge/	general / remote-access	Reverse SSH bridge: opens an outbound tunnel to a known host, providing remote access back into a Linux host on the affected network.
payloads/library/recon/dhcp_dns_ad/	recon	DHCP + DNS / AD Profiler: one-pass answer to "what kind of network is this?" (DHCP lease, DNS, Active Directory domain).
payloads/library/recon/direct_host_profiler/	recon	Fingerprints a single unknown device cabled directly to the Shark Jack (identity, services, OS hints).
payloads/library/recon/full_recon/	recon	Wired Network Recon + Loot: plug in, walk away, come back to a tidy on-device loot report.
payloads/library/recon/jack_survey/	recon	Jack Survey / Drop Validator: validates one wall jack (link, PoE, VLAN, DHCP, reachability).
payloads/library/recon/net_map_exporter/	recon	Discovers the local segment and exports a network map / diagram of the drop.
payloads/library/recon/passive_listen/	recon (passive)	Brings the link up, transmits almost nothing, and passively listens to characterize the segment.
payloads/library/recon/poe_survey/	recon (passive)	Passive PoE survey of a drop (class and power signaling).
payloads/library/recon/port_id_beacon/	recon (passive)	Passive cable-tracing beacon to trace an unknown wall jack back to its switchport.
payloads/library/recon/posture_quickhits/	recon / assessment	Security Posture Quick-Hits: sweeps live hosts for the findings that drive remediation (default-community SNMP, SMB enumeration).
payloads/library/recon/risky_devices/	recon / assessment	Rogue / Risky Device Detector: flags devices that don't belong or that nobody remembers plugging in.
payloads/library/recon/segmentation_egress/	recon / assessment	Segmentation + Egress Check: characterizes what a single drop is allowed to reach, internally and out to the internet.
payloads/library/recon/voice_camera_discovery/	recon (passive)	Passive discovery of VoIP phones and IP cameras (voice / camera VLAN signaling).
tools/deploy-shark/	tooling	Host-side helper (deploy-shark.sh, README.md, shark.conf.example) to push payloads onto the device over SSH.

Each payload ships with both a payload.txt and a README.md.

Changed

None. No existing files in this repository are modified by this PR.

New supporting files (justification)

• tools/ directory for deploy-shark: this script runs on the operator's workstation, not on the Shark, so it does not belong under payloads/library/; a top-level tools/ keeps host-side helpers cleanly separated from device payloads.
• tools/deploy-shark/.gitignore: ignores the operator's real shark.conf (site-specific IPs, hostnames, and overrides) so only the tracked shark.conf.example template ships, and no environment-specific data is ever committed.
• Root .gitignore: ignores .DS_Store so macOS contributors don't accidentally commit Finder metadata into the repository.

[thenrglabs]

These are interesting ideas but use strange syntax like "Glow" instead of the inbuilt duckyscript helpers like LED and leave the sharkjacks LED in strange states upon completion. I would look into using the Duckscript helpers and tightening up these scripts very cool stuff though man!

[brent-mills-engineering]

strange syntax like "Glow" instead of the inbuilt duckyscript helpers like LED and leave the sharkjacks LED in strange states upon completion.

So I had a theory and plan on that one, but I didn't really take advantage of it and then just copied the glow() wrapper around LED from one payload to the next. If you don't reach a true terminal state, it can leave the LED in the last state. Since the use case for the wrapper hasn't really materialized, I'll go back to the builtin LED helper

[brent-mills-engineering]

I removed my glow() wrapper and fell back to LED instead. I also removed the wrappers for spin_up() and spin_down() with CREATE_SPINNER and STOP_SPINNER as they didn't have any meaningful benefit other than being easier to write. And replaced say() with SCREEN_WRITE. This last one did offer the ability to collapse multiple arguments into a single string, but I never used it, so it can go for simplicity sake.

I left the bounded DHCP-wait loop (for i in $(seq 1 $DHCP_WAIT_SECS) on ip -o -4 addr show eth0) instead of WAIT_FOR_IP in my recon payloads (full_recon, jack_survey, net_map_exporter, dhcp_dns_ad, posture_quickhits, risky_devices, and segmentation_egress), since WAIT_FOR_IP blocks forever. This one allows a configurable timeout via DHCP_WAIT_SECS.