SSL | Register | Login Thursday, April 27, 2017
 
 Search
 DEPTest 1.02  
 
DepTest can serve as a second opinion on the state of Windows® data execution prevention (DEP) feature to see if the intrusion prevention feature is really enabled and protecting all running processes and services, if you have a look at threads like this one for example. Installing Microsoft's EMET may also be very helpful to investigate the system's configuration. You can find more information about why we recommend to enable AlwaysOn and how DepTest works internally in this thread on wilder security.

The tool was developed around 2002, around the same time as Sys-Manage BufferShield, to demonstrate that Microsoft's software based data execution prevention explicitly protected from one specific exploit that occurred one time only and was based on overwriting the pointer to the SEH Exception Handler. So giving this software based feature a similar name as the hardware NX protection was confusing the customers globally and stimulated a false sense of security. It also showed, that Comodo Memory Guard (shortly afterwards discontinued) was not effective at stopping buffer overflows, because it used a user-mode based approach (hooking up Windows APIs) instead of a lower level kernel-based approach through a driver. Initially they claimed on their forums, that our test is only executing a NOP, until we used some real shell code creating a file, bypassing the Windows API and using the call gate mechanism to directly invoke the kernels NtCreateFile API (There is many other ways of not using the Windows API and bypassing such a protection in shell code). [We still like Comodo's certificates!]

We don't support and develop BufferShield for any newer Windows versions than Windows XP and Server 2003 any more, because these operating systems ship with NX and ASLR protection right out of the box. You just have to take care of enabling them properly. The same applies to modern CPUs, which all have hardware based NX (or XD in case of AMD), so there is no more need to port it to newer operating systems that would not run efficiently on such old CPUs anyways.

If your computer should fail, please run the following command to enable NX (Intel) or XD (AMD) using the following command line in an administrative command prompt on Windows Vista and newer operating systems and repeat the test after rebooting:
bcdedit /set nx AlwaysOn


This will enable buffer overflow protection for all applications and services running and not just only the operating system. It also prevents smart shell code from using a so-called return-to-libc method to disable NX/XD in case ASLR fails or is broken. If you should encounter compatibility problems with certain 3rd party applications, please try to update them or contact the manufacturer / vendor. After more than 15 years, they should know that it is not a good practice to execute code from memory pages that have not been flagged for code execution.

You can get back to the default setting by running the following command in an administrative command prompt:
bcdedit /set nx OptIn

   
Download version 1.02
Download version 1.02
Please feel free to use our DEPTest tool to verify your computer’s current security settings regarding the mentioned pitfalls with MS software & hardware based NX protection.

Just click on the disc icon to download the file.

Please double click on the file DEPTest.Exe and start the test to see if your NX protection is working. In case your system is configured securely and data execution prevention (DEP) covers all executables, you should see a green checkmark for each test performed.

Note: Any Windows error message shown telling you that overflow.exe has stopped working is by design and indicates that DEP has detected and stopped code execution in a data area.
  
Copyright © Sys-Manage, 1998-2017. All Rights Reserved.

Privacy Statement
Terms Of Use