This question already has answers here:
How can I stop my installer from triggering Windows 10's "This app has been blocked for your protection" error?
(2 answers)
Closed 3 years ago.
I am new to windows development. I packed my project into a msi setup to install on other systems but when I open the msi in any system it shows a warning as attached . How can I remove this warning?
Note: Be sure to check if your organization already has an EV-level certificate? Just a few emails or phone calls might be wise before trying to research the purchase process?
Trust & Reputation: What you really need is an EV code-signing certificate. Microsoft's SmartScreen feature
in Windows (which is what you see with that blue prompt) is a
reputation-based system where unknown binaries are flagged as unsafe until they are validated safe by users in actual use.
Virustotal.com: An EV code-signing certificate "buys trust outright" - interesting concept - and should allow your users to not see such a prompt even for brand new binaries. Make sure to check all your binaries using virustotal.com though, as many malware-scanner detections can trigger a resurged smartscreen warning for any binary - which is what it is for (signed malware is still malware).
False Positives: False positives for malware is a huge problem since you have to deal with it and solve it, and you can't just tell your users to rebuild their PC and try again.
Moral: The moral of the story is to use Virustotal.com to test for both malware and false positives in your binaries and files for distribution, and to use an EV-level certificate for serious software distribution to get trust for your binaries outright (without delay). An EV-level certificate is not a silver bullet. Problems can still be seen. Trust can be lost too, not just gained (trust... hard to earn, easy to lose).
Tip: A properly signed MSI will also show up with the correct name in the UAC prompt: Installshield Custom Dialogue Installer (see screen shot and then the answer a bit down the page).
The Far Side Perspective: "Be sure that your setup is malware free or an applied digital certificate is proof positive that you delivered the malware" (until that is hackable too) :-)
We do our best.
Link:
How to protect MSI against modification (on malware and false positives - recommended)
How to add publisher in Installshield 2018
How to pass the Windows Defender SmartScreen Protection?
Related
On WPF installer project build generates setup.exe and it is being signed using Signtool on PostBuldEvent. It does show Publisher as unknown on UAC popup at the very last step of setup.exe.
Can someone help me to fix this ?
MSI vs Setup.exe: You should sign the MSI file as well as the Setup.exe file.
Certificate Type: What kind of certificate are you using? I believe you need a digital code-signing certificate from a recognized issuing authority (DigiCert, Thawte, etc...).
EV-code signing certificate (please visit this link).
Why do I still see publisher unknown with the UAC prompt?
Get a code signing certificate
Signtool.exe: If you have a valid certificate, are you using the /d option to the command line of signtool.exe when signing your MSI?:
signtool.exe /d "Your Software Name"
How to add publisher in Installshield 2018
Trust Yet Verify: When you have signed the file, right click it and select "Properties" to make sure the file is actually successfully signed. Look for the tab "Digital Signatures" (or equivalent in your own language):
Administrative Installation: Sometimes people forget that they have run an MSI through an administrative installation. This is essentially a file extract from the MSI resulting in a new MSI without the embedded CABs in the output location (more). This extracted MSI will not be signed - even if the original MSI was signed. This extracted source is used in many companies to keep the installation files on a networks share available for repair and inspection (and during application packaging to inspect the package content - and other purposes).
Post-Processing MSI: This is actually a very common issue: you must never touch a file that has been digitally signed. If you edit it after the signature has been applied this invalidates the signature. The whole point of digital signatures is to verify that the file you look at is the one that was signed by the vendor. In other words that the file has not been changed in transit to you (tampering, malware infection, etc...). More on this important issue here (attempted humor in there). Note that the tampering might happen via automation scripts and not by manual editing, hence one must always check for this cause.
Other Issues: There are also some other possibilities. The signed file could be corrupted during download or from malware attack and such things. Far beyond the question, but just mentioned for whoever might find this.
Links:
Is it possible to define a Windows Installer-uninstaller filename?
Installshield Custom Dialogue Installer
How can i generate windows certificate so my msi doesn't shows warning to users
Further Links:
Windows printscreen not working on Software Installation
WIX-Installer MSI Publisher Unknown
Everything you need to know about Authenticode Code Signing
I would like to be able to sign my code, mainly just so windows defender won't complain about it on other computers but it needs to be signed nonetheless.
Convienently, visual studio provides an easy way to do that! Unless you're me...
https://i.stack.imgur.com/Ym2LM.png
The sign the click one manifests thing is unavaliable, and the sign the assembly, well, when I create a password key, well, lets just say it makes major uncircumventable roadblocks.
So my question is -
How can I sign my windows forms app, and why is what I would assume to be the tradional method greyed out?d
As far as I know/gotten-to signing software requires a x.509 certificate. I've never bought one or an SSL certificate for serving HTTPS, but I'm assuming they are similar, so maybe you can buy them at the same place...?
I just posted the Microsoft link Add an exclusion to Windows Security, it's the best I can do right now.
Trying to get a ClickOnce application to work correctly, but I keep encountering the "Trust Not Granted" exceptions, and I'm not yet seeing why this is happening.
The EXE is signed with a code signing certificate from VeriSign, both by setting the "Sign the ClickOnce manifests" option in the Signing tab, as well as implementing the pre-publish approach metioned here: http://robindotnet.wordpress.com/2013/02/24/windows-8-and-clickonce-the-definitive-answer-2/ . I have verified that the certificate is installed on the client machine correctly. I have verified that my EXE is signed after the build as well.
I have taken the same approach with setting explicit trusts as this StackOverflow answer: https://stackoverflow.com/a/16816341/97879
I am presently deploying to a network share, and that is the expected path for updates until we're prepared to take this application to production.
My application can see that there is an update available, but then fails when trying to update. This happens the same way on both Windows 7 and 8 machines.
What am I missing?
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)
I have a .NET winform application that requires to register a native dll during installation. My question is how can I register a dll (regsvr32 ABC.dll) as part of MSI installion process? Similary how can I un-register a dll as part of un-installation process?
Nice answer from Chris Painter, adding for reference: how to register DLL's properly in wix 3.9. And one with WiX-focus: Registering COM EXE with WIX.
Self-Registration considered harmful
The proper way to register a COM file is to extract the COM registry information from the file and add to the appropriate family of COM tables in the MSI. Most MSI tools have features to support this COM extraction, see separate section towards the end of the answer for details.
This MSI SDK article lists several variations on the general issues with self registration described below, as well as describing some further details - particularly with regards to per-user registration of COM data, and run-from-source scenarios.
Extracted COM data will ensure reliable installation of your COM server as well as support for advanced MSI features such as "advertisement", "rollback", resiliency and "elevated privileges". You can read more about these advanced MSI benefits in this summary that has become somewhat popular on serverfault.com: corporate benefits of MSI.
It is also possible to use the built-in SelfReg table in Windows installer to register the file using regsvr32.exe as part of the installation process (or even invoked as a custom action), but this is considered bad practice for a number of reasons:
Rollback: Windows Installer is unable to properly handle rollback unless the COM data is extracted and embedded in the MSI. The result is that a failed setup may not clean up its COM footprint correctly and the MSI does not put the machine back in the original state properly. The rollback of COM data really does work like "auto-magic" tracking every change in the registry whether it be addition, modification or deletion and is reliable when done right.
Security: The self registration process of a COM server may in certain cases perform unorthodox tasks such as modifying the system's network settings or perform other crazy maneuvers that have nothing to do with COM and are hard to identify and debug. I have personally seen, in disbelief I might add, COM registration change system-wide network settings without any warning, and for no obvious reason. It might have been just an optimization for an application, but this is rarely acceptable when it changes the whole system affecting all other software. Though an EXE file run in admin mode can do the same and be equally faulty, self-registration may go under the radar and be less obvious as a security issue. This is a core reason why large corporations and Microsoft best practices insist on not allowing self-registration as it may interfere with business critical systems.
Chained dependencies: Some COM files may need to be registered in a specific order on the system to register successfully. In other words file B can't register until file A has been registered. I have honestly never seen this in real life, but it is technically possible, and I have seen dependencies on language dlls (resource only dlls) cause COM extraction to fail. Though slightly different, it is still a dependency issue. MSI does not allow specification of the registration order (probably due to the database origin of MSI, rows are unordered). If you extract the registry data properly on the build computer and put it into the MSI, these chained dependencies will not cause an application error.
Permission problems: Windows Installer has advanced features to elevate the privilege level of the user installing the MSI to allow all information to be registered without permission problems (no messing about with temporary admin rights). If you use the SelfReg table you are more likely to run into registration problems caused by permission or privilege peculiarities on the local system (in my experience this is particularly evident for self-repair operations). Permission problems like these occur more and more as new versions of Windows steadily put new obstacles in place for the successful deployment of software (UAC prompts, self-repair lockdown, impersonation changes etc...).
Resiliency: If another application destroys your COM registry entries, the COM data embedded in your MSI will reinstall the COM component with all associated registry entries via self-repair if proper COM extraction is used to make the package. This means that your application should always be able to launch with its COM servers properly registered. However, this can also trigger the dreaded repetitive sequence of self repair cycles that many experienced computer users have seen (here is a simpler and shorter explanation). In other words COM extraction can be riddled with problems as well, but just using self-registration would leave your application broken, and also prone to security errors being triggered if you run repair, modify or self-repair of your product (the self registration operation may run without elevated rights and hence fail to complete if the repair is run as a restricted user). This means the errors are impossible to fix for most normal users. It is all they know how to do if the product isn't working.
Advertisement: Advertised products are available to the user via shortcuts and registry entries, but not presently installed on the machine. An "on demand" installation can be invoked in a handful of ways - referred to as advertised entry points (recommended Symantec article), one of which is the invocation of an advertised COM server. No install will be triggered unless the file is properly advertised in the registry and a crucial trigger of "self repair" is hence missing if you use self-registration.
Installation Tool Support for COM Registration
The extraction of COM data and entry into MSI tables is a fairly involved task, and most tools on the market such as Installshield, Advanced Installer, and Wise (Wise is now off-market, unfortunately) have automated solutions for this.
In Installshield you simply enable a component flag called "Extract COM data on build", and Wise has a similar flag on the component level. WiX can extract the COM registry data using a tool called heat.exe and the generated WiX-code can be inserted into your source WiX file (there may be new features for this by now that I am not aware of). I am not aware of any features in Visual Studio that will extract the COM data automatically, but it looks like Chris Painter provides a possibility in his answer.
Check out RegSpy2 if Heat doesn't work for you (Phil Wilson - the author of "The Definitive Guide to Windows Installer" wrote RegSpy and someone extended it to RegSpy2). Also check this: Register ActiveX exe server using WiX (my answer towards the bottom for regspy.exe command line use).
Erroneous COM data inserted into an MSI - particularly for repackaged applications in corporate environments - is one of the leading causes of "unexpected cyclical self-repair". Please see this long article for explanation of this issue: How can I determine what causes repeated Windows Installer self-repair? (bullet point 3 in section "Some typical self-repair problem scenarios" describes this issue).
Several other installation tools exist with similar extraction features: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
vsdrfCOMSelfReg is not a best practice. Try vsdrfCOM instead. This will "extract" ( or try, vdproj is a POS sometimes ) the COM metadata from the DLL and author it into the correct COM tables. This is better then hoping an out of process call to DllRegisterServer will work at install time.
Now that MSI is natively aware of your COM resources, it will handle install and uninstall for you.
Scroll down to Rule 19 in the Tao of Windows Installer to see what the MSI team said:
Using the self-registering capabilities of certain DLLs is highly discouraged. Any activity performed by the self-registration (e.g. addition of registry entries) is out of the control of the Installer, so cannot be part of advertisement, repair and is not removed on uninstall. Instead you should have the Installer manage the data for you by using the appropriate tables in the MSI database.
Select the file you want to register and in the Properties window set the Register field to vsdrfCOMSelfReg. This will author an entry in the SelfReg table which will automatically register / un-register your DLL.
http://msdn.microsoft.com/en-us/library/aa371608(VS.85).aspx