Discussion in 'other anti-malware software' started by DR_LaRRY_PEpPeR, May 22, 2013.
IIRC there are at least 8 known public methods for bypassing Windows software DEP.
I guess you mean hardware DEP, right? Because software DEP does absolutely nothing but protecting from the SEH overwrite exploit. They should never have called it software DEP in the first place.
Yes you are right, there is many possibilities (without proper ASLR) to bypass DEP, for example using a memcpy to copy the payload to some memory that is flagged for execution or simply calling VirtualProtect to allow code execution for some memory and so on and so on. Even without a reboot.
Talking about ASLR might derail the thread a bit.... (at least on Windows7 it seems to be 8-bit only)
Yes sorry, hardware DEP as software DEP is just some type of DEP protection wannabe. That's what I get for rushing to answer while I'm running off
To come back to the topic a little bit....I just discovered/remembered that overflow.exe has one additional parameters.
If you specify one of the parameters I explained before, it will create a really simple shellcode consisting of 0x90 (NOP) and 0xc3 (RET) just to see if an exception is thrown.
If you specify any second parameter (whatever you like) it will use a different shellcode that will use int2e to call a system function (CreateFile) in this case to create an empty file c:\dep.txt. The DepTest.Exe will delete c:\dep.txt and validate if it exists after running overflow.exe.
We had added this test to show that some 3rd party protection software claiming to prevent buffer overflows from user land by hooking all the interesting entry points (for example comodo's memory guard if i remember the name correctly) is not really preventing anything if the shellcode uses int2e to call into system functions. They claimed that our test was only running a NOP and it would not be possible to execute anything. However, I think they don't offer it anymore.
And regarding the static stack addresses that caused the overflow.exe ASLR test to fail I did some more research today here: https://www.wilderssecurity.com/showthread.php?p=2300460#post2300460
I just noticed something strange with the DLL.
I have this app installed (Zapper 1.7.1 Build 236), it is old, build with Pascal:
I don't know what compiler it was made with.
However, this app does not run in AlwaysOn.
After installing the DLL and enabling it, putting the PC in OptOut Mode and passing the DepTestExe, Zapper.Exe was running all of a sudden, but without adding it to the exception list.
I have the source code for Zapper but don't know how to build it, maybe I will find some time to debug what is causing the problem with AlwaysOn and then we can draw some conclusions from that.
That is strange, isn't it?
Just made another test and all this happens without the DLL installed too.
In AlwaysOn Zapper.Exe does not start, in OptOut it does start, even though it was not added to the list.
So it seems that this is not related to the PermanentDEP.Dll. I will try to find out more about the strange behaviour of OptOut and Zapper.Exe later....no time
andreas, that's expected behavior! The Windows loader notices the characteristics of certain executables (typically packed ones) and implicitly disables DEP for them, without you needing to do so explicitly. I briefly mentioned that on my page (with link to info), but it could easily be missed...
But that special "auto opt-out" doesn't happen with AlwaysOn DEP.
In either case of opting-out (implicit/explicit), the Permanent DEP DLL doesn't do anything, since DEP is off when checked of course.
Normal/expected, and what I have. And yeah, SetDEP won't work on smss.exe, although I think everything else I've tried (not a lot) has worked.
I did see your post awhile ago, but couldn't think of a reason why DepTest might be failing on your system, when the DLL sounds like it's working otherwise... Then a few weeks later I happened to think about asking if you are using the Logging DLL by chance? Your DepTest results would happen with that version, because overflow.exe has already done its thing by the time the Logging DLL makes DEP Permanent. The DLL waits 1/4 of a second while waiting to see if the process sets Permanent DEP itself (to log that result).
Other than that, you will get the Permanent DEP, just after 1/4 of a second (and that DLL doesn't unload). So it's fine to use, but really just intended for information/debugging purposes.
Oh, and there's no DEP difference between Home and Pro versions of Windows (or any part of the kernel for that matter).
Separate names with a comma.