Debugging buffer overflow exploits

Off-topic Exploits
, , , ,
3

@TazWake said:

For some exploits this doesn’t matter. Sometimes the exploit isn’t written for a specific OS, just that is the OS it is tested on.

Any guidance on knowing when it should matter? I would think it would for buffer overflows because of the storage size of various types in memory.

I am currently trying to generate an windows/x64/messagebox python payload using msfvenom.

Any reason you went with this? I dont think I’ve ever knowingly used this payload in MSFVenom.

Yes, I am not familiar with msfvenom, metsploit, or buffer overflows. This seemed like an obvious payload with few moving parts to see if I was hitting the buffer overflow.

So if it is the box I am thinking of, I used windows/shell_reverse_tcpwhich worked well (but it also depends on which exploit).

I think you are thinking of the box I am working through. In fact, I think you have replied to me on the official forum thread, haha!

If netcat isn’t catching, then you can always try meterpreter.

Is it pretty safe to make the assumption that I can use netcat unless the payload calls out meterpreter, vnc, etc?

I might be getting confused but I am fairly sure windows/x64/shell/reverse_tcp is a staged payload. This means it expects the listener to be able to send more malicious content, which obviously netcat cant do. For more on this, have a look at https://www.offensive-security.com/metasploit-unleashed/payloads/

I did some more investigation, and you’re correct. windows/x64/shell/reverse_tcp is in fact a stager. I was looking for windows/x64/shell_reverse_tcp originally, saw the stager, and thought it was the 64-bit version of windows/shell_reverse_tcp.