I wrote an article on my Authenticode tools for (IN)SECURE Magazine: Issue 39 page 60.
AnalyzePESig is a tool to check signatures in PE files, just like Sysinternals’ sigcheck. But with a couple of differences.
First, when a signature is not valid, AnalyzePESig will tell you why and still display information about the invalid signature and related certificates. Second, AnalyzePESig displays more information and third, it is open source.
Here is a short explanation of the fields in the output produced by AnalyzePESig:
Filename
Self-explanatory.
Extension
Self-explanatory.
MD5
Self-explanatory.
Entropy
The entropy of the bytes of the file.
Use this as an indicator for compressed or encrypted content (high entropy).
This value is between 0.0 and 8.0.
Filesize
Self-explanatory.
Creation time
Self-explanatory.
Last write time
Self-explanatory.
Last access time
Self-explanatory.
Owner name
The username of the owner of the file specified in the security descriptor.
File attributes
The WORD itself for the file attributes.
File attributes
A text representation of some of the file attributes. Like A for the Archive flag, …
Characteristics
The Characteristics of the PE file.
Characteristics
A text representation of some of the flags of the Characteristics. exec for executable image flag, dll for dll flag.
Magic
The Magic value of the PE file.
Magic decode
The decoded Magic value of the PE file.
Subsystem
The Subsystem value of the PE file.
Size of code
The size of the PE file.
Address of entry point
The address of the entry point of the PE file.
Compile time
The compile time of the PE file.
RVA15
The relative virtual address stored in Data Directory 15. This value is different from zero for .NET assemblies.
CLR version
The version of the CLR.
Sections
The name of the sections found in the PE file.
Signature size 1
The size of the signature as specified in the Data Directory.
Signature size 2
The size of the signature as found in the PE file.
Signature Revision
The revision number of the signature (should be 200).
Signature Certificate Type
The certificate type of the signature (should be 2).
Bytes after signature
Extra bytes found after the signature in the Data Directory (should be 0).
Result PKCS7 parser
The result of the PKCS7 parser. 1 for success, 0 for failure.
PKCS7 size
The size of the PKCS7 data as returned by the PKCS7 parser.
Bytes after PKCS7 signature
The number of bytes found after the PKCS7 data. This data is padded to a size which is a multiple of 8. So the number of bytes after the PKCS7 signature should be between 0 and 7.
Bytes after PKCS7 signature not zero
Padding is done will 0x00 bytes. Finding bytes after the PKCS7 signature which are not 0x00 is not normal.
PKCS7 signingtime
The code signing time as found in the PKCS7 signature.
DEROIDHash
The DEROIDHash is a sha-256 hash of the DER structure and OID numbers of a PKCS7 signature. Signatures with the same structure and OID numbers share the same DEROIDhash.
Valid signature
1 if the file has a valid signature, 0 if not.
Error code
If the signature is not valid, this error code will provide more details.
From catalog file
1 if the file is signed using a catalog file.
Catalogs
The number of catalog files for this file.
Catalog Filename
The name of the last catalog file listed for this file.
Issuer Name
The issuer of the certificate for the digital signature.
Subject Name
The subject of the certificate for the digital signature.
Subject thumprint
Self-explanatory.
Signature Timestamp
The date and time the file was signed.
Countersignature Timestamp
If present, the date and time of the counter signature.
Extensions
The OID numbers of all extensions present in the certificate for the digital signature.
Root Subject Name
The subject of the root certificate.
Root Thumbprint
The thumprint of the root certificate.
Signature Hash Algorithm
The hash algorithm used for the signature of the file.
Not before and not after
The validity period of the certificate for the digital signature.
Subject Name Chain
The subject of each certificate in the chain.
Signature Hash Algorithm Chain
The hash algorithm used for each certificate in the chain.
Serial Chain
The serial number of each certificate in the chain.
Thumbprint Chain
The thumbprint of each certificate in the chain.
Keylength Chain
The keylenght for each certificate in the chain.
Issuer Unique Id Chain
The number of bytes of the issuer unique id for each certificate in the chain.
This should be zero. It is not for the Flame certificate.
Subject Unique Id Chain
The number of bytes of the subject unique id for each certificate in the chain.
This should be zero. It is not for the Flame certificate.
Extensions Chain
The OID numbers of all extensions present in each certificate in the chain.
File Description
The file description found in the version info of the file.
Company Name
The company name found in the version info of the file.
File version
Self-explanatory.
Product version
Self-explanatory.
Icons
The number of icons in the PE file.
AnalyzePESig_V0_0_0_8.zip (https)
MD5: C14A2C8AA91D34F534B4F76E7014E3A9
SHA256: BCCF90BF6E4C26C33BF16DA20CF220DAE8D748B942224659DC720B35BB8EFE86
ListModules takes a snapshot of all processes and then analyses all loaded modules (.exe, .dll, …), producing output very similar to AnalyzePESig.
You are best to run ListModules 64-bit on a 64-bit system, and to run it with the administrator account or elevate.
ListModules_V0_0_0_4.zip (https)
MD5: 36D05A56C06493A3EB1BAD6F9F5BB2E5
SHA256: FDB262E043F86EA4F147D50B2DD48707C63E0751B655AB3AF9577C1E54017CE6
Didier Stevens 
[…] added a new page to document my Authenticode Tools like […]
Pingback by Authenticode Tools Page « Didier Stevens — Tuesday 4 December 2012 @ 13:53
[…] is a new tool to analyze PE files, like my AnalyzePESig tool. In stead of analyzing all files you point it to, it takes a snapshot of all processes, and […]
Pingback by ListModules V0.0.0.1 « Didier Stevens — Thursday 20 December 2012 @ 0:00
[…] Soon I’ll release new versions of my Authenticode Tools. […]
Pingback by A Bit More Than A Signature | Didier Stevens — Tuesday 13 August 2013 @ 19:07
[…] is the effect illustrated with my AnalyzePESig […]
Pingback by MS13-098: Fixing Authenticode | Didier Stevens — Wednesday 11 December 2013 @ 23:17
Trying to download AnalyzePESig_V0_0_0_3.zip gives me 404 Not Found…
Comment by Sergey Vlasov — Friday 13 December 2013 @ 12:56
@Sergey Sorry, forgot to upload, fixed now.
Comment by Didier Stevens — Friday 13 December 2013 @ 12:59
[…] in the video, it gets a bit more technical by using tools (AnalyzePESig and sigcheck) to check […]
Pingback by Video: Checking the Digital Signature of Windows Executables | Didier Stevens — Monday 6 January 2014 @ 4:09
Wonder tools. Thank you!
Comment by Anonymous — Tuesday 7 January 2014 @ 20:36
Really appreciate the tool listmodules. Could you add in a flag/option to send the output to a specified destination/folder?
Comment by Jacov — Sunday 30 March 2014 @ 3:50
@Jacov Did you try output redirection (> result.txt) ?
Comment by Didier Stevens — Sunday 30 March 2014 @ 10:02
Yes, I can redirect but I do not want to create the CSV file as redirection then creates 2 files.
Comment by Jacov — Sunday 30 March 2014 @ 16:15
@Jacov I see, I’ll add it to my todo list.
Comment by Didier Stevens — Friday 4 April 2014 @ 15:44
Not sure yet why, but when running your tool under the context of the Local System account in a windows 7 64-bit environment, the tool hangs. When I run it under the context of my own credentials (I have local admin rights), it completes successfully. Note that I am running it under the System account by creating a scheduled task in Windows. Not sure if you have ever tested this, but any insight you may have as to why it is hanging would be appreciated. I have tried this with other tools like those from sysinternals and it seems to work ok.
Comment by Jacov — Thursday 10 April 2014 @ 21:04
Is it me or doesn’t v3 work with .msi files anymore?
Comment by Anonymous — Sunday 11 May 2014 @ 10:15
Actually, I didn’t design AnalyzePESig to work with .msi files. In versions 0.0.1 and 0.0.2, it was a side-effect. But in version 0.0.3, I added many PE file checks,
and .msi is not a PE file.
Comment by Didier Stevens — Monday 12 May 2014 @ 21:04
Thanks for your reply (#15) Mr. Stevens, now I understand the messages about invalid signatures as well -> they’re simply not PE files 😉
I’ll also keep 0.0.2 then, the “side-effect” is -and works- great!
Comment by Anonymous — Thursday 15 May 2014 @ 15:56
I’ll try to make analysis of .msi possible again.
Comment by Didier Stevens — Friday 16 May 2014 @ 13:05
When enumerating process modules, the flag TH32CS_SNAPMODULE32 should be set like so:
hSnapshotModules = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32, sPE32.th32ProcessID);
Otherwise, 32-bit modules loaded into 64-bit processes will be missing from the list.
Comment by Jacob Gajek — Saturday 10 January 2015 @ 8:53
@Jacob Thanks for pointing this out.
I did some further testing, and the real issue is this: if you do not use flag TH32CS_SNAPMODULE32 in a 64-bit process when querying a 32-bit process, then you don’t get the 32-bit modules of the 32-bit process.
I fixed this, and will try to release the code this weekend.
Comment by Didier Stevens — Saturday 10 January 2015 @ 19:21
You’re right, I misread the MSDN documentation. It’s the calling process that is 64-bit, and the TH32CS_SNAPMODULE32 flag pertains to 32-bit processes and their 32-bit modules.
Comment by Jacob Gajek — Sunday 11 January 2015 @ 3:01
This is excellent. I went looking for something like this because I was trying to see if using /td SHA256 with signtool.exe when timestamping had any actual effect. AnalyzePESig shows me the signature getting larger by 16 bytes, so at least something is happening.
Comment by johndallman — Tuesday 3 November 2015 @ 17:24
[…] I released new versions of my AnalyzePESig and ListModules authenticode tools. […]
Pingback by Update: Authenticode Tools | Didier Stevens — Monday 30 November 2015 @ 0:00
Please excuse me, Didier Stevens.
Due to newly added secondary SHA-2 signatures, i.e. to Google Chrome installer and many others, could you please add display and analysis of signatures beyond the 1st?
Thank you.
Comment by IL — Tuesday 26 January 2016 @ 8:08
this is on my todo list
Comment by Didier Stevens — Tuesday 26 January 2016 @ 10:29
For: “The certificate type of the signature (should be 2).” is this class (IE Class 2 cert vice class 3?)
Comment by Jack — Wednesday 4 January 2017 @ 1:17
No, it’s not part of the certificate.
Comment by Didier Stevens — Monday 9 January 2017 @ 20:04
I’m confused. I’m looking at a file named “C:\Windows\System32\drivers\bxvbda.sys” from a Windows 7 box. Although “sigcheck” and “AnalyzePESig” both say that this file is unsigned, VirusTotal is claiming that it is signed? Why the difference?
https://www.virustotal.com/en/file/de011cb7aa4a2405faf21575182e0793a1d83dffc44e9a7864d59f3d51d8d580/analysis/1499374831/
Comment by Ace Pex — Thursday 6 July 2017 @ 22:01
The file does not contain a digital signature. It’s most likely signed via a catalog file. You don’t have that catalog file on the system you use to verify the signature, that’s why it’s reported as unsigned by Mark’s and my tool.
Virustotal has a collection of catalog files to verify signatures. More details: https://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/
Comment by Didier Stevens — Thursday 6 July 2017 @ 22:10
Perfect, many thanks! However, that now begs the question… where and how does one obtain the necessary security catalogs for files such as this, for placement in the “catroot” directory? I would like to be able to get various local tools (e.g., Mark’s and yours) to report that the file in question is in fact signed (via a CAT file). I tried searching for the answer to this question, but my Google foo is failing me at the moment.
Comment by Ace Pex — Monday 10 July 2017 @ 22:52
Actually looks like the “/a” switch of Microsoft’s “SignTool” utility does exactly what I was asking about above:
“/a –
Specifies that all methods can be used to verify the file. First, the catalog databases are searched to determine whether the file is signed in a catalog. If the file is not signed in any catalog, SignTool attempts to verify the file’s embedded signature. This option is recommended when verifying files that may or may not be signed in a catalog.”
Is there anyway you could incorporate an optional similar check into your “Autorunner” tool, so that signature verification will succeed for images that have been signed in a registered catalog?
Comment by Ace Pex — Tuesday 11 July 2017 @ 1:11
If a file has been digitally signed via the catalog file method, is any metadata attached to the signed file which then points to the name of .cat file that contains its signature? It seems like there must be some way to identify the associated .cat file, otherwise you’d have to iterate through all of the available .cat files on a system looking for said files’ signature.
Comment by Clint — Wednesday 2 August 2017 @ 23:05
No, there is no such metadata. Catalog files are stored in a repositoey on Windows, and you can use the Windows API to search through them.
Comment by Didier Stevens — Saturday 5 August 2017 @ 7:48
Interesting. So how does Windows efficiently figure out which specific .cat file (under \catroot) to look in when trying to find some random files signature? Does Windows really just brute force search through “all” of the available .cat files every single time it needs to do signature lookup? That just seems to me like it would be terribly inefficient and slow. Perhaps the Windows API contains a function that somehow efficiently identifies which specific .cat file to look in for an associated files signature? I’m just thinking that there’s gotta be a more optimal method than just iterating through all of the available .cat files, and if so, I’m just wondering how Windows does it.
Comment by Clint — Tuesday 8 August 2017 @ 21:51
The problem I’m running into lately is that when I’m running a triage process on an image file, I’m now often finding that many of the EXE’s and DLL’s in the image do not validate signature on my examiner machine, even though most of those files are in fact properly signed and unaltered. The reason is because these days most OS files are signed via the catalog file signing method, but the catalog files in which those file signatures are stored are not present on my local examiner machine. Rather they are often only present in the .cat files that are contained within the \catroot dir of the image that I’m processing.
As such, in order to validate many of the files in the image, I now need to copy the entire \catroot dir from the image, run a batch file to generate a list of those exported catalog (.cat) filenames along with their full paths, then use tools (e.g., signtool, sigcheck, or AnalyzePESig) to search through “each” of those exported .cat files in sequence (one at a time) looking for an individual specified files’ digital signature. It’s an extremely slow process, and takes several minutes per file that I need to check. Somehow Microsoft seems to do this type of signature lookup much much faster as long as a files associated .cat is already present in the \catroot dir on the local machine. Any idea how Microsoft is speeding up the .cat file signature lookup process?
Perchance could you add a switch to AnalyzePESig that would make it look in a given “directory” containing a bunch of .cat files for a signature, rather than having to tell it which specific .cat file to look in? That way I could avoid having to generate a list of the exported .cat files, and then having to call AnalyzePESig repeatedly as I iterate through each of them. Just a thought. Many thanks!
Comment by Clint Hastings — Monday 14 August 2017 @ 23:33
Maybe you can do that with signtool verify https://docs.microsoft.com/en-us/dotnet/framework/tools/signtool-exe
Comment by Didier Stevens — Wednesday 16 August 2017 @ 21:53
Hi Didier, in the past I’ve run a lot of tests, but as near as I can tell, when using “signtool verify” it will only accept individual .cat file names when using the /c parameter. You can’t seem to point it to a directory full of .cat files and have it go through each of those .cat files looking for a digital signature.
Interestingly, although it isn’t specified in the documentation, the SysInternals “sigcheck” tool will actually accept a directory name (containing .cat files) when using the “-f” parameter rather than just a single .cat filename, but it works EXTREMELY slowly when you do that. For some reason it is much much faster to just generate a list of .cat files, then repeatedly call “sigcheck -f” specifying each individual .cat filename as an argument rather than just supplying it with a directory name that contains the .cat files. In my testing using “sigcheck”, it was nearly 200% faster to use the second method that I described above.
Comment by Clint — Thursday 17 August 2017 @ 18:32
Actually I just checked my test notes… calling “sigcheck” repeatedly against a list of individual .cat file names was over 5000% faster than just pointing it at the name of the directory which contained those same .cat files.
Comment by Clint — Thursday 17 August 2017 @ 18:53
BTW, just to clarify, even the “faster” method of generating a list of the .cat files and sequentially iterating through each of them to find a files’ digital signature is still extremely slow overall. On average this “faster” process still takes me several minutes to complete for every individual file that I need to check / validate.
Comment by Clint — Monday 21 August 2017 @ 21:08
If I may ask: no support for multiple signatures? Many .exe files have dual signatures. One with sha1 certificate (for supporting Windows XP and old Windows server platforms) and second signature made with sha256 certificate. I can see that the tool shows all certs (form all signatures) but it is not as obvious.
But the tool is useful anyway.
Comment by Anonymous — Monday 15 January 2018 @ 19:58
It’s on my todo list.
Comment by Didier Stevens — Thursday 18 January 2018 @ 7:27
how do I use List Modules to verify signature of windows executables? As of now when I run list modules it is running for all the processes running on my system. Instead how do I execute it to run for just one filepath that I specify, for example I want to use it like listmodules.exe “C:\\windows\\system32\\cmd.exe” should return the signature of cmd.exe. Please do suggest some solution. I don’t want to use sigcheck because it is not open source
Comment by Gaurav — Thursday 14 November 2019 @ 6:53
You need my other tool for this: analyzepesig.
Comment by Didier Stevens — Thursday 14 November 2019 @ 17:24
Hy
I try to gennerate again AnalyzePESig (project Visual studio 2019) I have change version off visual studio (ok) i have download sdk to get signtool.exe (ok. I have copy signtool.exe to all object directcry project (ok)
I have that you have add a commande poste build (ok) . So when that coomad run the result is wrong (SignTool Error: No certificates were found that met all the given criteria.)
Tel met what append ?
Jean Bezet
Comment by Jean — Thursday 4 June 2020 @ 8:53
signtool is for code signing. If you want to sign your compiled exe, then you need a certificate. if you don’t want to sign it, then remove the signtool command.
Comment by Didier Stevens — Friday 5 June 2020 @ 8:44