I've seen a few memory forensics tutorials, which start by looking for injected code in the "victim's" process memory. They always seem to find the injected code in pages which have RWX access (i.e. PAGE_EXECUTE_READWRITE).
Does this assumption always hold? Does code injected (e.g. by malware) into the process memory of a "victim", always belong to a page with RWX access? Or can the page access be changed, by the code that is injected? If so, how can this change be done via winapi?
The assumption does not hold true, as it is possible to alter page protection flags after you've allocated memory.
The usual mechanism for code injection on Windows is as follows:
OpenProcess for the target process, to get a handle that has appropriate access privileges.VirtualAllocEx to allocate a buffer in the target process, with a set of memory page access flags.WriteProcessMemory to copy the memory to the target.CreateRemoteThread to execute within the process via a new thread.Now, there are two options here. The first is that you can specify PAGE_EXECUTE_READWRITE as a flag to VirtualAllocEx, so that you have the right to use WriteProcessMemory on that page, and also the right to execute that memory when you get to step 4. This is the "lazy" way that leads to having RWX buffers hanging around. The alternative way is to pass PAGE_READWRITE when allocating the block, then write the code, and call VirtualProtectEx to swap the flag over to PAGE_EXECUTE_READ before step 4. This gives you an RW buffer when copying data, then an RX buffer when executing.
Pseudocode:
rights = PROCESS_VM_OPERATION |
PROCESS_VM_READ | PROCESS_VM_WRITE |
PROCESS_QUERY_INFORMATION |
PROCESS_CREATE_THREAD;
handle = OpenProcess(rights, false, pid);
targetAddr = VirtualAllocEx(handle, NULL, 4096, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
buffer = "Hello, world!\0";
bytesWritten = 0;
WriteProcessMemory(handle, targetAddr, buffer, 14, &bytesWritten);
oldProtect = 0;
VirtualProtectEx(handle, targetAddr, 4096, PAGE_EXECUTE_READ, &oldProtect);
threadId = 0;
CreateRemoteThread(handle, NULL, 0, targetAddr, NULL, 0, &threadId);
The reason for targeting the RWX pages is that the injected code most often carries data in the same region as the code, and requires that the data are writable. Thus the W flag is needed. The X flag is required to support DEP, in case the process opted in, or if the system enforces it for everyone. The R flag is entirely optional when requesting the page. Windows will ensure that it is set anyway. It is of course possible for malware to allocate two regions, one [R]X and one [R]W, and write only to the writable section, but I don't recall ever seeing this technique being used. For one thing, it complicates the injected code.
Page access can be changed. See VirtualProtect, Memory Protection Constants and VirtualProtectEx documentation. Injected code should be executable and readable, but not necessarily writable.
