Remember where we stuff our shellcode? Into the stack or the heap, which is memory set aside for a thread of execution. When a function is running, space is allocated for variables and other data needed to get the work done; in other words, these are areas that are not intended to contain executable code. Picking some spot in memory to store a number, but then later being told, hey, remember that spot in memory? Let's execute whatever's sitting there, should be suspicious. But don't forget that processors are incredible, lightning-fast, and dumb. They will do what they're told. This simple design of executing whatever is sitting at the location pointed to by the instruction pointer is what the shellcoding hacker exploits.

Enter DEP. The basic premise is to monitor whether the location that the instruction pointer is referencing is explicitly marked as executable. If it isn't, an access violation occurs. Windows has two types of DEP: software-enforced and hardware-enforced. Software-enforced DEP operates at the higher levels of the OS and, hence, it is available to any machine that can run Windows and can protect against attempts to ride on exception handling mechanisms. Hardware-enforced DEP uses the processor's Execute Disable (XD) bit to mark memory locations as non-executable:

How does this affect us as wily hackers? The whole trick is allocating memory for our code, which the program is treating like an ordinary variable. Meanwhile, we're hoping the processor will take our word for it that the flow of execution is intended to jump to the instruction pointer address.