claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a spec
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add SnailSploit/Claude-Red --skill offensive-bug-identification -a cursor -y
claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a specific attack surface — from SQLi to shellcode, EDR evasion to exploit development.
Questions
How do I install Claude-Red?
Download Skills/fuzzing/offensive-bug-identification/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does Claude-Red live?
The publisher keeps it at https://github.com/SnailSploit/Claude-Red.
Which agents can use Claude-Red?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a specific attack surface — from SQLi to shellcode, EDR evasion to exploit development.
Systematic bug identification methodology: source code review patterns, black-box testing strategies, taint analysis, dangerous function hunting, data flow tracing, and automated scanning setup. Use for code audits, bug bounty triage, or building vulnerability identification pipelines.
Trigger Phrases
Use this skill when the conversation involves any of:
bug identification, code review, taint analysis, dangerous functions, data flow, source audit, black box, vulnerability identification, static analysis, code audit, bug hunting
Instructions for Claude
When this skill is active:
Load and apply the full methodology below as your operational checklist
Follow steps in order unless the user specifies otherwise
For each technique, consider applicability to the current target/context
Track which checklist items have been completed
Suggest next steps based on findings
Full Methodology
Bug Identification
Overview
Bug identification is the process of discovering potential vulnerabilities in software through various techniques including static analysis, dynamic analysis, and fuzzing. This document outlines methodologies and tools for effective vulnerability research.
Debugging: Trace execution paths with controlled input
Instrumentation: Coverage-guided exploration
Taint Analysis: Track input propagation
Phase 4: Fuzzing
Corpus Generation: Create valid seed inputs
Harness Development: Isolate target functionality
Coverage Monitoring: Identify untested code paths
Crash Triage: Classify and prioritize findings
Phase 5: Exploitation
Primitive Development: Convert bug to reliable primitives
Mitigation Bypass: Defeat ASLR, DEP, CFG, etc.
Payload Development: Create working exploit
Weaponization: Package for real-world use (if authorized)
Attack Surface Identification
Before diving into specific bug hunting techniques, it's essential to understand where to look for vulnerabilities.
Windows User Mode
Shared Memory
RPC
Named Pipes
File & Network IO
Windows Messages
For authentication-related vulnerabilities, see Windows Auth
Kernel
Device Drivers
Many third-party software with drivers to target
Can accept arbitrary user input via the IOCTL interface
Also performs actions when we open,close handles to it
OS
Drivers that handle hardware and user input
Intercepts/transitions from user to kernel
Modern Linux interfaces (hotspots)
io_uring: SQE size/offset confusions, submission/completion race windows, kernel copy‑sizes derived from user buffers
userfaultfd: cross‑thread write‑what‑where and TOCTOU primitives during fault handling
seccomp user‑notifier: confused‑deputy patterns in broker processes; notifier time‑of‑check vs time‑of‑use gaps
Hyper-V & VTL Interfaces – On many modern Windows 11 systems (especially 24H2 on supported hardware), Virtualization‑Based Security and VTL1 are enabled or easily enabled by policy. Treat the hypervisor surface (e.g., hvix64.exe and synthetic MSRs) as a common kernel target, and verify VBS/HVCI status on the host before assuming defaults.
Drivers
DriverEntry: registers for any callbacks, setup structure, etc
I/O Handlers: handlers that get called when a process attempts to open,close,etc the driver, IOCTL allows driver functionality to be called from user processes
Practical triage example (CVE‑2025‑8061):
IOCTL handlers that accept a fixed‑size struct and pass a user‑controlled PHYSICAL_ADDRESS directly to MmMapIoSpace
then memcpy out/in mapped memory (sometimes via wrappers that swap src/dst) indicate physical memory read/write primitives.
gRPC / Protobuf: length truncation across language FFI, map/list coercion; see gRPC framing and protobuf varint rules
GraphQL: input coercion and resolver recursion limits; check GraphQL spec for type coercion semantics
WebAssembly Runtimes
WASM JIT optimization bugs in V8, Wasmtime, Wasmer
WASI sandbox escapes through host‑call interfaces
Typed‑Func‑Refs, GC, Tail‑calls, Memory64 expand type/bounds confusion surface. See the WebAssembly proposals status page for current rollout and engine adoption.
Checklist:
validate table element types/import signatures/hostcall marshalling
fuzz mixed 32/64-bit memories.
Fuzzing tip: compile native libs to WASM for fast, deterministic mutation cycles
Browser / JS Engine Exploitation
Modern V8 Architecture (2024-2025)
V8 now uses a multi-tier JIT pipeline with distinct exploitation characteristics:
HGX HMC (verify CVE/advisories): research indicates malformed NVLINK‑C2C packets can corrupt HMC register space; confirm against vendor advisories for the specific platform.
vGPU manager IOCTLs: diff nvidia‑vgpu‑mgr monthly; watch VGPU_PLUGIN_IOCTL_GET_STATE and similar calls for unchecked buffers.
LeftoverLocals info‑leak: contiguous VRAM allocations can leak data from prior tenants in multi‑tenant AI clusters.
Hardware Security Attack Surface
Side-Channel Analysis
Power Analysis: DPA/SPA attacks on cryptographic operations
Electromagnetic (EM): Near-field probing of processor emissions
Patch diffing compares vulnerable and patched versions of binaries to identify security changes.
What is Patch Diffing
Patch diffing is a technique to identify changes across versions of binaries related to security patches. It compares a vulnerable version of a binary with a patched one to highlight the changes, helping to discover new, missing, and interesting functionality across versions.
Benefits
Single Source of Truth: Without a CVE blog post or sample POC, a patch diff can be the only source of information to determine changes and deduce the original issue.
Vulnerability Discovery: While understanding the original issue, you may discover additional vulnerabilities in the troubled code area.
Skill Development: Patch diffing provides focused practice in reverse engineering and helps build mental models for various vulnerability classes.
Challenges
Asymmetry: Small source code changes can drastically affect compiled binaries.
Finding Security-Related Changes: Security patches often include other changes like new features, bug fixes, and performance improvements.
Minimizing Noise:
Diff the correct binaries to avoid analyzing unrelated updates
Reduce the time delta between compared versions
Use binary symbols when available to add precision to comparisons
Tools
IDA Pro with plugins like DarunGrim and Diaphora
BinDiff Works with analysis output from IDA or Ghidra
The process of patch diffing typically follows these steps:
Preparation
Create a diffing session
Load binary versions (vulnerable and patched)
Ensure binaries pass preconditions
Run auto-analysis on both binaries
Evaluation
Run correlators to find similarities
Generate associations between binaries
Evaluate matches between functions
Accept matching functions
Analyze differences until sufficient understanding is reached
Function Analysis
Identify new functions: Functions in the patched binary with no match in the original
Identify deleted functions: Functions in the original binary with no match in the patched version
Identify changed functions: Functions that exist in both versions but have been modified
Focus on functions with security relevance (often indicated by their names or based on CVE descriptions)
Interpreting Results
New functions often indicate added security checks or validation
Changed functions may show modified logic for handling edge cases
Correlate changes with public CVE information when available
Remember that patches are not necessarily atomic - multiple issues may be fixed in one update
When using Ghidra's Version Tracking:
Use "Show Only Unmatched Functions" filter to identify new or deleted functions
Look for functions with a similarity score below 1.0 to find modified functions
Examine the modified functions to understand what security checks were added
Starting with Ghidra 11 (December 2024) a built-in Partial Match Correlator covers most PatchDiffCorrelator use-cases; install the plugin only if you need bulk-mnemonics scoring.
Case Study: 7‑Zip Symlink Path Traversal
Target: 7‑Zip 24.09 (vulnerable) → 25.00 (fixed)
File of interest: CPP/7zip/UI/Common/ArchiveExtractCallback.cpp
High‑signal edits: absolute‑path detection and link‑path validation for WSL/Linux symlinks converted on Windows.
Linux/WSL symlink data containing a Windows‑style path (e.g., C:\...) was treated as relative by the Linux absolute‑path check, setting linkInfo.isRelative = true.
SetFromLinkPath prefixed the symlink’s zip‑internal directory when building relatPath, letting IsSafePath(relatPath) pass despite an absolute Windows target.
A subsequent “dangerous link” guard checked _item.IsDir; non‑directory symlinks skipped the validation.
Result: symlink creation to arbitrary absolute Windows paths; extracted files written into the link target.
# Downloading the correct IPSWs
ipsw download --device Macmini9,1 -V -b 23A344
ipsw download --device Macmini9,1 -V -b 23B74
# Comparing two different IPSWs
ipsw diff UniversalMac_14.0_23A344.ipsw UniversalMac_14.1_23B74.ipsw
# What is inside the DSC
ipsw extract -d IPSW
# Extracting files
ipsw extract -f -p file
# Extracting specific architecture file
ipsw macho lipo Contacts
Windows 11 Patch Diffing
This checklist mirrors the Apple IPSW workflow but uses Microsoft tooling and build numbers.
Identify the target update
Open Settings → Windows Update → Update history or consult the Windows Release Health dashboard to note the KB and OS build numbers (e.g., KB5037778 → build 22631.3525).
Record the previous build you want to diff against (e.g., 22631.3447).
Collect the binaries
winbindex download tcpip.sys 10.0.22631.3447 10.0.22631.3525
mkdir pre,post
wget -Uri https://www.catalog.update.microsoft.com/Download.aspx?q=KB5037778 -OutFile kb.msu
expand -F:* .\kb.msu .\post
# repeat for the older KB into .\pre
# Download both *UUP* bundles, then run
uup_download_windows.cmd --extract
# and copy changed PE files to *pre* / *post*
Fetch matching symbols
# Requires Debugging Tools for Windows
foreach ($ver in '3447','3525') {
symchk /r .\$ver /s SRV*https://msdl.microsoft.com/download/symbols
}
Load in the disassembler
Open tcpip.sys from both pre and post folders in IDA 8+ or Ghidra 11; ensure PDB symbols resolve.
Save the IDA databases (e.g., tcpip_3447.i64, tcpip_3525.i64).
Run the diff
BinDiff 7: Tools → BinDiff → Diff Database… and select the two IDBs to generate a .BinDiff report.
Snapshot two Windows 11 VMs (build 3447 and 3525).
Attach WinDbg (kernel mode) using bcdedit /dbgsettings net hostip:<IP> port:<PORT>.
Reproduce the issue against the pre‑patch VM; confirm no crash or breakpoint triggers in the post‑patch VM.
Automate monthly
Schedule a PowerShell script that, every Patch Tuesday (second Tuesday), downloads the latest Cumulative Update, extracts changed PE files, retrieves symbols, and launches a headless Diaphora diff.
Email the generated HTML report to quickly spot new attack surface.
[!TIP]
For large modules like ntoskrnl.exe, diff only the .text section to save RAM:
bindiff --primary ntoskrnl_pre.i64 --secondary ntoskrnl_post.i64 --section .text
Linux Kernel Patch Diffing
Patch‑diffing Linux kernels is often faster at the source level, but for binary‑only targets (vendor kernels, modules) function‑level diffing is still practical.
Identify target builds
Note distro and kernel build (e.g., Ubuntu 6.8.0-47-generic, RHEL 5.14.0-503).
Capture both pre and post versions (package changelogs or CVE bulletins help).
Fetch kernel images and debug info
Ubuntu/Debian:
# Discover versions
apt list -a linux-image-generic | cat
# Download image + modules dirs (repeat for both versions)
apt-get download linux-image-unsigned-<ver>-generic linux-modules-<ver>-generic
# Debug symbols via debuginfod (preferred to ddebs)
export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com https://debuginfod.debian.net"
# If only vmlinuz is present, use the upstream helper
/usr/src/linux-headers-<ver>/scripts/extract-vmlinux /boot/vmlinuz-<ver> > vmlinux-<ver>
# Or take vmlinux directly from debuginfo package tree
Identify changed modules quickly
# Compare module trees (pre vs post)
rsync -rcn --delete /lib/modules/<pre>/ /lib/modules/<post>/ | grep -E "\.ko$" | sed 's/^/chg: /'
Function‑level binary diff
Open vmlinux-<pre> and vmlinux-<post> in Ghidra 11/IDA 8 and run Diaphora/BinDiff/Ghidriff.
For hot subsystems (e.g., io_uring, net/ipv6, fs/overlayfs), diff only the relevant .ko pairs to reduce noise.
Source‑level triage (when sources are available)
# Ubuntu example: unpack both source trees, then
git diff --no-index -- function.c.orig function.c.patched | less
# Or use diffoscope for enriched reports
Symbolization and crash mapping (cheat‑sheet)
# Decode kernel oops backtraces to lines
./scripts/decode_stacktrace.sh vmlinux /lib/modules/<ver>/build < dmesg.log
# Map PC to file:line quickly
addr2line -e vmlinux-<ver> 0xffffffff81234567
[!TIP]
For modern distros built with Clang: KCFI and fine‑grained CFI thunks create many small stub changes; filter by real function body deltas to focus on security‑relevant logic.
[!NOTE]
Syzkaller routinely bisects kernel bugs; consult syzbot reports for reproducers and fix commits, then confirm your diff isolates the same region before deeper RE.
Always validate (offset + length) <= remaining_buffer and <= total_buffer using a widened type (e.g., u64) before arithmetic; reject on overflow with check_add_overflow()/array_size() helpers.
For chained entries with a next field, assert: next >= sizeof(entry_header), next <= remaining_buffer, and that pointer advancement actually makes progress. For entries carrying sub-lengths (e.g., name_len, value_len), assert header + name_len + value_len <= next.
Do not cast to a struct until the full header is present and aligned; gate recasts with a prior buf_len check.
Fixed-size buffers vs variable-length payloads
Ban unbounded copies/crypto/decompression into fixed-size arrays. Require len <= sizeof(array) (or clamp with min_t() and bail) when writing into in-struct arrays.
Crypto transforms are just writes with extra steps: if using ARC4/AES helpers that copy len bytes into a fixed buffer (e.g., session keys), bound len against a named maximum constant and prefer allocating a buffer sized from validated len.
Type/width hazards
Normalize parser math to a wide unsigned type before comparisons; avoid truncating u32/u64 fields into u16 for size checks. Favor size_t/u64 for offset+len arithmetic, then compare to buf_len of the same width.
Loop structure around next
Pattern to flag: e = (struct entry *)((char *)e + next); without a preceding block that revalidates buf_len and the entry’s internal sub-lengths.
Ensure a break condition on exhaustion and reject zero/negative progress values to avoid infinite loops or pointer stagnation.
Allocation-size correlation
When parser-controlled len influences a subsequent write into an object from a fixed SLUB cache (e.g., kmalloc-512), ensure the write length is bounded by the destination object field, not just the incoming length.
Patch-diff signals to prioritize
Newly added guards like if (len > CONST) return -EINVAL;, if (buf_len < sizeof(struct foo)) return -EINVAL;, or conversions to min_t(size_t, len, sizeof(...)).
Insertions of check_add_overflow(offset, len, &sum) or array_size(n, sz) helpers in hot parse paths.
Static query seeds (Semgrep/CodeQL), to tune per codebase
Crypto/decompression writes to fixed arrays (seed with function names in your tree, e.g., *_crypt, *_decrypt, decompress_*).
Dynamic confirmation (cheap)
Grammar fuzz small invariants: send next < header, next > remaining, name_len + value_len > next, and len > MAX_CONST variants; expect -EINVAL/reject. If not, investigate.
Use TUN/TAP + KCOV to drive packet/SMB request paths; enable KASAN/KMSAN to surface overflows/leaks early.
Reference (motivating example)
Lessons distilled from a 2025 ksmbd remote chain writeup combining a fixed-buffer overflow in NTLM auth with an EA next validation issue — see Will’s Root: Eternal‑Tux: KSMBD 0‑Click RCE (https://www.willsroot.io/2025/09/ksmbd-0-click.html).
Case Study: EvilESP Vulnerability (CVE-2022-34718)
This case study demonstrates real-world patch diffing to identify a Windows TCP/IP RCE vulnerability.
Vulnerability Overview
CVE-2022-34718: Critical RCE in tcpip.sys discovered in September 2022
An unauthenticated attacker could send specially crafted IPv6 packets to Windows nodes with IPsec enabled
Affects the handling of ESP (Encapsulating Security Payload) packets in IPv6 fragmentation
Patch Diffing Process
Binary Acquisition
Used Winbindex to obtain sequential versions of tcpip.sys (pre-patch and post-patch)
Loaded both files in Ghidra with PDB symbols
Diff Analysis
Used BinDiff to compare the binaries
Identified only two functions with less than 100% similarity: IppReceiveEsp and Ipv6pReassembleDatagram
Code Analysis
Ipv6pReassembleDatagram: Added bounds check comparing nextheader_offset against the header buffer length
IppReceiveEsp: Added validation for the Next Header field of ESP packets
Root Cause Identification
Found an out-of-bounds 1-byte write vulnerability
ESP Next Header field is located after the encrypted payload data
A malicious packet could cause nextheader_offset to exceed the allocated buffer size
(Update: Server 2022 build 20349.2300, May 2024, hardened this code path; the original PoC needs a 2-byte pad tweak to reproduce the crash.)
Exploitation
Required setting up IPsec security association on the victim
Created fragmented IPv6 packets encapsulated in ESP
Controlled the offset of the out-of-bounds write through payload and padding size
Value written is controllable via the Next Header field
Limited to writing to addresses that are 4n-1 aligned (where n is an integer)
Initially achieved DoS with potential for RCE through further exploitation
Lessons Learned
Binary patch diffing effectively identified the vulnerability location and nature
Understanding protocol specifications (ESP and IPv6 fragmentation) was critical
Simple buffer checks are still overlooked in complex networking code
Even limited primitives (single byte overwrite at constrained offsets) can be dangerous
Open unpatched version in IDA as the primary and the second, after that use BinDiff add-on to find the differences between them
then right click on a different matched function and see the visual diff in bin diff
also you can uncheck proximity browsing to see the entire function
look at red blocks and then yellow blocks
With patch clean script you can only see the actual changed files
Static Analysis Tools
IDA Pro and Rust Tools for Vulnerability Research
rhabdomancer: IDA Pro headless plugin that locates calls to potentially insecure API functions in binary files
Helps auditors backtrace from candidate points to find pathways allowing access from untrusted input
Generates JSON/SARIF reports containing vulnerable function calls and their details
Written in Rust using IDA Pro 9 idalib and Binarly's idalib Rust bindings
haruspex: IDA Pro headless plugin that extracts pseudo-code generated by IDA Pro's decompiler
Exports pseudo-code in a format suitable for IDEs or static analysis tools like Semgrep/weggli
Creates individual files for each function with their pseudo-code
Can be used as a library by third-party crates
augur: IDA Pro headless plugin that extracts strings and related pseudo-code from binary files
Stores pseudo-code of functions that reference strings in an organized directory tree
Helps trace how strings are used within the application
Complements other reverse engineering tools
Modern Static Analysis Tools
Semgrep Pro – Cloud-augmented SAST with custom rule sharing, LLM-assisted rule writing
CodeQL – GitHub's semantic code analysis, excellent for variant analysis
Weggli – Fast semantic search for C/C++ (better than grep for code patterns)
Joern – Code property graph analysis for vulnerability discovery
Ghidra 11.2+ – Built-in ML-powered function signature recognition
Load into Lighthouse (IDA) or lcov HTML to identify cold paths reachable from attacker input
Use results to select fuzz targets and build a minimal, representative seed corpus
Fuzzing
Fuzzing is a technique where you feed the application malformed inputs and monitor for crashes or unintended behaviors. See the dedicated Fuzzing document for more detailed techniques.
Fuzzing Overview
What is Fuzzing?
Target software parses controllable input
We create and/or mutate input and feed it into program
Emerald – Generates drcov data for coverage visualization
Specialized Fuzzers
ChatAFL / LLM-driller – LLM-guided corpus expansion (+30% coverage on complex targets)
Reads-From Fuzzer (RFF) – Concurrency fuzzer for race/TOCTOU bugs
LibFuzzer – In-process, coverage-guided fuzzer for source-available targets
Radamsa → Replaced by LibAFL mutators (more coverage-aware)
Symbolic Execution Engines
Triton – Dynamic binary analysis framework
Angr – Binary analysis platform with symbolic execution
Manticore – Dynamic symbolic execution tool
S2E – Selective symbolic execution platform
Continuous-Integration Fuzzing
ClusterFuzzLite – GitHub Actions/CI runner that feeds corpora to AFL++, libFuzzer or honggfuzz and files issues automatically.
Snapshot Fuzzing
VMM Snapshot Fuzzing
QEMU Snapshots: Fast restoration for stateful targets
KVM Acceleration: Dirty page tracking for efficient resets
Persistent Mode: Memory-only reset without full VM restore
Fuzzing Types
Dumb Fuzzing
Just sending random data to the target
Smart Fuzzing
Mutation Based: Test cases are obtained by applying mutations to valid, known good samples (e.g., Radamsa)
Generation(Grammar) Based: Test cases are obtained by modeling files or protocol specifications based on models, templates, RFCs, or documentation (e.g., Peach Fuzzer)
Model Based: Test cases are obtained by modeling the target protocol/file format (when you want to test the target's ability to accept and process invalid sequences of data)
Differential Fuzzing: Comparing outputs of different implementations with the same input
Evolutionary Fuzzing
Test cases and inputs are generated based on the response from the program
AFL is an example
Or Google ClusterFuzz
Concurrency Fuzzing
Systematically permutes thread scheduling to uncover data‑race, atomicity, and TOCTOU vulnerabilities that traditional coverage‑guided fuzzers miss
LLM‑Guided Fuzzing
ChatAFL – integrates an LLM to propose protocol‑aware mutations; boosts state coverage on network daemons by ~40 %.
SyzAgent / SyzLLM (2025‑02) – schedules kernel syz programs suggested by an LLM fine‑tuned on the Syzkaller corpus.
NumSeed – leverages natural‑language descriptions of inputs to seed generation for binary‑only targets.
Combined Method
The most effective approach often combines multiple techniques:
Reverse engineer first to identify interesting parts
Fuzz those parts to find crashes
Investigate crashes to find exploitable vulnerabilities
Grammar Inference: Automatically derive input structure from example files using transformer models
Practical Integration
# Example: Using local LLM for crash triage (OPSEC-safe)
from transformers import AutoTokenizer, AutoModelForCausalLM
def analyze_crash_local(crash_log, binary_info):
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3-8b")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3-8b")
prompt = f"""Analyze this crash and suggest root cause:
Binary: {binary_info}
Crash Log:
{crash_log}
Provide: 1) Root cause hypothesis 2) Exploitability assessment 3) Suggested exploit primitive"""
inputs = tokenizer(prompt, return_tensors="pt")
outputs = model.generate(**inputs, max_length=1000)
return tokenizer.decode(outputs[0])
Limitations and Considerations
False Positives: AI models can hallucinate vulnerabilities; manual verification essential
Training Data Bias: Models trained on public CVEs may miss novel vulnerability classes
OPSEC: Avoid sending proprietary code to cloud LLM APIs; use local models (Llama, Mistral)
Context Windows: Most models have 4K-32K token limits; chunk large binaries/logs appropriately
Quick Reference: Tool Selection Guide
By Target Type
Target
Primary Tools
Secondary Tools
Linux Kernel
Syzkaller, AFL++
KASAN, KCOV, ftrace
Windows Kernel
ICICLE, WinAFL
Verifier, KFUZZ
Browsers
LibFuzzer, Domato
ClusterFuzz, Dharma
Network Services
AFL++, Boofuzz
Peach, Sulley
Mobile Apps
QARK, Frida
MobSF, Objection
Web Apps
Burp Suite, FFUF
Nuclei, Semgrep
Firmware
Binwalk, EMBA
FACT, Firmwalker
Containers
Trivy, Falco
Grype, Syft
By Technique
Technique
Recommended Tools
Notes
Coverage Fuzzing
AFL++ 4.21+
Cross-platform, CMPLOG support
Snapshot Fuzzing
Nyx, QEMU+AFL++
Stateful target support
Concurrency Fuzzing
RFF, ThreadSanitizer
Race condition detection
Symbolic Execution
Angr, Triton
Path exploration
Taint Analysis
DynamoRIO, Triton
Data flow tracking
Binary Diffing
BinDiff 8, Ghidriff
Patch analysis
Static Analysis
CodeQL, Semgrep
Pattern matching
Dynamic Analysis
Frida, DynamoRIO
Runtime instrumentation
Tool Migration Path
Old Tool
New Alternative
Migration Notes
Intel Pin
DynamoRIO
Pin is sustain-only
WinAFL
AFL++ 4.x
Integrated Windows support
Radamsa
LibAFL mutators
Better coverage awareness
BinDiff 7
BinDiff 8/Ghidriff
Improved algorithms
IDA 7.x
IDA 8.x/Ghidra 11
Better decompilation
How do I install Claude-Red?
Download Skills/fuzzing/offensive-bug-identification/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does Claude-Red live?
The publisher keeps it at https://github.com/SnailSploit/Claude-Red.
Which agents can use Claude-Red?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.