Didier Stevens

Saturday 17 December 2011


Filed under: Windows 7,Windows Vista — Didier Stevens @ 17:36

I’ve talked about using the FORCE_INTEGRITY flag with EXEs, but how about DLLs? Its effect is similar.

If flag FORCE_INTEGRITY is set for a DLL, and the DLL is not signed or the signature is invalid, Windows will not load the DLL inside a process.

The error code will be 577, or:

Windows cannot verify the digital signature for this file.
A recent hardware or software change might have installed
a file that is signed incorrectly or damaged, or that might
be malicious software from an unknown source.

Thursday 27 October 2011


Filed under: Windows 7,Windows Vista — Didier Stevens @ 17:46

I discovered the flag FORCE_INTEGRITY last year when I released my tool setdllcharacteristics. This flag will force a check of the executable’s digital signature (on Windows Vista and Windows 7) and will prevent the program from running if the signature is invalid (or missing).

But it’s only now that I hold all the pieces to test this flag. A normal authenticode signature is not enough. And you can not use a selfsigned certificate. You need to buy a certificate (aka Software Publisher Certificate, SPC) from a commercial CA for which Microsoft issues a cross-certificate. And then you need to use your SPC and the related cross-certificate to sign your executable (with flag FORCE_INTEGRITY set) as explained here.

This is the same process for signing kernel-mode binaries, or user-mode binaries for AppInit_DLLs or other protected components.

I have the habit of signing my tools with a self-signed cert, so that I can quickly check if my tool has not been altered when I use it on another system (think infected machine). But now that I have a commercial SPC, I can go a step further: I can force Windows to check the integrity of my tools before executing them. If they have changed, Windows will warn me and refuse to run my tools:

There is a small performance hit because the loader has to check the signature, but you will not feel this if you don’t run the executable hundreds of times per second. There’s no problem with casual use.

If you want to test this, you can download a dummy application I signed here (32-bit). When you change the executable (TestIntegrityCheckFlag.exe), Windows will refuse to run it.

If this feature of Windows interests you, consider also the fact that you don’t need to own the source code to sign executables. If you use applications that are not protected by this flag, you can set the flag yourself and then sign the executable. But I don’t recommend that you publish this application, unless you get the author’s permission.

This method is good to protect your tools from malware, but not from malicious individuals: they just need to remove the FORCE_INTEGRITY flag from your executable and Windows will happily execute it regardless of the validity of the signature (I’m not speaking about kernel-mode binaries or other protected processes that require the FORCE_INTEGRITY flag to be set).

Remember that this is for Windows Vista and Windows 7; Windows XP will just ignore this flag. Windows 2008 R2 should also honor this flag, but I’ve not tested this. And it works on 32-bit and 64-bit systems.

Thursday 29 September 2011

Add Bottom Up Randomization To (Your Own) Source Code

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 19:14

EMET’s new Bottom Up Randomization spectacularly increased the entropy of DLL’s base addresses loaded into my test program. Instead of 15 different addresses, I had more than 200.

Matt Miller told me how he implemented Bottom Up Randomization:

“It works by reserving a random number (between [0,256]) of 64K regions via VirtualAlloc. This has the effect of consuming a small portion of the bottom part of the address space. Since the Windows kernel assigns base addresses for collided DLLs by searching for a free region starting at the bottom of the address space, bottom up randomization ensures that a random base address will be assigned. Without bottom up randomization the bottom part of the address space remains fairly static (with some exceptions, such as due to heap, stack, and EXE randomization).”

So I decided to add this algorithm at the start of my test program:

int iIter;
int iRand;

iRand = rand() % 256 + 1;
for (iIter = 0; iIter < iRand; iIter++)

Again, the result is spectacular. In stead of 15 base addresses, with the most frequent address being using 30% of the time, my Bottom Up Randomization implementation gives me more than 300 addresses after 150.000 runs. And there’s no single address being used more than 0,5% of the time.

From now on, I’m going to include this in my programs, and I advise you to do the same with your programs. Or to open source programs you use.

