We Keep Coding

Protecting WPF application with self-made key algorithm

I need to find a way to lock a software product, so only customers who bought it can use it. I was thinking about implementing my own "CD-key" feature.
How it works:
I have a seperate program, that is used only for generating keys.
The program uses the same algorithm than the software being selled. The key is shipped with the program (on lets say the manuals) and entered in the program one time. After that the user can use it freely without ever entering it again(until reinstalling).
This looks pretty simple and doable to me, but the only problem is that the key can be reused on other devices, so I would need to implement a way, that the key is online marked as used and unused, when the program is getting uninstalled.

I would try asking this on https://softwareengineering.stackexchange.com/ instead of here - but I'd advice you to look into (non)-commercial products/API's to help you out (e.g. http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm) in stead of reinventing the wheel. As it's not your core business, you'll likely have a less optimal solution (and thus weak and leaky solution) than what others might provide you with.
Some products you can look into:
free
QLicense (on CodeProject): https://www.codeproject.com/Articles/996001/A-Ready-To-Use-Software-Licensing-Solution-in-Csha
pay to use
SSWare's CryptoLicensing: http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm
SORACO: https://soraco.co/quick-license-manager/?gclid=CjwKEAiAirXFBRCQyvL279Tnx1ESJAB-G-Qvy65J7uzmMUClDy0fltJKN7U9HtFex5akQ-H3r7YgFhoCa7nw_wcB
PS: if you would start implementing a licensing solution on your own, please drop implementing the same algorithm in both the deployed code as well as the generator - it's too easy to reverse engineer. Try to use some mathematical formulas that support public/private key mechanisms for example, or as I said try to rely on a library/api that's specialised in this domain.

Problem:
Since your code can be reverse-engineered, there is not real way to provide safe solution for your key storage. All your variables hard-coded into application, or in separate files, where they are encrypted using the same application are not safe. You need to treat them as publicly available.
Second even if you will provide way of server key authentication, again. Your code can be reverse-engineered. Hacker will remove authentication part, and will re-build your application, DRM free.
Third, even if you whole code, will be crypted, there are still ways to decode that and remove authentication (look denuvo latest failures).
If you will connect code crypting and server side key authentication depending on how many people will be involved in hacking you can delay them be finite amount of time.
Solution:
There are 100% secure ways to prevent your application to be hackable, you need to make it 100% web based. There are solutions like ASP.Net if you wish to use C# as server engine.

Could I hide the encryption key of a c# exe securely (in a way that can't be decompiled in any known way), as in C/C++?

