Add reverse-engineering security skills

strix/skills/README.md

@@ -43,15 +43,24 @@ Notable source-aware skills:
 - `source_aware_sast` (custom): semgrep/AST/secrets/supply-chain static triage workflow
 - `dependency_cve_scanning` (custom): trivy-based SCA workflow for reporting known dependency CVEs via `create_dependency_report`
 - `npx_confusion` (custom): npx/npm exec/bunx fallback and adjacent package-runner identity confusion, with runner-specific registry and reporting gates
+- `semantic_confusion` (vulnerabilities): cross-boundary parser, normalization, and representation mismatch analysis
 - `agentic_system_security` (vulnerabilities): effective-authority and MCP/tool ecosystem security testing
+- `browser_security` (vulnerabilities): browsing-context, postMessage, XS-Leaks, service-worker, and cross-origin state-machine testing
 - `azure` (cloud): Azure and Microsoft Entra privilege, PIM, workload identity, and cross-plane escalation analysis
 - `infrastructure_lifecycle` (reconnaissance): abandoned or mutable external dependencies such as update endpoints, MX, storage, and control domains
 - `argument_injection` (vulnerabilities): shell-free CLI option smuggling, secondary argument-file parsing, and platform-specific argv transformation boundaries
+- `electron_desktop_apps` (technologies): Electron renderer-to-native trust boundaries, preload/IPC exposure, and navigation analysis
 
 Notable LLM security skills:
 - `llm_applications` (technologies): end-to-end OWASP 2026 LLM01-LLM10 coverage across models, RAG, vectors, agents, tools, outputs, supply chain, and resource controls
 - `llm_prompt_injection` (vulnerabilities): deep direct, indirect, multimodal, memory, and tool-result prompt-injection testing
 
+Notable reverse-engineering skills:
+- `advisory_to_poc` (custom): advisory-to-root-cause workflow for patch diffing, public PoCs, and detector design
+- `appliance_firmware` (technologies): appliance artifact, runtime, and install-state analysis
+- `protocol_reverse_engineering` (protocols): stateful/custom protocol reconstruction and controlled harnessing
+- `memory_corruption` (vulnerabilities): native crash triage, primitive quality, and exploitability constraints
+
 ---
 
 ## 🎨 Creating New Skills

strix/skills/custom/advisory_to_poc.md

