Are Windows DLLs signed by Microsoft? Can I detect if they've been tampered with by a third party?

Question

I'm implementing a locking and copy protection system for my software. I've shut every hole that would allow someone to break my lock (well, that's a little too optimistic, I know!) but the last thing is this:

I hear crackers can change Windows DLLs like Kernel32.dll in a way that the API I use returns a value which is specified by the cracker. I need to prevent this.

At first I thought I could make a hash value for every DLL I use, and check that hash against the calculated hash of the client DLL to see if the file is changed. That won't work since there are many different versions of the DLL for different versions of Windows, and every hotfix and Service Pack provided by Microsoft could change the file.

Then I realized I could check the signature of the file to make sure it has a valid Microsoft signature. Now there are 2 questions:

1. Does Microsoft sign Windows DLLs? How can I find some info on this signature?
2. Is a Public key provided to validate the signature? How do I use this key to validate the file?

Any walkthroughs are greatly appreciated. My app is written using Visual Basic.NET.

Thanks guys.

Answer 1

MS does sign some system binaries, depending on the version of Windows and the binary. For example, if you check kernel32.dll on Windows XP:

C:\Windows\system32>sigcheck kernel32.dll
Sigcheck v1.5
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Windows\system32\kernel32.dll:

Verified: Signed
Signing date: 02:07 14/04/2008
Publisher: Microsoft Corporation
Description: Windows NT BASE API Client DLL
Product: Microsoft« Windows« Operating System
Version: 5.1.2600.3119
File version: 5.1.2600.3119 (xpsp_sp2_grd.070416-1301) 

You can also use sigcheck to do stuff like find all unsigned binaries in a specific folder, e.g.

sigcheck -u -e c:\windows\system32 

I believe that the answer to your second question is "no", although MS does use root certificates for some validation purposes. It doesn't publish public keys in its Windows system binaries because the key pairs can and do change.

But fundamentally if you don't trust the OS, then you're fubar anyway.

Just face it, your app will be cracked. My advice would be to spend only 1% of your effort on slowing down the cracking process, and 99% on creating something that's worth cracking.

Answer 2

Are you going to write your own crypto routines so you can validate the signature yourself, or are you going to trust the Crypto API? Are you going to use signatures on the crypto dlls to validate the crypto dlls?

Who watches the watchers?

You'll be wanting to write your own operating system, and you'd better make sure it can't be run in a virtual machine! Perhaps you should make your own hardware hardware too.

Ultimately, you have to trust something. Really. If you're not prepared to trust the user, trust the OS because if you don't trust that, you're going to end up rolling your own hardware to make it 'secure'. Yes, someone will hack your software - it's pretty much inevitable. Make it difficult by all means, but remember that returns diminish (rapidly!)

Answer 3

Other answers say that you can check that the on-disk copies haven't been modified. You're SOL for the in-memory copies.

Answer 4

Unfortunately checking digital signatures of Microsoft's own DLLs, however great of an idea it could be in theory, is a totally moot point in practice. Why? You would ask. Because Microsoft don't seem to care to sign a big number of their own system DLLs.

You can theoretically use a version of this C code to check if an executable file is digitally signed and if the executable is intact/unchanged, but if you implement it and go through all system DLLs that may be loaded into your process you'll be greatly disappointed.

For instance, from about 50 system DLLs loaded into my process the following major libraries were not signed!

Windows 8.1:

Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\MSIMG32.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\COMDLG32.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\WINSPOOL.DRV"
Failed: hr=0x800B0100 "C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9600.18006_none_623f33d3ecbe86e8\COMCTL32.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\oledlg.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.9600.18592_none_933383bf47487fd6\gdiplus.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\dbghelp.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\uxtheme.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\RICHED20.DLL"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\USP10.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\msls31.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\msftedit.dll"

Windows 10:

Failed: hr=0x800B0100 "C:\WINDOWS\system32\apphelp.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\System32\COMDLG32.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\MSIMG32.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\WINSPOOL.DRV"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\oledlg.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.14393.953_none_7300116921188239\gdiplus.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\dbghelp.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\uxtheme.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\RICHED20.DLL"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\msls31.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\SYSTEM32\USP10.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\msftedit.dll"
Failed: hr=0x800B0100 "C:\WINDOWS\system32\dataexchange.dll"

So as you see, there's no hope in them doing it any time soon.

So yeah.... SHAME ON YOU, MICROSOFT!

PS. Error code 0x800B0100 = "No signature was present in the subject."