Discussion in 'other anti-malware software' started by DR_LaRRY_PEpPeR, Apr 27, 2013.

Thread Status:
Not open for further replies.
  1. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Oct 11, 2012
    St. Louis area
    After thinking I'd have my "DEP Tools" with Permanent DEP DLL (primarily for XP) available last weekend, after further experimentation/investigation, I now have a complete Vista/7-like DEP solution for XP. :) (Release 2 weekends now hopefully.) Instead of just making "already on" DEP (OptOut) permanent, it also checks if the EXE has the /NXCOMPAT compile (link) flag, and honors that. :argh: So simple, I wonder why XP SP3 doesn't do that itself like Vista SP1+. So that could be of some use with OptIn DEP on XP, although no built-in XP stuff uses /NXCOMPAT (but they mostly do opt-in with AppCompat, I believe, which would then be made permanent), and I'm not sure how much 3rd-party software is still missing /NXCOMPAT...

    Anyway, that's the background, now some different things I'm wondering about, to have a better/complete understanding. :)

    First, I noticed that Windows 7's DEP cannot be disabled, at all (at least not with SetProcessDEPPolicy), even when a process is not explicitly flagged as "permanent." Interesting...

    On 7 (and I think Vista too; just broke the VM so can't confirm), there doesn't appear to really be any difference between OptIn and OptOut DEP as there is on XP. Anyone have more of an explanation about that?! Both modes seem the same. Of course /NXCOMPAT EXEs get full DEP with OptIn (so that covers stuff that comes with Windows), but even non-/NXCOMPAT programs (my own and others) still have DEP enabled even with OptIn! They need OptOut on XP.

    Page 11 of the Bypassing Browser Memory Protections PDF talks about ways the loader may disable DEP for a process if it's not Permanent (I can't observe any of these; only packed loaders for the EXE itself implicitly disabling DEP on XP), including Image File Execution Options\DllNXOptions in the registry. This doesn't seem to apply to XP, where I was trying to use it first, but I see that key is never queried. I can't find any more information about it. There is a list of DLLs there on Vista and 7, including 1 (mscoree.dll) that's loaded in Process Explorer, yet it doesn't get its DEP disabled. I tried adding other Windows DLLs, or hiding (renaming) the whole key. Nothing seems to actually DO anything however. Anyone know more about DllNXOptions? Is it possible that DEP can just be disabled for a certain DLL, rather than the whole process? :doubt:

    Finally, about ASLR: Is there ANY benefit to DLLs being relocated (e.g. not loaded at their preferred address) on XP? Or is that pointless when the system and its DLLs aren't ASLR'd, so therefore, e.g. GetModuleHandle remains at a fixed location and can find other DLLs...? Of course a DLL being relocated on XP would at least prevent it and its code from being accessible with a fixed/hardcoded address, right? Just curious and wondered if an expert can comment more. :)

  2. luciddream

    luciddream Registered Member

    Mar 22, 2007
    Re. the first point... that is interesting indeed. Strange, head scratching interesting even. On the second point, I'm hardly the expect opinion you're looking for here, and have wondered the same thing at great length myself recently. Your understanding seems sound.

    I'm really looking forward to your release(s) and applaud your efforts. Do I remember correctly that your alternate interface for EMET will not require .NET FW to function? If so I'm definitely going to hold off on EMET 4 until I give your product a try... before I throw all this other framework on my machine to make the upgrade. I'm less than thrilled about adding that attack surface.
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.