Verifying that your system files are digitally signed

Date:June 16, 2004 / year-entry #237
Tags:tipssupport
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040616-00/?p=38853
Comments:    13
Summary:If you want to re-check that the files on your system haven't been tampered with, you can run sigverif (by typing its name into the Start.Run dialog) and tell it to start scanning. (UI note: If you go into the Logging page on the Advanced dialog, you can get trapped where it insists on having...

If you want to re-check that the files on your system haven't been tampered with, you can run sigverif (by typing its name into the Start.Run dialog) and tell it to start scanning.

(UI note: If you go into the Logging page on the Advanced dialog, you can get trapped where it insists on having a valid log file name even if you didn't ask for logging!)

The signature verification process takes a while, so go and do something else while you're waiting. When it's done, you'll get a list of all the system files that are not digitally signed by Microsoft. Just because a file is listed here doesn't mean that it's necessarily bad, however. For example, it might be a video driver or printer driver.

(Another UI note: You can't right-click the items in the list to view their properties, say, to see what company issued the files.)

One case when you would want to run sigverif is after you remove the test root certificate which was causing your desktop to say "for test/evaluation purposes only". That way you can find all the uncertified drivers that snuck in under cover of the test signature.


Comments (13)
  1. Ben Hutchings says:

    So how do you verify sigverif (and the parts of the OS that it depends on)?

  2. Cooney says:

    well, you could build a bootable linux cd with a known good copy of sigverif on it. For the full version, check out ‘On Trusting Trust’: http://www.acm.org/classics/sep95/

  3. will says:

    In reply to the acm linking dude-

    you could also use a known good version of WinPE to run sigverif on.

  4. Drew says:

    Ben:

    That’s one of the tough questions for us. In the future NGSCB might be an answer.

    Cooney/will:

    Running sigverif from a different OS install will probably give you lots of false results. Most of the files that are signed in Windows are signed indirectly with catalog (.cat) files. An install of the OS might have catalogs installed from a patch, service pack, or a 3rd party driver installation. So the one you’re running your check from won’t necessarily ahve the catalogs from the OS you’re checking.

    And WinPE won’t work because the infrastructure to check signatures (and store catalogs) isn’t there. Something like BartPE could be coaxed into working, but that means licensing trouble.

    Linux CD – Maybe if WINE supports the right APIs and implements cryptsvc. I’m putting this on my list of things to try sometime when I don’t have anything better to do. I have my doubts that it would work "out of the box" on any Linux distro, though.

    Unfortunately we don’t have a good (public, released) tool to find/view a signature for catalog-signed files at the moment.

  5. Harcourt Jarenmyer says:

    I ran this check, which scanned 2339 files. 842 files were not scanned, and 15 files were found that were not signed.

    Now what?

    I cannot find any info on each of these files by clicking on them. I cannot connect to a server to check if these files have been tampered with. I cannot connect to a server to verify that these files are genuine, and then have this app sign the files as valid.

    In fact, once the scan is over I get a list that I cannot even export to a txt file so I can send it somewhere to do something. Unless I specify it FIRST in the "Advanced" section.

    I would suggest that you are already advanced if you are running this app from the cli, and these options should be strung across the front of the tool.

    So, I have a machine that has unsigned dlls and other cruft, which someone could be using to compromise my machine, or in a compromise of my machine, and there is no immediate, simple action that I can take to "enclose my confidence".

    Just thinking aloud!

  6. Drew says:

    Not all files are going to be signed even if they’re "approved" – .log files created by the OS, for example.

    The signtool/capicom combo is a much better way to check signatures. It tells you what error was encountered.

    Yes, Harcourt – sigverif is clunky. It’s existed more or less unchanged since at least Win9x days. Which is probably why it’s too geeky for the average user yet too feature-poor for a geek. :-(

  7. Raymond Chen says:

    If a file shows up in the list it means "This is a file that is not in the list of approved Windows files." It could be because it’s been tampered with. It could be because it is a driver written by somebody other than Microsoft. The tool doesn’t know; it’s just listing everything it finds. (As you can easily tell by now, the tool is definitely *not* user friendly; its target audience was propeller-headed ultrageeks.) It’s now up to you to decide what you want to do with this information.

  8. YV says:

    Why does sigverif need to connect to internet halfway throught the process. ZoneAlaram alerted me , any ideas?

  9. Raymond Chen says:

    I have no idea. Perhaps it’s done as part of certificate verification? I’m just guessing. You could always debug it and find out.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index