Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've developed a piece of software n C#.
And I already implemented a way for customers to upgrade the software using a single license key.
The single license keys are (32 chars) calculated based on some hardware stuff which isn't likely to change (a lot).
This all works pretty good.
However now I want to implement a enterprise license.
Basically I want the customer to be able to license the software on different (unlimited) machines with only one key (so I cannot use the hardware checks for this).
What would be an approach for this?
There are some things I can think of:
Hardcode 1 license key in the software which always works
Build custom programs for enterprises on request with their hardcoded license key in it (not really something I would like to do)
Make some function / algo / something that will check if a entered license key is valid (and still be able to use different keys per enterprise also 32 chars long).
The last option will be preferred I think.
However I cannot come up with a way to check if the entered license is a valid enterprise license.
PS
I am not looking for a way to completely stop piracy of my application, just a simple way to implement an enterprise license.
In my experience, you should go for the solution that results in the least amount of friction for your paying customers.
People will either pay for your software or not, and as long as you have some kind of mechanism to validate licenses, it really doesn't matter how strong it is. There is not a single piece of software that I can think of for which you can't find working pirated copies, which to a large extent makes all efforts in this direction wasted.
One of the things that bother me the most is when the pirated copy is better than the paid-for version. As an example, the virtual CD/DVD software Daemon Tools is protected by a mechanism that sounds somewhat similar to yours. It generates a machine and software-version specific key and is generally a hassle to use legally. I own a 5-PC license and if I want to update it, I have to go and revoke the old-version licenses, issue a new one and re-register the updated software. Repeat for every installation. I've often considered just using a cracked version as it provides a much simpler upgrade path, which basically just involves installing the software.
I realize that you have probably considered all this and may be of a different opinion, but your guiding principle should be to make the paid-for experience beat the pirated one.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm (soon to be) graduate working on my first ever public release of a program and my ceo/boss' want to manage/"lockdown" the amount of times a client installs our software, I'm looking for the best practices for this or just best advice on how to do some sort of control on installs. I'm using the Visual Studio Custom Install Shield utility! I'm also working in C#, wpf, mvvm, if that really matters. Thank you in advance!
I'm moving my comment down as an answer; this is a fairly broad subject though...
As I mentioned in my comment, you would likely want to require online registration during the install process. During the install, the user would need to fill out their registration info that gets submitted to your registration servers. You can offer them a choice of different seat license packages starting from a "Free 30-day trial" up to an "Enterprise" edition with 20 seats, and free upgrades for 2 years (or whatever). As an extra bit of assurance that your product remains un-pirated, you may want to require the license authentication each time (or every so many days) upon the start-up of the program.
The benefit of this model is that you control the number of installs on your end. If the user needs more installs, they can contact your support staff, or go to your website, and purchase more seats/installs. Having an online central authentication server also makes it a bit harder (but not impossible) to pirate your software. Of course though, now we start into the realm of security and loss-prevention versus ease of use for your customers. But that is whole other subject for another time.
You may want to look around for a pre-built solution. I am sure there are services/products out there that do just this, that you can incorporate into your product.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Overview
Over the last 3 years we've built a full-featured software package in C#
Our software was architected in such a way that it handles a lot of the low-level plumbing required for the application so that our developers can focus on the specific problem they are trying to solve rather than all the minutiae. This has improved development and release times significantly
As such, the code is broken out into various projects to give us logical separation (e.g. a front-end MVC app, a services layer, a core framework layer, etc)
Our core framework project has a lot of functionality built into it (the main 'guts' of the application) and it has been carefully organized into various namespaces that would be familiar to all (e.g. Data Access, IO, Logging, Mail, etc)
As we initially built this, the intent was always for our team to be the target audience, our developers coding the various new pieces of functionality and adding to the framework as needed.
The Challenge
Now the boss wants to be able to open our codebase up to 3rd party developers and teams outside of our own company. These 3rd party folks need to be able to tap directly into our core libraries and build their own modules that will be deployed along with ours on our servers. Just due to the nature of the application it is not something we could solve by exposing functionality to them via REST or SOAP or anything like that, they need to work in an environment much like our own where they can develop against our core library and compile their own DLLs for releases
This raises many concerns and challenges with regard to intellectual property (we have to be able to protect the inner workings of our code), distribution, deployment, versioning and testing and releases and perhaps most important how we will shape the framework to best meet these needs.
What advice would you offer? How would you approach this? What kind of things would you look to change or what kind of design approach would you look to move towards? I realize these questions are very open-ended and perhaps even vague but I'm mainly looking for any advice, resources/tutorials or stories from your own background from folks who may have faced a similar challenge. Thanks!
I'm not sure the MEF answer really solves your problem. Even using Interfaces and MEF to separate the implementation from the contracts, you'll still need to deliver the implementation (as I understand your question), and therefore, MEF won't keep you from having to deliver the assemblies with the IP.
The bottom line is that if you need to distribute your implementation assemblies, these 3rd parties will have your IP, and have the ability to decompile them. There's no way around that problem with .NET, last I checked. You can use obfuscation to make it more difficult, but this won't stop someone from decompiling your implementation, just make it harder to read and understand.
As you've indicated, the best approach would be to put the implementation behind a SaaS-type boundary, but it sounds like that's out of the question.
What I will add is that I highly recommend developing a robust versioning model. This will impact how you define your interfaces/APIs, how you change them over time, and how you version your assemblies. If you are not careful, and you don't use a combination of both AssemblyVersion and AssemblyFileVersion for your assemblies, you'll force unnecessary recompiles from your API clients, and this can be a massive headache (even some of the big control vendors don't handle this right, sadly). Read up on these, as they are very important for API/Component vendors in my opinion.
NDAs and/or License Agreements are another way, as #trailmax indicates, if you feel your users will respect such agreements (individuals vs. companies may view these type of agreements differently).
Oh, also make sure that you Sign your Assemblies with a Strong Name. And to do this, you'll probably need to establish a strategy to protect your Signing Keys. This seems simple at first, but securing your signing keys adequately is not as easy as it appears at first blush. You often have to have multiple sets of keys for different environments, need to incorporate the keys into CI/CD systems, and need to insure access to the release keys is tightly held.
As #HighCore already said, implement interfaces for all the stuff you want to expose. Put them into a separate project/repository and give read-only access to the project/repository. But your interfaces must be properly documented, otherwise it might be painful for other guys.
This way your code is not really visible to them, and they can still work on it.
If that does not work-out, and you are forced to show them your code, get them to sign NDA. NDA should state that your code is yours and they can't redistribute it in any way.
I guess my answer is as vague as the question, but gives you some ideas.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've made a program that I need to license before selling it to customers. Since I'm not sure, that it will gain me at least the cost of commercial licensing software, I would not like to buy one.
So I'm looking for advice on how to implement licensing feature with following logic:
All license keys are validated on server side each time application starts (no licensing info is stored at userside except the license number).
There is only one application running with one license key at the same time.
What I do not know is how to protect my program from simple decompiling/disassembling and just removing a call to check license? Or making own server that will make a response true on each license? How does such security normally made?
I've searched for free SDKs or something like that, but could not find anything.
I'll be very thankful for your help!
P.S: I do not aspire to make the system "indestructible", but I would like to receive the protection that is more expensive to crack than paying $5.10 for a copy of the program.
P.P.S: Sorry for my bad english.
What I do not know is how to protect my program from simple
decompiling/disassembling and just removing a call to check license?
Or making own server that will make a response true on each license?
How does such security normally made?
You are confusing licensing and obfuscation. To prevent the above, you will need to obfuscate your exes and dlls using an obfuscator.
Since I'm not sure, that it will gain me at least the cost of
commercial licensing software, I would not like to buy one.
IMHO you are much better off focusing and spending time on your actual software than in developing a licensing scheme from scratch (re-inventing the wheel as they say).
If you do open up to paid solutions, take a look at CryptoLicensing (for licensing and copy-protection) and Crypto Obfuscator (for obfuscation and code-protection).
DISCLAIMER: I work for LogicNP Software, the developer of above mentioned products.
(Sorry can't comment on other people's posts???)
It depends on what your application is doing.
I'm currently faced with the same problem as you. I'm going for a log in system, simply fetch and compare to what's in the database. If not present do not launch app. Not that I need more, the application relies on my database and without it it is useless.
Then they can spend a couple of hours figuring out what my database looks like based on what they see on queries or practically rewriting my entire product. I'm going to spend little on in app security. The only protection I wish to have is not to show my server's data.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
First of all, I understand that almost all applications can be cracked (especially written in C#). My question here is to make it a little bit harder to crack.
Suppose that the user has saved the License file under the Application.StartupPath, where all users can read.
And then, every time when the application starts, it will check if it can find and verify the license file.
If the application can find and verify, we let the user to continue with full functionalities.
If not, we prompt a MessageBox showing "Unlicensed, continue to use with trial version, functionalities limited."
My question is, if I'm a hacker/cracker, I would try to get around or bypass the licensing check instead of cracking the license file, because, if we use RSA signature, it's very difficult to crack a license file.
So where should we put the license check?
P.S.: and also, is it safe if I put a global variable IsLicensed (true / false) to limit the functionalities? Is it easy for a hacker to change IsLicensed = true?
The #1 law of software licensing: You don't control your software once you allow it to be installed on a computer you don't control.
If you want to keep control over your code, you need to make it a web service and give the end user just a thin client that interfaces to that web service.
In many scenarios, this is unacceptable, because users want to be able to use their software even when they don't have an internet connection.
In almost all cases, you should focus on making the user experience better, and all forms of copy protection make it worse instead. Once you get to the point where the experience of downloading from a warez site and running it through several virus scans is better than doing the license setup for the legit version, you've lost.
You can obfuscate the code (make it harder to decompile/use the reflector on it), but with enough energy and knowledge, it will get broken, after that it's quite easy to change the bytecode of the assembly, thus circumventing the license check. Also, you could invest the money to make it possible for you to sign your assemblies, which would make it harder to change the assembly itself, but with enough energy (more than just breaking the obfuscation) this can also be circumvented.
Your goal shouldn't be to make the license process unbreakable, but to make your software itself worth to buy. This is a much better protection. Crackers (and only them, hackers are something completely different, see this article for more) won't be hindered by that, but with the software being worth it, much more people would buy it.
I think that check should be done in several different places in the source code; it is much harder to catch all of them than only one. Also, if wants to protect program written in C# (or any other .NET language), one should consider to use some obfuscator. In counterpart a cracker or even lamer will be able to crack a program using some software like .NET Reflector
As mentioned previously, one can simply use .NET reflector to get the entire source code of your software (in fact, it can even get it in VB.NET or other languages even if you're written it in C#!). You must obfuscate your assembly if you hope to have even a chance at slowing a cracker's progress.
What is to stop people from directly copying licenses? If you have a license which is signed, it will then just be signed in two places -- what have you put in place to stop this? Never mind whether a global variable would further weaken your protection without taking into account trivial "cracks."
There really is no good answer to this as Ben Voigt pointed out. If you need something that is uncopyable, make it a closed-source web application. Astalavista will show you that most things have been cracked. Adobe products which cost thousands of dollars have been cracked and I'm sure their employees are quite well versed in copy protection techniques.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
If you would want to build the most expensive possible web application what would you use?
Without buying Microsoft products except VS2010 and SQL Server database.
Does the value increase lie in the technologies that you use and in architectural patterns applied?
If so, what to use among .NET technologies in all application layers to increase the website value?
I am asking this because I have business opportunity and I have no money to invest thus I want to cover my partner's investment with technology contribution.
Thanks a lot.
IMHO I would not try to increase my website value by investing into expensive technologies :-)
I think you should put the working hours together it tooks to build this website and multiply this with a factor, which corresponds to your value.
I think you would be on your way using ASP.NET MVC development (Possibly MVC3 with EF 4.0 as ORM) using VWD Express 2010 and Sql Server Express (If you are hosting on your own, else the hosting company will give you Sql Server Db) now then then move on to Sql Server 2008 and visual studio after you start making money and the website hits increase. It may also be possible to continue using the same if you think the performance is alright.
Of course this is a simplistic answer, Mariusz is right as well.
Bob Muglia of Team Silverlight posted a blog entry after Microsoft's PDC conference. In regards to rich web applications, Microsoft has dubbed Silverlight its technology of choice (i.e. to compete with Flash). However, with the emergence of HTML 5, Microsoft may be switching its decision.
What does this all mean? Silverlight / HTML5 are Microsoft's technologies of choice for rich web applications. This does not mean that ASP.NET (including MVC) loses its value, but as users' demand for richer, more interactive web applications continues to increase, I would invest more in the tools that will help me with SL and HTML 5.
And this does not change the value add of Visual Studio / SQL Server.
Cutting edges are the first thing to get blunted.
I would go further that Mariusz and say that actually, while there are marketing advantages just in being able to talk about the cutting-edge tech that you use, in terms of the long-term value (whether to a customer or an investor), the use of cutting-edge technology is something that has to be justified, as much as it is a selling point.
Firstly, some cutting-edge tech requires the use of someone else's software. Even if it's open-source you are now dependant upon that other supplier. If it's proprietary, you are even more dependant (the possibility of forking off a custom version that suits just you has gone - not something you'd want to do with any software, but at least there is the possibility if you have the source).
At the same time as that issue, if it's licensed for a fee, then this adds to the TCO of you system in a way that doesn't benefit you (i.e. if each installation has third-party software that costs X dollars to set up, that's X dollars you have to include in your price that you never get any value from as a vendor).
Secondly, today's cutting edge technology can be tomorrow's fish-and-chip wrapper*. Indeed, one can say with absolute certainty that some of it will, while some of it becomes a common part of many people's toolkits, and some of it finds a niche in which it remains important while never becoming a tech that a very large number of people use.
That's a safe prediction. The tricky prediction is which will do which. The factors affecting this are a mixture of technological, psychological, social, political and marketing factors in a competitive landscape where it's hard to judge which of the current players will dominate and there's nothing to say that something new will kill all of what's there.
Now, none of this means that you should shy away from the cutting edge. None of it means that you should shy away from using third-party tech (whether proprietary or open). It does mean that you should be sure you are getting value out of it. If you use what's been tried and tested for the last ten years, the chances of it still being just as reliable (and perhaps further improved) in five year's time is much greater than if you use something that is six-months old.
The way to turn cutting edge technologies into a competitive advantage is not to use them, but to use them to do something that you couldn't do, or couldn't do as well (reliably, cheaply, quickly, efficiently all count as "well") as you could otherwise. Even here, if you can think of a good way to turn older tech to the use that someone else is putting newer tech, you may be able to compete with a cheaper and more dependable product.
It is also important to stay aware of tech relevant to your field that you choose not to use - the flip-side of it being hard to predict what will survive and grow is that tech you decided not to use might become tech that you later do want, or even need, to use.
In the end, all technical decisions become both assets and liabilities to future development and the value to customers and investors. You can't expect the tech to sell itself, you can only make sound technical decisions, so that the people who sell the tech (whether that is someone else, or you in a different role) have an easier job when talking up the assets.
*In days of less heavily regulated hygiene practices, it used to be common in Britain and Ireland to wrap fish and chips in old newspapers. I'm not sure how well the idiom about today's news being tomorrow's fish and chips translates to readers in the rest of the world.