Where does an application store "I'm deactivated" on Windows? [closed] - windows

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
Applications often have registration keys.
It can arguably be placed in a file or in the registry.
Sometimes, an application is deactivated by entry of another key,
or the passing of a date, etc. Where can one safely
store such information about an application be deactivated?
A file isn't the answer; a backup copy can be restored to
defeat this. The registry is a weak answer, only because
most people don't know its there, and don't think to restore it,
and if they do they restore the whole thing which usually
has other discouraging side effects.
It seems to me that storing deactivation information is
hopelessly unsafe, as old copies can always be restored.
At best one can hide this data by obfuscation under
cryptically named files or registry keys.
Is there a standard trick I don't know, or a standard
scheme supported by Windows, that helps with this problem?
Round 2: I've seen a number of answers. None of them
specifically say "you can't do this" but several imply
that phoning home is the only good choice (for "deactivation").
Let's assume phoning home and dongles are NOT the answer,
and one has to leave something on the machine. What do
typical licensing schemes actually do in this case?

In contrast to the IPhone and other closed environments on an open platform like windows/linux you always run a very high risk that the protection is easily circumventable (local serial protection) or will be cracked by reversing and patching your code. Virtually every modern single player game has this problem. Additionally it is very hard to find a solution that does not annoy the user too much. We all remember the Sony-CD-Rootkit disaster and in the game industry its the always the newest DVD-protection that doesn't work on all drives the way its supposed to. But what can you do? You can try the usual serial, call-home option and ban certain serials in newer updates (Adobe, FlashFXP, Windows). If you have a very low consumer base, this probably is enough for you. If - for whatever reason - that is not an option, what about an USB-Dongle that is needed to use your software. Heard of quite some CAD-programs using this. One last thing you can look into, what about watermarking your application? If it shows up on certain p2p networks you will maybe be able to see where the leak is. Basically nothing will give you a 100% guarantee, but there are options to make it more difficult for the average user... Please keep in mind that most of your money should be spend on creating a great product not in buying mostly useless protection!

Create and sign a license file on a server. If you use public key cryptography, the license file can't be faked easily. Your application can be of course cracked to not need the license, but that's a different thing.

Here is a short but pretty good overview of different options.
http://www.developer-resource.com/how-to-protect-software.htm

Ya,you could encrypt things,that's what they do!.Check the net for various licensing schemes.Even microsoft has one...Microsoft Software Licensing and Protection
You can use the Microsoft Cryptographic API to develop you code.Plus obscure you assemblies or dlls.Force user activation.

All protection schemes are vulnerable to some type of attack. Encryption of information does help prevent attacks because the information is stored in an obfuscated way, but even this isn't unbreakable.
Another possible option is to store the actual activation state information remotely and leave a reference to this information on the machine, possibly encrypted. There are many ways to do this but one that comes to mind is to store a GUID of some kind that you could then look up in your database
One downfall of this is the requirement of an internet connection, I don't know if that is prohibitive or not but the general idea is to remove the activation state from a machine you don't control and put it on one that you do

Related

How to deploy a commercial portable application? [closed]

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
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.

