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?
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.
Normal vtable Overwrite Crash
mov edx, [eax] <- Crash occurs here
mov ecx, eax
call dword ptr [edx+4]
In the above example, we control EAX. This means that in order to get
execution, 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 we
can use a heap spray of 0x0c0c0c0c to satisfy our requirements. If a
heapspray is not possible, we will need to find a real pointer chain. In
order to find such pointers you can make use of the byakugan functionality
!jutsu searchvtptr 4 call [eax+4]
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.
Full vtable Pointer Control Crash
mov edx, [eax]
mov ecx, eax
call dword ptr [edx+4] <- Crash occurs here
In this example, we have control over the actual function pointers, rather
than the pointer to the table of function pointers. We no longer need a
ptr -> ptr -> ptr, we only need a pointer to a pointer to executable
code that doesn't move. In this case we can use a heap spray of library
addresses and eschew execution on the protected heap.
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
Flipping the Heap to the Stack
mov esp, eax
If EAX points to a structure on the heap which you control, then the above
code will make that controlled memory become the effective contents of
the stack. From here you will be able to begin a chained ret2lib style
payload with arbitrary arguments. You can easily find non-moving return
addresses like this code with byakugan's searchOpcode functionality.
!jutsu searchOpcode mov esp, eax
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.