Thursday 1 September 2011

Bottom Up Randomization Saves Mandatory ASLR

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 17:32

I recently found out that pseudo-ASLR (or mandatory ASLR in EMET) has a lower entropy than real ASLR. While real ASLR has a 8-bit entropy for base addresses, mandatory ASLR turned out only to have about 4 bits of entropy, and the distribution was far from uniform. What I forgot to tell you in that post, is that I just enabled Mandatory ASLR as mitigation in EMET, and nothing else:

Matt Miller told me that a new feature of EMET version 2.1, Bottom Up Randomization, would greatly improve the entropy of mandatory ASLR.

The results are spectacular. When I let my test program run around 500,000 times, I get almost 200 different base addresses. And the distribution is more uniform too, no address appears more frequently than 3% of the time.

To get decent protection from mandatory ASLR, be sure to use the latest version of EMET (2.1) and enable Bottom Up Randomization. This gives you the same entropy than real ASLR, with the added bonus that the base address will change each time the application is started, compared to real ASLR which requires a reboot.

Tuesday 16 August 2011

So How Good is Pseudo-ASLR?

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 0:29

Let me first define what I mean with pseudo-ASLR. Address Space Layout Randomization (introduced in Windows Vista) loads executable files at different memory addresses. Studies have shown that ASLR uses 256 different base addresses and that the distribution is pretty uniform.

Pseudo-ASLR is what EMET and my tool SE_ASLR enforce. When a DLL does not support ASLR, memory at the base address of this DLL is allocated right before the DLL is loaded into the process. Since the address is not free, the image loader will load the DLL at a different address, thereby « randomizing » the base address. But how good is this randomization?

As I pointed out in my article on EMET, this base address is different each time a new process is started (unlike ASLR which needs a reboot for the base address to change). So maybe this is better ?

I developed a test program that loads a DLL but pre-allocates memory at the address of the DLL before loading. Then I ran that program thousands of times on a Windows 7 32-bit machine.

Running this program about 50.000 times gives me 68 different addresses. That’s by far not as good as 256 with ASLR. But what’s more important, is that the distribution of these addresses is not uniform at all:

There’s one address (0x000E0000 in my test) that is used 30% of the time. 2 other addresses are used 10% of the time. Rebooting the machine does not change this distribution.

When I do the same test, but enforce ASLR with EMET, I get a similar result:

Again there’s an address that is selected 30% of the time, but it’s different from my previous test. Rebooting the Windows 7 machine doesn’t change the address.

In this test, EMET uses only 15 different addresses, compared to the 68 addresses in the first test. I’ll have to research this difference, I’ve no explanation for it.

Conclusion from this simple test: pseudo-ASLR is rather weak, because I can predict the base address and I will be right one time out of three, which is not bad at all when I can launch my attack several times.

Monday 21 March 2011

Windows Security Center: Under the Hood

Filed under: Windows 7,Windows Vista — Didier Stevens @ 10:29

I’m sure you’ve seen the following warning before:

But have you ever wondered where the Windows Security Center gets its info? (BTW, Microsoft renamed it Windows Action Center in Windows 7).

It gets the information from the Windows Management Instrumentation interface, and more precisely, the WMI name spaces \root\SecurityCenter and \root\SecurityCenter2. I wrote a small script to display this info:

You can download the script here.

It’s also possible to modify this WMI information. Say you’ve uninstalled an antivirus program, but that it still shows up in the Windows Security Center. Then you can delete the WMI information with utility wbemtest.exe.

Start wbemtest (if you’re on Windows Vista or 7, you need to elevate wbemtest) and click on connect.

Type the name space you want to change: \root\SecurityCenter or \root\SecurityCenter2 (SecurityCenter2 is a recent addition). And then connect.

Click onEnum Classes…

Then click OK

Then double-click the type of information you want to change. Here we change AntiVirusProduct:

Then click Instances

And now you can change the information. Here we delete it:

Tuesday 18 January 2011