Is it unethical to send data to myself once a customer installs my software? [closed]

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
I'm trying to get an idea of how often my software is being installed. I was thinking about just including a simple URL call in the background the very first time the software is started. I am not trying to gather a lot of information. I really just want to get the date and time the software was installed. Is this unethical or commonly done by other developers?
You could always just have the installer open up a "Thank you for installing our product" page that's hosted on your web server. Since this page would normally only be hit after an install it should give you a decent indicator without being evil.
P.s. Before anyone hounds me on this please note that Firefox does this directly after an install.
In my opinion, yes, sending any data back that isn't authorized is unethical. Most software will prompt you to ask if it's OK to send back anonymous usage data. You could also track downloads and guestimate how many of them are actually installed.
There are a number of software products that gather data from the user but they all get the user's consent before sending any information. I suggest you do the following:
Ask the users to register, this way you will know some basic information like (roughly) when the software was installed.
If you need more complex/interesting usage statistics then make this a feature that users can easily turn off. Some people are not comfortable sending any data to you, Eclipse does this very well, the first time it wants to gather some usage statistics it allows the user to turn off the feature right away.
Finally , which ever way you implement this feature ensure that the users can see exactly what data you are collecting and sending and can choose to not do so.
If you do this in this correctly way you will gather some data in a way that does annoy your users or intrude on their privacy.
Just popup before installation:
"If you click Yes, the date and time the software was installed will be sent to us via your Internet connection. We would appreciate it a lot."
Let "Yes" be the default option and avoid the popup if there is no Internet connection available.
Doing it behind the scenes is unethical in my opinion.
you will always have to ask before calling home with anything, no matter how harmless you think it is.
kind of like you should always ask permission before putting a shortcut on a desktop.
If you want to do that — ask user permission.
Some companies just have automatic check for updates feature.
Only do this if your application uses the network as a primary function, otherwise a user will get weirded out by their standalone application asking to get internet access through their firewall.
Also: If you add in-line updates to your software, or ask to check for software updates periodically, you can easily log this information.
this is kind of tricky, if u are getting the information about the software only; without identifying the user, perhaps it might be passed as alright.
just think of google, i know it never gets installed on your system, but chrome again is a google product, which i believe probes ur google searches to give relevant advertisements. what is reading a cookie, is it any different from reading information from your computer.
also i have seen relevant advertising poping up in yahoo mail when i search for shopping stuff on google. they for sure are reading some info on your computer or browser session.
I think its ok to send the info from software, as long as u have no way to identify from what user it is coming from.
I don't see any particular areas of unethical or illegality except for this: My software, my computer, none of your business if I want to install it or just have it sitting in an installer.
Although I think a convincing argument could be made that it literally is your business to know about your software's installs.
Best route is simply to request to send 'anonymous usage information'.
How many of you windows users tell windows its OK to phone home and verify that your copy is genuine?
0.
There are a lot of high and mighty my-computer-is-my-domain answers here, and the bottom line is while its rude, its not against the law. Rather, its commonplace. Stick a disclosure in the EULA and you're good to go.
It is unethical to hide your collection of usage statistics.
That said, almost every website has a TON of personally identifiable information in the form of web logs that are almost never used to their "fullest potential for evil"
To ethically collect your install count just ask the users to activate the product on first usage or ....
Provide something useful! Prompt the user to check for updates on first use.
This approach IS ethical, can get you better and more relevant data (you can put voluntary forms together) and allows you to make a value exchange.
I think the circumstances also play a part.
If the app is a free app and the developers find that knowing each time an app is installed then as long as the user is told then most users wouldn't have an issue with that.
If the app contains sensitivie data (i.e. financial or credentials) and you notice the app calling home then that would freak most users out and wonder what else is being sent.
Also another point is having it call home each time the app is installed doesn't really tell the developers much, what if a user reinstalls the app or the operating system? What if the call home is denied by security software or their computer isn't even connected?
In my opinion if you can't collect meaningful useful stats then is it really worth collecting them to analyze them?
It’s unethical.
In the case the URL is opened in the default browser: A user might have explictly set beforehand that your tool should not be allowed to connect to the Internet. If your tool just calls the browser, you are circumventing this.
In some countries, users may face oppression or punishment for using specific tools. While they might manage to get the tool via sneakernet, your phoning home would be detectable by authorities.
You might lose/change your domain. If Malice registers it, she’ll have access to the incoming data from installations of your tool.
When your software wants to phone home, inform your users beforehand and allow them to cancel it.

