How do I make an exception for Cscript.exe in Windows Server 2008 R2?

Very interesting question. I've seen some DEP faults from cscript.exe before. It's annoying.

VBScript predates DEP in Windows, and as such it was not originally developed with DEP in mind. Furthermore when you start interacting with old, third-party COM and OLE interfaces in your scripts, they can cause NX faults and cscript.exe takes the blame for it. The latter is usually the case.

However, something really bothers me about using the old version. I feel like I could be introducing a security risk or a version issue.

It's a little funny to me that you would say that, because disabling DEP for a program like cscript.exe is going to be way more of a security risk than using the 2003 version.

You can't disable DEP for 64bit processes, period.

For the purposes of application compatibility when DEP is set to the OptOut policy level, it is possible to selectively disable DEP for individual 32-bit applications. However, DEP is always enabled for 64-bit applications.

http://technet.microsoft.com/en-us/library/cc738483(v=WS.10).aspx

So that leaves you with the 32bit, "SysWOW64" version of cscript.exe... however, modern executables can and usually are flagged with a "you can't turn DEP off on me," flag. Much like in the same way that an executable can be flagged as being large address space aware, etc.

Technically, it's the /NXCOMPAT flag that the executable was compiled with. It's a linker switch. The old 2003 version of the executable was not compiled with that switch, and that is why you are able to put it in the DEP exemptions list but not the 2008 version.

But wait there's more! If you still want to use the 2008 version of SysWoW64\cscript.exe, all you need to do is copy the executable, then run:

editbin /NXCOMPAT:NO C:\cscript.exe

Now you can add it to the DEP exemptions list. Editbin.exe comes with Visual Studio, the Windows SDK, etc.

Have fun injecting code on stack or heap memory and branching the instruction pointer to execute it!