Vulnerability Research & Exploit Development

Translate permission into testable constraints

“Authorized to test” is incomplete. Capture legal owner, asset and version, environment, accounts, techniques, rate and concurrency limits, allowed data handling, availability constraints, excluded systems, third parties, notification route, evidence retention, disclosure expectations, and emergency stop. For software you own, document who may approve destructive tests and release decisions.

1. Write the target and prohibited-impact statement in plain language.
2. Map each planned technique to an authorization clause and safety control.
3. Create a deterministic reset and emergency stop procedure.
4. Run a harmless canary test to prove the environment and evidence pipeline.
5. Reconfirm scope whenever the target, version, hosting, account, or dependency changes.

Boundary: a public IP address, public repository, downloadable binary, or internet-facing website is not permission to test it. Public information may support passive research; active interaction still follows the owner’s policy and applicable law.

Use identifiers for interoperability, not as a replacement for analysis

CWE describes weakness classes; a CVE record identifies a specific publicly disclosed vulnerability; CPE can identify affected products; CVSS communicates severity characteristics; EPSS estimates the probability of observed exploitation activity over the next 30 days; CISA KEV records evidence-backed known exploitation. CAPEC describes attack patterns, and ATT&CK describes adversary behavior. They answer different questions.

1. Describe the violated security invariant before choosing an identifier.
2. Map root cause to the most specific allowed CWE and document alternatives rejected.
3. Separate affected product/version statements from environmental reachability.
4. Attach CVSS vector and evidence date; add EPSS/KEV only when a CVE exists.
5. Link downstream attack behavior only where the demonstrated primitive supports it.

Primary references: CWE · CVE Program structure · CVSS v4.0 specification · EPSS user guide · CISA KEV

1200km: CVSS v4.0 practical field guide · AdversaryGraph CVE/CVSS intelligence workflow

Make every result reconstructable

Build provenance is part of the finding. Preserve source commit or binary digest, dependency lockfile, compiler and flags, symbols, operating-system image, architecture, allocator, locale, feature flags, configuration, seed corpus, harness revision, environment variables, and mitigation state. A trigger that works only on an unidentified workstation is not ready for disclosure.

research/
  scope/          # authorization and safety plan
  target/         # immutable source or binary digest record
  build/          # scripts, toolchain, flags, symbols
  corpus/         # seeds; no secrets or customer data
  findings/       # one directory per candidate
  traces/         # sanitizer, debugger, packet, syscall logs
  regression/     # minimized inputs and negative tests
  disclosure/     # private timeline and vendor correspondence

1. Create the environment from code or a documented image and prove snapshot restoration.
2. Produce instrumented and production-like builds from the same revision.
3. Run known-good and intentionally invalid fixtures to validate observability.
4. Pin inputs and record digests before triage.
5. Reproduce from a clean snapshot and, where possible, on a second independent environment.

Acceptance: another authorized researcher can reconstruct the target, rerun the minimized input, obtain the same failure class, and distinguish the vulnerable build from the patched or negative-control build.

Trace attacker-controlled data to a security-sensitive operation

Begin with architecture: entry points, parsers, privilege boundaries, serialization, authentication, authorization, update mechanisms, cryptographic trust, native interfaces, plug-ins, file operations, IPC, and external services. Build a data-flow hypothesis, then use manual review, compiler diagnostics, semantic queries, SAST, dependency analysis, binary metadata, strings, disassembly, and decompilation to test it.

1. Draw the trust-boundary and data-flow map.
2. Form a concrete invariant and candidate path.
3. Use multiple static methods to locate supporting and contradictory evidence.
4. Write a tiny fixture or unit test that exercises the path.
5. Move to dynamic confirmation; keep unexecuted findings labeled as hypotheses.

Tool boundary: SAST severity, dependency alerts, decompiler output, AI explanations, and suspicious strings are triage signals. Confirm reachability, configuration, version, attacker influence, violated invariant, and security consequence.

1200km: PE Import Analyzer · String Analyzer · String Analyzer source

Turn a static hypothesis into runtime evidence

Use debuggers, sanitizers, syscall/API tracing, application logs, coverage, packet capture, record/replay, and controlled fault injection to observe the exact path. Start with a known-good input, establish baseline state, introduce one controlled difference, and record where behavior diverges. Prefer breakpoints on the invariant boundary over random stepping.

1. Capture baseline trace and expected state.
2. Set breakpoints or probes around validation, allocation, authorization, parsing, and sensitive sink.
3. Reproduce while recording the first divergence and causal chain.
4. Minimize the input without changing the failure class.
5. Re-run on a clean image, then on the candidate patch.

Primary references: GDB manual · AddressSanitizer · UndefinedBehaviorSanitizer

