Didier Stevens

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.

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.