How to make a shareware program with a free demo [closed]

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 8 years ago.
Improve this question
I have a game that I'd like to sell with the following system: give away a demo (say, with the first few levels) and sell the full version. I'd like to make the transition to the full version as seamless as possible for the user. I've never sold anything before online, so I'm not sure how that would work (even if there were no free demo).
This seems like a very common issue, so I'd imagine there's a standard solution. I'm writing in C++, targeting Windows, and my installer is generated by NSIS.
There are two options:
A separate demo and full version. Your ecommerce provider will send the full version to people who buy it.
A demo that is unlocked by a registration key or online activation process. Registration keys can be generated on the fly (or taken from a pre-generated list). Ecommerce providers can then send the keys to customers immediately after purchase.
Both approaches have their pros and cons.
Separate full version
Smaller demo file, saves bandwidth
Less technical support required for customers who buy full version (in my experience)
Two builds of the game, more testing
Harder to distribute updated versions to customers - need to keep a login for each customer or a secret URL that expires after a few days.
Unlockable demo
Contains all assets, may waste bandwidth
Easier to distribute cracked version (pirates can distribute a 10KB patch or reg key and link to your demo file, more bandwidth waste)
Single build, less testing
Easy to distribute updated versions (everybody can download the same public version)
Regarding a "general" solution, look around for commercial DRM wrappers such as this one. Some game portals/publishers also require that you use their own wrapper.
Don't ship your full product as a demo that can be activated. This way you don't eliminate piracy (which will still be something you will have to deal with) but at least you remove the possibility of someone just downloading the demo, cracking it, and spreading it around (or even just a cracked executable). They would at least have to buy the full version first.
As for checking a legit customer is using the software, you can indeed do some online authentication as Danny suggest but note that this will only stop people from using your online services and it often is just a matter of time before a qualified cracker/reverser makes sure that your product's offline features can be used without purchase.
By not shipping the full product immediately, it does make upgrading a little harder, but there are ways around this, ex: Updater that only works after online authentication.
If you develop it correctly you should be able to have a checking mechanism after the Xth level. This checking mechanism could basically hit a registry key. This registry key could have some encoded information which was generated by your program. The key could basically represent an MD5 hash (or SHA-1 or SHA-2 if you really concerned with high security) of the installed machine MAC Address, the first and last name, so and so forth. When someone purchases the game, you have them input that data in a form and then generate a code to send along to the user to unlock the game. You could even take that same algorithm and put it on your ASP.NET website and automate the key generation after a purchase has been made.
My 2 cents:
Dont spend too much time devising methods against piracy. Use simple serial generator mechanism to unlock the game which user can enter manually during the execution.
I would say have a single build which can switch to trial mode or full based on the serial key entered. This will reduce the overhead of maintaining two separate code.
It is a personal opinion, that people who really buy software at first place will buy your game no matter how many pirated versions are available. So make registeration purpose as simple as possible which will deter a normal user from cracking it and at the same time easy to use. Hackers will crack it no matter what protection you use it. Otherwise we wont see the pirated copies of microsoft/adobe products etc who spend so much on making their products piracy free. No matter what they charge, people do buy it. Its the quality of the product which will encourage your users to buy your product.
Also, try not to impose locks on your software like using MAC address etc for generating the serial numbers etc. Online activation may be a good idea but remember people are skeptical as to what information you try to transmit while activation. Also you might have to provide an alternate mechanism for offline activation if your customers dont have internet connection or work in separate LAN.
Once you see that you game is getting popular and you see more pirated copies with users, you may invest more time and money on developing anti-piracy techniques.