Describe the primitive precisely

Memory corruption is not one vulnerability class. Distinguish out-of-bounds read and write, heap/stack/global location, use-after-free, double free, uninitialized read, null dereference, type confusion, integer overflow/truncation/sign conversion, format string, race-induced lifetime error, and resource exhaustion. Record offset, size, direction, attacker influence, object state, repeatability, and whether the access crosses a meaningful security boundary.

1. Reproduce under the relevant sanitizer or debugger.
2. Find the first invalid state and write the violated invariant.
3. Minimize input and environmental preconditions.
4. Classify the resulting primitive without overstating control.
5. Evaluate mitigations and reachable impact in a lab.
6. Propose a root-cause fix plus regression test, not only a crash guard.

Safe impact validation: use controlled marker values, synthetic objects, local process state, and non-destructive assertions. Do not develop persistence, stealth, credential theft, or deployment-ready payloads merely to “prove” a memory bug.

Understand the execution contract

For PE, ELF, Mach-O, APK/native libraries, or firmware images, identify architecture, endianness, calling convention, relocation model, dynamic dependencies, symbol state, signing, exception metadata, and loader behavior. Record which defenses are compiled, linked, and enforced at runtime. A mitigation’s presence changes the exploitability analysis; its absence does not prove exploitability.

Primary references: Linux kernel self-protection · Microsoft exploit protection reference

Report both layers: “root cause: unchecked length creates heap out-of-bounds write” and “observed exploitability: deterministic process crash under build X with mitigations Y; controlled code execution not established.” This is more useful than either “critical RCE” or “just a crash.”

Build a fast, deterministic, state-correct experiment

Coverage-guided fuzzing mutates a corpus and uses instrumentation feedback to explore code. The engine is only one component. The researcher must choose a meaningful target, initialize it correctly, reset state, supply a representative corpus and dictionary, enable suitable bug oracles, constrain resources, measure coverage, deduplicate failures, minimize triggers, and convert confirmed bugs into regression tests.

// Authorized lab target; no network or persistent side effects.
extern "C" int LLVMFuzzerTestOneInput(
    const uint8_t *data, size_t size) {
  if (size > kMaxInput) return 0;
  ParserContext ctx = MakeFreshContext();
  ParseResult result = ParseBuffer(ctx, data, size);
  CheckPostconditions(ctx, result);
  return 0;
}

1. Select one narrow API or parser and define security-relevant postconditions.
2. Build with compatible compiler instrumentation and sanitizers.
3. Seed valid, boundary, empty, truncated, and structurally distinct inputs.
4. Run smoke tests; inspect coverage and reject a harness trapped in validation glue.
5. Execute under quotas; collect artifacts atomically.
6. Deduplicate by root cause, not only stack hash; minimize while preserving class.
7. Reproduce outside the fuzzer and on a clean build.
8. Fix, add the minimized input as regression data, and rerun the corpus.

Coverage boundary: higher coverage is useful, but no percentage proves absence of vulnerabilities. Compare coverage at the relevant function/branch level and investigate code that remains unreachable from the harness.

Primary references: LLVM libFuzzer · OSS-Fuzz · OSS-Fuzz getting started

Test authorization and invariants, not only payload strings

Map roles, tenants, resources, sessions, workflows, APIs, asynchronous jobs, file processing, webhooks, integrations, caches, and administrative transitions. Build a subject–action–object matrix and state diagram. Many severe findings are ordinary-looking requests performed by the wrong principal, in the wrong order, or against an object whose ownership was never revalidated.

1. Enumerate states and principals using owned test accounts.
2. Write security invariants and expected denials.
3. Exercise one variable at a time with an intercepting proxy or test client.
4. Confirm server-side state, not only the UI or HTTP status.
5. Demonstrate impact with synthetic records and minimum privilege.
6. Verify centralized enforcement and regression tests after remediation.

Do not collect real data: prove unauthorized access with synthetic cross-tenant objects or owner-supplied canaries. Stop before enumerating other users or retrieving unrelated content.

Controlled practice: 1200km DVWA lab with Ansible · 1200km lab catalogue

Analyze the complete application boundary

For Android, preserve the APK/AAB digest, package, version code/name, signing certificate, minimum/target SDK, ABI, build flavor, and device image. Review manifest components and permissions, deep links/app links, network security configuration, WebViews, local storage, backups, cryptography, IPC/Binder, intents, content providers, services, receivers, exported activities, update/signing trust, and bundled native libraries.

1. Build a component and data-flow map.
2. Prioritize externally reachable and privilege-bearing components.
3. Validate with a controlled intent, URI, test account, or fixture.
4. Confirm both device-side and service-side state.
5. Classify the platform/API-version preconditions and affected releases.
6. Verify the fixed build across install, upgrade, and supported OS versions.

