Im building a small winforms app using: ayende rhino licensing. The licensing is working fine, I can create licences and distribute them as I choose.
The problem is, How do I make each license work on just one machine? I know there is a class in ayende's project called LicensingService which I believe does something like what I'm trying to do, but I just cant figure it out. I've done quite a bit of searching and couldnt really find any tutorials except this one.
Maybe someone has implemented this, or has some tips on how I could accomplish this? I do have access to a webserver, if that helps.
Any help is much appreciated, as always.
Depends how annoying you want to make it for your users to be honest. You could implement a HWID (see How to fast get Hardware-ID in C#? on how to generate them) which will be unique from system to system, then have your program check if the HWID matches the ID found to the place you store them on-line (usually by using a database).
Needless to say, this will make your application require internet connection in order to run which might be a bit frustrating for your users.
Or you can merge the HWID with the serial and have your application do the same to verify if they match, but that would be easily cracked by the average cracker.
In the end of the day, .net isn't the best as far as security goes since you can easily get the source code and modify the assemblies as needed to patch certain protections. Keep that in mind when deciding what route you want to take to protect your software.
I do not know what exactly is a rhino licensing. To tackle your need generally there are two approaches.
Either give some randomly generated password to the client machine, and maintain a pool of passwords in your server. Each time a password is entered to register the application in a local machine, check if it was already registered elsewhere by connecting to your server via internet.
Or, what we do is, generate a code unique to that machine (perhaps a hash of some unique machine id, say mac id) and get the client sent it to you. You would then rehash the code and send it back using some logic. Now when the client enters this code to his machine do the same thing: fetch the very machine id, do the same rehashing using the same some logicand check if it matches.
I cant think of anything else
Related
First of I'd like to say thanks to this community that has gotten me as far as I currently am programming in c#. I'm teaching myself as I go and not really doing any formal training so you guys have been a great help.
I'm writing a small application that is intended to make one of the mundane tasks for upgrading a piece of equipment my company sells a bit easier. Typically these devices are not connected to the internet, and we need to remote in to a customer's computer to accomplish the task of connecting to their device over SSH and running some commands once logged in to do the upgrade. I'm hoping to distribute an app to the customer, and an encrypted key (generated on our side) that has information about the options they are upgrading, and the serial number to ensure the key can only be used on their device.
In my app, I'm using SharpSSH to accomplish to initial SSH connection which is working great. However my concern is that the root password on our device is actually a fairly simple one. The devices themselves have rather limited functionality so not much someone could do if they got on it themselves, however if they got on the device they could upgrade theirs and anyone else's device if they so desired.
So my question is, how could I best 'hide' the password in my script so it's not easily searchable by anyone with a decomplier?
Right now the code is simply,
SshStream ssh = new SshStream(ip, "easytoguessuser", "notsocomplexpassword");
So I'd like to hide the password somewhere, but I can't think of a method that means someone with a decompiler couldn't just open up the exe and look for where the password is, or how I derive it from somtething else...
Like with real world locks you can't keep someone with the right tools out. You only can make it harder.
This can include:
store the password in an encrypted string that is only decrypted shortly before it is used
obfuscate the source code so it is harder to determine where the connection is initialized
This wont make it safe, but it hinders the less determined folks.
Apps downloaded from the Windows Store are installed in this location:
C:\Program Files\WindowsApps
If you look inside this folder you can access each application's .exe and use reflector to decompile them.
Currently, my Windows RT application sends a password over SSL to a WCF service to ensure that only people using my app can access my database (via the service).
If my code can be read by anybody, how can I ensure that only people using my Windows 8 app are accessing the service?
Thanks!
In the very general sense, it is impossible. If ever you create anything that is placed on the customer's computer, eventually you will stumble upon someone that will manage to decipher your code and understand how to call your service. You may obfuscate it into insane levels, but still it has to be executable by the processor, so the processor has to understand it. And if it does, then potentially anyone knowing assembly can understand it too. You may smartly obfuscate it so that it will be very time-consuming to cleanup the code from unimportant trash, but still, at some point of time someone will read it.
One of common defenses is in trying to detect who* is actually trying to use your service. This is why all the "portals" require you to "register". This way, the application identity is marginalized and it is the user who provides login, password, PGP keys, etc is checked and verified whether he/she is allowed to actually run your service.
Also, on the OS/framework layer, there are several ways to selectively provide "licenses" to your customers and then in your application you may use keys/hashes from the licenses to authenticate in your service. This may partially remove from the user the burden of remebering the passwords etc, or it may provide an additional authentication factor, or it may simply be a yes-no flag that allows to run the app or not. Still, it will not guard your code against being read. Licenses just help in verifying if the software copy is legit and if belongs to that specific user/computer.
You may act selectively only against 'reflectoring' (or dotpeeking, or ildasming, or ...). Those tools really make the decompilation easy (although the original reflector is now paid software). So, the simpliest form would be to use obfuscator that will make the decompilation impossible or harder - that cuts some percentage of the potential code-readers and you can assume scriptkiddies are gone. You may ignore obfuscators and you may write the service connector in native code (C++, not C++/cli). That will make the code completely un-reflectorable and un-ildasmable, and that will cut off another large percentage of people, but with some will still be left (me and thousands of others, but that's much less than millions).
While this does not give you definitive answer, I wanted to show you that you can only get some "level of hardness", but you cannot make it totally safe from being read. This is why you should focus on making the service access in that way, that showing your code to a stranger on the street does not compromise your security.
Now gettint to your problem: the core thing seems to lie not in the fact that your app uses some secret algorithms, but rather - that you have hardcoded the password in. You see, there's with this approach, they do not need to read your code at all. They just need to listen what data your app sends over the sockets..
Another issue is that everyone uses the same keyphrase.
A hardcoded magic string may be some sort of validation, but never authentication. If you want the app to be register-free, make the registration silent and automatic at first run? Of course, you will just bounce the problem: anyone could read the code and learn how to autoregister, and then they will make a clone.. But, again, like I've said: you never know who's on the other side. Is it your app, or is it an ideal-clone of it? Or maybe is it a clone that uses your own hacked-a-bit libraries to connect to you? If it looks like a duck, and quacks like a duck, it is a duck..
I need some ideas how to create a activation algorithm. For example i have demo certificate. Providing that the application runs in demo mode. When full version certificate is provided then application runs in full mode.
Is it even possible and how would be a good way creating this system?
One simple was i was thinking would be just have a 2 encrypted strings, now when the decryption is succsessful with the demo public key certificate then the application will run in demo mode and etc..
You could do something like:
Generate public/private key pair
As owner of private key, you can sign those "activation certificates" (called AC from now on)
In your app, with public key, you can check if the sign is correct
As Overbose mentioned -- you can't prevent reverse engineering. In general someone could take functionality and put it in his/hers own app and thus eliminate any possible activation algorithm. So you can only assume (or make) this is hard enough not to be worth the effort (this is the same as for cryptography -- when you make the cost of breaking the message greater then the profit of gaining it you can say it is well secured).
So you could:
Make executable self-verifying (signed by you, self-checking based on hard-coded public key (one thing: you must skip this value when self-checking)).
Do some tricks with pointers (point to the activation function, go to 7th bit and change value of it for something based on value of another pointer; in some weird places change hard-coded values to those based on occurrence of some bits in other places of the code; generally -- make it more difficult to break than by simply changing bits in executable with hex editor)
Try to make some protocol that your server would use to ask questions about the app ("gimme the value of 293 byte of yourself") and check answers.
Use imagination and think of some weird self-checking method nobody used before :)
As mentioned -- none of this is secure from cutting the authentication part off. But nothing is and this could make it harder for crackers.
Background: I've deployed an activation based system built on top of a third-party license system, i.e. server, database, e-commerce integrations. I've also separately written a C# activation system using RSA keys, but never deployed it.
Product Activation commonly means that the software must be activated on a given machine. I assume that's what you mean. If all you want to do is have two strings that mean "demo" and "purchased", then they will be decrypted and distributed within hours (assuming your product is valuable). There is just no point.
So. assuming you want "activation", then when the user purchases your software, the following process needs to happen:
Order-fulfillment software tells Server to generate "Purchase Key" and send to user
User enters "Purchase Key" into software
Software sends Purchase Key and unique Machine ID to server.
Server combines Purchase Key and Machine ID into a string and signs it with its certificate and returns it to user.
Software checks that signature is valid using Servers public key.
Software could check in lots of places: loading the sig in lots of places, checking it in others.
When generating Purchase Keys, the server can store not only what produce was purchased, but what level of product. You can also have "free" products that are time limited, so the user can try the full version of the software for 30 days.
You are using C#, so make sure you obfuscate the binaries, using dotfuscator or equivalent. However, even with that there is nothing you can do against a determined hacker. Your goal, I assume, is to force non-paying users to either be hackers themselves, or to have to risk using a cracked version: kids wont care, corporations might. YMMV.
The code that does the checking needs to be in every assembly that needs protecting, otherwise an attacker can trivially remove protection by replacing the assembly that does the checking. Cut and paste the code if you have to.
Or just buy something.
Another option is to have the server pre-generate "Purchase Keys" and give them to the Order fulfillment service, but then you dont get to link the key to the customers details (at least not until they register). Better to have the ecommerce server hit your server when a purchase has been made, and have your server send it out.
The hard part isn't so much the generation of activation keys as it is the creation of the server, database, and the integration with e-commerce software, and most of all, human issues: do you allow unlimited installs per Purchase Key? Only 1? If only 1 then you have to have customer-support and a way to allow a user to install it on a new machine. That's just one issue. All sorts of fun.
This guy wrote a blog post about a similar idea, explaining what he did with their own commercial software. Also wrote a list of recommendations about the most obvious cracking techniques. Hope it helps.
One simple was i was thinking would be just have a 2 encrypted
strings, now when the decryption is succsessful with the demo public
key certificate then the application will run in demo mode and etc..
Could be a simple solution. But this way you won't prevent someone to reverse engineer your binaries and make the execution jump to the correct line. Everyone has your program, has a complete version of it, so it's only a matter of find how to break this simple mechanism.
Maybe a better solution is encrypt a part of the binaries needed to use the full application version, instead of a simple string. This way to execute the application complete version someone need to decrypt those binaries in order to execute them.
Please take in consideration that even that solution isn't enough. There are other problems with that:
Does all the version of your tool will share the same encryption key? Breaking one of them for breaking all..
Even if you use a different key for each binary application released, does the encrypted binary are identical? Once cracked one, you can reuse the unencrypted binaries for all distributed applications.
How to solve these problems? There's no simple solution. Most of the more important commercial software with even sophisticated protection systems are broken just few hours or days after they have been released.
Product activation is not a problem that asymmetric cryptography can solve. Asymmetric cryptography is about keeping secrets from your adversary. The problem is that you can't keep a secret that is stored on you're adversaries machine, that would be security though obscurity.
The correct way to do product activation. Is to generate a Cryptographic Nonce that is stored in a database on your server. You give this Nonce to the customer when they buy the product, and then they activate it online. This activation process could download new material, which would make it more difficult for the attacker to modify the copy they have to "unlock" new features.
But even with DRM systems that require you to be online while using the product. Like the ones found in new games like "From Dust" are still broken within hours of their release.
One of the benefits of public key encryption is that you can verify the origin of a given piece of data. So if you store the public key in your assembly, then sign a given piece of data (say an authorization code or serial number) your assembly can verifiably determine that you were the one that created that data - and not a hacker. The actual data itself isn't all that important - it can be a simple pass/fail value.
This is actually pretty easy to do with .NET. You can use an x509 certificates or like we use in DeployLX Licensing the RSACryptoServiceProvider.
I would highly recommend buying a commercial product (doesn't really matter which one, though DeployLX is excellent) and not doing this yourself for 2 reasons
Even if you're a great developer, you'll probably get it wrong the first time. And any savings you might have enjoyed by rolling your own will be lost to recovering from that mistake.
You'll spend far more time working on your own system - time that you should spend making your product great.
The second phase in protecting the software is to make sure that it runs the way you created it - and hasn't been modified by a hacker. It really doesn't matter what encryption you use if hackers can check if( licensed ) to if( true ).
You can use AsProtect to solve this problem. This is good staring point.
It might be duplicate with other questions, but I swear that I googled a lot and search at StackOverflow.com a lot, and I cannot find the answer to my question:
In a C#.Net application, where to store the protection trial info, such as Expiration Date, Number of Used Times?
I understand that, all kinds of Software Protection strategies can be cracked by a sophiscated hacker (because they can almost always get around the expiration checking step). But what I'm now going to do is just to protect it in a reasonable manner that a "common"/"advanced" user cannot screw it up.
OK, in order to proof that I have googled and searched a lot at StackOverflow.com, I'm listing all the possible strategies I got:
1. Registry Entry
First, some users might not have the access to even read the Registry table.
Second, if we put the Protection Trial Info in a Registry Entry, the user can always find it out where it is by comparing the differences before and after the software installation. They can just simply change it.
OK, you might say that we should encrypt the Protection Trial Info, yes we can do that. But what if the user just change their system date before installing?
OK, you might say that we should also put a last-used date, if something is wrong, the last-used date could work as a protection guide. But what if the user just uninstall the software and delete all Registry Entries related to this software, and then reinstall the software?
I have no idea on how to deal with this. Please help.
A Plain File
First, there are some places to put the plain file:
2.a) a simple XML file under software installation path
2.b) configuration file
Again, the user can just uninstall the software and remove these plain file(s), and reinstall the software.
- The Software Itself
If we put the protection trial info (Expiration Date, we cannot put Number of Used Times) in the software itself, it is still susceptible to the cases I mentioned above. Furthermore, it's not even cool to do so.
- A Trial Product-Key
It works like a licensing process, that is, we put the Trial info into an RSA-signed string. However, it requires too many steps for a user to have a try of using the software (they might lose patience):
4.a) The user downloads the software;
4.b) The user sends an email to request a Trial Product-Key by providing user name (or email) or hardware info;
4.c) The server receives the request, RSA-signs it and send back to the user;
4.d) The user can now use it under the condition of (Expiration Date & Number of Used Times).
Now, the server has a record of the user's username or hardware info, so the user will be rejected to request a second trial. Is it legal to collection hardware info?
In a word, the user has to do one more extra step (request a Trial Product Key) just for having a try of using the software, which is not cool (thinking myself as a user).
NOTE: This question is not about the Licensing, instead, it's about where to store the TRIAL info. After the trial expires, the user should ask for a license (CD-Key/Product-Key). I'm going to use RSA signature (bound to User Hardware)
P.S.: My software will be targetting the China market, whose software market is different from US. Most people in China, they only buy hardware, they usually don't buy software like Micosoft Windows/Office (they just use pirated copies). However, some professional software aiming to a specific field, research people are still willing to buy it IF there is no crack version or the crack version is very difficult to install.
Either option 1 (plain registry key) or 2 (plain file) is just fine. Here's my reasoning:
Standard-privileged users do have read permissions for the registry. If they can't read your key, something else is wrong. Standard-privileged users do not have write permissions for the registry, but this doesn't matter because they also don't have permissions to install software in the first place. In other words, either the user will have permission to create your registry key at install time, or they'll need help installing anyway. Therefore the basic technical issues you raised for the registry key aren't really a factor.
Just don't worry about those users who do things like set back their system clock or manually hack the registry to break your key. Let me say that again: Just don't worry about users who make a conscious decision to alter their system in a significant way to get past your trial limitations — and make no mistake, setting back the system clock or editing the registry are significant modifications. The reason you shouldn't worry about these users is that they represent exactly $0 in potential income. A user willing to make to take this kind of conscious choice about pirating your software isn't going to just give up and decide to pay for your product if it doesn't work. If they can't get your software for free, they'll either go with a competitor or do without. You're in this to make money - you don't want to spend time and resources trying to grab sales you can't win or sending users to a competitor. Therefore, the basic security issues you raised for either option aren't a factor.
You won't find a single perfect solution. The efforts you put into this should be proportional to the price of the product you make. If it's worth a lot, then buy a professional solution. If not, then use any combination of methods that you find. Use the registry, request an online trial key, check if the user manipulates the system time, and so on.
I would suggest taking a slightly different tact.
Give a "lite" version of your software away. No trial, just really limited functionality.
If they want to trial a "professional" version then ask them to get a trial key. This should be encrypted in some format, store it where ever you want. When the app starts, test for the existence of this trial key. If it's there then decrypt it. Inside the key should be the expiration date of the software.
Test the date and act accordingly. If it doesn't exist then just run as the lite version.
To get a trial key, you can have them enter an email address and some other info you want into a box in your app. It's not unreasonable to ask that the machine be connected to the internet for this limited part. Even MS Office requires you to connect to the internet briefly to validate the keys. Have the app contact your server with the key request. Email them back the key.
For bonus points tie the trial key to some metric of the machine itself. Even if it's just the name of the box. Those change rarely and it's a trial anyway.
If you truly can't force them to be connected to the internet to acquire a key, then you can go a slightly different route. Have the app generate a request (which includes the machine name or something along those lines). Have the user either call you with that generated request id or have them plug it into a website. Then email them the key for that machine.
All of this prevents sharing keys. Has a fall back in case the key location is jacked with and prevents the key from being moved to other machines. It also gives you a way of doing this in a completely disconnected manner. Even if they rip the public encryption key out of your app to decrypt the software license key, they won't have your private encryption key in order to build a new license key file.
Now, key management is only one aspect of the evil you are fighting.
The next step is that you need to obfuscate your app in such a way that they can't simply decompile it and bypass your key checks. This is much more common than passing around key files.
You might even have multiple methods in the app that test for the key in different ways.. But this is a different question.
As a final bonus for those vindictive enough to do this: Seed the various pirate boards with key gen software that does interesting things to the machines of the people who are trying to rip you off. You can get really creative here.
Or, like Joel said, you could just simply not worry about them. After all, if they are going out of their way to find a cracked version of your software they weren't going to pay for it anyway and you really haven't lost anything.
Can you require that users using the trial be connected to the internet? If so just have the trial version contact a server during startup and you can check all sorts of things. you don't have to worry about storing stuff on the users computer or them tampering with the data or the system time.
I know this is an old thread, but I just stumbled upon it and other might find this useful.
A valid option these days could be that your application queries a rest service at install time to generate a trial or payed license. Every time the user opens the application the application queries the rest service for the license info that is linked to that one specific copy of software.
There are loads of profilers and static code analyzers out there for C# assemblies.
Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.
I have searched all over the Internet and stackoverflow. There seems none for my wonder.
What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):
"Assembly Manipulation and C#/VB.NET Code Injection"
"How To Inject a Managed .NET Assembly (DLL) Into Another Process"
Is it just me being too worried or what?
BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.
If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.
To prevent someone tampering with your deployed assmebliles, use Strong Names.
Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.
Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.
Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.
The first thing you need to decide against what you are trying to protect?
Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money.
If the attacker has physical access there is not much you can do.
If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...
Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.