Implementing Licencing mechanism for a Software [closed]

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 am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used. I am thinking of a mechanism based on hardware IDs etc. Do you guys have any better suggestions? What are the parameters/algorithms/characteristics that I need to concern to make a hack proof license mechanism?
Ideally you need something that is OS independent.
I would recommend that you embed the license protection within your code or wrap your application within it in such a way that it cannot be run without the copy protection code having run first.
It would be best if your application needs a license key file in order to operate and that this isn't generated locally.
One way of doing this is that your application generates some form of image code based upon the hardware on it's initial run. This is supplied to you and in return you supply the license key which will allow the code to run. Best to base the hardware image around CPU and motherboard as these will change the least often.
Your app. should check against hardware image and license key whenever it is run.
If you want your app. license time limited then it should also keep track of how long it has run and embed it within the license key file.
Don't forget to encrypt the license file.
Also don't forget to make it more difficult to reverse compile your executable by use of a dotfuscator or similar.
Check this question: What copy protection technique do you use?
It also links to other related questions.
First of all, nothing is hackproof, so i wouldn't spend too much time on protecting your software.
The downside of a mechanism based on hardware IDs is when a user buys a new computer or upgrades most of his computer he needs to update the key too.
HWHash is a pretty good HardwareID implementation, but i guess there are more (free) solutions.
At work we use Hardlock and Hasp keys, but these are usbkey solutions which are not very efficient for small applications.
I am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used.
Then how about a periodic online check of the licence?
When the user logs in the first time, the user verifies the install against his account and a licence file is stored on the users PC. This licence file is encrypted and contains all the data needed to uniquely identify the license. This is all stored on your server.
The licence file expires in set number of days or even months. Logging in after the file expires checks against the account and verifies its legitimacy. You might even consider generating a new licence file at this time.
There should be some smarts that give some leeway in the case that the users internet is down and the licence cannot be registered. Perhaps 7 days.
If the software is reinstalled on a new computer the user has to repeat the verification process.
As the others have stated there is no way to beat a determined pirate, since such a person will hack the code, but this should prevent or slow down casual piracy.
You can check out Microsoft's SLP - I haven't used it, but it definitely looks interesting (yknow, IF you're into MS stuff...)
One important point to note - no licensing mechanism will protect you from piracy, or even substantially reduce it. By definition, the licensing mechanism will be client-side - which is inherently breakable. Take a look at all what happened with DRM...
Your guideline should therefore be usability - the intent should be to use it as a general policy, the good guys will be comfortably limited to what they're supposed to be allowed to do, and the bad guys - well, the bad guys will get around your intent anyway, your best hope is to make it more work.
I'd be very wary of published software protection mechanisms, as they are much more likely to have published hacks. You are probably better off using some of the techniques to get a unique persistent ID and use this to roll your own protection mechanism. I also think that it is a poor idea to simple check the license whenever you run the program, as this leads the hacker to the location of your proection mechanism. IMO, your are better checking the license in a more random fashion, and more than once per session.
FWIW, I use hardware locks (hasp) for my high end desktop software, and device ID based licensing on mobile solutions. If you are selling small quantities of high cost software in a vertical market, IMHO, a good license protection mechanism makes sense, and hardware dongles work well. My experience has been that people will use more licenses than they purchase if this is not in place. For high volume, low cost software, I'd tend to live with the piracy based on increasing the size of the user base and product visibility.

Selling source code, What should I be aware of [closed]

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 have received a request of buying the source code of a website I have developed and I wondered if anybody have been in the same situation and if there is anything I should specially be aware of. Anybody got some advise on how I should handle this situation?
First - a caveat - I'm not a lawer. Not at all. But I care alot about intellectual property and not getting sued, so I try to learn about it a bit.
In no particular order:
Double check your employment rules - when you took the job currently paying you money, what is your arrangment? Did you have to sign any statements giving your company control over all the code you produced? Even if it was a personal, unpaid project - corporate ownership can get you if you signed a strict intellectual property agreement.
Used open source? - there are a few main open source licenses, read through and check them to see the terms for sale of a product with dependancies on open source.
What deliverables does buyer expect? - Built code? source code? Also - what can you do to protect your code (obfuscation).
Do they expect support? - be careful, in my experience with corporate customers, a helpful, free of charge "sure, just call me if you have a quick question" can quickly become time consuming. If you are willing to throw in a free couple hours, be very clear that you will give up to X hours of support for free. And be clear about what your billing rate is after. If you really don't want to support it, make the cost of your time very high.
What sort of support do they want? - answers & configuration help? Bug fixes?
What sort of installation instructions are expected?
What do they own when they buy this? - a single installation for a single server? a site-wide license to install it wherever they wish? or --- worst case -- do they own this lock, stock and barrel such that you may no longer develop it and continue to use it yourself?
Get these answers cleared up, in writing, with signatures.
It's a good idea to have someone external read it to check for ambiguity.
It's an even better idea to draw up the agreement and have a lawyer read it - your lawyer, not the buyer's lawyer.
Avoid any nod/wink/handshake deals. Personal trust is great, but people change if the situation becomes stressful. Or people come and go within companies - the buyer today may be a different person tomorrow.
The first thing you need to consider is:
What license are you providing the code under?
If you don't stipulate a license, they're pretty much free to do with it what they want. Is that what you want? It's hard to answer the question without knowing the specifics of the situation: why are you selling the source code?
If this is a customer and so it's they can do their own custom modifications that you were otherwise being paid to do, the price should reflect that "lost work". Also, you will want to limit their ability to redistribute or resell that source code.
If someone just likes your site and wants the code, be very wary because there's every chance they'll just take it and set up their own. This may or may not be an issue for you. But again consider the issues of resale, redistribution, usage rights and ownership.
Depending on what the code is for, you may also want to consider what it is used for, what it can be used for and how that will affect you professionally or otherwise. It's possibly you may want to restrict the code from being used for certain things (eg adult or poker sites) or you want to require attribution.
Also for all of these things, you need to consider what terms transfer in the event of redistribution (ie how "viral" your license is).
There are lots of open source licenses out there (GPL, Apache, MIT, BSD, MPL, LGPL, etc). I'd suggest you take one as a basis and modify it to suit your tastes. You're far less likely to get in trouble that way than you are with coming up with your own terms.

Resources