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.
Related
I'm creating a firmware update application (in C#, WPF, MVVM, .Net version still up in the air, but I hope to run it on Windows and Mac) that will allow the user to check for updates to both the application itself and for the latest firmware. I plan to use the common method of putting a file on a server that contains the latest version number and a URL to the files. The application will download the file, compare the versions in the file with the local versions, and download the latest files and/or update the application. Universally lacking in the 'how to's' of this method is the topic of security.
My initial thought was to put the "current version file" in a password protected secret folder, but then that seems overkill for a simple XML file. And since the user will be able to download the app from the website anyway, hiding/password protecting the URL to the application seems pointless. Even the firmware, being a binary file running on custom hardware, at first thought seems rather benign from a security perspective. But then again, I don't spend my days thinking of how to hack into systems.
So, in regards to just the process described above, what kinds of security measures should be taken to protect the server, data and user from attacks? And potentially as a bonus question, what security measures can be taken to protect the application update itself? With this, I can at least see the potential to trick the updater into installing malicious code, so a checksum to verify the updated file's integrity would be a minimum there.
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.
The Problem:
We have a software-project coded in C#/.Net with report functions builded on Crystal Reports. This project worked for years with this functions until someday it came to a strange error. If the project was installed on a 64-Bit Windows System Crystal Reports won't log in into the Report-Viewer. This means, before the report was shown to the user, there will be a window, in which you have to insert your credentials of your Database. Sadly after giving the credentials, no login will be performed, instead there will be a message telling the user that the login failed. And after that the login box returns. It doesn't matter, what you insert into the password or user field, there won't be a login.
Login Screen Image
Login Issue Image
Well, this error could be solved by installing the 32-Bit version of the sql-native Client from 2005 or 2008 instead of the 64-Bit version. But now Windows 10 64 Bit doesn't allow to install a 32-Bit version of this native sql clients. Therefore the old fix doesn't work anymore and the problem returned.
This question is discussing the same problem (like many other threads), without a solution.
Stackoverflow Question asking kind of the same question
We have two computers with windows 10 64 bit on which the problem occurs. On one of them, the login window has no database selected (visible in the database-field). On the other computer, this field is correctly filled with the database. We found no difference in the behavior of both issues, except from the empty field. We tested, if the database wasn't correctly given to Crystal Report. It was, but the field still remained empty on one of the computers. This issue is also discussed on the internet without a solution (at least I couldn't find some). As an example, in the following link the problem with the empty Database-field is discussed.
Example with a question about the empty database field.
The "best" solution in the thread above is "There is no solution to this problem. Regards [...]", wich is not a good solution.
There is another oberservation. The problem doesn't occure, if the windows 10 System is an upgrade from a lower system, on which the 32-bit version of the Sql-Native-Clients was installed. Therefore, Crystal Report can run indeed on windows 10 64 bit, if the correct environment could be installed. But we can't install the needed clients on the freshly installed 64-bit systems.
What was done until this question:
Cause the Code does work on every other system, except from a freshly installed Windows 10 64-bit one, we haven't looked into the Code deeply for the fixing. Instead we concentrated firstly on internet research and secondly on trying to get the sql native clients 32-bit on the new systems (or at least the needed dlls). Therefore we tested:
Registry Solution
Cause a research-founding, we tried to add the registry entries under "SAP BusinessObjects" into the "WOW6432Node", if it wasn't there. This didn't fix anything at all.
DLL Copies
We tried to determine the dll-files installed by the sql-native Clients 32-bit and manually copy them into the folders. But all the systems already had them.
We unziped the msi for the native clients and tested for the dlls in the msi directly. Also we searched for the files, that will be copied into the System32 folder directly and found them.
(German) Microsoft site with information about dlls
"Die SQL Server Native Client-Dateien (sqlncli11.dll, sqlnclir11.rll und s11ch_sqlncli.chm) werden in folgendem Verzeichnis installiert:
%SYSTEMROOT%\system32\"
Meaning: The SQL Server Native Client-files (sqlncli11.dll, sqlnclir11.rll and s11ch_sqlncli.chm) will be installed in the following folder:
%SYSTEMROOT%\system32\
So we checked for this files and also for the sqlncli...dll files with lower version (10). They were in the system folders.
Cause the dlls may not be compiled in the GAC folder, this may not be the solution at all (cause we can't write them into the folder without installing the 32-bit versions).
Installing all the avaiable sql-native clients for 64 bit
Hoping, that one of the versions had the needed files in them, we installed all the version for the 64-bit version, but without success.
Clearing the Connection for Crystal Report in Code
Following a solution from the internet, we tried to clear the DataSourceConnections before setting the new one. Just for testing purpose, if this may help (which it didn't).
Some Solutions for the Problem, that didn't work for us
Debugging and Research
As said in the text above, we tested the Information in Code and found no problem with the connections. We could connect with the same information in the database from every other tool of the programm. The issue only occurs with Crystal Report. Also researching the issue showed only "open" questions withouth answers, or without answers that worked for us.
The Question
What to do, to get into the CrystalReport-Viewer without the login-window failing to login?
As solutions there may be two ways to fix this. One within the code, and one with the needed files from the sql native clients, or other environmental changes.
Both solutions are welcome. Of course we will further search for solutions ourself, but in the moment, we are a little clueless (which explains this question).
So any help is welcome.
And at last a little Code:
repdoc.FileName = _pfad;
if ([...]Configuration.ServerType == [...].DB.Utils.ServerTypeMSSQL)
{
if (repdoc.DataSourceConnections.Count > 0)
repdoc.DataSourceConnections[0].SetConnection([...]Configuration.Server, [...]Configuration.Database, DatenbankAdministration.DefaultUser, DatenbankAdministration.DefaultPassword);
repdoc.SetDatabaseLogon([...]Configuration.User, [...]Configuration.Password, [...]Configuration.Server, [...]Configuration.Database);
}
repdoc.Load(_pfad);
In this code example, we set the filepath towards the report and the connection towards the database. Everything is correctly filled on the systems with issues. But if there are some configurations to be done, feel free to comment them.
If you are interested to look into the issues, but need some further information, that we can provide, I will happily provide them.
COM Excel AddIn, C#, VS2008
The error happens occasionally when I install/uninstall my AddIn.
sometimes I see Error 1001 the specified file can not be found
Anyone know what causes these and how to fix? thanks
I use windows installer
http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=VS.90%29.aspx says if use [TARGETDIR], it should be like "[TARGETDIR]\" or "[TARGETDIR] ". I simply use /filepath = "[TARGETDIR]myinstallfile" in CustomActionData
What I do not understand is it works almost all time and fails occasionally
Also even if I change this to including space or backslash, I can't tell if that fixes issue since the issue does not happen every time. Anyone has experience? thanks
I found this and it fixes the issue though I am not sure I ever use DDE in my program
http://sympmarc.com/2010/02/04/microsoft-excel-error-there-was-a-problem-sending-the-command-to-the-program/
Then I found this http://www.opendylan.org/documentation/opendylan/interop2/inte_278.htm
It talks about COM Server
so I went to cmd, type in "Excel.exe /RegServer", then the error disappears.
I am not really not sure if this solution works for all cases.
In fact, I am concerned that I miss sth in installer.
Here is a Microsoft Support page related to an issue which looks quite similar to yours. So for me it looks like a bug in Excel rather than in your installer.
The article is quite large, but it boils down to making sure that:
your Excel app is not running with elevated rights
advanced setting "Ignore other applications that use Dynamic Data Exchange (DDE)" is unchecked
Other than that you might try to repair Excel installation or follow the advice given in this thread of ASP.NET forums to fix the registry for Excel installation.
I hope it helps someone facing similar issues.
If you get this type of error when uninstalling a VS setup project MSI, then the most likely reason is that TARGETDIR is not preserved between the install and the uninstall, therefore it has no value, and attempts to use it in an uninstall custom action will result in failure to find the file. The easiest solution (apart from always installing to known locations such as common files etc) is to save TARGETDIR to the registry and retrieve it later. In the VS IDE you can create a registry item with the value [TARGETDIR] to have it resolved at install time.
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.