Craft Custom Buffer Overflow Payload -- 2
Budget: $30 – $250 AUD
I need a small, purpose-built payload that I can inject into my own desktop application to probe for buffer-overflow weaknesses. Off-the-shelf fuzzers such as libFuzzer, AFL, or similar suites are off-limits for this exercise; the whole point is to rely on clean, hand-written C code and low-level debugging techniques.
You’ll be working on a recent Linux distro where I can give you SSH access to a hardened test VM. Expect to spend most of your time inside vim, gcc, and gdb (remote debugging with gdbserver is fine if you prefer). The program you’ll attack is closed-source to everyone except you and me, so everything must stay in userspace—no kernel tricks, no external libraries that do the heavy lifting.
What I’m after
• A minimal C source file (or small set of files) that reliably triggers an exploitable overwrite in the target binary.
• Inline comments explaining the exploit logic, offsets, and any gadget selection you employ.
• A concise walkthrough (text or markdown) that shows the gdb session you used to confirm control of EIP/RIP, including the exact commands and breakpoints.
Acceptance criteria
– Payload compiles with gcc -O0 -fno-stack-protector -z execstack and runs under ASLR-enabled Linux.
– Attaching gdb proves instruction-pointer control without crashing the OS or invoking undefined behaviour elsewhere.
– No external fuzzing frameworks; only standard POSIX headers and libc calls are allowed.
If you’re fluent in C, comfortable single-stepping in gdb, and love squeezing every byte out of a crafted input, let’s talk.
pls you have to teach me side by side, or if you have done it u have to show me as well how to do it and teach me.
You’ll be working on a recent Linux distro where I can give you SSH access to a hardened test VM. Expect to spend most of your time inside vim, gcc, and gdb (remote debugging with gdbserver is fine if you prefer). The program you’ll attack is closed-source to everyone except you and me, so everything must stay in userspace—no kernel tricks, no external libraries that do the heavy lifting.
What I’m after
• A minimal C source file (or small set of files) that reliably triggers an exploitable overwrite in the target binary.
• Inline comments explaining the exploit logic, offsets, and any gadget selection you employ.
• A concise walkthrough (text or markdown) that shows the gdb session you used to confirm control of EIP/RIP, including the exact commands and breakpoints.
Acceptance criteria
– Payload compiles with gcc -O0 -fno-stack-protector -z execstack and runs under ASLR-enabled Linux.
– Attaching gdb proves instruction-pointer control without crashing the OS or invoking undefined behaviour elsewhere.
– No external fuzzing frameworks; only standard POSIX headers and libc calls are allowed.
If you’re fluent in C, comfortable single-stepping in gdb, and love squeezing every byte out of a crafted input, let’s talk.
pls you have to teach me side by side, or if you have done it u have to show me as well how to do it and teach me.
Related categories:
C Programming
Linux
C# Programming
C++ Programming
Debugging
Penetration Testing
Vim
Reverse Engineering