Usually when you need to use a heap spray, you're SOL when it comes to DEP. The reason for this has to do with why you used the heap spray in the first place. In the case of a vtable overwrite you need a chain of pointers to get the job done. A neat way to deal with this is to find an address (like
0x0c0c0c0c) that has a few special properties. It's the same char over and over, it is executable as a NOP generally, and with a spray you can fill memory up to and including that address. If you can't execute on the heap however due to hardware DEP, the fact that it's a NOP doesn't really help you, does it?
Normal vtable Overwrite Crashmov edx, [eax] <- Crash occurs heremov ecx, eaxcall dword ptr [edx+4]In the above example, we control EAX. This means that in order to getexecution, we need EAX to be a pointer, that points to another pointer(to be placed in EDX) which in turn points to code we wish to execute. None of these pointers can be volatile for this to work. In this case wecan use a heap spray of 0x0c0c0c0c to satisfy our requirements. If aheapspray is not possible, we will need to find a real pointer chain. Inorder to find such pointers you can make use of the byakugan functionality!jutsu searchvtptr.!jutsu searchvtptr 4 call [eax+4]
If, however, the vtable control isn't control of the pointer to the table, but of the table itself (as may be the case in say, a use after free vuln where you have strong heap control and grooming ability) then you only need to find a ptr->ptr and the heap spray isn't needed as a nop sled. You'd only use the heap spray to ensure that despite movement of data, you still hit executable code. The sled will contain a list of return addresses only now. This will require the pointer you choose be a multiple of 4, so that the return addresses are aligned properly. 0x0c0c0c0c is still a good bet for this, but we simply wont fill the heap spray with 0c, we'll instead use a pointer that we'll find in just a moment.
Full vtable Pointer Control Crashmov edx, [eax] mov ecx, eaxcall dword ptr [edx+4] <- Crash occurs hereIn this example, we have control over the actual function pointers, ratherthan the pointer to the table of function pointers. We no longer need aptr -> ptr -> ptr, we only need a pointer to a pointer to executablecode that doesn't move. In this case we can use a heap spray of libraryaddresses and eschew execution on the protected heap.
So, assuming we have control of data on the heap that a register points to, and also perfect control of EIP, we can use a technique which "flips" the heap to the stack to get execution on DEP systems. What we'd do is find an instruction in memory that wont move around which will move that register into ESP, then return. On non-ASLR systems such as XP, this is a simple matter. By placing this address in EIP, we will effectively make the heap (which we fully control in this case) become the stack. With stack control, we can return to already mapped library code which also will not move, allowing us to make arbitrary system calls, with arbitrary arguments.
Flipping the Heap to the Stackmov esp, eaxIf EAX points to a structure on the heap which you control, then the abovecode will make that controlled memory become the effective contents ofthe stack. From here you will be able to begin a chained ret2lib stylepayload with arbitrary arguments. You can easily find non-moving returnaddresses like this code with byakugan's searchOpcode functionality.!jutsu searchOpcode mov esp, eax
From here, you can go the hard route, mapping pages, re-protecting them, copying your shellcode to them, then returning back to that newly mapped space which is of course mapped executable. The alternative is to just jump to the turn DEP off function (NtSetInformationProcess), and return to your new stack. (See Uninformed v2 article 4: "bypassing windows hardware-enforced dep" for details: http://www.uninformed.org/?v=2&a=4&t=txt
If a vendor tells you that DEP will protect you from a vulnerability, do not assume that your hardware will protect you. Perform other mitigations as well.