How to protect MSI against modification

Question

I would like to protect the MSI file against modification. It could be easily done with ORCA or with MSI API. It is sad because anyone can modify/add/remove windows installe

Answer 1

Short Answer: You can't really protect it, and you shouldn't either, and the below tries to explain why. You can, however, sign the MSI with a digital certificate in order to ensure the file is unchanged in transit to the customer, hence protecting file integrity and facilitating better security.

---

Transparency: MSI files are transparent for a reason - corporate application packagers want to be able to modify the package to fit corporate standards. This transparency is in fact a core advantage of MSI. As such I wouldn't work to protect the MSI. Compiled custom actions are still "black box" (not inspectable, but they can be disabled).

Documentation & Comments: If your MSI has custom actions that are critical, you can indicate this with "inline" comments in the MSI, or perhaps in the name assigned to the custom action. You can also deliver a one page PDF file (call it Large Scale Deployment Guide.pdf?) along with your setup where you describe how to best deploy your application - and crucially what not to do with the MSI. I prefer to embed this document in the MSI so it comes out with an administrative installation - which is MSI's file extraction mechanism - for the packager to see. The first thing a corporate packager generally does is extract the files from the MSI using an admin installation.

Digital Signatures: As has been mentioned by others a digital signature (details from Advanced Installer, details from Installshield) helps to ensure the MSI is unchanged on delivery to customers. This is obviously of major importance security-wise. This is even more of an issue with new features such as SmartScreen (reputation-based security - an EV code-signing certificate "buys trust" - interesting concept? Who smells a racket? :-) ). Be sure that your setup is malware free or a digital certificate is proof positive that you delivered the malware (until that is hackable too). And speak of the.... Hmmm.

Malware Detection: Remember that it is also necessary to deal with false positives. The online tools with file upload are great for testing this. File size upload limits apply. Just a couple of links:

• https://www.virustotal.com (scans using a number of malware scanning suites)
• https://virusdesk.kaspersky.com (major anti-virus vendor)

A tool such as Process Explorer from SysInternals also makes it possible to scan for malware processes by running your application and then selecting Options => VirusTotal.com => Check VirusTotal.com. Video tutorial here (I didn't look too much at it, not familiar with the other products discussed). Use this method to save your application from false-positive nightmares (and also for real malware infections of course).

Application Launch: If you have something you need to run for sure, you could potentially add it to your application launch sequence instead of your setup. This definitely works if you don't need admin rights. If you need to write something to HKLM you can open ACL write access there for regular users - not ideal at all, but possible. Application launch code is just easier to deal with. Easier to debug and no impersonation, sequencing and conditioning concerns (when action runs) like you have in a setup.

Legacy Setup.exe: If you insist on doing "secret stuff" in your setup, then you could use a legacy tool to make a regular setup.exe (not an MSI). Be aware that with tightening security scans and malware detection your setup could be even more prone to the problem of false positives for malware detection. A very serious bump in the road for selling software. With real malware you tell the customer to rebuild the PC, with false positive you have to do something to fix the problem. Corporate acceptance could also depend on MSI format or other inspectable formats ("that is our standard"). And you should be aware that capture tools in corporate settings will see what the setup did in detail as they convert it to MSI (or other formats these days for example AppV and MSIX).

And one more issue thrown in: Cross platform installers.

Answer 2

The short answer is no, you cannot prevent someone from editing a .msi file. There are various approaches you can take to minimize the likelihood of someone doing so, or approaches that increase the difficulties associated with any edit, but you cannot fully prevent it.

To answer this better, one must refine the question you are asking. "Protect" sounds like a security sort of question, so it helps to establish at least an armchair threat model. For instance, here are three things you may be trying to prevent:

1. an interested user altering the bits that are installed to that user's system
2. a corporate user modifying what his system administrators install to the user's machine
3. a malicious party altering and providing bits masquerading as your app that someone else mistakenly installs

Of those three, the first isn't really a security boundary, so there's not much you can do. Either it's an install that requires administrative privileges and the user has them, or it's a per-user install that allows users without administrative privileges to use it. In either case, the .msi has no more access to the system than the user who altered it already had.

The second crosses a boundary, but involves someone who should be diligent about verifying signatures, and may likely acquire the installation from the source instead of the user. The third is a clear security concern, and unfortunately involves people you cannot reliably expect to be diligent about verifying signatures.

So what can you do?

• You can sign the .msi file. This leaves indications that the file was altered, if it was. Note that transforms (.mst files) can alter what the .msi does without altering the file itself; however this also affects the representation of the signed status.
• You can try to educate your prospective users about the importance of verifying the digital signature before accepting a UAC prompt. This won't stop someone who's trying to subvert your licensing, but may help someone avoid installing malware instead of your actual program.
• You can wrap the .msi in a signed .exe bootstrap. This makes things harder to access; attempts to use the normal tooling won't work directly, and instead require the altering party to figure out how to extract the .msi file. While that's typically not very difficult, it's at least another hurdle.
• You can try to inject signature verifications into the .msi file. As you say, these are likely to be easy to defeat by further alterations to the .msi file, unless you can couple them with important and hard to duplicate other code. That, of course, merely makes it harder to alter; but not impossible. Again you'll have to consider the .mst case, and whether you want to support administrative installations and installations from those caches.
• You can add relevant signature or other verifications to the app itself. If the .msi file is altered, but it doesn't alter what is installed to the machine, does your app care? The answer depends on what exactly you're trying to protect against; for instance it won't help prevent tag-along malware.
• Consider other packaging or deployment options, whether from Microsoft (like .appx / .msix) or from third parties. Each comes with their own set of advantages and disadvantages, and their own level of susceptibility to each thing I've discussed here.
• Run your app somewhere else; for example, rewrite your app as a web application so that there is no installation. Obviously this can only work for certain kinds of applications, but that list continues to grow.

What you can't do?

• Make all users pay enough attention
• Prevent a malicious party from creating an installer that pretends to be for your app but has only a malicious payload
• Prevent a machine's owner from altering the machine either before or after the .msi runs
• Support all of the ways people use .msi files without just using a .msi file (administrative installs, transforms, "repackaging", various .msi-specific deployment utilities, etc. are all normal use patterns for certain classes of software)

At the end of this exercise, you'll have to decide whether this is a deal breaker for you, or something you can accept. Make sure you understand why someone would want to alter your .msi file, and before focusing on the .msi file itself, consider whether they can have the same effect through non-.msi means. If it's specific to .msi and is a deal breaker, look into other installation technologies. If nothing can prevent the scenario you seek to prevent, perhaps you can find ways to reduce the incentive for people to attempt it.