I am working on a windows application. After creating the installer file i.e. MSI, it gets installed and works perfectly however, once i upload it on cloud server and try downloading it from there and install it, i get the warning message saying "Microsoft Defender Smart Screen Prevented an unrecognized app from starting. Running this app might put your PC at risk" (below screen).
Any help would be greatly appreciated!!!
You can just submit your software to Microsoft for malware analysis
https://www.microsoft.com/en-us/wdsi/filesubmission
Basically they scan the file, and establish reputation. It works even with Self-Signed Code certificates.
I have linked to an answer above. Might summarize quickly:
Digital Signature: You need an EV-Certificate to sign your setup to gain "trust outright" (Interesting concept?).
False Positive Check: Run your binary through false-positive detection by checking with multiple anti-virus software. This site is a great help: https://www.virustotal.com. Another one you can try is: https://opentip.kaspersky.com/ (Threat Intelligence Portal). For further resources, search for "malware" here: https://www.installdude.com/jumpgate.php
Flagged Downloaded File: You might also want to make sure the file is not flagged as downloaded from another computer:
Description of this file tagging feature here (point 2)
"This file is blocked because it came from another computer"
Please check the linked answer for more details (don't want to create too many similar answers - "dual source problem" - hard to keep updated): How to add publisher in Installshield 2018.
Related
I just made a small and simple windows form. I uploaded the .exe to mediafire so anyone could download it, but when someone(or even myself) tries to download it: windows defender instantly deletes it, because it thinks it is a virus. Is this a problem with the code or does it has to do with something else?
Hash it to check it was not modified
Check with some digest algorithm like SHA-2 that the file you download from the site is actually the exact same that you uploaded.
If it is not the same, something fishy has happened to your file when on a trip to the internet. I wouldn't try to open it, and try to find another service to host your file.
Sign your executable with a certificate
Invest in some code signing certificate.
Some are free, and for beginning and test pourposes you can create it yourself and self-sign it, but it will still be frowned upon by anti-malwares and your system.
Other comments
Also, some code operations are considered "dangerous" by some antivirus, because theese operations are much more oftne found in exploits attempts than in real commercial code. I remember, when I was playing with simple console C++ code while learning, I did some unsafe operation with a simple string char[]. On my school computer, the result executable was automatically deleted with the McAfee guard within seconds of compilation...
We're currently building an Outlook Add In that we package with a Click Once Installer and host on S3 with Cloud Front on top. In it's current state both the manifests and the bootstrapper (setup.exe) have been signed with an authenticode cert from Globalsign. Despite this, several customers have reported that the setup application has been flagged as a virus by Norton (among other products). My question, are there best practices regarding code signing and distribution of Click Once packages that will help mitigate this risk? I've contacted Symantec and so far the only solution they can give me is submitting a whitelist request for every version update we do to the product. Obviously not ideal as it requires users to have the latest whitelists and slows down our delivery of new functionality significantly.
I've also noticed cases where .dll files get flagged as suspicious. I'm looking into signing the assembly files now.
Any help, experience, or anecdotes related to this situation would be supremely helpful. Thanks!
The digital signature doesn't protect anybody/anything from viruses. It is used to confirm that the package comes from a trusted vendor (i.e. confirms your identity). But viruses and other malware is another subject. I'd suggest working with Symantec to produce more suitable solution or try to use any other antivirus software. They can also detect viruses as well (if any).
Reposting from http://www.mentalis.org/forum/thread.qpx/971 because I need an answer. I hope you guys can help me out.
The component in question is Org.Mentalis.SecurityServices.dll.
Hey all. I'm having troubles.
CryptographicException: Couldn't acquire crypto service provider context.
StackTrace:
at Org.Mentalis.SecurityServices.Cryptography.CryptoHandle.CreateInternalHandle(IntPtr handle, String container)
at ORG.Mentalis.SecurityServices.Cryptography.CryptoHandle.get_Handle()
at Org.Mentalis.SecurityServices.Cryptography.RC4CryptoServiceProvider.ctor()
at <place in my app where I try to create the RC4 CryptoServiceProvider>
I had to copy that exception trace by hand, from a screenshot sent to me by a client.
Essentially, I have created a .NET 3.5 WinForms application for XP that uses the RC4CryptoServiceProvider to load encrypted user details from an .ini file on startup. It's worked fine for months.
About a week ago, I got this exact exception message on my computer. I did some hunting online, but couldn't find much - everything I found was related to websites.
I eventually stumbled on a workaround that got things working on my computer. When I deleted the files from the following three folders:
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys\
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\token\
C:\Documents and Settings\my_username\Application Data\Microsoft\Crypto\RSA\token\
The problem went away. The folders re-populated with new information the next time I ran the application.
I had thought this was just something unique to my own development environment - that I had downloaded something weird that corrupted my cryptographic files and folders. It's not a field in which I am an expert - I just use the component, and it Just Works. Well... Up until now.
The problem is, one of my company's clients has just recently started experiencing the same error, and I'm not comfortable asking them to just clear out their Crypto files without being able to justify why. Also, it would seem that this wasn't due to something odd that I downloaded, as this exception is arising on a series of commercial Terminal Servers.
I've been looking around for support on this issue, but I'm not having much luck. I'll keep looking around. Can anyone out there shed some light on the situation?
Thanks for your time.
Do you know if your clients have the CSPs installed on their computer? Older versions of Windows won't have certain CSPs installed. It's also possible that they're running a foreign version of Windows that doesn't support strong cryptography (I'm thinking the French version might not be allowed to have all of them.)
Another possibility might be permissions. Maybe the process running the code is no longer running with administrative authority, or the authority associated with your account changed.
The Mentalis library should really be setting the CRYPT_VERIFYCONTEXT flag when calling CryptAcquireContext. Since they are not, each instance of RC4CryptoServiceProvider creates a handle to the default persistent key container (which is stored in the file you located with procmon).
Are you creating keys in multiple threads (or from multiple processes)? A wild guess would be that you are having some problems with locking of the file.
What would be the Most secure and Safe way to allow software to auto-update without opening too many holes to enable a hacker easy access to a system?
Have you looked into ClickOnce Deployment?
http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx
The short overview is here:
http://msdn.microsoft.com/en-us/library/142dbbz4(VS.80).aspx
I recommend not building your own auto-update, use ClickOnce if it works for you or a commercial auto-update component if not.
If you want to see what is involved I wrote a series about writing an auto-update component on my blog some time ago, the last post with links to all the posts in the series is at: http://www.nbdtech.com/blog/archive/2007/08/07/How-To-Write-an-Automatic-Update-System-Part-8.aspx
If you are going to make your own system then you will probably want to have a public/private key pair.
So, you would zip up the update.
Then encrypt with the private key on the server.
The client can then decrypt and unzip it, and then install it.
That way, as long as your private key is secure then you can ensure that the update is legit.
The only weakness here is that if someone changed the public key to some other key, then they could fool that program into thinking that a trojan is a valid update.
There are various schemes you can use to get around this, but that would depend on how much work you want to put into this.
ClickOnce auto update is all fair and well but anyone can admit that it is not the most of fashionable solution. I've recently developed a solution that requires such an auto-update feature. Here is a list of brief steps I took to deploying my very own updating service that also allows for roll-backs with 'minimal' know-how.
Add a Setup project to the solution so that the project could be wrapped up neatly in a .exe or .msi installer package.
The following is to setup a FTP server with your desired user credential that only your application knows. On the ftp server, setup a default directory for where you will put any new updates.
Your application will check for internet connection on start-up, log into your remote FTP server and check for any new files to download.
Download new updates to your client application and put them in a date-time named folder for future reference. Some checks need to be in place to make sure that you don't download the same old files.
Close the application and run the new installation. Depending on how you setup your Setup project, the installation wizard may remove the previous version completely or just update partial (patches, etc.).
Your application may have a feature to roll-back to previous version by going into the local update directory and fish out the previously downloaded files. This is where the date-time stamped files come in handy for reference.
This solution offers a level of customization that I think most Enterprise solutions will need and I found that it works very effectively for me. FTP servers are secure and reliable as far as file downloads are involved. You can find a lot of FTP download helper library on the internet so its a matter of making work the way you want and not worry too much about how it works.
When a user installs my application how do I keep User Account Control from producing this dialog? And no I don't want to tell them to disable UAC.
(source: netron.com)
You'd need to design your installation such that it doesn't require administrative access to install, which essentially means that you'll need to install inside the user's home directory instead of ProgramFilesDir and write registry entries only to HKEY_CURRENT_USER. For more details on how do this with a .MSI package, see this article. Inno Setup also has some details on limited user installs.
I don't think Visual Studio's setup project builder is capable of producing packages that don't require administrator rights to install. In any case, Vista seems to assume that anything that looks like a Setup.exe needs elevation (and results in the prompt).
Code signing will not remove the prompt, it will only make it say "Program XYZ from Developer Name wants access to your computer" instead of "An unknown program wants access to your computer".
You need a code signing digital certificate from a certificate authority like Comodo or VeriSign. It's debatable how useful it is, though, because it only replaces this scary-looking warning with a slightly less scary warning (yellow alert vs red alert) that says "Publisher: " instead of "Unidentified Publisher" and still tells the user only to run it if they trust you.
I'm somewhat doubtful that the average user really notices the difference between the two warnings.
Your application would need to be certified by microsoft.
User Account Control, as it says at the bottom of the dialog, but you don't want to do. No other way. Either that or get it signed/certified? :)