I own a code signing certificate, so I can add digital signatures on files that contain executable code.

Microsoft seems to use a "new" way and provides most digital signatures not in the file itself but in a signature catalog (C:\Windows\System32\catroot). AFAIK, the lookup in that list is based on a hash value. Therefore, changing the file in any way - even adding another valid signature - will actually result in a removal of the Microsoft signature.

I agree that changing a Microsoft file should result in an invalid signature, but I can't see the benefit of removing a Microsoft signature when the file is signed again by someone else. Although I agree that this will rarely happen.

I see the following disadvantage: given you copy a valid Microsoft executable over to another PC which does not have the catalog (e.g. a newer catalog or older catalog), it will be displayed as unsigned, leaving it up to the one who copied the executable to proof that this is not malware.

When did Microsoft start to use catalogs any especially: why?

  • 1
    "when the file is signed again by someone else": Do you mean signed again by using an "old" way which modifies the file? It sounds like the new way just no longer ignores the old signature section of the file, and signs the entire file now. This means that the entire file would now be tamper-proof.
    – Macil
    Aug 12, 2016 at 0:43
  • @AgentME The signature does not take the hash of the entire file, it is just the binary portion and most of the PE headers. In other words, the signature is not part of what is signed. Aug 12, 2016 at 0:50

2 Answers 2


There are some other interesting benefits around the "WHY":

  1. You can catalog sign non-executables. inf, ini etc...That's not possible with an embedded Authenticode signature. Sometimes you want to make sure non-PE files have not been tampered with.

  2. If you take a binary on system A and copy it to system B, you will break the signature if the required catalog is missing. That can help prevent certain classes of exploits that involve user input.


Catalog files have actually been around since Windows 2000/XP. They are an alternative to signing single binaries as you attach one signature to the catalog file rather than a signature to every single binary. You can use either one to the same effect, but catalog files are more efficient for a large collection of files.

Microsoft typically does not include hashes from third party binaries in their catalog files, unless they are including them as part of the OS or a Microsoft application and are willing to sign those files. The exception to this is kernel mode drivers for Windows 10 as explained in this post. It is unlikely that a third party would modify a Microsoft-signed file without having it signed again.

  • This is rather interesting. How does one go about creating a catalog for a large set of files? I've only been able to find information about doing this using Microsoft's inf2cat tool, in the context of Windows device drivers, and .inf files don't seem to have categories for ordinary executables and DLLs. Oct 24, 2016 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .