I have a number of files that were encrypted using EFS on my old Windows XP installation. I installed Windows 7 and now I can't access these files. You can read about the whole embarrassing situation here.
The good news is that I have keys that will allow the files to be decrypted. I know this because I used EFS data recovery and it was able to decrypt a file. It also identified that I had some usable key files of some sort (master key and private key).
The problem here is that Elcom want's $150 for their tool and what I have encrypted is not worth $150. Is there a way that I can do this myself, programmatically?
EDIT: This link is awesome...EFS recovery
I found the following resource:
http://www.beginningtoseethelight.org/efsrecovery/
It outlined how I could recover my files. I did have all the keys so I can decrypt the files if necessary. However, I gave up on this because I didn't want to trash my existing system in order to recover the old one. There's still a chance you can torch the new Windows installation and I didn't want to deal with all the backup stuff.
The only other answer I know of is to use a tool called RECCERTS.EXE that Microsoft Product Support has available to those who call. I can't even begin to imagine why after years of these kinds of problems people have had with EFS over and over, Microsoft still hasn't released this tool as a free download. It searches any available files it's pointed at to look for all the remnants of the keys and metadata necessary to decrypt and use the RSA private key that your previous OS install used to decrypt the EFS-encrypted files on your system. It works awfully well, but from what little documentation there is on the web (i.e. MSDN Social forum postings - latest in 2009), it appears this tool is still only available if you can find a way to convince MS Product Support to send you a copy. It appears that the cheapest official doorway here is the $99 email incident, but I wonder if they'd refund your money if you demonstrated that this fixed your problem (cf. how they used to refund - and may still do so - PSS incidents if you were able to demonstrate that there was a bug in their software for which you're calling). Not saying this is a bug, just the painful byproduct of a dubious design that doesn't warn users to take appropriate and explicit steps to avoid these recovery nightmares.
The only other possible solution is to search the web for RECCERTS.EXE and see if there are any locations where it's been made available for download. Many of such sites use legit filenames as "lures" to get you to download something that turns out to be malware, so be very careful if you take this approach. However, if your time is worth less than $99, then you just risk hosing a Windows install with nasty malware - and having to wipe & recover the system. [Just make sure there's an offline copy of the files you're trying to recover, in case the malware infects or corrupts an online, mounted copy of those files.]
Related
I am searching for a function that allows me to put a dialog-window(w/ a password query) before the folder is accessed. Is there such a function? Also, this would be great if this protection is there before any program, even Windows Explorer/cmd.exe are allowed to access those files. Is that possible to make?
I'm not using something like IOContainer, passwd. protected ZIPs or any other things that are too slow, because I guess 20GB in one file are a bit overkill and it would take ages to decrypt that file. Is there maybe a VFS solution for C# which supports password protection and can be used as a normal filesystem or folder on the disk?
Thanks!
There exist two options. The simpler one is to have a virtual file system mapped from the file. Our product, SolFS (OS edition), does exactly what you are asking in the second part of your question - it provides a container with optional encryption, which is exposed as a virtual drive so that access to the contents is transparent. Decryption in such systems is done in pages, so 20GB-large file won't be decrypted in whole as you worry.
Another option is to employ a filesystem filter driver, which will intercept requests for directory opening, and will ask the user for a password. This approach is possible (we even have a product for this, called CallbackFilter), but there are two drawbacks in it: first, it's not impossible to remove the driver, leaving the data unprotected. And the second problem is that if you ask the user for a password in a callback, while the OS is waiting for access to the directory, you can end up in a deadlock or a timeout while the user is thinking.
With these two limitations in mind something like SolFS is the preferred and recommended approach.
PS: and we have free non-commercial licenses as well.
I'm developing a program in C#.
It connects to the internet to see if this copy is valid.
Currently I'm just sending the licence key and getting a response (0 or 1) if the key is valid.
The problem is that some users just fake the data with some packet capturing tool and replay it.
So the application is very easy to crack. How can I prevent this?
Here is what I essentially want to prevent:
Network replay attacks
Authentication "emulators"
It should be impossible to find out what data is sent.
Maybe I should add the current time and then encrypt the packet ?
So it's always different ?
Attention: Please don't warn me that it's easy to crack the application itself by modifying it. I know that. This question is only about the network part.
If you use SSL or HTTPS then you don't have to worry about users cracking the data packets. This is easy because the libraries already exist and are easy to implement. With C# and IIs for example it is just a matter of installing the certs and changing a few configuration items. (Maybe a recompile with some slight code changes).
Assuming you actually want to prevent license abuse there are far better ways to do this. The "phone home" approach is easy to roll yourself, but as you've noticed it's full of holes.
Disclaimer: I work for a company that makes commercial tools to solve these license management and copy-protection issues. There are other similar products available from a variety of vendors.
This isn't that different from thinking about how to do setup for your application. Choices are roll your own or buy an existing 3rd party toolset. Rolling your own at first blush make seem cheaper, but that's perhaps only because you haven't really discovered all the true requirements to create something robust and reliable. The 3rd party tool vendor needs to charge for their products, but they've spent years discovering all the issues with particular problem set and have solved the problems. So that eliminates work for you and leaves you free to focus on where your application can add value.
The difference is if you get setup wrong your users will be irritated; if you get copy protection wrong your product will be pirated.
In any event, reducing license validation checking to a binary "either/or" condition is extremely easy to crack--doing that check over the net makes it 10 times easier (record playback attack). Modern approaches encrypt the executable and the license is contained in the key to decrypt it (this is an oversimplification since the actual methodology includes a lot more complexity to make it virtually impossible to get around). Only by having a valid license can the executable be decrypted on program load and run.
If you want to do it the way you've described, consider this:
Have the app use a predictable, changing value (such as a lookup from a table of random numbers coupled with some external value like time) to create some kind of hash. Have the server implement the same code. The server sends the hash to the app, which compares it to its own hash. If they match, the app is allowed to run. If they don't, it errors out. Since the hash is different on ever startup attempt, recording it over the network won't allow the user to get it to run the next time it tries to start.
We have around 60 MB of device configuration implemented in at least 1000 xml files.
Now we are releasing the software to the customers. But our requirement is not to allow the user to view and edit the xml configuration files. XML configuration files contains a lot of secret of the device information which can be easily hacked if it is readable.
Now we need to encrypt the xml files. Are there any recommended method to encrypt the xml file and it can be decrypted at run time?
This is a problem known from DRM applications - you want to make the data available to the user agent of your choice but not to the user operating the user agent. But, since the user agent is usually on the user's side, as Jon and Oded point out, a determined hacker will find a way to break the encryption. It's a cat and mouse game. You are trying to find a solution to exactly the same problem that people implementing DRM want to solve. Software-only user agents are easier to hack than hardware-assisted user agents, but in either case time works for the hackers. The latest development is the latter - embedding all the cryptography in hardware - like the HDMI's HDCP method (High-bandwith Digital Content protection Path) where they have essentially made the decrypted digital signal inaccessible to the user by letting it pass along black-box hardware from its point of decryption until it is made so available, but at the intended destination - TV screen. The key for HDCP to succeed however was implementing it in hardware. Most hackers have learned to deal with software. But since I would say there is 1 good hardware hacker per 100 good software hackers these days, the mouse hopes no cat will be around to catch it. Sorry for too much theory, it is essential to your problem though, I believe. If you are still willing to play the game, encrypt your XML files and make sure the decryption key is not available to potential hackers on a silver plate - i.e. obfuscate it, can't do much else.
How determined are you expecting the "hackers" to be? If all the information required to decrypt the information has to be present on the system anyway, then a determined attacker is going to be able to get at it anyway.
You can use the classes in the Cryptography namespace.
Most of the encryption classes will allow you to encrypt and decrypt streams, so are good for your purpose.
However, you will still need to hold the encryption keys somewhere, even if it is in the assembly.
As Jon points out, a determined hacker will find a way to break any encryption.
As others explained, you won't get it absolutely secure without a trusted device which stores the key and does the decryption without granting access to the key under any circumstances. Computers aren't "trusted devices"...
My employer sells such technology and if your data is really money worth, you should possibly take such a solution into account.
If an additional USB-Dongle is not acceptable (or too expensive) at least use public-key (asymmetic) cryptography (see System.Security.Cryptography).
Asymmetric cryptography has the advantage that the key used to decrypt your data can't be used to encrypt the data.
Your application has to store the decryption key and the hacker can determine it with more or less effort. He then can decrypt all your data but he can't not encrpyt the changed data again. So he can't use your application with the changed data.
If you want to prevent him from doing this, you have to obfuscate your application and use anti-debugging techniques (static and runtime). If you go this way buying an existing solution is probably cheaper.
Watch out: Hackers can see all functions in .net generated executables and dll's!
If you make a decription algorithm in your .net project like DecryptXML(string Path), it is very easy for a hacker to call this instruction. So be sure to dotfuscate your project.
I was initially going to use a signed serialized xml file to store license details.
In planning, more and more has moved into this "license file" which will allow for us to distribute a single application and control available functions via the supplied license file.
The UI and printed reports are co-branded with distributors logos, so it would be good if this could be embedded into the license. I know this could be done with the serialized xml file but I was wondering what are the pros and cons of storing this data in a compiled assembly?
The license generation tool could compile the assembly with the appropriate properties and resources and sign it.
Update
From what I can see, using serialized xml or an assembly would be pretty similar. From my point of view, assemblies would allow me to add other resources and leaves some flexibility for the future. As soon as the resources get complicated, xml serialization is a pain.
Update2
The software only works with our hardware so licence security is not a massive concern. The main aim is to stop the casual user from enabling features that they have not paid for. I would be choosing one over the other for design simplicity!
A signed xml license file has few advantages, but they may not be applicaple to your situation:
You can inspect the contents of it using a simple tool like notepad or a web browser. If you have to manage a lot of licenses and a lot of time goes by, you can check the license scope more easily by simply viewing the file. Even the customer can read you the most important points of his license over the phone.
If a single application installation can have many licenses assigned to it (per user, per function, etc), it is easier to manage a list of xml files, than to dynamically load assemblies.
It is easier to create a tool for client-side license creation -> the application would submit an unsigned xml file for signing.
It's easier for versioning. If a new version of your software has new licensing options, and the old license should work with the upgraded version, depending of your implementation of the singed licensing assembly, you can break the old software.
If you don't have any of these specific needs, go with the assembly-as-a-license option, as it's simpler to implement.
Update
Looking at other answers that popped up after mine - a perfect protection for software running on a local computer does not exist and will likely not exist for a very long time. Don't spend too much time on protecting your software, because if anyone really, really wants to use it for free, he will find a way to do so. Give the users more reasons to use your application and simplify the buying experience.
Going with signing the license in a dll or an external xml file is good enough.
You could use an assembly in lieu of a licence file, but you shouldn't. It has always been possible to remove the digital signing from an assembly; now it's trivial using the Reflexil tool.
See the article CAS Tamper-Proofing is Broken: Consequences for Software Licensing for more details.
A good solution that has always worked for me is to create a license class with all the properties needed such as name, expiration, logos and such. Serialize the class to binary data in memory, then encrypt that and save to a file. Doing it this way doesn't require signing and the file is hack resistant. To read your license simply do the reverse, read the file, unencrypt, unserialize. One caveat to this is that if multiple assemblies are going to read this license file, then the encrypt/unencrypt functions should be in a separate shared assembly.
I wouldn't go with using an assembly as a license file - as others have pointed out it's relatively trivial to break.
I would use a file ( xml or whatever ) then lock it to the users machine. This can be achieved in several ways :
1) Use System.Cryptography.ProtectedData - this just wraps the Windows DPAPI and uses the windows key store ( either per user or per local machine ). This a simple(ish) approach but you will have to using Encoding.UTF8.GetString ( or whatever your encoding is ) to convert back from a byte array. This is simple but not industrial strength as someone could still dig out the key store etc.
2) Use a machine unique ID such as the SID with a symmetric algorithm such as Rijndael or Blowfish and provide the SHA-256 hash of the unencrypted license file as the IV. This is a bit more complex to implement as you'd need to use WMI to find the SID and then use System.Security.Cryptography.RijndaelManaged etc to do the encryption/decryption.
I think using the assembly is creative, but easier to reverse-engineer. After you open the application with reflector, all locations that check the licenses are recognizable as property reads on the license class. Another problem I see is versioning. When version 2.0 comes, your marketing team might require you to accept 1.0 licenses. Your 2.0 software may have a new license class with extra properties which is no longer interchangible with the 1.0 version of the class. You can make workarounds for that, sure, but it will kind of defeat the simplicity of the original design.
I would prefer the assembly version because:
Instead of .net sign, you can use authenticode (you need a certificate for it, but it’s not that expensive), or you can use both. Than in your application, you can check the signature. This removes the security hole for a tampered .net sign.
It’s more flexible. You can define an interface for the license assembly which can be later extended.
You can have some logic in the license assembly.
But remember. It’s just a software protection. The next step would be to use a crypto key (hasp, marx…)
I'm currently conceiving a system that works like an anti-virus, but also uses the White Listing i.e
Preventing Viruses from Running by having a database of Known legitimate Programs
Yes , there is the Windows UAC, but still many viruses "work around" it. I'm planning on a more reliable system.
My system has also a database of known threats (cryptographic hash).
Is this approach viable,
What are the possible loop holes in this approach
I understand that there has been a lot of attempts at this. But still I want to try it out.
I'm planning to use C# and .Net for a prototype may be i'll move on to C++ for performance later
Update:
Thank you all for your time and thoughts.
I decided to do some more research in this area before actually designing something
Espcially as pointd out below the Zeroday threat problem
What about DLLs used by executables? Do you hash them too? A virus can replace a DLL.
This has been brought up before, and there are products out there which do that. (Faronics Anti-Executable works like this)
There are two main problems with this approach:
A virus can embed itself into any file; not just EXEs. Programs can load DLLs and other bits of code(macros, scripts, etc), and programs can contain bugs(such as buffer overflows) which can be exploited by malicious documents and other files.
Every time you patch a system or otherwise legitimately modify the software, you also need to update the white list.
There is products like Appsense Application Manager that do this already. It was temporarily pitched as a security product but they changed tact and focused it on licensing. I think it's because it didn't work too well as a security product.
If you are planning to work with a limited set of applications and you can work with application developers you can use a code signing model. You can find a similar approach in most mobile operating systems. You have to sign all the executable modules including libraries and need to verify they have a valid signature and not modified using a root certificate.
If you are only planning to white list applications based on their hash value you need to make sure your white listed applications verify any modules they use before they load. Even if the applications/installation files are digitally signed it does not guarantee that a library will be modified later in a malicious way.
In reality, it is not even enough to only verify executables and libraries. For example, Xbox Linux hack utilizes a malicious save file. It is a specially prepared save file that causes a legitimate and signed application behave in unexpected ways. And, of course it is not possible to white list a save file based on its hash value.
Another problem with keeping a database is zero day attacks. You need to be ahead of the curve for creating hash values for new attacks and propagating these updates to your users otherwise they will be vulnerable all new attacks. Unless you only allow only white listed applications to be executed and that would be really restrictive.
IMHO, it is really difficult build such a system on open platfom. Good luck with it.