Yesterday we introduced the need to sign program modules for AutoCAD 2016. Today we’re going to see how AutoCAD behaves when loading signed and unsigned modules, as well as what the innards of a signed LISP module look like.
Here’s a simple piece of AutoLISP code that I’ve placed in a file called c:/temp/MyModule.lsp:
(defun c:test()
(princ "\nThis is a test command.")
(princ)
)
Here’s what AutoCAD displays when we try to load this module:
We can use AcSignApply.exe to sign this module with our digital certificate, as we discussed yesterday:
Here are the contents of the file once it has been signed:
(defun c:test()
(princ "\nThis is a test command.")
(princ)
)
;;;-----BEGIN-SIGNATURE-----
;;; awUAADCCBWcGCSqGSIb3DQEHAqCCBVgwggVUAgEBMQ8wDQYJKoZIhvcNAQEFBQAw
;;; CwYJKoZIhvcNAQcBoIIDATCCAv0wggHloAMCAQICEBENNIof/K6LQXlK3euL2qUw
;;; DQYJKoZIhvcNAQEFBQAwEjEQMA4GA1UEAxMHd2FsbXNsazAgFw0xMTA2MjkwNzI1
;;; MTdaGA8yMTExMDYwNTA3MjUxN1owEjEQMA4GA1UEAxMHd2FsbXNsazCCASIwDQYJ
;;; KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOHaTSHh3lEysSuRgYt0eilDszvLn9ez
;;; WLHm2XNrmqfkCDM2bx3YeELKmcavXY7JUTEWzpcfsHDFjHQMJZ4MbdN4y+pj8s/9
;;; 9CLUZ8X6GdU7ZeliBMFYGmn/G1PgI7D7imwZn3yHNehqztMxO3Ng9llSBc7QW8sM
;;; XnK83BS2HdJwdCO60T1XKnLo6IqpCjYwgGwdB9Vq0EGAGsvAzg8S4sjqo4NbIpXr
;;; VkED/1QLMKyk5xOxG3Uo4Wuf3AzaopDrWgdEAs1czNSSGMhLDqyfiS2nDXL2cACL
;;; qFn2ln/cj6PDwztgvXNh6ro72vl5/FmT0tU7VuQKHr4UYfKFv5pGYHcCAwEAAaNN
;;; MEswFQYDVR0lBA4wDAYKKwYBBAGCNwoDBDAnBgNVHREEIDAeoBwGCisGAQQBgjcU
;;; AgOgDgwMd2FsbXNsa0BBRFMAMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEB
;;; AEroAr+Kwf9LSqh0mdDq7//eY0fVv7rSnCyjZJn2wrX75HVuWv1Yaltowa0wvdS6
;;; +E9Jt/O0VyAXcQQnKMD8cPnRD4XsAxHBdv02mlpPBKAJQTEpNlfpRK/OB7ViuPmB
;;; V/IhCsMTIDrl8cIjrPVCFfJzH19ynjOKrmiZ36/5TUkhwafxF/I67nMNp8xJLnzp
;;; ueZJTg+DJ4sARwQx0I6xGooqPP+3K+I32poXclLq2xyiD1lQAlusBgdRpLyQGztM
;;; n65jUBC5UAQsCpfWLZEvwMZ4s/pBVYItxQvguwVJuiNteQ30/8UolyFdsNToUoWH
;;; SbypkUHgeGt3kddzndVYP9sxggIqMIICJgIBATAmMBIxEDAOBgNVBAMTB3dhbG1z
;;; bGsCEBENNIof/K6LQXlK3euL2qUwDQYJKoZIhvcNAQEFBQAwDQYJKoZIhvcNAQEB
;;; BQAEggEAljG2hxJiepuetcU2B0hP//TNKrk888ImhxOggB9sU0duZtSrBdfX25VQ
;;; lBtxlXZzKYkb+ob7+vFFTLY9hsVugzAzsJH2Bz1Ow6N1zidG4SJkxK2+In65ANTQ
;;; KB7yx9T///hFP/FS2PM+ZKe9G4pDnZ6Xz2dM2+CQUZjb8hZDZJjTCEjnODEve0F/
;;; Y2g+2tajS6tjtqa++bGTaDkvqeQyB7mGKHYtEDYcHyJz/DmjjTFvgcb+H4JaOfy6
;;; Nib24lLU661pIspuaD1do4yjoRkXhqaOIR2Rc4bNg4Y6F42LWw4E9zzkRpAsqreu
;;; 0CMm73m3NpsJFDkxuwG8gSq5IYeJl6GB1jCB0wYDVR0OMYHLBIHINQA3ADsANQAv
;;; ADIAOAAvADIAMAAxADUALwAxADYALwA1AC8AMwA0AC8AVABpAG0AZQAgAGYAcgBv
;;; AG0AIAB0AGgAaQBzACAAYwBvAG0AcAB1AHQAZQByACAAKABOAEUAVQBLAEUAVwBB
;;; AE4AQgAxADAALQAyACkAUwBpAGcAbgBlAGQAIABmAG8AcgAgACIAVABoAHIAbwB1
;;; AGcAaAAgAHQAaABlACAASQBuAHQAZQByAGYAYQBjAGUAIgAgAHAAbwBzAHQAAAA=
;;; AA==
;;; -----END-SIGNATURE-----
The digital signature has essentially been encoded in plain text and appended to the file's contents. Now let’s see what AutoCAD says when we attempt to load this newly signed module:
As this module was not found in one of our “trusted locations”, we do still get a message, despite its being signed. So there are a couple of important things, here…
Firstly, we need to consider whether the module should be in a trusted location. The locations that are trusted implicitly by AutoCAD are:
- C:\Program Files\Autodesk\ApplicationPlugins
- C:\Program Files (x86)\Autodesk\ApplicationPlugins
- C:\Program Files\Autodesk\AutoCAD 2016 (or wherever AutoCAD is installed to)
This is a change from prior versions, where an ApplicationPlugins folder under the current user’s (and all users’) application data was also trusted. We realised this was actually a bad idea and so removed automatic trust for such folders in 2016.
It has previously been suggested that applications should append their installation folder to the TRUSTEDPATHS system variable (or the Registry entry in which it is stored), but this is actually not such a good idea: this setting is really intended for users and CAD managers to control what is considered trusted. If applications start writing to it, behind the scenes, then bad things could happen. So you should expect access to this system variable to become more controlled, over time.
This means that to trust an application based on its location, you can either place your application in AutoCAD’s install folder – its sub-directories are also trusted, by the way – or in a trusted ApplicationPlugins folder/sub-folder. This latter option is intended for applications in the Autoloader bundle format, but also works for non-Autoloader applications. While not ideal from a logical perspective, if applications don’t contain a valid XML manifest then they simply won’t get loaded by the Autoloader.
The good news is that if an application module was signed using a trusted digital certificate, then it doesn’t matter if it’s in a trusted location or not*. Which takes us to our next point…
[* It’s also worth noting that the inverse is true: modules found in trusted locations don’t have their digital signatures checked by AutoCAD, as they get trusted automatically.]
Secondly, it’s possible for modules signed with a particular digital certificate to be trusted. If the “Always trust applications from” option is selected, that’s what happens: the user won’t be asked the question for any other application modules, or when the module is loaded in future. Checking this option results in the digital certificate being added to the Windows certificate store.
If you launch certmgr.msc, you’ll see the contents of this store on your system:
It’s possible to add this certificate to the store at install time, even though MSI doesn’t support it directly. Over on the ADN DevBlog, Madhukar has described a number of options for achieving this using a custom action, from calling the certutil.exe to using the Microsoft CryptoAPI from C# or C++. I haven’t yet had to do this, myself, but it seems that adding this certificate on installation isn’t unreasonable.
Conclusion
Now is a really good time to start signing your program modules. This will allow AutoCAD to inform your users in case your application gets tampered with by a malicious process (or person!). Once you’ve signed your modules, you can either have your digital certificate added to the certificate store at install time or the first time one of your modules is loaded (documenting this manual step is clearly an option, if you’d rather make the trusting of your application an explicit user action).
You might also rely on the trusted locations mechanism, by installing to AutoCAD’s program files folder or to ApplicationPlugins. Signing modules is a good idea, irrespective of where they get installed to, so my own preference would be to follow that path.
That’s it for this series, unless someone raises some concerns that haven’t been addressed by these two posts. On Monday I’m planning to unveil a new look for this blog, so get your mobile devices ready… :-)
Update:
I’ve been told (thanks, George!) of the existence of a command-line tool for signing AutoLISP modules. This is clearly helpful when integrating digital signing into your build process.
Appendix
- Product documentation
- About Digitally Signing Custom Program Files
- About Digital Signatures for Executable Files
- About Loading A Digitally Signed Custom Program File
- To Make a Digital Certificate
- To Create A Personal Information Exchange (PFX) File
- To Import a Digital Certificate
- To Digitally Sign an AutoLISP File
- To Digitally Sign a Binary (ObjectARX or Managed .NET) File
- To Digitally Sign a Binary (ObjectARX or Managed .NET) File with a Post-Build Event in Microsoft Visual Studio
- ADN DevBlog
- Dieter Schlaepfer’s posts on Lynn Allen’s blog