Read Signature info of UM Application from inside the driver in KM

I need to read an executable’s digital certificate (name of signer) from inside a filter driver (in kernel mode).
I am searching for help for this task and unable to find a way to how to achieve this using KMDF.
Is it even possible to to do this in kernel mode.

Please help.

Is it possible? Of course. You can find the path to the executable file, then open the file, read the PE headers and parse them, find the certificate chain, figure out which certificate in the chain is the one you want, decode the certificate, figure out which field means something to you, and read it.

Is it going to be easy? No. Is it foolproof? No. A nefarious actor could delete the executable file after loading, leaving no trace. Why do you want to do this?

Or something much simpler like modifying the code bytes in memory after they have been loaded - then when you verify that the signature of the file on disk is valid, and agree to trust this process based on a valid certificate, you now trust the newly modified code.

This class of question: ‘I need to do x in kernel mode’, where x is trivial to do in user mode but not really supported in kernel mode, needs to first explain why using a user mode service cooperating with the kernel mode driver is not an acceptable solution.

While that it certainly true, in this case the validity of X is also a question. Wherever it may be verified from, a disk image may be perfectly ‘valid’. While the executing can be arbitrarily different. Normally, these differences are the result of the various loader fixups - dramatically reduced by the x64 instruction encoding and RVA but still required in some cases. Which means that you can’t check the cryptographic signature against the loaded memory image. And that means that so called security checks of this kind are at best useless

Is it even possible to to do this in kernel mode.
Yes, it’s possible but requires a huge amount of work and thorough testing.
All basic information is described in the following documents:

“Microsoft Portable Executable and Common Object File Format Specification”
RFC 2315 - “PKCS #7: Cryptographic Message Syntax Version 1.5”
RFC 5280 - “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”
RFC 5652 - “Cryptographic Message Syntax (CMS)”

It’s quite real to find WIN_CERTIFICATE array and then parse ASN.1 structures, but many things must be taken into account:
old WIN_CERTIFICATE revisions, invalid block length, T61String and other strings decoding, RFC822name, BER indefinite-length
encoding, double/triple signatures, etc. Also be ready to write many tricky test programs and use it with 100500 executable
files collected from different PC - this is the only way to ensure that your parsers work well.

Yes, but… The original poster hasn’t told us so, but I don’t think they want to be able to read EVERY file ever signed. They want to verify that the calling process is THEIR process. If they get something unexpected, they can just reject it.

1 Like

Still a useless check. Whatever magic combination of bytes get checked to determine that the caller is THEIR special process can be spoofed by any sufficiently privileged attacker - and if they are not privileged, then the usual ACL security will be just fine

Well, if attacker can run some spooky code that is not file-based (at least lives outside of the main executable file) then verifying the executable file is useless.
For example, a legitimate signed exe can load a hostile DLL or execute script from non-executable file.