1200km: Android APK Vulnerability Research Complete Guide · Deliberately Vulnerable Android App · Vulnerable APK source · Android analysis lab

Model the product, not just the firmware filesystem

Record manufacturer, model, hardware revision, region, bootloader, firmware version, update channel, components, licenses, interfaces, and acquisition provenance. The security boundary spans boot ROM, secure boot, storage, debug ports, bootloader, kernel, services, web/API, mobile/cloud companion, radio/peripheral buses, update signing, rollback prevention, supply chain, and recovery behavior.

1. Create a device trust-boundary and lifecycle map.
2. Verify firmware identity and update authenticity path.
3. Inventory attack surfaces statically and confirm reachable services dynamically.
4. Test one invariant using non-destructive input and a recoverable device state.
5. Classify physical, local-network, adjacent, or remote preconditions.
6. Verify remediation, update delivery, rollback resistance, and recovery behavior.

1200km research: Embedded Systems, Hardware, Firmware—source-verified research on edge appliances, BMCs, UEFI, routers, OT/IoT, silicon, and hardware trust boundaries.

Move from failure to supported security consequence

Exploitability is a structured argument: attacker can reach the vulnerable path; attacker-controlled state creates a specific primitive; the primitive survives environmental constraints and mitigations; and a defined security property can be violated. Reliability, privileges, interaction, network position, configuration, and availability effects belong in the analysis.

1. State the claimed attacker, preconditions, and impact before extending the trigger.
2. Demonstrate the smallest primitive using controlled markers.
3. Measure relevant mitigations and environmental constraints.
4. Use a laboratory-only assertion or benign effect to validate impact.
5. Record non-working variants and alternative explanations.
6. Share only the level of detail needed for maintainers to reproduce and fix.

Exploit-development boundary: this guide does not require a deployable exploit, stealth, persistence, evasion, destructive effects, credential theft, or real-data access. A reliable local laboratory demonstration with synthetic data is normally sufficient for engineering and disclosure.

Defensive connection: map the validated path to ATT&CK T1190, T1203, or another technique only when the demonstrated behavior supports the relationship; then design telemetry and a safe regression simulation.

Use AI to organize and test hypotheses—not to manufacture certainty

Models can summarize code, propose attack surfaces, translate decompiler output, draft harnesses, cluster crashes, compare patches, generate test cases, map CWE candidates, structure reports, and retrieve relevant advisories. Every result remains untrusted until tied to exact source, binary, runtime, and primary documentation. Generated code must pass the same review, build, sandbox, and test gates as human-written code.

1. Give the assistant a bounded question, exact artifact identity, and handling policy.
2. Require structured hypotheses with cited evidence, assumptions, and disconfirming tests.
3. Review every proposed command and generated harness before isolated execution.
4. Compare output against runtime evidence and authoritative source documentation.
5. Record model/provider, prompt template, retrieval snapshot, tools, approvals, and resulting artifacts.
6. Reject unsupported severity, exploitability, attribution, or affected-version claims.

Prompt-injection boundary: source files, READMEs, tickets, firmware strings, webpages, and tool output are untrusted data. They cannot grant authority, change scope, request secrets, or approve tool calls.

1200km: HexStrike AI field guides · AI-driven PT with Cursor and MCP · Attacks against LLM agents · Vulnerable AI Lab

Deliver a maintainable security result

Find the vendor’s security contact or vulnerability disclosure policy. Send a concise private report containing affected product and versions, researcher contact, discovery date, authorization context, weakness and root cause, prerequisites, reproducible steps, minimized artifacts, observed impact, severity rationale, suggested remediation direction, evidence handling, and proposed coordination. Do not promise a CVE, bounty, severity, or deadline you do not control.

1. Peer-review the report for technical claims, secrets, personal data, and weaponization risk.
2. Submit through the authorized channel and confirm receipt without flooding contacts.
3. Agree on secure artifact exchange, status cadence, and disclosure timeline.
4. Support reproduction with exact versions and bounded evidence.
5. Verify candidate fixes independently and communicate limitations.
6. Coordinate CVE/advisory content and publication timing.
7. Publish safe details, detection/mitigation guidance, credits, and fixed versions.
8. Add the regression fixture to the appropriate private or public suite.

Primary references: NIST SP 800-216 vulnerability disclosure guidelines · CVE Program and CNAs · CVSS v4.0 user guide

Close only when: affected and fixed versions are clear; the patch prevents the root cause under regression; advisory language matches observed evidence; public artifacts respect the coordination agreement; and downstream owners have actionable upgrade or mitigation guidance.