The idea behind DEP is that you are making regions of memory non-executable, such that shellcode in this area cannot be executed. DEP alone is really easy to bypass, you can just ret-to-lib, and call any function you would like, `system()` is a favorite. However, under Windows, [ASLR][1] enabled libraries will have a randomized memory space, so the attacker won't know the memory address of the `system()` function, and there for cannot call it. The idea behind ASLR is that **It doesn't matter if you can control the EIP if you don't know where to jump to.** Being able to read the location of a region of randomized memory undermines the protection of ASLR, because now you have a reliable jump location. This can be accomplished though a wide verity of methods. Using a buffer overflow to simply overwrite the null terminator and **read** past the end of an array has been used in pwn2own against IE. But really the most common technique is using a [Dangling Pointer][2] which can be used to read/write or even execute a valid memory location despite ASLR. Even with ASLR, not every memory location is randomized. In fact the executable binary has a predictable layout, so you can use the executable against its self in a [ROP Chain][3]. However sometimes its difficult to find useful ROP gadgets, especially if the target binary is very small. If you are unable to build a useful ROP Chain, then a memory disclosure vulnerability, such as a dangling pointer, is a great method of attack. Its important to note that ASLR only randomizes the location of the page (the first few bytes of the memory address), if you can populate a region within this page with your shellcode then it maybe possible to accurately execute your shellcode by using the leaked memory address as a base and then hopefully your shellcode is at some offset of this random location. [1]: http://en.wikipedia.org/wiki/Address_space_layout_randomization [2]: http://en.wikipedia.org/wiki/Dangling_pointer [3]: http://en.wikipedia.org/wiki/Return-oriented_programming