Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/Miosa-osa/OSAnpx agentmods add skills/miosa-osa/osa/offensive-fuzzingWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/miosa-osa/osa/offensive-fuzzing)<a href="https://agentmods.dev/skills/miosa-osa/osa/offensive-fuzzing"><img src="https://agentmods.dev/badge/skills/miosa-osa/osa/offensive-fuzzing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/miosa-osa/osa/offensive-fuzzing"><img src="https://agentmods.dev/badge/skills/miosa-osa/osa/offensive-fuzzing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00091 | $0.03850 |
| Opus 5.5 | $0.00036 | $0.01540 |
| Sonnet 5.5 | $0.00018 | $0.00770 |
| Haiku 4.5 | $0.00009 | $0.00385 |
Grade A, and why
offensive-fuzzing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
94% identical to offensive-fuzzing — 40 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 379 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Offensive Fuzzing
Fuzzer Types
| Type | Coverage | Speed | Tools |
|---|---|---|---|
| BlackBox | Poor | Fast | Peach, Boofuzz |
| GreyBox | Good | Fast | AFL++, Honggfuzz, libFuzzer, WinAFL |
| Snapshot | Good | Fastest | Nyx, wtf, Snapchange |
| WhiteBox | Best | Slow | KLEE, QSYM, SymSan |
| Ensemble | Best | Fast | AFL++ + Honggfuzz + libFuzzer |
GreyBox sub-variants: Directed (AFLGo, UAFuzz), Grammar (AFLSmart, Tlspuffin), Concolic (QSYM, Driller), Kernel (syzkaller, kAFL, wtf).
Core Workflow
Research target → Choose analyses → Build harness → Seed corpus → Instrument → Fuzz → Triage crashes → Report
1. Research Target
- Map all input surfaces (files, network, IPC, syscalls, IOCTL)
- Identify high-value areas: previously patched code, complex parsers, newly added code, input ingestion points
- For kernel modules: look beyond
copy_from_user— DMA-BUF ops, page fault handlers, VM operation structs, allocation callbacks
2. Instrument and Build
# AFL++ (preferred for GreyBox)
CC=afl-clang-fast CXX=afl-clang-fast++ cmake -DCMAKE_BUILD_TYPE=Release .. && make -j
# libFuzzer + ASan/UBSan (C/C++)
cmake -DCMAKE_CXX_FLAGS="-fsanitize=fuzzer,address,undefined -O1 -g" ..
# CmpLog build for hard compares
AFL_LLVM_CMPLOG=1 CC=afl-clang-fast CXX=afl-clang-fast++ make clean all
Windows (MSVC): Project Properties → C/C++ → Address Sanitizer: Yes (/fsanitize=address)
3. Write Harness
libFuzzer (C++):
#include <cstdint>
#include <cstddef>
extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
parse_or_process(data, size);
return 0;
}
Honggfuzz HF_ITER (persistent mode — preferred for large targets):
#include "honggfuzz.h"
int main(int argc, char** argv) {
initialize_target(); // runs once
for (;;) {
size_t len; uint8_t *buf;
HF_ITER(&buf, &len);
FILE* s = fmemopen(buf, len, "r");
target_function(s);
fclose(s);
reset_target_state();
}
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 379 lines · 91 tokens per session scan A 7b38f3022cc7
offensive-fuzzing is a skill published in the GitHub repository Miosa-osa/OSA (78 stars, last pushed 11d ago), licensed Apache-2.0. It adds 91 tokens to every session and 3,850 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 94% identical to offensive-fuzzing, differing in 40 lines, and is treated as a copy.
Other skills, from other repositories
benchmark
Benchmark a local LLM model with MetriLLM. Measures performance (tok/s, TTFT, memory) and quality (reasoning, math, coding, instruction following, structured output, multilingual). Use when the user wants to test, compare, or evaluate a local model.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
skill-authoring
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Applies TDD methodology to skill documentation.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
golang-testing
Go testing best practices including table-driven tests, test helpers, benchmarking, race detection, coverage analysis, and integration testing patterns. Use when writing or improving Go tests.