Question

I allocated some space, wrote some asm and tried to start a thread at that point.
But I keep getting an access violation. Its suppose to push four 0s and call the messageboxa function. But right at the area address it gets a access violation.
How can I get it to run like normal code?

void test2()
{
    byte* area;
    HANDLE process;

    area = new byte[1024];

    for(int i = 0; i < 1024; i++)
        area[i] = 0;

    memmove((char*)area, "\x6a\x00\x6a\x00\x6a\x00\x6a\x00\xE8", 9);

    *(DWORD*)&area[9] = ((DWORD)GetProcAddress(GetModuleHandle("User32.dll"), "MessageBoxA") - (DWORD)&area[9] - 4);

    memmove((char*)&area[13], "\x33\xc0\xc3", 3);

    VirtualProtect(area, 17, PAGE_EXECUTE_READWRITE, 0);

    CreateThread(0, 0, (LPTHREAD_START_ROUTINE)area, 0, 0, 0);
}

here’s a screen shot of the disassembly
http://screensnapr.com/v/P33NsH.png

Answer 1

The VirtualProtect() call doesn’t do anything in this case: it just fails since it expects the 4th parameter to be a valid pointer to a memory area which receives the previous access protection flags (so you can restore it later). So, the CPU refuses to execute this page and you get the GPF at the very first instruction.

You also need to use PAGE_EXECUTE_READ for the flag, otherwise the first heap operation (even read access to any other variable in the heap, which happens to touch the same page) will generate GPF. Alternatively, use VirtualAlloc(), instead of allocating on the heap.

Note, I didn’t check the rest of the code, so there might be some other issues with it. Also note that this is not the way to write assembly, unless you’re writing an exploit (messing with VirtualProtect() is a sure sign of that). Here’s to hoping that I’m wrong in my assumption about the exploit.