@@ -0,0 +1,235 @@
+---
+name: advisory-to-poc
+description: Vulnerability research workflow for turning advisories, patches, release artifacts, public PoCs, and incident clues into root-cause analysis, safe reproducers, reliable detectors, patch-bypass review, and adjacent-bug hypotheses
+---
+
+# Advisory to PoC
+
+Use this skill for authorized product-security and n-day research where the starting point is an advisory, fixed release, patch, public PoC, or incident evidence rather than a known vulnerable endpoint.
+
+The goal is a version-bounded root-cause explanation and reliable, reproducible validation. Do not equate a changed function, crash, scanner hit, or advisory claim with exploitability.
+
+## Evidence Ledger
+
+Keep facts, inferences, and experiments separate:
+
+| Type | Examples |
+|---|---|
+| Published fact | affected versions, CWE, exposed feature, vendor mitigation |
+| Artifact fact | changed function, new validation, removed route, configuration delta |
+| Inference | likely attacker-controlled field, suspected auth path, probable sink |
+| Experiment | vulnerable response, fixed response, crash, OAST callback, file canary |
+
+Record source URL, artifact hash, product edition/branch, build number, platform, configuration, and date. Re-check assumptions whenever the experimental result conflicts with the advisory narrative.
+
+## Research Workflow
+
+### 1. Scope the Claim
+
+- Extract affected and fixed versions, branches, platforms, roles, protocols, and feature/configuration prerequisites.
+- Note whether the vendor describes impact, root cause, mitigation, or only a CWE category.
+- Treat bundled CVEs and large release rollups as multiple candidate changes until proven otherwise.
+- Identify whether the issue is pre-auth, low-privilege, post-auth, local, or requires a victim/session bridge.
+
+### 2. Acquire Comparable Artifacts
+
+Prefer the closest vulnerable/fixed pair for the same edition and platform:
+
+- source commits, tags, tests, pull requests, and dependency lockfiles
+- packages, containers, installers, JAR/WAR/DLL/assemblies, Python bytecode, firmware, or VM images
+- web-server/reverse-proxy configuration, service definitions, scripts, and bundled third-party components
+- documentation and shipped examples that reveal routes, protocols, defaults, or extension points
+
+Hash originals and work on copies. Preserve installation lineage: default credentials, generated keys, legacy files, and retained configs may matter even if a fresh fixed install does not contain them.
+
+### 3. Reduce Diff Noise
+
+Start with inventories before line-by-line analysis:
+
+- added/removed/renamed files and dependencies
+- changed routes, authorization annotations, allowlists/denylists, parser calls, command construction, length checks, and deserialization types
+- edge configuration changes that block or rewrite a route without changing application code
+- tests added, removed, or updated; these often encode a near-ready reproducer
+- sibling call sites of the changed helper or validator
+
+For binaries, combine string/import/symbol diffing with a decompiler and a second diffing method when possible. Large compiler or bundled-library changes create false clusters; anchor on advisory-relevant constants, protocol handlers, response strings, and call graphs.
+
+### 4. Map External Reachability
+
+Work from both directions:
+
+```text
+external listener -> edge config -> router -> authentication -> parser -> sink
+known changed sink -> callers -> route/protocol -> authentication -> external listener
+```
+
+Inventory auxiliary listeners, management agents, sidecars, localhost APIs, custom RPC services, CGI/script dispatch, and framework direct-component routes. Do not assume the main web UI's authentication protects every product service.
+
+Record branch-specific and configuration-specific exposure. A powerful sink behind a disabled feature or unreachable route is not a pre-auth vulnerability.
+
+### 5. Explain the Patch Mechanism
+
+State what security invariant the patch tries to restore:
+
+- bounds, termination, initialization, or length/type consistency
+- authentication/authorization before dispatch
+- canonicalization before comparison
+- allowlisted deserialization or reflection targets
+- safe command/process APIs instead of shell construction
+- file path confinement and extension/handler restrictions
+- route removal or edge blocking
+- session-field filtering or trustworthy state reconstruction
+
+Then ask what the patch did not change: alternate callers, sibling parsers, secondary routes, nested gadgets, transitive deserialization, old aliases, different protocol handlers, and edge/application disagreement.
+
+### 6. Build a Reproducer Ladder
+
+Escalate one capability at a time:
+
+1. **Presence** - product/version/protocol fingerprint with low noise
+2. **Reachability** - expected route/parser/handler responds
+3. **Security differential** - unauthorized behavior differs from a denied control
+4. **Primitive** - safe read, controlled callback, canary write, harmless constructor, or deterministic crash in an isolated lab
+5. **Impact** - demonstrate the requested authorized impact and preserve its prerequisites
+
+Prefer distinctive non-secret response structure, benign errors, OAST DNS/HTTP callbacks, inert file markers, or no-op commands. For deserialization, use a non-executing network gadget before command execution. For memory corruption, establish the bug and mitigation constraints in a lab; a connection close or crash is not proof of RCE.
+
+### 7. Calibrate on Controls
+
+Run the same reproducer against:
+
+- vulnerable version
+- fixed version
+- unaffected neighboring version where available
+- feature disabled / hardened configuration
+- malformed but non-triggering negative input
+- authentication present vs absent, if the claim crosses an auth boundary
+
+Repeat enough times to distinguish deterministic behavior from crashes, timing noise, worker restarts, load balancers, and transient network failures.
+
+### 8. Hunt Adjacent and Partial Fixes
+
+After reproducing the primary issue:
+
+- enumerate every call site of the patched function/validator
+- cluster nearby handlers using the same parser, session format, command wrapper, or file primitive
+- replay the old PoC and structural variants against the first fixed version
+- inspect whether the patch blocks the route while leaving the sink reachable elsewhere
+- test nested/transitive objects rather than only top-level denylisted types
+- check whether one advisory/CVE bundles multiple distinct vulnerable paths
+
+Do not call a variant a bypass until the fixed version demonstrably remains vulnerable.
+
+## Tool Routing
+
+Use the lightest maintained tool that answers the current question. Pin versions in research notes and preserve generated outputs so another analyst can reproduce the diff.
+
+### Artifact and Package Diff: diffoscope
+
+[diffoscope](https://diffoscope.org/) is the default first pass for packages, directories, archives, and binaries. Use it to build a changed-file/config/package manifest before opening a decompiler. For hostile artifacts, keep inputs read-only, disable network, and run the helper-heavy comparison in an isolated environment.
+
+### Firmware and Appliance Artifacts
+
+When the starting point is firmware, a virtual appliance, or a nested image format, load `appliance_firmware`. That skill owns extraction, package/rootfs/runtime correlation, Ghidra/BinDiff routing, overlay/install-state analysis, and device-lifecycle caveats.
+
+### Java/JVM: Vineflower
+
+Use maintained [Vineflower](https://github.com/Vineflower/vineflower) for JAR/class decompilation. Diff archive inventories before decompiled text; compiler, obfuscator, and synthetic-code changes produce noise. Confirm suspicious control flow with bytecode (`javap -c`) rather than treating reconstructed Java as source truth.
+
+### .NET: ILSpy / ilspycmd
+
+Use [ILSpy](https://github.com/icsharpcode/ILSpy) for managed assemblies. Work offline, inspect IL/metadata when the C# reconstruction is ambiguous, and use only GitHub Releases or NuGet.
+
+### Native Code: Ghidra and BinDiff
+
+Use official [Ghidra](https://github.com/NationalSecurityAgency/ghidra) for cross-architecture disassembly/decompilation and [BinDiff](https://github.com/google/bindiff) only after the file/package diff has narrowed the relevant binaries. Keep the toolchain pinned, offline where practical, and non-executing. Decompiler output and similarity scores are triage aids, not proof.
+
+## Source and Binary Techniques
+
+### Source-Available Products
+
+- Search route declarations, filters/interceptors, auth decorators, and direct framework component dispatch.
+- Trace attacker-controlled fields through type coercion, validation, shell/process APIs, filesystem operations, reflection, template/XSLT evaluation, and deserialization.
+- Compare callers, not just the patched callee. The same helper may be safe in one route and exposed in another.
+- Read tests and examples for expected protocol syntax and serialized message shapes.
+
+### Managed Artifacts
+
+- Decompile JAR/WAR and .NET assemblies; diff namespaces/classes/method bodies and embedded configuration.
+- Trace public setters, opaque identifiers, type metadata, and framework serialization hooks.
+- Inspect bundled libraries and version changes, but prove application reachability before assigning impact.
+
+### Native Binaries and Firmware
+
+- Inventory architecture, mitigations, imports, strings, services, and exposed ports before deep reversing.
+- Diff functions around new bounds checks, initialization, string termination, length casts, command builders, and protocol parsers.
+- Reconstruct the smallest valid protocol state machine before mutating the suspected field.
+- Use debuggers, sanitizers, traces, and process monitors inside an isolated lab when available.
+- Separate bug existence from exploitability under ASLR, NX, stack canaries, allocator behavior, architecture, and restart model.
+
+### Public PoC or Incident First
+
+- First decompose and neutralize a public or captured PoC; reproduce its stages in an isolated lab while preserving the headers, ordering, sessions, and negotiation relevant to each stage.
+- Decompose the PoC into stages and identify the oracle for each stage.
+- Work backward from the final sink to root cause and forward from the entry point to confirm reachability.
+- If no patch pair exists, controlled honeypot/instrumentation can reveal in-the-wild request structure; never expose a live vulnerable system beyond an isolated, monitored environment.
+
+Pair `protocol_reverse_engineering` when the external entry point is binary, TLS-wrapped, message-oriented, or stateful.
+
+## Detector Design
+
+A detector must distinguish the vulnerable behavior reliably from fixed and unaffected behavior:
+
+- match a structural response or deterministic state change, not a secret value
+- use a unique per-target canary and clean it up when the test writes data
+- distinguish patched denial from generic 404/500, WAF blocking, authentication failure, and connection loss
+- complete protocol/session prerequisites instead of relying on a single raw request
+- rate-limit crash-prone or resource-intensive probes and keep them opt-in
+- calibrate templates against vulnerable, fixed, and negative-control targets
+
+When scaling, separate fingerprinting from exploitation. Presence can prioritize assets; it does not confirm the vulnerability.
+
+## Exploitability Triage
+
+Rate each condition explicitly:
+
+- attacker position and credentials
+- default vs optional feature/configuration
+- internet-facing vs auxiliary/local listener
+- data/byte/control precision
+- restart, race, victim action, or environment requirements
+- available mitigations and architecture
+- reliable primitive vs crash-only or unstable behavior
+- practical post-primitive chain in the product's default deployment
+
+Down-rate unrealistic chains even when the underlying bug is real. Conversely, revisit “low” primitives such as SSRF, reflection, arbitrary write, cache control, or information disclosure in product context; native admin features may convert them into RCE.
+
+## Validation Deliverable
+
+Include:
+
+1. exact affected/fixed artifacts and hashes
+2. authoritative published claims and unresolved ambiguity
+3. minimal relevant diff and restored invariant
+4. external route/protocol and auth/config prerequisites
+5. source-to-sink or packet-to-sink trace
+6. safe reproducer plus positive and negative controls
+7. vulnerable vs fixed results across repeat runs
+8. exploitability constraints and why the demonstrated impact follows
+9. adjacent paths reviewed and any partial-fix evidence
+
+## Anti-Patterns
+
+- Trusting the advisory CWE/title as the actual root cause
+- Diffing only application code while ignoring edge/proxy/service configuration
+- Treating any crash, close, 500, scanner alert, or changed function as exploitation
+- Running a weaponized public PoC before isolating its stages and side effects
+- Claiming pre-auth impact without tracing the complete auth and routing path
+- Assuming one CVE maps to one code path or one patch fixes the whole vulnerability class
+- Searching only for the published payload instead of the restored invariant
+- Reporting a registry/download/callback signal without separating automated noise from authentic target execution
+- Generalizing from one appliance/version/configuration without testing prerequisites
+
+## Summary
+
+Advisory-driven research is evidence-driven reverse engineering. Acquire comparable artifacts, reduce the diff to a security invariant, prove external reachability, climb a safe reproducer ladder, calibrate against fixed and negative controls, and then audit sibling paths and partial fixes. The reusable output is the method and invariant—not the vendor-specific exploit string.

strix/skills/custom/source_aware_sast.md

@@ -105,6 +105,18 @@ tree-sitter parse -q <file>
 
 Use outputs to improve route/symbol/sink maps for subsequent targeted scans.
 
+## Cross-Component Semantic Mapping
+
+Pattern scanners find local sinks but often miss a security decision in one component followed by a different interpretation in another. For complex middleware, proxies, frameworks, and plugin systems:
+
+1. Identify shared request/context fields and every writer/reader.
+2. Order the readers and writers by lifecycle phase: parse, route, authenticate, rewrite, authorize, dispatch, render.
+3. Mark fields whose semantic type changes (URL/path, MIME/handler, alias/package, external/internal route).
+4. Trace normal, error, retry, subrequest, and internal-redirect paths separately.
+5. Compare the representation checked by security code with the representation consumed by the final sink.
+
+Load `semantic_confusion` when this graph reveals overloaded fields, multiple parsers, normalization steps, or protocol translation.
+
 ## Resolution and Namespace Risks
 
 In repositories with developer tooling, plugins, templates, or package runners, inspect lookup order rather than only dependency versions:

strix/skills/protocols/protocol_reverse_engineering.md

@@ -0,0 +1,176 @@
+---
+name: protocol-reverse-engineering
+description: Authorized analysis of undocumented, proprietary, binary, or stateful network protocols using passive captures, client/server artifacts, explicit state machines, bounded lab harnesses, and semantic vulnerable-versus-fixed validation
+---
+
+# Protocol Reverse Engineering
+
+Use this skill when an exposed service cannot be tested correctly as isolated HTTP-like requests: custom RPC, binary framing, TLS-wrapped management protocols, message queues, VPN negotiation, in-band control records, or any protocol whose authentication and parsing depend on prior state.
+
+The objective is a reviewable protocol model and controlled evidence that proves or disproves a security property. A socket connection, completed TLS handshake, `200`, or parser crash does not prove authentication, authorization, or code execution.
+
+## Authorization and Safety Boundary
+
+- Work from supplied artifacts, offline captures, or an isolated lab target unless active testing is explicitly authorized.
+- Prefer offline parsing. Captures may contain credentials, session material, personal data, or private topology; minimize, encrypt, redact, and expire them.
+- Never replay production credentials or captured authentication material.
+- Put active harnesses in a network namespace or isolated VLAN with an explicit destination allowlist, low rate, bounded retries, and one mutation at a time.
+- Do not broadcast, scan unrelated addresses, or start mutation/fuzz loops by default.
+- Treat a malformed-packet crash as a denial-of-service test. Perform it only in a restartable lab and never infer RCE from it.
+
+## Build the Protocol Model
+
+Record each layer separately:
+
+| Layer | Questions |
+|---|---|
+| Transport | TCP, UDP, HTTP tunnel, queue, Unix socket, reconnect behavior? |
+| Security | TLS/mTLS, certificate role, message MAC/signature, encryption boundary? |
+| Framing | magic, version, type, flags, length, checksum, terminator, nesting? |
+| State | negotiation, challenge, authentication, session, command, teardown? |
+| Identity | where is peer/user/device identity introduced and verified? |
+| Authorization | which state or role permits each operation? |
+| Data model | integers, strings, TLV, XML/JSON, compression, serialization? |
+| Responses | acknowledgements, errors, correlation IDs, timing, connection close? |
+
+Maintain a message-field ledger:
+
+```text
+offset/path | size/type | endian/encoding | producer | consumer | validation | state | confidence
+```
+
+Label every statement as observed, inferred, or experimentally confirmed. Unknown bytes remain unknown; do not name them after a single sample.
+
+## Workflow
+
+### 1. Collect Passive Evidence
+
+Use, in order of preference:
+
+- official protocol or integration documentation
+- offline captures of a legitimate client/server exchange
+- client binaries, SDKs, schemas, constants, error strings, and debug logs
+- server handlers, dispatch tables, configuration, and certificate logic
+- vulnerable/fixed captures or binaries from the same branch
+
+Use two supplied or explicitly authorized successful sessions and controlled variations when available. Otherwise record the evidence gap; do not obtain or replay production credentials merely to complete the model. Compare message boundaries, counters, nonces, lengths, identity fields, and state-dependent responses. Keep the original capture immutable and hash it.
+
+Use [TShark](https://www.wireshark.org/docs/man-pages/tshark.html) for reproducible offline extraction:
+
+```bash
+tshark -r session.pcapng -q -z conv,tcp
+tshark -r session.pcapng -Y 'tcp.stream == 0' -T fields \
+  -e frame.number -e tcp.seq -e tcp.len -e tcp.payload
+```
+
+Prefer `-r` over live capture. Do not run Wireshark/TShark as root, capture unrelated production traffic, or assume dissector output is safe or correct; use a patched build in an isolated environment for hostile captures.
+
+### 2. Reconstruct Framing Before Meaning
+
+- Reassemble streams before assigning message boundaries; TCP packets are not application messages.
+- Test length hypotheses against multiple messages and both directions.
+- Identify byte order, signedness, alignment, padding, compression, and checksums.
+- Separate outer transport/tunnel framing from the inner application message.
+- For nested formats, model each parser boundary independently.
+- Reject impossible lengths before allocation, recursion, decompression, or slicing.
+
+When the layout stabilizes, encode it in a declarative grammar such as [Kaitai Struct](https://kaitai.io/). Add `valid` constraints and strict size/count limits; generated parsers can still allocate or recurse dangerously on hostile lengths. Keep compiler/runtime versions aligned and regression-test the grammar on positive, truncated, oversized, and unknown-type samples.
+
+### 3. Recover the State Machine
+
+Write transitions explicitly:
+
+```text
+DISCONNECTED -> TRANSPORT -> NEGOTIATED -> PEER_VERIFIED
+             -> USER_AUTHENTICATED -> AUTHORIZED -> OPERATION
+```
+
+For every transition, record:
+
+- initiating message and required prior state
+- server-side check and identity source
+- success, denial, and malformed responses
+- state stored across messages or reconnects
+- timeout/replay/counter behavior
+- whether an alternate message type reaches the same handler
+
+Distinguish transport establishment, peer verification, user authentication, session creation, role authorization, and successful privileged action. Prove the specific boundary relevant to the security claim.
+
+### 4. Trace Fields to Decisions and Sinks
+
+From binaries or source, anchor on message IDs, error strings, constants, certificate handling, dispatcher tables, and changed functions. Trace attacker-controlled fields through:
+
+- length arithmetic, allocation, copy, termination, and integer conversion
+- parser state, tag nesting, recursion, and unknown-field behavior
+- identity selection, trust flags, signature/certificate verification, and session lookup
+- shell/process calls, filesystem paths, deserialization, reflection, or product-native admin operations
+
+Decompiler output is a hypothesis. Confirm important conditions in assembly, bytecode, runtime logs, or controlled packet results.
+
+### 5. Build a Bounded Active Harness
+
+Only craft packets after valid framing and state are understood. [Scapy](https://scapy.readthedocs.io/en/stable/) is appropriate for packet layers and stateful automata:
+
+```bash
+python -m pip install 'scapy==<reviewed-version>'
+```
+
+Start with a local responder or replay parser, not the appliance. Preserve a known-good transcript, mutate one semantic field, recompute dependent lengths/checksums, and compare the response. The harness must enforce:
+
+- exact destination/port allowlist
+- one target and one mutation by default
+- rate, packet count, response size, timeout, and retry ceilings
+- no broadcast/multicast and no automatic crash retry
+- artifact logging without credentials or secret payloads
+- cleanup and target health check after each risky case
+
+Raw sockets may require privilege; isolate socket creation and drop privileges afterward where possible.
+
+### 6. Design Semantic Experiments
+
+Prefer experiments that answer one question:
+
+- Does an invalid identity or signature reach the authorized state?
+- Does a declared length govern copying, parsing, or only framing?
+- Do duplicate/unknown fields change the selected handler?
+- Does patched behavior add validation, change state, or block an outer route?
+- Does a response prove the operation, or merely that dispatch began?
+
+Use vulnerable, fixed, and malformed-negative controls. Repeat enough to separate deterministic semantics from loss, retransmission, process restart, load balancing, and timeout noise.
+
+## Safe Oracles
+
+Prefer, from least to most invasive:
+
+1. distinctive protocol/version field
+2. deterministic denial-versus-accept response
+3. synthetic-account no-op or non-secret lab read
+4. unique constant callback through explicitly authorized, preferably self-hosted OAST
+5. inert canary write with cleanup
+6. process execution only under separate explicit authorization when no lower-harm oracle can establish the required impact
+
+A connection close is normally an ambiguous result. If crash validation is unavoidable, combine lab-only process logs, restart evidence, and a non-triggering control; report bug existence separately from exploitability.
+
+When the starting point is an advisory, fixed build, patch, or public PoC, pair this skill with `advisory_to_poc` for evidence classification, artifact comparison, and partial-fix review.
+
+## Patch and Version Differentials
+
+- Compare message/state behavior across the closest vulnerable and fixed builds of the same branch.
+- Derive a fingerprint from the restored invariant, not only from banners.
+- Check configuration, certificate role, feature enablement, architecture, and deployment mode.
+- Treat protocol differences as version evidence unless they directly prove vulnerable behavior.
+- When one handler is patched, enumerate sibling message types, alternate transports, and pre-auth dispatch paths using the same parser or decision.
+
+## Validation Deliverable
+
+Include:
+
+1. target versions, platform, configuration, and artifact/capture hashes
+2. layered protocol diagram and message-field ledger
+3. explicit state machine and identity/authentication/authorization boundaries
+4. source/binary trace for the relevant field and decision
+5. bounded harness with rate/destination safeguards
+6. vulnerable, fixed, and negative-control results
+7. minimum safe oracle and any side effects/cleanup
+8. unresolved fields, assumptions, and confidence levels
+9. bug-existence versus exploitability assessment

strix/skills/technologies/appliance_firmware.md

@@ -0,0 +1,253 @@
+---
+name: appliance-firmware
+description: Security analysis of appliances and firmware through artifact provenance, safe extraction, root filesystem and runtime mapping, listener and trust-boundary inventory, patch comparison, managed/native code triage, hardware constraints, and isolated device validation
+---
+
+# Appliance and Firmware Analysis
+
+Use this skill for VPNs, firewalls, storage/backup systems, management appliances, embedded products, virtual appliances, and other packaged systems where security behavior is split across firmware, web-server configuration, native daemons, scripts, managed services, generated state, and hardware-specific runtime details.
+
+Appliance research is architecture research. The public web UI is only one entry point; auxiliary listeners, localhost APIs, sidecars, support agents, update services, telemetry jobs, package installers, and product-native administration features often carry equal or greater authority.
+
+## Build and Artifact Matrix
+
+Record before comparing anything:
+
+| Dimension | Examples |
+|---|---|
+| Product | model/SKU, physical/virtual/cloud image, edition/license |
+| Software | marketing version, build/revision, branch, hotfix, package set |
+| Platform | architecture, endian, kernel, libc, bootloader, filesystem |
+| Install state | factory image, upgraded system, migrated config, retained files |
+| Configuration | feature flags, listeners, authentication mode, HA/cluster role |
+| Artifact source | vendor download, updater, installed disk, backup, marketplace |
+| Update form | full image, delta package, component hotfix, rollback bundle |
+| Authenticity | signature/encryption state, certificate/key ID, manifest/base-version requirement |
+
+Hash original artifacts and preserve acquisition metadata. A neighboring version from a different SKU, edition, architecture, or installation lineage can produce a convincing but irrelevant diff.
+
+## Safe Extraction
+
+Treat firmware and every embedded archive/filesystem as hostile input. Extract as an unprivileged user into a fresh writable quota-limited output directory with no network, bounded recursion/processes, and read-only input.
+
+### unblob
+
+[unblob](https://github.com/onekey-sec/unblob) provides recursive extraction plus structured metadata for many firmware/container/filesystem formats. Prefer a reviewed container image digest:
+
+```bash
+appliance_out="$(mktemp -d)"
+docker run --rm --network none \
+  --read-only --cap-drop ALL --security-opt no-new-privileges \
+  --user "$(id -u):$(id -g)" --pids-limit 256 --memory 4g --cpus 2 \
+  --tmpfs /tmp:rw,noexec,nosuid,size=512m \
+  -v /path/to/input:/data/input:ro \
+  -v "$appliance_out":/data/output \
+  ghcr.io/onekey-sec/unblob@sha256:<reviewed-digest> \
+  -e /data/output -d 6 -p 2 --report /data/output/unblob.json \
+  /data/input/firmware.bin
+```
+
+Create the output directory first and ensure it is writable by the chosen UID/GID; otherwise the host may create a root-owned mount point. Never extract over an existing analysis tree. Inspect symlinks, device nodes, archive paths, decompression ratios, and output size before interacting with the tree.
+
+### diffoscope
+
+Use [diffoscope](https://diffoscope.org/) for a recursive format-aware first comparison of vulnerable/fixed directories, packages, images, JARs, and executables:
+
+```bash
+diffoscope --html diffoscope.html vulnerable-root/ fixed-root/
+```
+
+Run it in an isolated reviewed container when processing hostile artifacts because it invokes many external format helpers. Use the first report to narrow files/config/packages rather than repeatedly expanding the entire image.
+
+Use the unblob report and packaged filesystem metadata for ownership, mode, xattr, capability, and device-node claims; a host extraction run under your own UID can intentionally remap them. Do not mount an untrusted extracted filesystem or `chroot` into it on the analyst host.
+
+## Filesystem and Boot Architecture
+
+Inventory:
+
+- partition table, bootloader, kernel, initramfs, SquashFS/UBIFS/ext filesystems
+- init system, service definitions, inetd/socket activation, rc scripts, supervisors, and watchdogs
+- read-only base image versus writable overlay, tmpfs, bind mounts, containers/chroots, and persistent data partitions
+- factory defaults, first-boot generation, upgrade/migration scripts, rollback slots, and retained legacy files
+- environment files, credentials, certificates, secrets, licenses, databases, sessions, caches, and backup/restore formats
+- cron/timers, log rotation, telemetry, diagnostics, update checks, package deployment, support bundles, and cleanup tasks
+- ownership, group membership, capabilities, setuid/setgid, ACLs, sudo/doas rules, device access, and IPC permissions
+
+Static extracted files may not match runtime. Boot-time scripts can patch files, mount overlays, generate configs, copy certificates, activate routes, or replace binaries. Capture live filesystem/mount/process state when an apparently relevant change is absent from the disk image.
+
+## Update and Installed-State Reconstruction
+
+Before trusting a package or image diff, reconstruct how the device installs it:
+
+- verify signature and manifest order, trust anchors, and whether integrity/authenticity checks cover the whole payload or only a wrapper
+- distinguish full image, delta update, component hotfix, and required base version
+- identify target partition, boot slot, rollback path, and anti-rollback/version checks
+- review pre/post-install hooks, migrations, symlink changes, permission/capability changes, and retained/generated state
+- map overlay, bind-mount, and generated-file precedence over the extracted rootfs
+- test fresh install versus upgraded and partially rolled-back states
+- reconcile package contents with hashes/build IDs from the actual running process and live filesystem
+
+Record package-manager databases, shipped SBOM/manifests, bundled library copies, loader path, and `RPATH`/`RUNPATH` so you can distinguish a vulnerable library on disk from the library the running process actually maps.
+
+## Listener and Service Map
+
+Build a table for every network and local endpoint:
+
+```text
+address/port/socket | transport/TLS | process | config/init source
+route/message type | authentication | authorization | privilege | feature/default
+```
+
+Include:
+
+- HTTP(S) UI/API, CGI/FastCGI, WebSocket, SOAP, SAML/OIDC, upload/download
+- SSH/SFTP, VPN/IKE, message queues, databases, backup/storage protocols
+- proprietary TLS/RPC, cluster/HA, device-manager, agent, and telemetry ports
+- loopback/Unix sockets, localhost APIs, sidecars, containers, and debug/support agents
+- outbound update/download endpoints and trusted remote control planes
+
+For outbound updater, telemetry, licensing, or control-plane names, record authoritative DNS/ownership, TLS identity and pinning, proxy/fallback behavior, request data, failure behavior, manifest integrity, payload integrity, rollback/version policy, and whether the external domain, bucket, package, or provider resource can expire or be reassigned.
+
+Map edge configuration to code: reverse-proxy rules, rewrites, location blocks, authentication modules, trusted client-IP headers, TLS client certificates, and backend socket selection. A handler can be patched while a new edge rule merely hides it—or vice versa.
+
+## Trust and Authorization Boundaries
+
+Trace:
+
+```text
+external listener -> proxy/config -> router/dispatcher -> authentication
+                  -> parser -> privileged operation -> OS/service identity
+```
+
+Test conceptual boundaries such as:
+
+- public versus management interface
+- external versus localhost/sidecar trust
+- managed device versus manager/controller trust
+- cluster peer, certificate, flag, or registration state
+- web user versus OS/service/database authentication
+- direct route versus internal redirect/component dispatch
+- fresh install versus upgraded/retained installation state
+- optional feature disabled versus installed-but-reachable handler
+
+Successful TCP/TLS/WebSocket negotiation proves transport reachability, not authenticated identity or authorization. Determine the actual privileged result and which server-side flag/session/role enabled it.
+
+## Code and Configuration Triage
+
+### Scripts and Configuration
+
+- Trace Apache/nginx/lighttpd rules, CGI mappings, environment variables, and shell/Perl/Python/PHP scripts.
+- Search command construction beyond obvious shell metacharacters: arithmetic expansion, config files, response files, argument injection, newline/control characters, and third-party CLI parsing.
+- Inspect support/debug functions, backup/restore, package install, log/telemetry processors, custom tags/templates, and native admin command runners.
+- Compare configuration and init/upgrade changes alongside application code.
+
+### Java/JVM and .NET
+
+- Use [Vineflower](https://github.com/Vineflower/vineflower) for Java class/JAR reconstruction and `javap -c` to confirm ambiguous bytecode.
+- Use official [ILSpy/ilspycmd](https://github.com/icsharpcode/ILSpy) for .NET assemblies and inspect IL/metadata when reconstructed C# is ambiguous.
+- Do not build or run decompiler output, target assemblies/classes, bundled build scripts, or embedded resources in their associated target runtimes/viewers.
+- Diff class/resource inventories before decompiled text to separate compiler/obfuscator noise from semantic changes.
+
+### Native Binaries
+
+- Use official [Ghidra](https://github.com/NationalSecurityAgency/ghidra) for strings/imports/xrefs/decompilation and reproducible headless projects.
+- Use [BinDiff](https://github.com/google/bindiff) after manifest/package triage isolates the relevant native binaries, and keep the disassembler/BinExport version pair compatible across both sides.
+- Confirm changed length, auth, command, parser, and file-handling conditions in assembly/runtime; decompiler types and similarity scores are hypotheses.
+- Record architecture-specific calling convention, endian, alignment, libc, allocator, and mitigations.
+
+Load `memory_corruption` for bounds/lifetime/disclosure findings and exploitability analysis. Load `protocol_reverse_engineering` for custom/stateful message formats.
+
+## Version and Patch Analysis
+
+Compare more than one adjacent pair when possible:
+
+```text
+older unaffected/unknown -> vulnerable -> first fixed -> current
+```
+
+- Build changed-file/package/config manifests first.
+- Identify the security invariant introduced by the patch.
+- Review every caller/sibling handler using the patched helper/parser.
+- Check branch backports and inconsistent fixes across SKUs/architectures.
+- Re-test the old structural condition on the fixed build and nearby routes.
+- Inspect boot/runtime overlays and upgrade scripts if static diff shows no meaningful change.
+- Distinguish one CVE from one code path; advisories may bundle several bugs or fix only the most exposed route.
+
+Pair with `advisory_to_poc` for evidence classification, public-PoC decomposition, vulnerable/fixed controls, and detector handoff.
+
+## Hardware, Virtualization, and Emulation
+
+Record what the test environment omits:
+
+- hardware security module/TPM/secure element and device-bound keys
+- NIC/accelerator/driver behavior, DMA, endian/alignment, and kernel modules
+- boot chain, secure boot, verified partitions, recovery mode, watchdog, and HA peer
+- model-specific memory, allocator pressure, process limits, and service configuration
+- virtual appliance differences from physical products
+
+Full-system emulation can help recover routes and protocol behavior but often changes drivers, timing, entropy, memory layout, certificates, hardware identity, and mitigations. Treat emulation results as a separate platform and reproduce security-relevant behavior on the actual supported model when the claim depends on those properties.
+
+Do not disable ASLR, canaries, signature checks, or other mitigations without labeling the resulting demonstration as lab-only and nonrepresentative of default exploitability.
+
+## Physical-Lab Prerequisites
+
+Have a recovery path before live-device work:
+
+- console, serial, hypervisor, snapshot, or other known-good rollback method
+- exact in-scope image/build and a way to reapply it
+- isolated management network and controlled outbound connectivity
+- process or watchdog visibility and a safe way to capture one request at a time
+
+## Runtime Observation
+
+Within an authorized lab, collect:
+
+- process tree, executable/build ID, argv, cwd, users/groups/capabilities, open ports/sockets/files, mounts, namespaces/containers
+- service logs, audit logs, core files, watchdog/restart events, and packet captures
+- loaded mappings/libraries, relevant Unix sockets/file descriptors, and config source while sending one known request
+- filesystem/process events while sending one known request
+- boot/upgrade output and live configuration generated from templates/databases
+
+Prefer observation that explains a static hypothesis. Do not install intrusive agents or attach a debugger to production equipment.
+
+## Capability and Chain Mapping
+
+Treat findings as product-context primitives:
+
+- file read → configs, sessions, credentials, tokens, keys, topology
+- SSRF/request → loopback APIs, sidecars, metadata, package agents
+- file write → web roots, plugins, templates, restore packages, jobs, telemetry inputs
+- auth bypass → support/admin command runners, package deployment, native operations
+- parser disclosure → session/token/pointer material
+- low-privilege identity → built-in management tools and trusted peer relationships
+
+Inventory native product consumers before importing a generic exploit gadget. An appliance's normal backup, restore, diagnostic, package, scripting, or cluster function is frequently the shortest bridge between primitives.
+
+## Deliverable
+
+Include:
+
+1. artifact provenance/hashes and complete SKU/version/platform/config matrix
+2. extraction method and filesystem/boot/runtime architecture
+3. listener/service/auth/trust-boundary map
+4. changed-file/config/package manifest and relevant code path
+5. external route/protocol through privileged operation and OS identity
+6. hardware/emulation/mitigation constraints
+7. vulnerable/fixed/negative-control behavior
+8. adjacent handlers/branches/install states reviewed
+9. tool versions, generated artifacts, and unresolved assumptions
+
+## Common Errors
+
+- Diffing different SKUs/architectures and attributing packaging noise to a security fix.
+- Assuming extracted rootfs equals live state despite overlays, generation, or boot-time patches.
+- Mapping only the web UI and missing auxiliary/custom/local listeners.
+- Treating a hidden route as removed or a blocked route as a patched sink.
+- Assuming fresh-install behavior covers upgraded systems with retained files/configuration.
+- Calling a service pre-auth because a connection succeeds before a privileged operation is attempted.
+- Treating emulator-only behavior or disabled mitigations as representative of a shipping device.
+- Running an analyzed binary, extension, build script, or firmware helper on the analyst host.
+
+## Summary
+
+Appliances are integrated systems, not single applications. Preserve artifact lineage, extract safely, map boot/runtime state and every listener, trace edge configuration into code and privileged native features, compare fixes across branches and install states, and keep hardware/platform constraints attached to every finding.

strix/skills/technologies/electron_desktop_apps.md

@@ -0,0 +1,181 @@
+---
+name: electron-desktop-apps
+description: Test Electron desktop applications across renderer, preload, IPC, main-process, navigation, custom-protocol, storage, permission, and update trust boundaries; use for packaged Electron apps, ASAR review, web-to-native capability analysis, and Electron-specific exploit chains
+---
+
+# Electron Desktop Applications
+
+Use this skill for Electron applications. Other webview desktop frameworks may share the high-level web-to-native trust question, but their bridge, sandbox, update, and process APIs differ; do not apply Electron-specific conclusions to NW.js, CEF, Tauri, or Wails without mapping that framework separately.
+
+Pair this skill with `browser_security` for browser state and navigation, `xss` for renderer injection, `argument_injection` for native subprocess launches, and `insecure_deserialization` or `rce` for a main-process sink.
+
+## Architecture and Authority Map
+
+Inventory each security principal and the capabilities crossing between them:
+
+```text
+origin + document + frame
+  -> renderer JavaScript
+  -> preload isolated world
+  -> contextBridge API
+  -> IPC channel
+  -> sender/argument/identity checks
+  -> main process or utility process
+  -> filesystem, process, credential, media, network, update, or OS action
+```
+
+Record:
+
+- Electron, Chromium, Node, and application versions
+- packaging form, `app.asar`, unpacked resources, entry point, and fuses
+- every `BrowserWindow`, `WebContentsView`, `<webview>`, session/partition, and child window
+- `webPreferences`: `preload`, `nodeIntegration`, `contextIsolation`, `sandbox`, `webSecurity`, `allowRunningInsecureContent`, experimental features, and subframe/worker integration
+- every preload export and every `ipcMain.handle`/`ipcMain.on` consumer
+- origins/documents/frames that can reach each exported API
+- custom protocols, deep links, navigation helpers, permissions, downloads, storage, and update channels
+
+Do not infer authority from a setting or channel name alone. Follow one request from renderer input to the main-process side effect and record each authorization decision.
+
+## Package and Source Reconnaissance
+
+Extract the application bundle with a reviewed, version-pinned ASAR implementation or inspect an already unpacked `resources/app` tree. Locate `package.json#main`, preload paths, build metadata, Electron version, native modules, and update configuration.
+
+Search for:
+
+```text
+BrowserWindow  WebContentsView  webviewTag  webPreferences
+preload  contextBridge.exposeInMainWorld  ipcRenderer
+ipcMain.handle  ipcMain.on  webContents.ipc
+will-navigate  will-frame-navigate  will-redirect
+setWindowOpenHandler  loadURL  loadFile  openExternal
+setPermissionRequestHandler  registerSchemesAsPrivileged
+setAsDefaultProtocolClient  open-url  second-instance
+autoUpdater  electron-updater
+```
+
+Treat decompiled or bundled JavaScript as a hypothesis when source maps, minification, generated IPC bindings, or runtime feature flags can change the installed behavior.
+
+## Preload and Context-Bridge Analysis
+
+A preload script has privileged Electron/Node access even when `nodeIntegration` is disabled. With context isolation, it can still expose selected functions and values into the page's main world.
+
+Classify every export:
+
+- narrow operation with fixed channel and validated arguments
+- caller-selected channel or event name
+- direct exposure of `ipcRenderer`, Node/Electron modules, filesystem/process objects, or mutable privileged objects
+- callback/event registration that leaks the raw IPC event or privileged objects
+- secret/session/storage access
+- operation whose authorization exists only in renderer JavaScript
+
+A generic `send(channel, ...)` or `invoke(channel, ...)` bridge expands the renderer's candidate capability set, but the registered handler list is not the ACL. For each handler, inspect:
+
+- `event.senderFrame` URL/origin and frame identity validation
+- expected `webContents`, window, session/partition, and application state
+- user/tenant authorization and request provenance
+- argument schema, paths, URLs, command options, and object deserialization
+- result exposure and event subscriptions
+
+An IPC handler's existence does not prove an untrusted frame can invoke it successfully.
+
+## Navigation and Window Boundaries
+
+Web preferences belong to a `webContents`; navigation does not automatically turn a privileged window into an ordinary browser tab. A configured preload can run for newly loaded documents and expose its bridge to content that was never intended to receive it.
+
+Map all navigation causes:
+
+- user- or page-initiated main-frame navigation (`will-navigate`)
+- subframe navigation (`will-frame-navigate`)
+- server redirects (`will-redirect`)
+- new windows and popups (`setWindowOpenHandler`)
+- application calls to `loadURL`, `loadFile`, history APIs, or routing helpers
+- custom-protocol redirects and external-link handlers
+
+`will-navigate` does not cover every programmatic navigation, so the event's presence is not complete enforcement.
+
+Parse candidate URLs with `URL` and compare explicit protocol, origin/host, port, and path rules. Do not use string-prefix checks such as `startsWith("https://trusted.example")`. Apply the same canonical policy to initial loads, redirects, frames, popups, programmatic loads, and externally opened URLs.
+
+Before calling `shell.openExternal`, validate the scheme and complete destination expected by the feature. Treat `file:`, custom schemes, handler-specific arguments, credentials in URLs, and ambiguous encodings as separate cases.
+
+## Node, Isolation, and Sandbox Settings
+
+- `nodeIntegration: true` in a renderer that can execute untrusted script directly exposes Node capability and commonly turns renderer injection into native code execution.
+- `contextIsolation: false` weakens the boundary between page and preload worlds but is not, by itself, proof of native code execution.
+- `sandbox: false` removes Chromium process isolation; determine which preload or renderer capabilities become reachable rather than reporting the flag alone.
+- `webSecurity: false`, `allowRunningInsecureContent`, permissive experimental features, and unsafe `<webview>` preferences change separate browser boundaries and must be traced to an exploit path.
+- `nodeIntegrationInSubFrames` and preload injection into frames require frame-by-frame sender and origin analysis.
+
+Record Electron-version defaults. A missing explicit setting can mean different behavior on different major releases.
+
+## Custom Protocols and Deep Links
+
+Treat OS-delivered URLs and second-instance command lines as attacker-controlled inputs:
+
+```text
+OS handler / browser / document
+  -> custom scheme or argv
+  -> URL/argument parsing
+  -> application router
+  -> renderer navigation or native operation
+```
+
+Test authority and parser boundaries for host/path normalization, duplicate parameters, encoding depth, file paths, option injection, and cross-profile/account routing. Confirm which application instance and user session receives the event.
+
+For custom application protocols, record whether the scheme is registered as secure, standard, CORS-enabled, stream-capable, or privileged, and how that affects origin and storage behavior.
+
+## Permissions, Storage, and Secrets
+
+Map session permission handlers for media, notifications, geolocation, clipboard, display capture, USB/HID/serial, filesystem access, and external protocols. Verify decisions use the requesting frame/origin and cannot be inherited from a more trusted window.
+
+Inventory secrets and capability-bearing state reachable from renderer or preload code:
+
+- tokens, cookies, session identifiers, recovery material, and encryption keys
+- IndexedDB, local/session storage, cookies, cache, filesystem databases, and keychain wrappers
+- local service ports, named pipes, Unix sockets, and authentication material
+
+At-rest encryption does not protect data when the renderer can retrieve the key or ask a privileged bridge to decrypt it.
+
+## Updates and Native Extensions
+
+Trace the update pipeline as an executable supply chain:
+
+- feed URL and channel selection
+- TLS identity, redirects, proxy behavior, and metadata parsing
+- artifact signature and publisher verification
+- version/rollback policy and staged update state
+- native modules, helper binaries, installers, and post-update hooks
+
+An attacker-controlled feed is not automatically native code execution if independent artifact signatures are mandatory. Conversely, HTTPS does not compensate for missing artifact authenticity or unsafe rollback behavior.
+
+## Validation
+
+- Record the exact installed build, Electron version, preferences, preload, handler, and current document/frame origin.
+- Demonstrate the complete path from attacker-controlled input or renderer state to the main-process operation.
+- Capture sender-validation and argument-validation outcomes, not only successful IPC transport.
+- Re-test after cross-origin navigation, redirect, frame creation, window creation, and session/profile changes.
+- Separate renderer script execution, bridge access, accepted IPC, privileged data access, filesystem/process control, and native code execution.
+
+## False Positives
+
+- A preload or handler exists but the tested document/frame cannot reach it.
+- A channel is registered but rejects the sender, identity, state, or arguments.
+- `contextIsolation` or sandboxing is disabled without a reachable privileged API.
+- Navigation is blocked on user links but still possible through application code, or vice versa.
+- A remote page has no preload export, Node integration, IPC route, or privileged permission.
+- An update feed is mutable but every artifact and version transition is independently authenticated.
+- A secret-looking value is scoped to synthetic/test data or cannot authorize any downstream action.
+
+## Remediation
+
+- Load local application UI and isolate remote content in an unprivileged `WebContentsView` or external browser.
+- Keep Node integration disabled, context isolation enabled, and renderer sandboxing enabled.
+- Expose narrow preload APIs with fixed operations and strict schemas.
+- Validate every IPC sender frame, application identity, authorization context, and argument in the main process.
+- Parse and allowlist navigation destinations consistently across every navigation path.
+- Restrict permissions per session and requesting origin.
+- Keep credentials and encryption keys outside renderer reach.
+- Authenticate update metadata and artifacts, enforce rollback policy, and pin publishers.
+
+## Summary
+
+Electron security depends on which document and frame can reach which native capability. Map navigation, preload exports, IPC sender checks, permissions, storage, protocols, and updates as one authority graph, then validate the entire path to the privileged operation.

strix/skills/tooling/hurl.md

@@ -0,0 +1,99 @@
+---
+name: hurl
+description: Reproducible, reviewable HTTP request chains and response assertions with Hurl for authorized multi-step security validation, vulnerable-versus-fixed regression cases, captured values, and low-rate semantic oracles
+---
+
+# Hurl Security Regression Playbook
+
+Use [Hurl](https://hurl.dev/) when a security proof requires an ordered HTTP session whose requests, captured values, and assertions should be code-reviewed and replayed. It is well suited to authentication flows, redirects, cookies, CSRF tokens, upload lifecycles, patch regression, and paired semantic-differential cases.
+
+Hurl sends exactly what the file describes. It does not make state-changing requests safe. Review scope, methods, targets, and captured secrets before every run.
+
+## Install
+
+Prefer an official release binary or package. On macOS:
+
+```bash
+brew install hurl
+hurl --version
+```
+
+Official alternatives include release packages and `cargo install --locked hurl`; see [installation](https://hurl.dev/docs/installation.html). Record the tool version with results.
+
+## Minimal Chain
+
+```hurl
+# lab-regression.hurl
+GET {{base_url}}/session
+HTTP 200
+[Captures]
+csrf: xpath "string(//input[@name='csrf']/@value)"
+[Asserts]
+header "Content-Type" startsWith "text/html"
+
+POST {{base_url}}/action
+Content-Type: application/x-www-form-urlencoded
+[FormParams]
+csrf: {{csrf}}
+operation: noop
+HTTP 204
+```
+
+Hurl keeps cookies across requests in the same file, so an explicit `Cookie` header is unnecessary here.
+
+Run one reviewed case against one authorized target first:
+
+```bash
+hurl --test --jobs 1 --connect-timeout 5s --max-time 15s \
+  --variable base_url=https://lab.example lab-regression.hurl
+```
+
+When credentials are required, pass them with `--secrets-file local-secrets.env`, keep that file outside version control, and avoid verbose/debug output that could expose headers or bodies. Use `--variables-file` only for non-secret environment values.
+
+## Designing a Security Regression
+
+- Assert the security invariant, not only a status code: denied identity, final normalized location, absence/presence of a structural field, unchanged object state, or exact benign result.
+- Capture only values needed by later requests. Do not write tokens, personal data, or response bodies into committed reports.
+- Encode a malformed but non-triggering control alongside the suspected case.
+- Run the same file against vulnerable and fixed builds through `base_url` or other explicit variables.
+- Keep state-changing methods in a clearly labeled lab/staging file; prefer no-op actions, inert markers, and cleanup requests.
+- Check every redirect step when the vulnerability crosses routing, origin, or authentication boundaries. Blindly following redirects can hide the relevant transition.
+- Use unique canaries so cached or pre-existing state cannot create a false positive.
+
+## Chain Structure
+
+Organize longer files around capability transitions:
+
+```text
+fingerprint -> establish session -> reach boundary -> prove primitive -> verify state -> cleanup
+```
+
+At each response, assert the condition required by the next request. A final success assertion cannot explain which earlier assumption failed.
+
+Useful Hurl features include:
+
+- captures from headers, cookies, JSONPath, XPath, and regex queries
+- assertions over status, headers, body, JSON/XML, redirects, and timing
+- request-local options and variables
+- `--test` plus JSON, JUnit, TAP, or HTML reports
+
+Consult the [Hurl manual](https://hurl.dev/docs/manual.html) for version-specific syntax instead of guessing an option.
+
+## Safety Rules
+
+- Use an explicit `base_url`; never derive the destination from untrusted response data without validating scheme, host, and port.
+- Review POST/PUT/PATCH/DELETE requests and server-side side effects before replay.
+- Set bounded timeouts and retries for the target; do not use polling as an unbounded brute-force loop.
+- Do not use Hurl for raw HTTP parser/smuggling cases when its HTTP stack normalizes the bytes being tested; use an appropriate raw harness in an isolated lab.
+- Use `--path-as-is` when literal `/../` or `/./` path segments are the behavior under test; otherwise Hurl's underlying URL handling can normalize them.
+- Redact reports. HTML/JSON/JUnit artifacts may contain request URLs, headers, captured variables, and response snippets.
+- Keep authentication material in local secret storage and use dedicated test accounts with minimum privilege.
+
+## Validation Deliverable
+
+1. reviewed `.hurl` file with variableized target and no embedded secrets
+2. vulnerable, fixed, and negative-control environment descriptions
+3. assertion at every capability transition
+4. deterministic results with tool version and timestamps
+5. side effects, cleanup, and residual-state check
+6. redacted report appropriate for sharing

strix/skills/tooling/hypothesis.md

@@ -0,0 +1,100 @@
+---
+name: hypothesis
+description: Property-based local differential testing with Hypothesis for parsers, canonicalizers, serializers, validators, routers, and other pure functions, emphasizing explicit invariants, shrinking, reproducibility, and bounded resource use
+---
+
+# Hypothesis Differential Testing
+
+Use [Hypothesis](https://hypothesis.readthedocs.io/) when a security property can be expressed over local code and failures are likely to hide in combinations of encoding, normalization, structure, or parser recovery. It is especially useful for comparing two implementations or checking that validation and consumption preserve the same meaning.
+
+Do not point unrestricted generators at a live service. Hypothesis is safest and most useful against pure local adapters with no network, subprocess, filesystem, or persistent-state side effects.
+
+## Install
+
+Use an isolated virtual environment and install a reviewed pinned version:
+
+```bash
+python -m pip install 'hypothesis==<reviewed-version>'
+```
+
+Official project: [Hypothesis](https://github.com/HypothesisWorks/hypothesis)
+
+## Start From an Invariant
+
+Write the security relationship before writing strategies. Examples:
+
+```text
+allowlist(raw) implies sink(canonicalize(raw)) remains inside the allowed origin/path
+validator(raw) accepts implies consumer(raw) assigns the same media type/structure
+parse_A(raw) and parse_B(raw) agree on message boundaries and authoritative fields
+serialize(parse(raw)) cannot introduce a delimiter, wildcard, traversal, or new field
+```
+
+A test that only checks “does not crash” can find robustness bugs but does not establish a security differential.
+
+## Minimal Differential Harness
+
+```python
+from hypothesis import given, settings, strategies as st
+
+
+def outcome(parser, raw):
+    try:
+        return ("accept", parser(raw))
+    except ExpectedParseError as exc:
+        return ("reject", type(exc).__name__)
+
+
+@settings(max_examples=250, deadline=500)
+@given(st.text(max_size=128))
+def test_security_boundary(raw: str) -> None:
+    checked = outcome(security_parser, raw)
+    consumed = outcome(sink_parser, raw)
+    assert equivalent_security_meaning(checked, consumed)
+```
+
+- Bound string/list/binary sizes, recursion, examples, and deadline.
+- Build structured inputs from relevant tokens rather than generating unrestricted noise.
+- Normalize expected accept/reject/error outcomes explicitly so ordinary parser rejection is not mistaken for a property-test failure.
+- Use `st.one_of`, `st.sampled_from`, `st.lists`, `st.binary`, `st.text`, and composite strategies to represent the actual grammar.
+- Add explicit edge seeds with `@example` for known delimiters and regressions.
+- Let Hypothesis shrink failures; the minimal counterexample is often the clearest explanation of the parser disagreement.
+
+## High-Value Strategy Axes
+
+- percent and double encoding, malformed escapes, mixed separators
+- Unicode normalization, replacement characters, surrogates, case folding, IDNA
+- dot segments, slash/backslash, absolute/relative paths, sibling-prefix collisions
+- duplicate, empty, first/last, comma-joined, or differently cased fields
+- declared length versus actual bytes, truncation, padding, and terminators
+- nested objects, parser depth, ordering, unknown keys, and error recovery
+- serialize/deserialize round trips and version-to-version behavior
+
+Generate only axes supported by the target's transformation graph. Cartesian payload spraying obscures causality.
+
+## Reproducibility
+
+- Keep the minimized failing example as a normal regression test.
+- Preserve code revision, dependency lock, locale, platform, and parser/library versions.
+- Keep Hypothesis's example database in a task-specific artifact directory when replay across runs matters.
+- For CI, rely on stored explicit regressions for critical cases; randomized discovery supplements them.
+- Classify nondeterminism before suppressing health checks. Timing, global state, environment, and shared caches can create flaky false differentials.
+
+## Safety and Resource Controls
+
+- Adapt target functions so tests cannot reach the network or execute commands.
+- Use temporary directories and non-secret corpora for parsers that require files.
+- Put native parsers in a disposable, networkless process/container with CPU, memory, file-size, and process ceilings.
+- Do not disable deadlines globally to hide hangs; isolate and bound intentionally slow examples.
+- A crash, timeout, or excessive allocation is a robustness result. Prove a security boundary or exploitability separately.
+- Never reuse captured credentials, customer content, or production requests as generative corpora without sanitization.
+
+## Validation Deliverable
+
+1. stated invariant and why it protects a security boundary
+2. adapters and exact component/version pair compared
+3. bounded strategies and resource settings
+4. minimized counterexample and both interpretations
+5. stable explicit regression test
+6. impact trace from disagreement to privileged consumer
+7. fixed-version or corrected-invariant result

strix/skills/vulnerabilities/browser_security.md

@@ -0,0 +1,192 @@
+---
+name: browser-security
+description: Browser-internals security testing for browsing-context relationships, postMessage, client-side path traversal, XS-Leaks, service workers, Web Workers, navigation behavior, CSP interactions, caches, and cross-origin state machines
+---
+
+# Browser Security
+
+Use this skill when exploitability depends on browser behavior beyond a basic HTML injection. Model origins, browsing contexts, navigation history, workers, caches, router decoding, request metadata, and user activation as explicit state.
+
+Pair this skill with `xss`, `oauth`, `open_redirect`, `csrf`, or `semantic_confusion` when one of those is the primary vulnerability class. For an Electron renderer with a preload or IPC bridge, load `electron_desktop_apps` to analyze whether navigation and origin transitions reach native capability.
+
+## Safety Boundary
+
+- Use a controlled browser profile, synthetic account/data, explicit target allowlist, and a fresh assessment-specific proxy/CA when interception is required.
+- Redact tokens, cookies, message contents, storage values, and personal data from console logs, captures, recordings, and reports.
+- Treat oversized URLs/headers, cookie inflation, redirect loops, cache exhaustion, and high-rate timing trials as resource/denial-of-service tests; run them only with strict ceilings in a restartable lab.
+- Do not attempt to set or spoof browser-generated `event.origin`. Vary the sender URL and record the serialized origin supplied by the browser.
+- Restore monkey-patched browser APIs and unregister test workers/caches after validation.
+
+## Browser State Model
+
+For each relevant page or worker, record:
+
+- origin and site, including transitions after navigation
+- top-level window, opener, parent, child frames, named contexts, and retained references
+- sandbox flags, CSP `frame-ancestors`, COOP, COEP, CORP, and X-Frame-Options
+- service-worker controller and scope
+- storage access: cookies, local/session storage, IndexedDB, Cache API
+- navigation/history entries and redirect type: HTTP, JavaScript, form, meta refresh
+- user-activation and interaction requirements
+- browser family/version and enabled experimental features
+
+Draw the context graph. Security checks on `event.origin`, `event.source`, or a popup reference are meaningful only when the lifetime and ownership of that context are understood.
+
+## High-Value Surfaces
+
+### postMessage and Window Relationships
+
+- Enumerate listeners and senders; record message schema, origin check, source check, and reachable sinks/actions.
+- Validate origins after URL parsing and canonicalization, not with raw-string regexes.
+- Test numeric/alternate IP forms, userinfo, path masquerading as a host suffix, and redirects.
+- Treat predictable `window.open()` target names and iframe names as potentially shared namespace entries. Confirm reuse within the same browsing-context group, opener chain, COOP state, and relevant navigation/message timing.
+- Check whether a blocked intermediate frame leaves a useful browsing-context relationship intact.
+- Use random per-flow names or `_blank` with `noopener` where an opener relationship is unnecessary.
+
+### Client-Side Path Traversal
+
+Trace the complete source-to-request pipeline:
+
+```text
+browser URL -> router parser -> route/query/hash accessor -> app interpolation -> fetch/XHR -> final normalized URL
+```
+
+- Test path parameters, query parameters, and hashes independently.
+- Determine exactly where `%2F`, `%5C`, `%2E`, and double-encoded forms decode or re-encode.
+- Instrument `fetch`, XHR, Axios, router navigation, and server-side fetch wrappers to capture the final URL.
+- Escalate only after identifying the sink: state-changing API for CSRF-like impact, HTML/attachment response rendered in an unsafe sink for XSS, or server-side fetch for SSRF.
+- Do not assume the same framework API behaves identically in client components, server components, and route handlers.
+
+### XS-Leaks and Cross-Origin Oracles
+
+Inventory observable signals that do not require reading the cross-origin response:
+
+- load/error events for script, image, stylesheet, frame, media, and module elements
+- timing, connection reuse, cache state, redirect count, and navigation success
+- window/frame count, focus, history length, and resource dimensions
+- browser-generated error pages and status-dependent behavior
+- request headers such as `Sec-Fetch-Dest`, `Sec-Fetch-Mode`, and `Origin`
+
+Test controls such as ORB, CORP, COEP, and MIME enforcement. A service worker or alternate fetch path can change request destination metadata and therefore change whether a blocked response becomes a network error or an empty response. Validate the oracle across authenticated and unauthenticated control cases.
+
+### Service Workers and Caches
+
+- Map service-worker registration scope, update lifecycle, controller acquisition, and fetch handlers.
+- Inspect Cache API keys and responses; determine whether HTML or JavaScript is served directly from a writable cache.
+- Test whether a constrained script context can poison app-managed cache entries later consumed by a normal page or service worker.
+- Treat service-worker persistence as high impact, but prove registration/control scope and update survivability.
+- Compare a direct subresource request with the same request proxied through `fetch(event.request)`; request destination and mode can differ.
+
+### Web Workers and Constrained Script Execution
+
+When script runs inside a worker, inventory capabilities instead of dismissing it as low impact:
+
+- credentialed same-origin `fetch` for data access and state changes
+- `postMessage` gadgets into the main page
+- IndexedDB and Cache API shared with other same-origin contexts
+- Blob construction and object URLs
+- import mechanisms, WebSocket, and available browser-specific APIs
+
+Prove the strongest reliable capability first. If escalation requires a user gesture, document the exact gesture, timing, browser, and visibility rather than calling it zero-click XSS.
+
+### Navigation and Redirect Control
+
+- Distinguish HTTP 30x, script navigation, form submission, meta refresh, and popup navigation.
+- Test invalid or blocked URL schemes and WAF-generated error pages only when they support a real flow. Oversized URLs/headers, cookie-path-specific header inflation, redirect limits, and navigation throttling are restartable-lab-only tests with strict size/iteration limits and health checks.
+- A sandbox inherited by a new top-level context can selectively block forms, scripts, popups, or navigation; enumerate the exact flag set.
+- Preserve and inspect history when a built-in error page replaces the active document; do not assume the errored URL is lost.
+
+### CSP and Browser Parsing
+
+- Evaluate the delivered policy on the exact response, including redirects and error/API/static paths.
+- Map nonces, hashes, `strict-dynamic`, allowed schemes, trusted script gadgets, `base-uri`, `frame-ancestors`, and Trusted Types.
+- Test parser namespaces and repairs in HTML, SVG, and MathML. A protected attribute or sanitizer rule in the HTML namespace may behave differently after namespace transitions.
+- Treat scriptless disclosure of a nonce or trusted URL as a primitive; prove a second controllable sink before claiming bypass.
+- For response splitting, consider whether a same-origin endpoint can be turned into a script resource with a controlled body length or framing.
+
+### JavaScript Gadget Discovery
+
+- When direct calls are blocked, inspect implicit coercions (`toString`, `valueOf`, iterators, getters, proxies) and callbacks invoked by accessible library functions.
+- Search for functions whose `this` object and arguments can be attacker-shaped.
+- Build a bounded harness to enumerate reachable globals and observe property reads/calls; avoid assuming one library gadget is universal.
+- Validate the complete call chain to a dangerous sink such as navigation, HTML insertion, `eval`, `Function`, or a privileged API.
+
+## Reconnaissance
+
+### Runtime Instrumentation
+
+Instrument in a controlled browser session:
+
+```javascript
+const realFetch = window.fetch;
+window.fetch = (...args) => {
+  const input = args[0];
+  const rawUrl = typeof input === 'string' ? input : input.url;
+  const url = new URL(rawUrl, location.href);
+  const method = args[1]?.method || input?.method || 'GET';
+  console.log('fetch', {method, origin: url.origin, path: url.pathname});
+  return realFetch(...args);
+};
+
+window.addEventListener('message', e => {
+  const keys = e.data && typeof e.data === 'object' ? Object.keys(e.data) : [];
+  console.log('message', {origin: e.origin, sourceMatches: e.source === window.opener, keys});
+}, true);
+```
+
+Use the wrapper only in the controlled profile and restore `window.fetch = realFetch` afterward. Do not log bodies, message values, credentials, or query strings.
+
+Also inspect DevTools network initiators, service workers, storage, CSP violations, frame tree, and navigation history. Use raw browser behavior for validation; command-line HTTP clients cannot reproduce origin/window/worker semantics.
+
+### Source Review
+
+- Search for `postMessage`, message listeners, `window.open`, named targets, opener/parent access, frame creation, and sandbox attributes.
+- Search for router parameter APIs flowing into `fetch`, Axios, navigation, or HTML rendering.
+- Search for service-worker registration, Cache API writes, worker constructors, Blob URLs, and dynamic imports.
+- Search for raw HTML sinks and trust escape hatches in every supported frontend framework.
+- Compare CSP and framing headers across document, API, static, callback, redirect, and error routes.
+
+## Testing Methodology
+
+1. **Define the browser state** - Origin/site, context graph, policies, workers, storage, and activation.
+2. **Identify a source and observable sink** - Message, URL component, cache entry, navigation, load/error event, or implicit call.
+3. **Trace transformations** - URL parsing, framework decode, browser normalization, request destination, and document replacement.
+4. **Build paired controls** - Same-origin/cross-origin, status success/error, worker/direct, unique/predictable window name, encoded/raw path.
+5. **Prove the primitive** - Data transfer, path change, state oracle, cache modification, or context capture.
+6. **Escalate deliberately** - Chain to a privileged action, sensitive disclosure, SSRF, or executable DOM sink.
+7. **Cross-browser check** - At minimum record Chromium/Firefox/Safari applicability when the primitive is browser-specific.
+8. **State interaction requirements** - Click, drag, popup permission, timing window, login state, and visual deception.
+
+## Validation
+
+1. Capture the context graph and relevant policies at exploit time.
+2. Show the exact browser-parsed origin or final request URL, not just the attacker-supplied string.
+3. For postMessage, prove both message origin and source/context ownership.
+4. For XS-Leaks, repeat randomized success/failure trials and quantify separation and noise.
+5. For workers/caches, show which later context consumes the modified data.
+6. For client-side traversal, capture the final network request and the security-relevant response/action.
+7. For interaction-dependent chains, provide a screen recording or deterministic event trace.
+
+## False Positives
+
+- A message reaches a listener but fails schema, origin, source, or state validation before any action
+- A router decodes traversal characters but the value never reaches a URL/path sink
+- Different load/error behavior caused by unstable network rather than protected state
+- Worker script execution with no sensitive API, shared state, main-thread gadget, or meaningful action
+- CSP nonce disclosure without a controllable way to reuse it in an executable sink
+- Named-window collision blocked by origin scoping, randomized names, COOP, or `noopener`
+- Browser-specific behavior reported without the required version, flag, or user interaction
+
+## Pro Tips
+
+1. Treat browsing-context names as attacker-contestable identifiers unless randomized.
+2. Query parameters are usually decoded automatically; path parameters vary by router and execution context.
+3. Compare request metadata, not just URLs. Service workers can alter destination/mode semantics.
+4. A strict origin check does not compensate for attacker control of the supposedly trusted window reference.
+5. Error pages, redirects, and blocked frames still mutate history and context relationships.
+6. Keep browser-version claims narrow and retest; these behaviors change faster than server-side primitives.
+7. Prefer a small state-machine explanation over a large payload catalog.
+
+## Summary
+
+Browser exploitation is state-machine exploitation. Map origins, context references, policies, workers, storage, navigation, and decoding as one system. Prove each state transition with browser evidence, then chain only the primitives that survive the target's browser and interaction constraints.

strix/skills/vulnerabilities/header_injection.md

@@ -5,7 +5,7 @@ description: HTTP header injection testing covering CRLF / response splitting, c
 
 # HTTP Header Injection
 
-Header injection turns user input into protocol-level control: response splitting, cache poisoning, session fixation, authentication bypass, and request smuggling all trace back to a server-controlled header value that wasn't normalized. The bug usually lives in middle layers — frameworks that copy a request value into a response header, proxies that trust forwarded headers, caches keyed on something the attacker influences. Treat any user-controlled value that reaches a header as code-execution-equivalent until proven otherwise.
+Header injection turns user input into protocol-level control: response splitting, cache poisoning, session fixation, authentication bypass, and downstream parser confusion can trace back to a server-controlled header value that was not normalized. The bug usually lives in middle layers — frameworks that copy a request value into a response header, proxies that trust forwarded headers, caches keyed on something the attacker influences. Impact depends on which downstream component consumes the injected field and how.
 
 ## Attack Surface
 
@@ -62,7 +62,7 @@ Header injection turns user input into protocol-level control: response splittin
 
 ## Key Vulnerabilities
 
-### CRLF Response Splitting and Smuggling
+### CRLF Response Splitting
 
 Inject `\r\n\r\n` to terminate the current response and prepend a second attacker-controlled response. Cache or downstream proxy may key on the first response and serve the second to other users.
 
@@ -70,7 +70,7 @@ Inject `\r\n\r\n` to terminate the current response and prepend a second attacke
 GET /redirect?to=foo%0d%0aSet-Cookie:%20admin=1%0d%0a%0d%0a<html>poisoned</html> HTTP/1.1
 ```
 
-Request smuggling is the same primitive at the request layer: inject a header that causes the proxy and backend to disagree on message framing — most commonly conflicting `Content-Length` and `Transfer-Encoding`, or two `Content-Length` headers with different values. Backend reads one request, frontend reads a different one; the leftover bytes become a smuggled request prepended to the next victim's connection.
+Request smuggling is a separate request-boundary vulnerability involving disagreement between two HTTP parsers, not simply response header injection at the request layer. Load `http_request_smuggling` when conflicting lengths, transfer coding, HTTP/2 downgrades, or connection desynchronization are in scope.
 
 ### Cache Poisoning
 
@@ -106,16 +106,23 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 - `X-Forwarded-For: 127.0.0.1` to bypass IP allowlists or rate limits keyed on client IP
 - `X-Forwarded-Proto: https` to satisfy "HTTPS-only" checks while still using HTTP
 - `X-Forwarded-Host: attacker.tld` for the Host-confusion variants above
-- `X-Real-IP`, `Client-IP`, `True-Client-IP`, `CF-Connecting-IP`, `Forwarded` (RFC 7239) — same primitive, different header names; spray all of them
+- `X-Real-IP`, `Client-IP`, `True-Client-IP`, `CF-Connecting-IP`, `Forwarded` (RFC 7239) — same trust class under different conventions; select evidence-supported variants for the observed proxy/CDN stack
 - `X-Original-URL` / `X-Rewrite-URL` (IIS, ASP.NET) — server-side URL rewriting after auth check, classic admin-panel auth bypass
 
 ### Content-Type / Encoding Confusion
 
 - Inject `Content-Type: text/html` into an endpoint that returned JSON; browsers may sniff and render → XSS
-- Inject `charset=utf-7` in `Content-Type` for legacy XSS via UTF-7-encoded payloads
 - Inject `Content-Disposition: inline` to switch a download into in-page rendering
-- Inject `Content-Encoding: gzip` without actually compressing — clients decode-fail and may reveal raw response bytes in error paths
 - *Absence* of `X-Content-Type-Options: nosniff` is what enables the sniffing attacks above; the header is a hardening control, not an attack surface — but if a server sets it inconsistently across endpoints, target the ones that don't
+- Compare MIME validators with browser parsing of duplicate or comma-joined `Content-Type` values. Record first/last valid member behavior and invalid-parameter recovery for each consumer.
+
+### Internal Redirect and Handler Confusion
+
+- Determine whether CGI/FastCGI/WSGI-style response headers can trigger an internal redirect instead of an external response.
+- Trace which request fields survive the redirect: content type, handler, method, authorization result, path, and environment.
+- Test whether response metadata is reused as an internal handler, proxy target, template type, or interpreter selection.
+- Compare direct access controls with the internally dispatched resource. A protected URL may be unreachable directly while the same handler is invokable through a clean internal redirect.
+- Treat CRLF injection and response-controlling SSRF as possible inputs to this chain, then validate handler selection before using a privileged handler.
 
 ### XSS via Response Headers
 
@@ -165,8 +172,9 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 4. **Probe forwarding headers** — spoof `X-Forwarded-For`, `X-Real-IP`, `True-Client-IP`, `CF-Connecting-IP` against IP-restricted endpoints (admin, rate-limited)
 5. **Test cache key / response content split** — find inputs that change the body but not the cache key; confirm a second request from a different session sees the poisoned response
 6. **Test method override** — `X-HTTP-Method-Override` paired with state-changing endpoints reachable via POST or GET
-7. **Test request smuggling pairs** — conflicting `Content-Length` and `Transfer-Encoding`, two `Content-Length` headers, malformed chunked encoding, against any frontend → backend pair
+7. **Route framing discrepancies** — if evidence indicates request-boundary disagreement, switch to `http_request_smuggling`
 8. **Cross-protocol** — replay payloads over HTTP/1.1 and HTTP/2; diff behavior
+9. **Trace internal reprocessing** — where response headers can cause subrequests/internal redirects, diff retained fields and final handler selection
 
 ## Validation
 
@@ -174,8 +182,8 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 2. Capture a password-reset / OAuth link pointing at attacker-controlled host — proves Host injection
 3. Demonstrate the same endpoint returning different auth decisions with and without a forged forwarding header
 4. For response splitting: show a downstream cache or proxy serving the injected second response to an unrelated request
-5. For request smuggling: show one victim request seeing data from a different request appended (not just timing or single-shot anomaly)
-6. All findings should produce a durable artifact (cached response, sent email, log entry, session change) — transient anomalies are not validation
+5. All findings should produce a durable artifact (cached response, sent email, log entry, session change) — transient anomalies are not validation
+6. For internal redirects, capture both the injected response metadata and the final internally selected route/handler
 
 ## False Positives
 
@@ -183,7 +191,6 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 - `X-Forwarded-*` reflected back but only used for logging — not a security boundary, may not be exploitable
 - Browsers blocking `Location: javascript:` or `Location: data:` — capability exists in the protocol but most modern browsers refuse to navigate
 - CRLF appearing in response headers but stripped by an outer proxy before reaching any client or cache
-- Request smuggling indicators that turn out to be normal pipelining or keep-alive behavior
 
 ## Impact
 
@@ -192,7 +199,6 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 - Auth bypass on endpoints trusting forwarding headers
 - Session fixation and cookie tossing leading to account hijack
 - Open redirect for phishing / OAuth `redirect_uri` abuse
-- Request smuggling — one victim's request reads another victim's response, including auth headers and cookies
 - WAF / detection bypass via header-name and encoding tricks
 
 ## Pro Tips
@@ -200,7 +206,7 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 1. The fastest win is usually Host / `X-Forwarded-Host` in a password-reset or OAuth flow — try first, costs one request
 2. For cache poisoning, find the *unkeyed* input first (header that influences body but not cache key); the rest follows
 3. `X-HTTP-Method-Override` is high-yield against backends that route on it before checking method-based auth — most useful from server-side / non-browser callers (it triggers CORS preflight in a browser, so not a CSRF primitive)
-4. Smuggling lives at the boundary — identify the proxy → backend pair (CDN → origin, ingress → service) and target the framing disagreement
+4. If a header test exposes message-boundary disagreement, switch to the dedicated request-smuggling workflow and identify the proxy → backend pair
 5. `X-Original-URL` / `X-Rewrite-URL` against IIS / ASP.NET admin endpoints is still a high-yield bypass
 6. Before claiming a CRLF win, verify the second line landed as a real header in the cache or downstream consumer — many servers strip CRLF silently
 7. Outbound email flows are a separate but related surface — user input flowing into SMTP headers (To, Cc, Subject, Reply-To) is its own injection class with the same root cause

strix/skills/vulnerabilities/insecure_deserialization.md

@@ -10,13 +10,16 @@ Insecure deserialization passes attacker-controlled byte streams or structured b
 ## Attack Surface
 
 **Formats**
-- Java: Java native serialization, XStream, JSON → object mappers (Jackson, Fastjson), YAML (SnakeYAML)
+- Java: Java native serialization, XStream, JSON → object mappers (Jackson, Fastjson), YAML (SnakeYAML), Hessian/Burlap, Kryo
 - Python: `pickle`, `yaml.load` (unsafe), `marshal`, shelve
 - PHP: `unserialize()`, Phar deserialization
 - .NET: `BinaryFormatter`, `Json.NET TypeNameHandling`, ViewState
 - Ruby: `Marshal.load`, YAML.load
 - Node.js: `node-serialize`, `unserialize.js` (less common; see prototype_pollution for merge bugs)
 
+**Transports and Containers**
+- Java RMI/JMX, HTTP/RPC endpoints, messaging protocols, queues, signed wrappers, and product-specific binary envelopes can carry one or more formats above
+
 **Input Locations**
 - Cookies, session tokens, hidden form fields
 - API parameters (`data`, `state`, `object`, base64 blobs)
@@ -58,6 +61,22 @@ yaml.load       readObject(     TypeNameHandling    Marshal.load
 ```
 When `enableDefaultTyping` or `@JsonTypeInfo` allows attacker-chosen types.
 
+**JNDI Pivots from Object Construction**
+
+JNDI injection is not itself a serialization format. It becomes part of this workflow when an attacker-selected type, setter, or gadget performs `Context.lookup()` during object construction or property population. `JdbcRowSetImpl` and some historical polymorphic JSON chains are examples; Log4j lookups reach JNDI through a different input path and should not be classified as deserialization.
+
+- Trace fields such as `dataSourceName`, `jndiName`, and `namingURL` into the exact lookup API and provider.
+- Record the accepted schemes/provider factories (`ldap`, `ldaps`, `rmi`, DNS URL context, or application-specific naming providers). A `dns://` value is not a universal oracle; it works only when the relevant DNS provider and lookup path are present.
+- Separate network lookup, remote object/reference processing, serialized LDAP attributes, remote codebase loading, and local object-factory invocation. Each is a different capability with different runtime controls.
+- JEP 290 filters incoming Java serialization graphs; it does not disable JNDI remote codebase loading. JNDI providers gained separate remote-class-loading and serialized-data controls across JDK updates, and current JDKs disable remote code downloading by default. Record the exact JDK build and relevant provider properties instead of using a single “modern Java” rule.
+- When remote class loading is unavailable, test whether the returned reference can reach a compatible **local** `ObjectFactory`, bean-property path, expression engine, script engine, or other class already present. Confirm exact class names, versions, module access, and trigger methods from the deployed classpath.
+
+**Hessian / Burlap**
+- Binary RPC formats deserialized by `HessianInput`/`Hessian2Input`. Attacker object graphs reach gadgets even though it is not native Java serialization.
+- Treat serializer version, allowed type metadata, constructors/setters invoked, collection/comparator behavior, and classpath as independent prerequisites.
+- Pair `semantic_confusion` when a proxy or route policy is expected to make the RPC endpoint unreachable.
+- Inspect the exact deployed libraries rather than relying on generic gadget labels; similar-looking Spring, Resin, Tomcat, XBean, EL, or Groovy classes are not interchangeable.
+
 ### Python Pickle
 
 Pickle executes arbitrary code during unpickling by design:
@@ -162,6 +181,8 @@ When `TypeNameHandling` != `None`.
 3. Check cookies named `JSESSIONID` alternatives, `.ASPXAUTH`, `laravel_session`, custom tokens
 4. In white-box, trace from `readObject`/`unserialize`/`pickle.loads` backward to source
 5. ViewState MAC off is still common on legacy ASP.NET — test early on `.aspx` apps
+6. Model JNDI lookup, reference/object processing, remote codebase loading, and local factory invocation as separate stages
+7. A "blocked" enterprise deserialization endpoint may still be reachable through a proxy/path-normalization mismatch — pair `semantic_confusion`
 
 ## Tooling
 
@@ -172,6 +193,7 @@ Payload generation is the practitioner's core tool here. The sandbox has `git`/`
 | **ysoserial** (frohoff) | Java native | Gadget-chain payloads: `CommonsCollections1-7`, `Groovy1`, `Spring1/2`, and `URLDNS` for a safe no-exec DNS oracle. Needs a JRE. |
 | **phpggc** (ambionics) | PHP `unserialize` / Phar | Framework POP chains (Laravel, Symfony, WordPress, Drupal, Monolog). Needs `php-cli`. |
 | **ysoserial.net** | .NET `BinaryFormatter` / Json.NET | Windows/.NET gadget payloads. Needs .NET/mono — usually out of scope in a Linux sandbox. |
+| **marshalsec** | Java Hessian/Burlap, Kryo, JSON, and JNDI reference tooling | Use only from a reviewed, pinned upstream commit when a non-native Java marshaller requires it. It has no stable release and intentionally bundles historical gadget dependencies; do not treat it as a globally installed default tool. |
 
 ```
 # Java: prove the sink with a no-exec DNS oracle BEFORE any RCE chain

strix/skills/vulnerabilities/insecure_file_uploads.md

@@ -67,6 +67,8 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 
 - Double extensions: avatar.jpg.php, report.pdf.html; mixed casing: .pHp, .PhAr
 - Magic-byte spoofing: valid JPEG header then embedded script; verify server uses content inspection, not extensions alone
+- Detector/consumer differential: make the upload validator and the later parser disagree about type, structure, or validity
+- Probe detector scan windows, recursion/nesting limits, maximum bytes inspected, invalid-syntax recovery, and version-specific magic databases
 
 ### Archive Attacks
 
@@ -120,6 +122,8 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 - Client-side only checks; relying on JS/MIME provided by browser
 - Trusting multipart boundary part headers blindly
 - Extension allowlists without server-side content inspection
+- One parser validates metadata or leading bytes while another parser processes the full file
+- Type-detection wrappers assumed identical even when they bundle different library/database versions
 
 ### Evasion Tricks
 
@@ -146,8 +150,9 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 1. **Map the pipeline** - Client → ingress → storage → processors → serving. Note where validation and auth occur
 2. **Identify allowed types** - Size limits, filename rules, storage keys, and who serves the content
 3. **Collect baselines** - Capture resulting URLs and headers for legitimate uploads
-4. **Exercise bypass families** - Extension games, MIME/content-type, magic bytes, polyglots, metadata payloads, archive structure
-5. **Validate execution** - Can uploaded content execute on server or client?
+4. **Map validators and consumers** - Identify the detector/library/version when possible and every later parser, converter, renderer, or browser context
+5. **Exercise bypass families** - Extension games, MIME/content-type, magic bytes, parser limits, polyglots, metadata payloads, archive structure
+6. **Validate execution** - Prove the accepted object reaches a more privileged consumer and can execute or render active content
 
 ## Validation
 
@@ -182,6 +187,7 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 8. When you cannot get execution, aim for stored XSS or header-driven script execution
 9. Validate that CDNs honor attachment/nosniff
 10. Document full pipeline behavior per asset type
+11. Reproduce detector/consumer mismatches on the deployed library versions; OS packages and language bindings may ship different limits
 
 ## Summary
 

strix/skills/vulnerabilities/memory_corruption.md

@@ -0,0 +1,228 @@
+---
+name: memory-corruption
+description: Native memory-safety analysis for stack and heap overflows, out-of-bounds access, uninitialized memory, use-after-free, integer and signedness errors, format strings, crash triage, exploitability constraints, and controlled lab validation
+---
+
+# Memory Corruption
+
+Use this skill for authorized analysis of native parsers, network services, firmware daemons, libraries, and mixed web/native components where attacker-controlled bytes may violate memory safety.
+
+Separate three questions throughout the work:
+
+1. **Bug existence:** does an input cause an invalid read, write, lifetime violation, or disclosure?
+2. **Primitive quality:** what bytes, address, length, timing, or object state can the attacker control or observe?
+3. **Exploitability:** can that primitive bypass the target architecture, mitigations, allocator, protocol, and restart constraints?
+
+A crash, connection close, watchdog restart, or sanitizer report proves neither instruction-pointer control nor RCE.
+
+## Lab Boundary
+
+Malformed-input and crash work is denial-of-service testing. Run it only against an explicitly authorized, restartable lab target with console/process visibility, health checks, rate ceilings, and a recovery procedure. Do not fuzz production services or automatically replay crash cases.
+
+Analyze hostile binaries, cores, packet captures, and corpora inside an isolated environment. Do not execute an unknown sample merely because a debugger or decompiler imported it.
+
+## Vulnerability Classes
+
+### Bounds and Length Errors
+
+- fixed destination with attacker-controlled copy/format length
+- allocation based on one length and copy based on another
+- off-by-one termination or delimiter handling
+- nested length fields and cumulative-size overflow
+- stack/heap out-of-bounds read or write
+- negative length converted to unsigned, truncation between integer widths, or multiplication/addition overflow
+- encoded/decoded/compressed size disagreement
+
+### Initialization and Termination
+
+- uninitialized stack/heap data returned in a response
+- reused object/buffer retaining data from another request or tenant
+- missing NUL termination followed by string length/format operations
+- partial structure initialization with stale flags, pointers, or lengths
+- padding, union, or serialization bytes copied beyond initialized fields
+
+### Lifetime and Object Confusion
+
+- use-after-free, double free, stale callback, iterator invalidation
+- type/object confusion after parsing, casting, or virtual dispatch
+- reference-count races and cross-thread ownership errors
+- reallocation invalidating stored pointers
+- constructor/destructor/finalizer behavior reached in an unexpected state
+
+### Format and Variadic Errors
+
+- attacker-controlled format string
+- type/width mismatch in variadic arguments
+- destination-size assumptions around `sprintf`-family calls
+- logging/error paths that process attacker bytes after a partial parse
+
+## Build the Input-to-Memory Model
+
+Record:
+
+```text
+transport field -> parser type/width -> normalized value -> allocation
+                -> copy/read/format operation -> object/buffer -> later use
+```
+
+For each relevant field, capture:
+
+- wire offset/path, endian, encoding, signedness, and declared versus actual size
+- validation order and parser state required to reach the operation
+- allocation expression and destination capacity
+- copy/read/write expression and implicit casts
+- terminator/padding/alignment behavior
+- attacker-controlled byte alphabet and precision
+- thread, connection, session, heap, and restart lifetime
+
+Trace both source-to-sink and sink-to-source. Start from changed bounds checks or crash instructions when available, but reconstruct the minimum valid protocol state that reaches them.
+
+## Source-Available Workflow
+
+### Compiler Instrumentation
+
+Build a lab-only target or minimal harness with the compiler's maintained sanitizers when source permits:
+
+```bash
+clang -g -O1 -fno-omit-frame-pointer \
+  -fsanitize=address,undefined \
+  harness.c parser.c -o parser-harness
+```
+
+- Keep the harness local and networkless; call the narrow parser/API directly.
+- Preserve the exact compiler, flags, architecture, allocator, and dependencies.
+- AddressSanitizer changes layout and timing. Reproduce important behavior on a representative unsanitized build under a debugger before drawing exploitability conclusions.
+- UndefinedBehaviorSanitizer may report conditions that do not produce the deployed security impact; trace each report to attacker control and later use. It does not replace explicit arithmetic and cast review.
+- For ordinary uninitialized-value hypotheses, use a separate MemorySanitizer build such as `-fsanitize=memory -fsanitize-memory-track-origins=2`; it requires an instrumented dependency set and is not interchangeable with ASan.
+- For race-dependent ownership or refcount paths, use a separate ThreadSanitizer build only when concurrency is in scope; do not imply the sanitizer families compose cleanly into one representative build.
+- Add regression cases for the minimized triggering input and neighboring non-triggering controls.
+
+### Static Review
+
+Search around input parsing for:
+
+- `memcpy`, `memmove`, `strcpy`, `strcat`, `sprintf`, `snprintf`, `scanf` families
+- manual cursor/end-pointer arithmetic and nested TLV/XML/string parsers
+- `malloc/calloc/realloc/new` size arithmetic
+- signed/unsigned conversions and narrowing casts
+- length values stored in smaller fields or reused across decoded representations
+- error cleanup, ownership transfer, callbacks, and asynchronous lifetime
+- custom allocators, pools, slabs, ring buffers, and request-buffer reuse
+
+Do not report a dangerous function name without proving attacker control, reachable state, capacity mismatch, and the actual deployed implementation.
+
+## Binary-Only Workflow
+
+1. Identify architecture, endian, ABI, OS/libc, compiler clues, and stripped/symbol state.
+2. Record NX/DEP, ASLR/PIE, stack canaries, RELRO, CFI/PAC/CET, allocator hardening, seccomp/sandbox, privilege, and restart behavior.
+3. Anchor on imports, strings, message IDs, error paths, new checks, crash PC, or advisory-relevant constants.
+4. Trace length/copy/allocation dataflow in decompiler and assembly.
+5. Record the deployed binary identity: build ID or hash, interpreter or loader, loaded modules/base addresses, allocator, and whether the runtime executable came from base image, overlay, bind mount, or update staging.
+6. Reproduce under a debugger or emulator only when its environment matches the relevant parser and allocator behavior.
+7. Compare vulnerable and fixed functions; describe the restored invariant and inspect sibling callers.
+
+Use official [Ghidra](https://github.com/NationalSecurityAgency/ghidra) for cross-architecture static analysis and [BinDiff](https://github.com/google/bindiff) for function-level version comparison after package/file diffs narrow the target. Similarity scores and decompiled C are triage aids, not proof; confirm critical conditions in assembly and runtime evidence.
+
+## Crash and Disclosure Triage
+
+Preserve one known-good transcript and then minimize while keeping the framing, checksums, parser state, and negotiation required to reach the vulnerable operation. Identify the first invalid access, not only the eventual crash site. Use a distinctive non-executable pattern to measure overwrite offset or disclosure position, classify whether the observed effect is read, write, non-control-data, pointer/object, or control-state influence, and then repeat the same case on a representative unsanitized build plus fixed and negative controls.
+
+For each case, record:
+
+- exact minimized input and protocol transcript
+- deterministic frequency and required heap/session preparation
+- signal/exception, PC, faulting instruction bytes/disassembly, fault address, access type/size, registers, stack, loaded mappings/build IDs, and relevant object memory
+- process versus worker crash, watchdog/restart, and external symptom
+- corrupted object provenance and last known-valid parser state
+- vulnerable/fixed/unaffected build behavior
+- whether the same case under debugger/sanitizer changes outcome
+
+Deduplicate by root cause, not only crash address. One overwrite may crash at many later consumers; one parser family may contain multiple distinct missing checks.
+
+For disclosures, classify the returned bytes:
+
+- predictable padding or constant data
+- same-request content
+- cross-request/tenant secrets
+- heap/stack pointers useful against ASLR
+- session tokens, keys, credentials, or application data
+
+Derive detectors from response structure or a constant non-secret marker rather than collecting sensitive memory.
+
+## Primitive Analysis
+
+### Write Primitive
+
+- location: fixed, relative, attacker-derived, heap-neighbor, object field, return/control data
+- width and count: single byte/bit, bounded span, arbitrary length, repeated writes
+- value control: exact, restricted alphabet, additive, terminator, pointer-derived
+- timing/state: before validation, after free, race-dependent, heap-shape-dependent
+- repeatability under default allocator and mitigations
+
+### Read/Leak Primitive
+
+- offset and length control
+- termination rules and response encoding
+- ability to repeat/advance across memory
+- cross-request process reuse
+- pointer or secret classification
+- noise, truncation, and crash threshold
+
+### Control-Flow/Object Primitive
+
+- overwritten callback, vtable, length, non-control-data flag, pointer, credential/session reference, allocator metadata, saved return state, or interpreter structure
+- required heap grooming/object placement
+- available modules/gadgets and address disclosure
+- thread/process privilege and sandbox boundary after control
+- whether the attacker can only corrupt a field, or can also choose the dereference target and value later consumed
+
+Document what remains constrained. “Arbitrary write” should not be used for a relative, partial, alphabet-limited, or race-only overwrite.
+
+## Exploitability Matrix
+
+| Dimension | Record |
+|---|---|
+| Reachability | listener, authentication, feature/config, valid prior state |
+| Platform | architecture, endian, ABI, firmware model/SKU |
+| Input | transport, maximum size, forbidden bytes, encoding/transforms |
+| Primitive | read/write/control precision, repeatability, heap dependence |
+| Mitigations | ASLR/PIE, NX, canary, RELRO, CFI/PAC/CET, allocator, sandbox |
+| Process | privilege, chroot/container, worker isolation, watchdog/restart |
+| Information | version fingerprint, pointer/module/heap leak availability |
+| Reliability | attempts, races, connection/session persistence, crash side effects |
+
+Rate exploitability separately from bug severity. A strong memory disclosure can enable a later control-flow bug; a large overflow may remain crash-only under the deployed constraints.
+
+## Protocol and Patch Pairing
+
+- Load `protocol_reverse_engineering` when valid negotiation/state is required before the vulnerable field.
+- Load `advisory_to_poc` for vulnerable/fixed artifact matrices and patch-invariant review.
+- Load `appliance_firmware` for rootfs, listener, runtime overlay, architecture, and device lifecycle mapping.
+- Model transformation boundaries explicitly when the memory length or type changes across transport, parser, decoder, or native FFI layers.
+
+## Validation Deliverable
+
+Include:
+
+1. exact vulnerable/fixed build, platform, configuration, and artifact hashes
+2. minimized input plus complete protocol/parser prerequisites
+3. source, IR/bytecode, or assembly trace from attacker field to invalid access, with the exact crashing process/build identity
+4. debugger/sanitizer/core evidence and non-triggering control
+5. primitive precision and constraints
+6. mitigation, architecture, allocator, process, and restart analysis
+7. bug-existence and exploitability conclusions stated separately
+8. adjacent callers/parser family reviewed
+
+## False Positives
+
+- Connection close caused by protocol rejection, idle timeout, rate limit, or load balancer behavior.
+- Process restart inferred from one failed request without process/console evidence.
+- Sanitizer finding unreachable in the deployed feature, route, architecture, or configuration.
+- Out-of-bounds read that returns only deterministic in-buffer padding, described as sensitive disclosure.
+- Crash-only overwrite called RCE without a controlled data/control primitive and mitigation analysis.
+- Decompiler type or buffer size accepted as ground truth without assembly/runtime confirmation.
+- Lab build with mitigations disabled presented as representative of production.
+
+## Summary
+
+Memory-corruption research is constraint analysis. Trace exact bytes through length, allocation, copy, object lifetime, and later use; establish the read/write/control primitive; then evaluate architecture, mitigations, allocator, protocol, and process context independently from the mere existence of a crash.

strix/skills/vulnerabilities/path_traversal_lfi_rfi.md

@@ -11,6 +11,7 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 
 **Path Traversal**
 - Read files outside intended roots via `../`, encoding, normalization gaps
+- Write or create files outside intended roots, then evaluate framework-controlled resolution paths separately from direct web access
 
 **Local File Inclusion (LFI)**
 - Include server-side files into interpreters/templates
@@ -51,7 +52,7 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 ### Capability Probes
 
 - Path traversal baseline: `../../etc/hosts` and `C:\Windows\win.ini`
-- Encodings: `%2e%2e%2f`, `%252e%252e%252f`, `..%2f`, `..%5c`, mixed UTF-8 (`%c0%2e`), Unicode dots and slashes
+- Encodings: `%2e%2e%2f`, `%252e%252e%252f`, `..%2f`, `..%5c`, and Unicode lookalikes only where a documented conversion layer maps them to path syntax
 - Normalization tests: `..../`, `..\\`, `././`, trailing dot/double dot segments; repeated decoding
 - Absolute path acceptance: `/etc/passwd`, `C:\Windows\System32\drivers\etc\hosts`
 - Server mismatch: `/static/..;/../etc/passwd` ("..;"), encoded slashes (`%2F`), double-decoding via upstream
@@ -69,7 +70,7 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 
 ### OAST
 
-- RFI/LFI with wrappers that trigger outbound fetches (HTTP/DNS) to confirm inclusion/execution
+- For RFI or URL-capable resource loaders, a correlated callback confirms server-side resolution/fetch. It does not by itself prove inclusion or execution; use a separate response or side-effect oracle for that claim.
 
 ### Side Effects
 
@@ -81,7 +82,7 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 ### Path Traversal Bypasses
 
 **Encodings**
-- Single/double URL-encoding, mixed case, overlong UTF-8, UTF-16, path normalization oddities
+- Single/double URL-encoding, mixed case, UTF-16 or Unicode conversion only when present in the stack, and path normalization oddities
 
 **Mixed Separators**
 - `/` and `\\` on Windows; `//` and `\\\\` collapse differences across frameworks
@@ -147,13 +148,38 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 - Verify symlink handling and path canonicalization prior to write
 - Impact: overwrite config/templates or drop webshells into served directories
 
+### File Write to Execution
+
+Characterize the write primitive before choosing a payload:
+
+- create vs overwrite vs append; atomic replace vs streamed write
+- absolute vs relative path; controllable directory, filename, extension, and bytes
+- text encoding, newline conversion, templating, compression, or report generation applied before write
+- target process permissions and whether symlinks are followed
+- immediate load, hot reload, cache invalidation, restart, scheduled task, or user action required
+
+Then inventory generic execution and influence surfaces:
+
+- view/template search paths and implicit rendering
+- module, controller, plugin, package, or class autoload directories
+- application bootstrap files and language package initializers
+- server/user configuration that changes handler or interpreter behavior
+- job definitions, hooks, startup scripts, cron/task inputs, and CI workspace files
+- logs, sessions, caches, generated sources, and compiled-template directories later included or evaluated
+
+Do not require the malicious file to be directly web-accessible. An HTTP extension allowlist can block `/path/payload.ext` while an internal view engine, autoloader, or interpreter still opens and executes that file through a clean route. Trace public request filtering and internal file resolution as separate security boundaries.
+
+Test search order with candidate marker files or filesystem traces. Trigger the normal route/action that causes internal resolution. Record whether the framework creates, compiles, caches, or executes the artifact and what reload condition is required.
+
 ## Testing Methodology
 
 1. **Inventory file operations** - Downloads, previews, templates, logs, exports/imports, report engines, uploads, archive extractors
 2. **Identify input joins** - Path joins (base + user), include/require/template loads, resource fetchers, archive extract destinations
 3. **Probe normalization** - Separators, encodings, double-decodes, case, trailing dots/slashes
 4. **Compare behaviors** - Web server vs application behavior
-5. **Escalate** - From disclosure (read) to influence (write/extract/include), then to execution (wrapper/engine chains)
+5. **Characterize writes** - Determine create/overwrite/append, path and byte control, permissions, and reload/trigger conditions
+6. **Map resolvers** - Test template/view search paths, autoloaders, plugins, configs, jobs, and other internal consumers separately from direct file serving
+7. **Escalate** - From disclosure (read) to influence (write/extract/include), then to execution through a proven resolver or interpreter
 
 ## Validation
 
@@ -161,7 +187,8 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 2. For LFI, demonstrate inclusion of a benign local file or harmless wrapper output (`php://filter` base64 of index.php)
 3. For RFI, prove remote fetch by OAST or controlled output; avoid destructive payloads
 4. For Zip Slip, create an archive with `../` entries and show write outside target (e.g., marker file read back)
-5. Provide before/after file paths, exact requests, and content hashes/lengths for reproducibility
+5. For file-write chains, first prove a canary is created at the intended path, then prove the normal resolver loads it; document cache/reload requirements
+6. Provide before/after file paths, exact requests, and content hashes/lengths for reproducibility
 
 ## False Positives
 
@@ -184,6 +211,7 @@ Improper file path handling and dynamic inclusion enable sensitive file disclosu
 3. For LFI, prefer `php://filter` base64 probes over destructive payloads; enumerate readable logs and sessions
 4. Validate extraction code with synthetic archives; include symlinks and deep `../` chains
 5. Use minimal PoCs and hard evidence (hashes, paths). Avoid noisy DoS against filesystems
+6. When direct execution is blocked, enumerate internal search paths before assuming the write is low impact
 
 ## Summary
 

strix/skills/vulnerabilities/semantic_confusion.md

@@ -0,0 +1,189 @@
+---
+name: semantic-confusion
+description: Cross-component semantic confusion testing for parser differentials, normalization mismatches, overloaded fields, lifecycle state drift, internal redirects, protocol translation, and validator-to-sink inconsistencies
+---
+
+# Semantic Confusion
+
+Use this skill when two or more components consume the same attacker-influenced value. The central question is not merely whether input is validated, but whether every consumer assigns the same meaning to the value at the moment it makes a security decision.
+
+Typical chains cross a validator, router, proxy, framework, parser, filesystem, interpreter, cache, or browser. A value can be safe in one representation and dangerous after a later decode, normalization, fallback, or field mutation.
+
+## Authorization and Safety Boundary
+
+- Run active differentials only against explicit authorized targets. Preserve destination allowlists and set request, rate, body, response, timeout, and retry ceilings.
+- Perform malformed framing, delayed-body, oversized-input, crash, or resource-exhaustion cases only in a restartable isolated lab with health monitoring.
+- Use synthetic canaries, reversible actions, non-secret protected resources, or a constant per-test callback identifier. Never place target-derived secrets in an OAST label/body.
+- Change one representation axis at a time so the security-relevant disagreement remains attributable to a specific boundary.
+- Pair `browser_security` when the final consumer is a browser context, worker, cache, or navigation state machine.
+- Do not load this skill for pure ownership drift where every component resolves and interprets the name consistently; use `infrastructure_lifecycle` unless a representation, alias, identity, or resolution-result mismatch is present.
+
+## Core Model
+
+Build a transformation graph before spraying payloads:
+
+```text
+raw bytes
+  -> transport parser
+  -> proxy / middleware representation
+  -> authorization or validation decision
+  -> rewrite / decode / normalization
+  -> internal redirect or dispatch
+  -> final sink interpretation
+```
+
+For every edge, record:
+
+- exact input representation: bytes, string, URL, path, header list, object, or structured field
+- owning component and implementation/version
+- transformation performed, including error and fallback behavior
+- security decision made before or after the transformation
+- whether the original and transformed values remain available simultaneously
+- whether a field changes semantic type, such as filename to URL or MIME type to handler
+
+The highest-signal condition is `security_check(value_A)` followed by `sink(transform(value_A))` where the checked and consumed representations are not equivalent.
+
+## High-Value Confusion Classes
+
+### Parser Differentials
+
+- Compare browser, framework, proxy, library, and backend parsing of the exact same bytes.
+- Test duplicate and comma-joined fields, first-match vs last-match behavior, invalid-token recovery, comments, quoting, and empty members.
+- Include structured formats and metadata: URL, MIME, JSON, multipart, XML, cookies, forwarded headers, and serialized objects.
+- Treat leniency as a security feature only when every downstream consumer is equally lenient in the same way.
+
+### Normalization and Canonicalization Drift
+
+- Map percent-decoding count, Unicode conversion, slash/backslash handling, dot-segment removal, case folding, IDNA, numeric IP conversion, and filesystem cleanup.
+- Compare string-prefix checks with segment-aware or origin-aware comparisons.
+- Test malformed Unicode and replacement behavior; a rejected code point may become an allowed delimiter or wildcard later.
+- Test path, query, and fragment separately. Browsers and routers commonly transform each source differently.
+
+### Field and Type Overloading
+
+- Identify shared fields reused for different concepts: path vs URL, content type vs handler, display name vs executable name, route vs filesystem location.
+- Trace every writer and reader of the field across the complete lifecycle.
+- Look for implicit fallback: when the intended field is empty, another field becomes authoritative.
+- Exercise fields after errors, rewrites, subrequests, retries, internal redirects, and protocol upgrades/downgrades.
+
+### Lifecycle and State Drift
+
+- Trigger error paths that should terminate processing and verify that later phases actually stop.
+- Look for stale metadata copied into a new request, subrequest, background job, cache entry, or retry.
+- Compare direct external access with internal dispatch. Edge controls may inspect the public URL while an internal resolver opens a different path or invokes a different handler.
+- Test order-dependent behavior: validation before rewrite, auth before route normalization, or content classification before processing.
+
+### Boundary Translation
+
+- Map HTTP/2 to HTTP/1 translation, proxy to application rewriting, URL to filesystem resolution, upload detector to content consumer, and client router to API request construction.
+- In a restartable lab and only when supported by evidence, vary framing, bounded delays/body sizes, content type, pseudo-headers, and method conversion. Check target health after resource-sensitive cases.
+- Do not assume a WAF or authorization sidecar sees the full body or final normalized request.
+
+### Namespace and Resolution Fallback
+
+- Identify names resolved across multiple scopes: local path, environment `PATH`, cache, private registry, public registry, plugin directory, template search path, or autoloader.
+- Record lookup order and what happens when the intended entry is missing.
+- Compare protected package/module names with exposed command, binary, handler, or alias names. For npm, a scoped package can expose an unscoped `bin` name, so the protected package name and invoked executable may differ.
+- Treat automatic remote fallback or search-path fallback as an execution boundary.
+- Load `npx_confusion` when `npx` or `npm exec` may reinterpret a missing executable as a public package spec.
+
+## Reconnaissance
+
+### Black-Box Mapping
+
+1. Capture a clean baseline with raw request and response bytes.
+2. Change one representation axis at a time: encoding depth, delimiter, duplicate, separator, method, protocol, body framing, or Unicode form.
+3. Diff status, headers, body digest/length, timing, redirects, cache state, and out-of-band callbacks.
+4. Replay through different paths: direct origin vs CDN, HTTP/1.1 vs HTTP/2, public route vs alternate host, synchronous vs background processing.
+5. Cluster responses by behavior before escalating. Small differentials reveal component boundaries.
+
+### Source-Aware Mapping
+
+- Find every read and write of shared request/context fields, not just the obvious sink.
+- Trace route matching, auth middleware, rewrites, internal redirects, handler selection, and response generation in execution order.
+- Inventory decode/parse/normalize calls and note whether return values or errors are ignored.
+- Search for compatibility fallbacks, legacy aliases, permissive recovery, default handlers, and search-path iteration.
+- Inspect packaging and deployment defaults; distro configuration, enabled modules, plugins, and symlinks often determine reachability.
+
+## Differential Test Matrix
+
+Build a bounded matrix from relevant axes instead of blindly combining everything:
+
+| Axis | Representative variants |
+|---|---|
+| Encoding | raw, once encoded, twice encoded, mixed case, malformed Unicode |
+| Structure | duplicate, comma-joined, empty member, quoted, comment-like suffix |
+| Path | `/`, `\\`, `//`, dot segments, absolute, sibling-prefix collision |
+| URL | userinfo, numeric IP, alternate IP radix, trailing dot, fragment/query split |
+| Transport | HTTP/1.1, HTTP/2, chunked/fixed body, delayed DATA, oversized body |
+| Lifecycle | normal, error, retry, internal redirect, cache hit, background worker |
+| Consumer | edge, application, library, filesystem, interpreter, browser |
+
+Select axes supported by evidence from the target. Record which component saw which representation.
+
+### Repeatable Harnesses
+
+- For two local parsers, canonicalizers, or validator/consumer functions, load `hypothesis` and express the expected relationship as a property. Bound sizes/examples and keep the minimized disagreement as a regression test.
+- For an ordered HTTP flow with cookies, redirects, captured values, and assertions, load `hurl` and encode vulnerable, fixed, and negative-control environments using the same request chain.
+- Use raw-byte or protocol-specific harnesses when a high-level HTTP client would normalize the ambiguity away.
+- Separate input generation from transport. Generators that are safe against pure local functions become active fuzzers when connected to a live target.
+
+## Chaining Strategy
+
+Treat the first differential as a primitive, then ask what authority the later consumer has:
+
+- auth or ACL bypass -> protected route or file
+- path/URL confusion -> source disclosure, SSRF, local socket, or unintended handler
+- detector/consumer mismatch -> active upload processing or inline browser execution
+- internal redirect state carryover -> handler selection or policy bypass
+- search-path or namespace fallback -> attacker-controlled code resolution
+- browser/router decode -> client-side path traversal, CSRF-like action, SSRF, or XSS sink
+
+Enumerate existing local gadgets only after the primitive is proven. Prefer generic classes such as interpreters, template engines, debug tools, package scripts, local sockets, and autoload paths over a vendor-specific file list.
+
+## Testing Methodology
+
+1. **Define the invariant** - State what all components are expected to agree on: origin, path, type, handler, identity, length, or package name.
+2. **Draw the graph** - List consumers and transformations in real execution order.
+3. **Locate early decisions** - Mark validation, auth, WAF, cache, and routing checks.
+4. **Locate late meaning changes** - Mark decodes, rewrites, fallback, internal dispatch, and sink parsing.
+5. **Build a focused matrix** - Exercise only transformations supported by the stack.
+6. **Isolate the disagreement** - Produce paired inputs that differ at one boundary and explain both interpretations.
+7. **Prove the primitive safely** - Use a synthetic protected canary, reversible marker, constant callback identifier, or no-op handler whose behavior and side effects are understood.
+8. **Escalate by capability** - Track Read -> influence -> write -> dispatch -> execute transitions with evidence and prerequisites for every edge.
+9. **Cross-check versions/configurations** - Reproduce on a fixed version or hardened configuration when possible.
+
+## Validation
+
+A valid confusion finding should include:
+
+1. the exact bytes or structured input supplied
+2. the representation observed by the security control
+3. the different representation observed by the final consumer
+4. the transformation or lifecycle event that created the difference
+5. paired control and exploit results across repeat runs
+6. version, protocol, configuration, and interaction prerequisites
+7. a minimal impact proof that does not depend on unrelated undefined behavior
+
+## False Positives
+
+- Different error messages with identical final authorization and sink behavior
+- A parser accepts odd syntax but downstream consumers preserve the same safe meaning
+- A normalization difference visible only in logs, with no security decision between representations
+- WAF bypass where the application itself rejects the request identically
+- Version-specific behavior claimed as universal without testing the relevant deployment
+- A search-path candidate that is attacker-named but cannot be created, claimed, loaded, or executed
+
+## Pro Tips
+
+1. Begin with relationships and shared state, not endpoint payload lists.
+2. Preserve raw traffic; high-level clients often normalize away the exploit before sending it.
+3. Error paths are alternate lifecycles. Verify which fields survive and which phases still execute.
+4. Compare direct and internal access separately; ingress policy rarely governs framework file IO or handler dispatch.
+5. When a prefix allowlist is used, test a sibling sharing the prefix and verify with a segment-aware comparison.
+6. Distinguish presence, reachability, and impact. Each needs separate evidence.
+7. Generalize a finding by naming the disagreement class, not by copying its final payload.
+
+## Summary
+
+Semantic confusion exists when a security decision and a privileged consumer disagree about the meaning of the same attacker-influenced data. Model the entire transformation lifecycle, isolate one disagreement at a time, and prove both interpretations. The reusable unit is the boundary and its invariant—not a CVE-specific string.