We can take a dive back into our Windows 7 test machine from the previous chapter to see what happens when we crank up DEP. If you just got here from the previous chapter, then you saw how we gained control over the Windows 7 machine with a heap spraying attack. Let's repeat the attack, down to the last detail, but this time we've enabled DEP for all running programs and services.

Once your Kali attacker is up and hosting the exploiter web page, find your advanced system settings on the Windows 7 test machine and select Performance Options followed by the Data Execution Prevention tab. You'll see that the default only enables DEP for essential programs and services.

This means the core Windows system and its parts. Though we all associate Internet Explorer with the Windows operating system, IE isn't essential to Windows' functioning; therefore, IE was not protected by DEP when we pulled off our heap spraying attack. So, select Turn on DEP for all programs and services except those I select: and reboot the box:

Windows boots up and everything feels the same, so fire up Internet Explorer. Once IE is up and running, open up the command-line, use tasklist to identify the PID for IE, and then attach WinDbg to it. Head over to your lottery exploiter page lying in wait on our Kali box. The page (along with the sprayer() function) will load fine; remember, the sprayer is merely allocating memory and putting NOPs and shellcode there. Now click the CLICK TO CLAIM button and watch WinDbg:

Well well well, what have we here? Take a look at the registers dump, and EIP in particular. It's pointing at 0x11ecffff, which is the middle of a NOP sled and exactly where we want to send the flow of execution. This worked in the last chapter. However, 0x11ecffff is not explicitly marked as executable. It's important to understand that 0x11ecffff wasn't marked as executable when our attack worked in the last chapter, either. The difference is that DEP has stepped in, and we see this as an access violation in WinDbg.