void main()Not to be confused with my future travel site, avoidmaine.
File permissions on XP with "Simple File Sharing"/Home Edition: Since I've been using my Windows XP Home copies as Professional ("Home-as-Pro," thanks to a simple 1-byte, pre-install, Setupreg.hiv trick), I've needed a way to have the Security tab on file/folder Properties since I purposely leave Simple File Sharing enabled (for a couple reasons). So normally the Security tab would only be available in Safe Mode. :-( A few years ago I found a simple hack for rshx32.dll (responsible for Security tab), which checks Safe Mode status via the SYSTEM\CurrentControlSet\Control\SafeBoot\Option registry key, and OptionValue value. By changing that last backslash (bolded) to a null-byte (5C to 00 at offset A02), the string is terminated sooner and the code looks for OptionValue (1) in the SafeBoot key instead, so rshx32.dll thinks it's in Safe Mode and displays the Security tab without Windows itself being affected.
It always seemed a little hackish and sloppy to have to add the "fake OptionValue," so after a post on Wilders in Nov. made me think about it again, I decided to see if I could simply change the code to skip the Safe Mode, etc. check altogether. YES, it only took like 30m to figure things out and look up some assembly stuff, and a couple revisions on changing the fewest bytes, but it works great! At offset 4E36, change original bytes 56 8D 45 F8 50 to 33 C0 40 EB 57. See disassembled diff — unnecessary grayed parts are just skipped now by adding an unconditional jump. :^) If anyone else wants the change and doesn't want to use a hex editor, you can download my modified copy of rshx32.dll (SP3 version 5.1.2600.5512, English). Either way, you need to delete (replace?) the copy in dllcache first!
February 22nd (birthday) update: The non-logging Permanent DEP DLL (which unloads itself) is now compatible with Sandboxie 4's InjectDll as of 4.09.1! Nice! I was surprised to discover this after checking the first beta under new ownership a couple days ago. So now it's like Sandboxie 3.x again, without causing "The application falied to initialize properly" (yes, it actually sets permanent DEP and is unloaded). After what tzuk told me last year, the change must make it behave like a dynamically-loaded DLL again (e.g. optional) instead of statically-linked (required) when FALSE is returned after initialization (DllMain), which usually means failure... It's irrelevant for MY usage, since it's installed system-wide (AppInit), but good news for anyone else that may just want to enforce Permanent DEP in their sandboxed programs. :-)
In other news, I still haven't touched the OpenEMET stuff further. :-/ I switched hosting to a new VPS server and since November have been using what-would-have-been-OpenEMET-time playing with and figuring out different Linux/server stuff in preparation for launching a hopefully-major new site, and I'm in the process of building/coding that, SO... sorry! If I take a week, I think it'll happen — I'm still hoping to have something available before/around when XP updates end. So, April-ish?
November 6th update: Yes, I am still alive! I haven't posted in months at Wilders (thread about DEP Tools), or replied to a PM or two (from a crazed fan :-D). And sorry for still not clearifying/updating the information on this page after the original first draft... (If you don't expect too much from me, you might not be let down.)
I did post an update about OpenEMET! Things are still the same after this long "pause." :-) Anyone think the proposed name should be changed, or have something better in mind...? I noticed Google'ing, many references to "Open EMET" (spaced), as a verb, etc. But maybe it's a good thing to have the OpenEMET name? LOL Oh, and I/we do need some sort of icon for it! I've never really understood the EMET "padlock" icon... I'm no designer (see SetDEP), so if anyone wants a NICE icon, perhaps you or someone you know can create something — for credit of course!
A lot of my "computer time" this summer was wasted fighting with convincing/helping tzuk with Sandboxie v4 performance problems at those forums. *Sigh* At least that's finally (finally, geez!) been resolved about as much as it can be since August. Still some other issues with v4 that I need to post/remind about, but haven't gotten to that either (low priority).
One thing trying to investigate Sandboxie allowed me to do was learn a bit more about Windows programming! :-) In creating an example program to demonstrate slowness with CreateWindow, I was forced got to [see a way to] create a GUI dialog window and stuff (albeit simple: screenshot) using resource files, etc... (GUIBench.zip + source linked from a Sandboxie post.)
I'm still waiting to finish reinstalling Windows on 2 systems, wow. :-/ Got one to finish, and hopefully I'll fin-al-ly get to the main system after this month's updates. That's what I'm waiting on before continuing other things. Then I need to figure out how to clean up/rearrange many TV recordings on another system, in which one of the new 3 TB drives is bad/failing. :*( Of course I didn't notice this until I filled the drive (written "fine," can't read "some" files [??] back). Guess I shoulda ran a full scan first. Lotta data; what a mess to get the drive RMA'd or whatever is needed. :-(
And finally, it looks like I'm back to modifying and compiling PHP since accidentally discovering a Windows bug (with microtime(), et al.) introduced back in the spring... Want to test my solution-in-mind fix for that first. (Seriously, why did nobody else code it "right" in the last 12+ years after many weird bug reports?!) Also, since I've been annoyed since hearing that PHP 5.5 would no longer run on my beloved Windows XP, I *think* I'm able to fix that easily and can soon have XP-compatible builds available here! :-O (Probably of no interest to anyone...)
It's with great fanfare (is there any other kind?) that I'm proud to finally announce the release of my trivial flagship "DEP Tools!" It's my IPO, Initial Public Offering, of something for Windows, and my first time using my preferred C language since PHP stuff years ago. Not much has changed since I whipped it up 3 months ago, but after referring to it for a while at Wilders, I "finalized" stuff (mostly, still some changes coming) and polished it for release. And I spent like 6 weeks working on the uber-1337 icon for the SetDEP program, which I hope everyone loves! (That's all a lie... just the last sentence.)
If you're using a Windows computer (is there any other kind?), this could be the greatest site you've ever seen (not including cheezburgers and hotdogz, of course). I fully expect this page to be Slashdotted soon, so get it while you can. I'm not sure if my host can handle a million downloads by the end of the month, or year.
Version history
Download and install
SetDEP
Background info/story
Future stuff
The "Permanent DEP" DLL (via AppInit, or within Sandboxie) is the main, and most important, part of DEP Tools. (Inspired by Didier Stevens' EnforcePermanentDEP, an "unconditional enabler.") Why do you need it? Because I said so, and if more people download it, I'll make big monies. :-)
If I can get serious for a minute: If you haven't configured DEP to be AlwaysOn, DEP can be disabled in a process (exploit code, etc.). This is more [common] of a problem on Windows XP, since later versions (starting with Vista SP1), automatically enable DEP permanently for programs compiled (linked) with the /NXCOMPAT flag, although some programs are still missing that flag, and they may or may not call the SetProcessDEPPolicy function on themselves. Non-permanent DEP could be an issue for any 32-bit program (including on 64-bit versions of Windows); 64-bit programs always use DEP.
Other than the included, companion SetDEP program, you can use BufferShield's DEPTest tool to see how DEP can be disabled. All tests will show "Unprotected" without AlwaysOn DEP or the Permanent DEP DLL (not the logging version).
Some programs can't run with AlwaysOn DEP, because they're incompatible with DEP and need to be excluded: either explicitly ("except those I select:" in System Control Panel) or implicitly by the Windows loader (certain types of executables). Or, they may actually be compatible with DEP (mostly), except that they need Windows to apply something called "ATL thunk emulation," which intercepts certain DEP exceptions and allows them to function normally (this doesn't happen with AlwaysOn).
Using the Permanent DEP DLL allows OptOut DEP to be used (recommended minimum) for its compatibility and covenience, but with basically all the benefits of AlwaysOn. So the DLL is useful if you have DEP configured as OptOut on any version of Windows; or with OptIn on Windows XP (I haven't seen DEP opting-in that's not permanent on Vista and later, with the exception of some weirdness on Windows 8).
On XP, DEP should be permanent, just because (that's all it has). On Vista and later, it should be permanent to ensure effectiveness when used with ASLR. (I used to ask "ASLR?" in chat rooms before 2000, when I was 12 or almost 21.)
If using Process Explorer to check DEP, please note that on Windows 7/8 the current version's indication of DEP status has been broken since v15.13. You can get the last working version, 15.12, from FileHippo.
On XP, the DLL enables /NXCOMPAT to be honored the same as later Windows versions — it enables full DEP permanently even when configured as OptIn. "Full" DEP means "ATL thunk emulation" is disabled (not sure how much difference that makes, if any, but it's disabled since it's not needed).
Otherwise, if DEP is on, the DLL will make it permanent if it's not — almost everything on XP, if the program (or EMET) doesn't call SetProcessDEPPolicy; or some programs on other versions, depending if they're missing /NXCOMPAT.
If a program is excluded from DEP (explicit/implicit), the DLL won't do anything. It has worked fine in all cases that I've seen, although if there's something that can implicitly disable DEP later after process initialization (I don't understand ...Image File Execution Options\DllNxOptions on Vista and later! see Bypassing Browser Memory Protections, p. 11), that would fail, and you would need to add an explicit exception for such a program.
Besides Process Explorer, how can you know which programs don't have permanent DEP and can benefit from using the DLL? You can use the logging version of the DLL to see more detail about what's happening, or not, for processes. :-) If DEP is excluded or it's already permanent (/NXCOMPAT on Vista and later), nothing will be logged. Otherwise, the DLL will wait for 1/4 of a second and then check if the program permanently enabled DEP itself. The status and the program name will be written to "PermanentDEP.txt" (must exist first) in the same folder as the DLL.
Possible log status messages:
| <No NX> | Not /NXCOMPAT and didn't call SetProcessDEPPolicy |
|---|---|
| +NX (XP) | XP only: /NXCOMPAT and full DEP will be enabled as on later Windows versions |
| Set-ATL | Called SetProcessDEPPolicy and enabled full DEP (disabling "ATL thunk emulation") |
| -NX,Set | Not /NXCOMPAT, but called SetProcessDEPPolicy |
| *NX,Set | XP only: /NXCOMPAT, and called SetProcessDEPPolicy, but when using the non-logging DLL, full DEP will be enabled first |
| -NX,EMET *NX,EMET | Same as ,Set messages, except SetProcessDEPPolicy was called by EMET's forced DEP, which happens before the program's call, if any (but after the non-logging DLL); Simply uncheck DEP temporarily in EMET if you want to see an accurate status about the program |
DEP Tools 1.0.1 (29 KiB; MD5: 7196f66e581e89fbf2dbf3624cdd95b0)
I'll put up a full source "package" shortly, but here are the main files:
PermanentDEP.c
PermanentDEP.asm (planned, now unused, basic assembly version)
SetDEP.c
DEP Tools requirements: Windows XP SP3, Vista SP1, 7, or 8. (Probably 2008, 2008 R2, and 2012?) It's been tested on 32-bit XP, Vista SP2, 7, and 8; as well as 64-bit 7 SP1.
To install the Permanent DEP DLL, open the following registry key:
32-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
64-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
On Vista and later, set LoadAppInit_DLLs to 1
On Server 2008 and later, set RequireSignedAppInit_DLLs to 0
Then add PermanentDEP.dll to the AppInit_DLLs value. You need to put the full path to the DLL, without spaces (otherwise use short names: ...~1), unless the DLL is in, for example, your system folder:
32-bit Windows: Windows\system32
64-bit Windows: Windows\SysWOW64
The non-logging DLL unloads itself so it will never be seen loaded into processes in e.g. Process Explorer. If you want to verify the DLL is loading, check with the logging version. Note: If processes have it loaded, you cannot delete the DLL, but you can rename, etc. and delete later when it's not in use (or after a restart).
If you only want to enforce permanent DEP for programs within Sandboxie, you can use its InjectDll setting. Note that InjectDll in Sandboxie 4 (prior to version 4.09.1!) is not compatible with the non-logging DLL (because it unloads). Alternatively, AutoExec can be used to make the AppInit registry changes in the sandbox only, which I hope to include with a future installation script. :-)
Also, remember if using the logging DLL (no matter how it's installed) with sandboxed programs, the log will be written in the sandbox unless it's excluded!
I never found any problems using the DLL, but I guess it's possible that someone else could (during startup, etc.). I had recently added a check for Safe Mode, to prevent the DLL from functioning in that scenario. However, when testing that functionality, I noticed that Vista and later doesn't even load AppInit DLLs in Safe Mode! (I guess that makes sense since they have the extra LoadAppInit_DLLs setting.)
Windows XP does still load AppInit DLLs in Safe Mode. But I can't see a scenario where setting permanent DEP could possibly be a problem like with later Windows (where it's suggested that DEP could be disabled by Windows after process initialization). In fact, when I thought I was going to create 2 non-logging versions of the DLL (assembly for Vista+, C with NX check for XP), I never planned to include the Safe Mode check for XP anyway. :-)
If you want to be really cautious (on XP), simply try the DLL first where it can easily be removed without starting Windows, e.g. USB drive, etc.
The only tiny reason I created the SetDEP program (name from SetACL :-D) is because on Windows XP, csrss.exe doesn't load the Permanent DEP DLL for whatever reason (even though it loads user32.dll). So on XP I can run it as a startup program (as Administrator): SetDEP -a csrss.exe
Usage: SetDEP [-c] [-d | -a] <process | PID> [| more]
Enables DEP (permanently) by default (without -d or -a)
-d Disable DEP if it's not "permanently" enabled
-a Disable "ATL thunk emulation" (like /NXCOMPAT, or AlwaysOn System DEP)
-c Console output of usage text; command status always goes to console
You won't see output in a Command Prompt unless you pipe to | more
(see or use cliDEP.bat)
To prevent a window flash in my startup scenario, it's not a Console program (whatever that is), so to see the standard output, it has to be piped to | more
So it's there if anyone wants to experiment on any Windows version. :-) It will work on your own processes as a standard user. It needs to be run with Administrator (elevated) privileges to work on processes with a higher Integrity Level, but it will not work for processes running in a different Session on Vista and later (e.g. services and system stuff).
It's purposely linked with /NXCOMPAT:NO so you have at least one program that doesn't get permanent DEP, for testing on Vista+ — you can SetDEP using the PID of another, waiting GUI instance.
It uses CreateRemoteThread to call SetProcessDEPPolicy in the other process. I think I first saw that method in Process Hacker's source after trying to use NtSetInformationProcess.
This project is fairly trivial, though I don't consider it useless. :-D The DLL should be completely transparent, set-and-forget, in which case there's no reason not to use it. It was more of a thing to finally create something, however small, for Windows that actually has some purpose, instead of just a "Hello World" type thing! I learned a bit more about Windows-specific coding, a bit of assembly, building/compiling/linking/etc. that are helpful for any future projects. :^)
I made the conditionally-enable-permanent-DEP DLL mid February, based on Didier's. I figured I'd create the SetDEP program quickly and release "DEP Tools" early-mid March, maybe on Pi Day. But I didn't really like the fact that a simple DLL was 40 KiB compiled with Visual C++ Express!
Having seen WinRoll's assembly and small file sizes, I figured this DEP DLL would be simple enough to implement in MASM32 assembly. But I was too lazy, or thought it might be a pain, so I didn't install it until April! It was very simple to install, although I don't like how it installs to the root of the drive, and how includes work, etc... But after waiting so long, I had the assembly version completed in like 30 minutes. :-O
That got the size down to where I'd expect, then I just wanted to make an icon for SetDEP and version info resources, etc. Then at the end of April I guess, I realized (for XP) that I could check programs for the NX_COMPAT bit — idea from Didier's SE_ASLR, although I realized I didn't need to read the file, since it's already in memory, pointed to by GetModuleHandle(NULL). :^)
But... how was I going to do THAT in assembly — dereferencing pointers to structures?! I think I have more of an idea now, although I never tried. Since that was around the time I finally saw some clearer instructions than I had seen before about reducing the size of VC++ binaries — removing (or reducing) CRT dependencies. It's simpler than that page suggests: for these DLLs, simply explicitly link with /ENTRY:DllMain and since I'm not using any CRT functions (or functionality), it's as small as the assembly version!
Looking at the disassembled DLL (using MASM32's Quick Editor), compiled by VC++ without optimizations, it looks basically like what I wrote and what the assembly version compiled to. With optimizations (/O2), the code is smaller, and presumably "better." Plus the separate functions get inlined with VC++. So I see no reason to use assembly unless one has a specialized reason to. ;-)
Then I found the DEP problems with Process Explorer in Windows 7 and 8, and some unexpected values when checking GetProcessDEPPolicy on Windows 8 that I still don't understand. Then I created the logging version of the DLL at the beginning of May, and added the Safe Mode check (which turned out to be unnecessary, it seems).
That's about the whole story... I planned to release everything on May 12th, which is special day, like October 24th. I just happened to get almost incapacitated with a painful, "paralyzed" neck for a few days — almost had to resort to a doctor and/or drugs of questionable legality. :-( I've been slow getting this information page created!
If I update SetDEP with some enhancements, I'll probably try to remove the CRT dependencies from it as well and reduce the size to less than 20 KiB (mostly the icon resource).
Some other things I hope won't crash your computer to release sometime:
OpenEMET
SRP bypass fix for XP/Vista (8?)
Steady Clock (one word function: SetSystemTimeAdjustment)
SluRP