Back in 2014, I explained two techniques that have been used by developers to store information in Authenticode-signed executables without breaking the signature.
Recently, Kevin Jones pointed out that Chrome’s signed installer differs on each download, as you can see in this file comparison of two copies of the Chrome installer, one downloaded from IE and one from Firefox:
Surprisingly, the Chrome installer is not using either unvalidated data-injection technique I wrote about previously.
So, what’s going on?
The Extra Certificate Technique
Fortunately, Kevin wrote an awesome tool for examining Authenticode signatures at a deep level: Authenticode Lint, which he describes in this blog post. Running his tool with the default options, the solution to our mystery is immediately revealed. The signing block contains an extra certificate named (literally) “Dummy Certificate”:
By running the tool with the -extract argument, we can view the extra (unsigned) certificate included in the signature block and see that it contains a proprietary data field with the per-instance data:
This technique for injecting unsigned data into a signature block could be a source of vulnerabilities unless you’re very careful; anyone using this Extra Certificate technique should follow the same best practices previously described for the Unvalidated Attributes technique.
Authenticode Lint is a great tool, and I strongly recommend that you use it to help ensure you’re following best-practices for Authenticode-signing. My favorite feature is that you can automate the tool to verify an entire folder tree of binaries. You can thus be confident that you’ve signed all of the expected files, and done so properly.
-Eric
text/plain 