CODEWITHSUNDEEP
assemblywinapi64-bitshellcodevirtualalloc
ab ab
ab ab

Reputation: 11

VirtualAllocEx Returns Memory Marked as MEM_FREE/PAGE_NO_ACCESS

I am writing x64 assembly code to invoke VirtualAllocEx win32 API (as part of process injection lab, so I am injecting into explorer.exe) and seeing unusual (to me) behavior.

The documentation states that the return code is 0 if the function fails, or otherwise gives the base address of the requested allocation. I am getting a positive non-zero return code everytime, and the windbg !gle extension says that the API call is successful. However, the !vprot extension says that the page is marked MEM_FREE/PAGE_NO_ACCESS, which I am fairly certain is not what I requested. Additionally, if I try to use VirtualProtectEx to try and alter the memory, the function fails and !gle says essentially that access to that memory is denied.

Argument values are as follows: RCX: hProcess -- handle to process returned from OpenProcessAPI. Seems to be valid and with PROCESS_ALL_ACCESS permission RDX: lpAddress -- null, I am letting API choose R8: dwSize -- I am using 0x1000. My VM is running pretty low on space but if this were an issue, allocation would fail completely, yes? R9: flAllocationType -- 0x3000 MEM_COMMIT | MEM_RESERVE [rsp+20]: flProtect: -- 0x40 PAGE_EXECUTE_READWRITE (x64 is fairly new to me but I think this is where the 0x40 should go. I tried spraying it in every DWORD from RSP+0 to RSSP+40 and got no better results.

My actual code for this call (directly after valid OpenProcess call) is:

    mov rcx, rax ; handle first arg from RAX returned from OpenProcess into RCX
    xor rdx, rdx ; null second arg, API chooses addr
    mov r8, 01000h ; size, 0x1000 bytes
    mov r9, 03000h ; mem commit/reserve
    mov rax, [r15+90h] ; retrieving saved function pointer for VirtualAllocEx, this is valid
    mov dword ptr [rsp+20h], 040h ; access PAGE_EXECUTE_READWRITE
    call rax ; alloc addr in rax after
    mov r13, rax ; stash allocation

Can anyone help me understand why this is occurring?

I repeatedly reviewed the argument placement under debugger (especially of the flProtect DWORD that goes on the stack, checked the validity of the handle and the process ID used to create it. This is a very early step so there isn't much else to try I don't think.

Upvotes: 1

Views: 80

Answers (0)

Related Questions