Didier Stevens

Tuesday 8 November 2011

White Hat Shellcode Workshop: Enforcing Permanent DEP

Filed under: Shellcode — Didier Stevens @ 21:12

Here’s a video of an exercise in my White Hat Shellcode Workshop I gave at Brucon in September.


  1. What did you use for video capture and text annotation? Nice video btw

    Comment by Jkp — Wednesday 9 November 2011 @ 4:46

  2. That’s fascinating – thank you. I’ve been looking forward to seeing a demo because, regrettably, I couldn’t attend Brucon.

    I know that you’ve published simple-shellcode-generator.py and intended publishing create-remote-thread.py after Brucon. I’m keen to replicate your experiments – do you know when you’ll publish this code? I also saw some slides of the workshop and there was a package “shellcode-workshop.zip”. Do you plan publishing that too?

    I realise that you created this material for the workshop and quite understand it if you decide to delay publication.

    Comment by Iain — Wednesday 9 November 2011 @ 19:32

  3. @Jkp I use VMware Workstation’s Capture Movie feature. And video + subs is produced with avisynth.

    Comment by Didier Stevens — Wednesday 9 November 2011 @ 20:02

  4. @Iain If you search a bit on the Brucon site, you’ll find all you need…

    Comment by Didier Stevens — Wednesday 9 November 2011 @ 20:03

  5. Got the package Didier – thank you. I’ll have a play around with it this weekend!

    Comment by Iain — Thursday 10 November 2011 @ 11:53

  6. I’ve had an interesting time playing around with the code and seeing some of the possibilities. I’m sure some real-life situations will pop into my head where I can use white hat shellcode!

    I realise that CreateRemoteThread is flagged by AVs and, as far as I know, it is still available in Windows 7. I have a couple of questions:

    I assume that, if an application needs to use this API, the AV will flag it as a problem so are there any alternatives that software developers can use? What about alternative methods of DLL injection?

    If CreateRemoteThread is still available in Windows 7, why? Have Microsoft left it there for legacy purposes? Given the fact that AV pick it up if it’s used, what’s the point it being there?

    Comment by Iain — Friday 30 December 2011 @ 14:04

  7. @Iain I’ve not seen a lot of AV products identifying executables that call CreateRemoteThread malware. But there are security products that monitor calls to CreateRemoteThread.

    Comment by Didier Stevens — Saturday 31 December 2011 @ 13:15

  8. You can also set the IMAGE_DLL_CHARACTERISTICS_NX_COMPAT flag in the Dll Characteristics field of the PE header to enforce permanent DEP.

    Comment by waliedassar — Saturday 21 April 2012 @ 1:33

  9. @waliedassar No, you should take my workshop. That is exactly what I explain in my workshop: the IMAGE_DLL_CHARACTERISTICS_NX_COMPAT flag enforces DEP, not permanent DEP! DEP set with IMAGE_DLL_CHARACTERISTICS_NX_COMPAT can be turned off, permanent DEP set via the API can’t be turned off.

    Comment by Didier Stevens — Saturday 21 April 2012 @ 10:21

  10. You are right.

    My test was made on Windows 7 where what i mentioned applies. In Windows 7, executables with the NX_COMPATIBLE flag set are assigned permanent DEP.

    Sorry for disturbance.

    Comment by waliedassar — Saturday 21 April 2012 @ 12:41

  11. @waliedassar No Problem, you are not disturbing.

    But what you are observing is not because you use a Windows 7 machine, but because you use 64-bit Windows.

    DEP on 32-bit and 64-bit Windows behaves differently, that’s why I use 32-bit Windows for my workshop.

    If you take a look at the MSDN entry for SetProcessDEPPolicy
    you’ll notice it’s for 32-bit processes only.

    Comment by Didier Stevens — Saturday 21 April 2012 @ 12:47

  12. Hmm, I hadn’t seen this entry before — just found it while searching about some DEP/Permanent *weirdness* in Windows 8, for an AppInit make-DEP-Permanent-if-it’s-not DLL I’ll release shortly (inspired by your EnforcePerm DLL :-), along with SetDEP to manipulate other [session/non-perm] procs with CreateRemote). Not an “uncoditional enabler,” so works with OptOut (implicit/explicit exceptions). There’s some other entries I’ve been meaning to leave comments on, so I’ll be back…

    Anyway, sorry Didier, but you’re wrong, waliedassar is right. :^) Since Vista SP1, I believe, where “Permanent” DEP was introduced, the NX_COMPAT flag | /NXCOMPAT link (ignored by XP, without my DLL) DOES enable Permanent DEP. So those programs running on Vista SP1+ have no need to call SetProcessDEPPolicy — of course they would on XP.

    Obviously that only applies to 32-bit processes (SAME on Win x64, re: your last comment) — 64-bit ones always have DEP permanently enabled, period, AFAIK.

    BTW, in other news, I just discovered that Process Explorer in Windows 7 (and 8) shows “DEP” even when it’s OFF! And in Windows 8, it shows “(permanent)” even when it’s not! :-O Probably has to do with the GetProcDEP behavior I’m seeing — look at the value of &permanent. No longer TRUE|FALSE only like XP/Vista/7. Plus other stuff with &flags and OptIn/OptOut… :-/ Ugh, trying to see how to sort this out.

    Comment by Matt — Wednesday 1 May 2013 @ 1:05

  13. @Matt Thanks for the info, I’ll test it out, but I don’t have access to a 32-bit Windows Vista SP1+ machine now.

    Comment by Didier Stevens — Wednesday 1 May 2013 @ 9:11

  14. You don’t need a 32-bit Windows, everything should be the same on 64-bit. You just need to look at/use 32-bit processes, of course. 🙂

    In my limited looking so far, I’m surprised how many 3rd-party 32-bit stuff still isn’t using /NXCOMPAT, and not getting the automatic permanent DEP post-XP…

    On XP with /NXCOMPAT programs, my DLL will not just Set(DEP_ENABLE), but also | DISABLE_ATL_THUNK_EMULATION, which is what the NX_COMPAT flag sets on Vista SP1+ (if you didn’t know). AlwaysOn system DEP does the same, unlike OptOut. I’m not sure how much “better”/stronger disabling thunk emulation is, but, that’s what they do… I couldn’t find anything about abusing “ATL thunk emulation,” so it seems more like a “just in case, since we don’t need it” thing? *shrug*

    Comment by Matt — Wednesday 1 May 2013 @ 15:16

RSS feed for comments on this post. TrackBack URI

Leave a Reply (comments are moderated)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.