Quickpost: Checking ASLR

Filed under: Quickpost,Uncategorized,Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 11:13

Some people asked me for a simple way to check shell extensions for their ASLR support. You can do this with Process Explorer.

Start Process Explorer, and set the lower pane to display DLLs. Select process explorer.exe, and add column ASLR to the lower pane view. Then sort on column ASLR.

You will see this:

Notice that on a default Windows 7 32-bits install all DLLs (with code) support ASLR. The n/a is for resource DLLs, they don’t contain code, and ASLR doesn’t apply to them.

Now open an explorer window and right-click a file, like this:

This action will load the context menu shell extensions.

Take a look at Process Explorer:

Now you see the shell extensions without ASLR support.

Quickpost info

Wednesday 1 December 2010


Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 9:56

Because I didn’t find a program to start an application with a given integrity level from “Image File Execution Options”, I wrote runasil.

The following command launches notepad.exe with a low integrity level, instructing notepad to open test.txt:

runasil.exe notepad.exe test.txt

To automatically launch notepad via runasil.exe, using “Image File Execution Options”, create this registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe and create a value debugger equal to “runasil.exe -d” (don’t forget option -d).

You can also specify the integrity level via an option:

  • -l for low
  • -m for medium
  • -h for high
  • -s for system

By default, runasil launches the application with a low integrity level.

Don’t forget you need at least Windows Vista to use integrity levels, and that a process can’t create a new process with a higher integrity level than itself.


runasil_V0_0_0_1.zip (https)

MD5: 5B8CE64715903DD7EEF4AF3B89E6E6FD

SHA256: 15841A9D9985E626C5B70B4BC3B2BF2CD68C38102B6BB1D92BA352D19F5C8A65

Monday 8 November 2010


Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 0:45

Like its name reveals, EnforcePermanentDEP is a DLL to switch on permanent DEP in the loading process.

When loaded inside a process, this DLL will call SetProcessDEPPolicy with argument PROCESS_DEP_ENABLE, hereby enabling DEP permanently on the loading process. After this, DEP can’t be disabled anymore for this process.

Once DEP is set, this DLL unloads itself. There is no need for this DLL to remain loaded once it has enabled DEP. This is done via the entry point DllMain function which returns FALSE for DLL_PROCESS_ATTACH, hereby making that the DLL doesn’t remain loaded inside the process.

To load this DLL inside a process, you can add it to the import table of the target process (EnforcePermanentDEP.dll exports function Dummy), use LoadDLLViaAppInit or use your own preferred injection method.


EnforcePermanentDEP_V0_0_0_1.zip (https)

MD5: B0A89B0CE8DC5BA2472B3D744D40E4A3

SHA256: 525BA6EF82BD2B0ABD30DAD0D676CE085A9FA6E0DE3E3A8A0ADD6DF050F5A635

Sunday 17 October 2010


Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 20:39

The PE-file format specifies flags to enable DEP and ASLR. You can set these flags with a hex-editor or a PE-file editor.

Because I need to set DEP and ASLR flags in a script, I wrote a C-program to read, set or clear these flags (together with another flag to check AuthentiCode signatures, more about this later).

It’s a standard C program, you can compile it under *nix too.

The option handling is simple, you can’t combine flags into one option string. For example, to set DEP and ASLR, you issue the following command:

setdllcharacteristics +n +d program.exe

This will not work:

setdllcharacteristics +nd program.exe

Don’t forget that by changing these flags on signed executables, the signature is not valid anymore. But that shouldn’t be a problem to run the program.

Later, I’ll post tools to force DEP (and maybe ASLR) without changing the PE file.

And I also updated the PE-file format template for the 010 editor to support these 3 flags.


setdllcharacteristics_v0_0_0_1.zip (https)

MD5: F96358BF90AA4D8C6B32968B2068BFCB

SHA256: 5A9D3815F317C7C0FF7737F271CE0C60BE2CB0F4168C5EA5AD8CEF84AD718577

Next Page »

Blog at WordPress.com.