I love c# for programming applications (I consider myself intermediate with c#, and a bit less with C/C++, but am only learning, nothing real yet in the arena), and I used to like it until i discovered "anyone" who understand MSIL (not an easy task to learn neither) could decompile my code. I don’t really care about someone decompiling my code, but my utter concern is the security for my eventual program users. I know obfuscators exist, and I even know of one or two that are really good, I hear (even if they only delay a decompiling).
For example, if I want to decrypt something using c#, some where in the code the key should be, making it a danger for anyone who use my program (someone who know someone who encrypted the file using my program could decrypt it by researching on my MSIL code, finding my key). Then, the developing of massive applications that encrypt/decrypt stuff (or OpenSSL) is insane with c#, I think, for this reason.
I mean, most users won’t know what language was used to make that exe, but a bunch of people are able to program n c#, and an elite of this people can read MSIL, and a minority of this elite would like to hack what ever is possible to hack. Of those people who like to hack, some of them can do it with perverse intentions (in a value-less world where we live that shouldn’t surprise anyone).
So, if I want to make a program that download a file from the internet, someone could interfere the transmission and do some evil, even if I use OpenSSL with c#, because somewhere in the c# file is the key. I know avoiding hacking is probably impossible, but it looks like c# is a very unsecure way.
Does it happen with Java? (Java has the same “interpreting” and “decompile” structure as C#); I mean, the fact that the key is visible in Java (with some educated eye) some where in the building file? Or does Java use some C/C++ based API that makes it harder (way harder) to decompile the file where the key is and so making it hard to get the key?
Is my only option to write my program with c/c++? Because if so, my only option is C++Builder, since its a hell to even try to watch (and less to learn) MFC/OWL code; I mean: I cant hardly think of someone who could like MFC/OWL programming. In fact, I suppose Assembly could be of more interest in the today programming world.
So, here I am, wanting to find someone who could explain me better a way to store securely crypto keys for encrypting/decrypting or to use OpenSSL with c#. Or even with Java. I would like to confirm that C/C++ is the only way of really using these features with some security for decompiling reasons (as other compiled programming languages, i.e. Delphi).
If anyone knows a site where I can find precise information about the subtle reasoning I suppose I have done (specially one that shows am wrong in my analysis), please tell me. If any one can confirm my analysis, please confirm. If anyone find any hole in my analysis, again, please tell me, and where to find more information that rule me to get a better understanding of all this.
Am sorry for making this philosophical computer programming question that long.
Thank you,
McNaddy

Could I hide the encryption key of a c# exe securely (in a way that can't be decompiled in any known way), as in C/C++?
No. You can't do that in any language.
The .NET security system is designed to protect benign users from hostile code. You are trying to protect benign code from hostile users. You simply cannot do that, so don't even try. If you have a secret, do not share it with anyone.
The purpose of crypto is to leverage the secrecy of some private key into the secrecy of a text. If that is not the security problem you face, crypto is the wrong tool. Explain the security problem you actually have and someone here can help you solve it.

So, if I want to make a program that download a file from the internet, someone could interfere the transmission and do some evil, even if I use OpenSSL with c#, because somewhere in the c# file is the key.
You don't need to store a secret key in the program just to download a file safely.
If you want to ensure that the file you downloaded is authentic and hasn't been modified in transit, you use a digital signature. The private key used to make the signature doesn't have to be (and shouldn't be) distributed with the program; all the program needs is the corresponding public key, which you don't have to hide.
If you want to prevent eavesdroppers from reading the file as it's downloaded, then you need to encrypt it, but that can be done with a temporary session key generated randomly for each download; it doesn't have to be stored anywhere. If you use HTTPS for your download, it'll do this for you.

The choice you've mentioned (embed key into executable) is bad irrespective of language you choose - it is not too hard to extract data from C/C++ and slightly easier for C#/Java.
As Jordão said - you need to figure out your story of distributing key outside the binaries. You also need to figure out what you actually trying to protect and understand possible exploits. Just using encryption of some sort in an application does not make it more secure.

You should not store cryptographic keys inside assemblies; they should normally be provided from outside, e.g. from a key-store, or derived from a secret known to a user.

You can also generate a key from a password(this means the key is no more stronger than the password though). So each time the user runs the program, they are prompted for a password, and that password is then used to generate a key. Depending on your requirements you could employ this in a variety of ways.
When the user needs to access the encrypted data, the password can be provided again and this generates the key for use during that session. Once the program is closed the key is discarded(there are techniques/APIs in C# to help ensure that sensitive data is only present in memory as short a time as possible).
For example, this is essentially what many password storing programs like Keepass or Roboform do. The user can upload and download the encrypted data to and from servers. No keys are ever stores, and instead generated on demand as the user supplies their password for that session.
With a service like Dropbox, when you register with their site, they generate the private key on their server and keep a copy there. So the user's machine and client software never store the key, but the server has a copy stored. Dropbox does this so that they can decrypt user data for many purposes, such as compression, de-duplication, compliance with law enforcement, etc.

Checking efficiency of obfuscation of C# code

I'm evaluating several obfuscators for protecting code in a WPF application.
For checking results of job done by each obfuscator on a given assembly I use Red Gate's .Net Reflector. Just after each obfuscation I open the assembly with .NET Reflector and see what it looks like.
Is it enough? Can .NET Reflector's results be treated as an indicator of quality of obfuscation, or should I try some additional tools? (not any possible instrument of such a kind, but from a point of view of practical common sense).

The results from Reflector should be enough on an indication of how any casual attempt at decompiling would fare. Some obfuscatory will obfuscate code to the extent that the assembly will not even open in Reflector.
Anyone who would try any deeper than that will not be easily deterred by more advanced obfuscation than others.

It would be best, if Reflector and ILSpy would outright refuse to decompile the resulting assembly. I know that there exist obfuscators that are capable of that.

My opinion is: that "is it enough" or not depends on your target app. Obfuscation is never about 100% secure code, it's always to make the code deassembly difficult enough for potential attacker, but it all depends on how much that "potential attacker" will put effort to deassembly your app. And also .NET Reflector is a viewer, like you mantioned, so if it's ecure or not can deduct you, by looking on, for example:
if strings are encrypted
if parameters are encrypted
if class names and fields like (PWD_USER) are encrypted
...
Regards.

How to protect my .net winforms assembly from customers of a customer

This question appears to have died, so I've decided to offer a bounty.
What I'm most interested in knowing is if my scenario in the ETA1 below is viable and is used. If it isn't, then a good explanation of why not would be a good answer. Another good answer would be an alternative (but not including the internalsvisibleto attribute).
The best answer would be, yes, it's viable, everyone does it and customers love it!
ETA2: I think I've thought of a good solution. I provide the customer with a distributable edition that is as functional as their edition but is unlicensed and has the classes and members hidden, using attributes.
I can do this with compiler directives, on every single important member, but I wondered if there was some global way to hide all members of a class?
A simplified scenario:-
I have a class that extends a control in someway and I want to sell my class under two licenses;
(1) Standard - The customer gets x number of controls that use my class but can't instantiate the class (its internal).
(2) Developer - The same as Standard except they can create their own controls that use my class.
My problem is that when the developer customer comes to sell their controls, they can't help but expose my class to all their customers.
--- Ignore this
The only way around it, in my scrambled mind, would be for the developer to somehow integrate my assembly into theirs, and in that way I can keep the constructor internal. Or, use the internals visible to attribute. / Ignore this ---
I'm sure someone here has had the same situation and any help would be greatly appreciated.
ETA1: I'm thinking aloud here, but, I could have a list of permissable calling assembly names which the customer could add to. When they ship their product, their customers' assemblies would not be in the list and therefore they wouldn't be able to instantiate certain classes. (The list could obviously be hashed).

I believe you will store the licensing information (i.e, Standard and Developer) somewhere in the registry. In such case, I suppose the simpler solution would be to implement LicenseManager. This is what most .NET component vendor use.
http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx
Hope this helps !

I believe you've come up with the only real solution, assuming the runtime will support it. As long as yours is a separate DLL, if the developers can instantiate your objects then so can anyone else, whether you try to hide it behind a constructor, a factory, whatever.
I wonder, though, whether consumers might not even be able to get around that restriction by integrating the shipped assembly into their own?

Why don't you use license keys? Your class reads the license key and depending on what permissions the license offers it disables methods at runtime?
The license key could be defined in the config file.

It's a tough one, just due to the nature of .NET. It's a shot in the dark, but you could look into products such as CodeVeil which provides assembly encryption at the IL level. Your assembly would essentially be shipped encrypted and the key would be handed to your customer. The customer would then be the only entity with the ability to decrypt your assembly instructions. Now, CodeVeil claims the following about its decryption keys:
Even though the key is stored in the application that does not make is insecure. In fact the key itself is not as important as the transformation of the data itself. CodeVeil also uses many runtime-protection operations to frustrate hackers attempting to capture the decrypted assembly. In addition CodeVeil uses a very special decryption system that decrypts only enough information for the .NET runtime to execute that specific method. The code is never stored in the same memory as the assembly itself so the decrypted code cannot be dumped to disk for analysis.
This is obviously a good thing, but this is the part you'd have to research because i am not familiar with the other techniques they use as part of their decryption algorithm. The cool thing about this is if it works, your customers will be happy and THEY can make their customers happy by exposing parts of your assembly through their own API. At the same time your code stays protected from tools such as ILDASM and Reflector.

(C#/C++ CLI) Is it possible to protect my C++ CLI assemblies from being used in other .NET projects?

I have created a C++ CLI wrapper for native C++ code, which in turn I reference in my C# application. Is it possible to somehow protect this assembly so that it may only be used in my application without the possibility of someone else using it?
I'm a Microsoft technology developer, I'm all about selfishness :)

I have used this technique with success.
Basically, it's about protecting your assembly from being loaded by placing a link-time security demand and using the assembly strong name's public key as evidence. Only assemblies signed with your private key will be able to load it.

Yes, but this will be a losing battle against a determined attacker.
For example, you could provide an encrypted version that only accepts a particular key, as some people have suggested. But then you'll need to decrypt it on your clients, who may not have encrypted memory stores, so a determined attacker could simply read the appropriate block of memory and deserialize the result to get your original assembly.

Not perfectly. LinkDemand is only enforced in a partial trust environment. Code running with full trust can also use reflection to access private types, and generally bypass any protection you care to discuss.
Maybe you want your C++/CLI code to call Assembly::GetEntryAssembly and check it against a whitelist of approved apps for which the library is intended.
Of course, you want to minimize the amount of managed code (and attributes) involved in the checks since managed code is really easy to decompile.
Actually, mixing the occasional check into the core logic of the C++ code is the only hope you have that it won't be bypassed.