I am working on making educational CDs. I require medium level copy protection code which may not be easily breakable by "non experts", similar to that in game CDs, so you have to have the CD in the drive while playing and have to enter key while installing it.
I think CD copy protection mechanisms MUST BE STAYED AWAY FROM! They cause your software installations recorded on such CDs to run incorrectly on many devices. What such protection mechanisms do is inserting BAD TRACKS on your CD hoping that the CD copying program will choke on them. However, the driver of the CD drive may choke as well. You're better off with an additional privacy prevention scheme.
Whatever trick you'll find, someone smart will find away around it.
Decide first for what kind of users you want to protect your software:
For casual users and kids, it might be enough to check the volume id
For more advanced users, consider using commercial protection software like SecuRom
You may also consider using a registration via Internet, where you provide your users with a 'license file' in which their username (and maybe some other configuration information) and a checksum is stored, and which should be saved on their PC. Users and especially companies are then less likely to hand out this configuration files to others, as this file simply states "I handed out my license to someone else, so if you want to sue someone, sue me".
Many games use third-party software such as SecuRom for this.
If you do not require that level of protection, you can simply check for the presence of certain files on the CD. That will stop people from running without having the CD, but not from copying the CD itself.
Related
Just thought I'd run this idea past far more experienced heads.
I've made a desktop application in java 8. It is a niche app that will be sold via a single website. The market is individuals in a specific work environment who would not be "tech-savvy", and who are either on or chasing a 6-figure salary. My client, the publisher/vendor anticipates sales of maybe (don't laugh) 50-100 per year... so it's very niche. The retail price of the software, because of the low volume and niche setting, is to be around $100. So it's just a pet project that maybe helps to fund the family holiday at the end of the year.
The target customers will be on a high enough salary to not worry about paying the premium for the software (tax deduction anyway), which will directly enhance their ability to make more money, but they also have a reputation for having few scruples, and would generally not care about casually copying the software and giving it to their work mates.
The software will not be able to connect to the internet, so it's stand-alone, isolated.
So I need a copy protection scheme that is simple, not onerous to the end user and, due to it's target market and low volume, doesn't need to be "hacker-proof".
So this is what I've come up with:
Vendor has a "password" generator, that uses a simple algorithm, an
adaptation of the Luhn formula, that is capable of a few million
unique 8-char strings, out of a total possible pool of a few hundred
billion. So a valid password would be very hard to guess. Software
downloaded, generated password emailed to customer.
Software checks the "password" for validity, using a checksum-related
scheme. If valid, software is unlocked, and an invisible file is created somewhere generic on the hard drive, which flags that the software install is valid.
A different invisible file is written to the parent folder of the
software, which contains the provided original password. This is storage for passwords that have already been used, and are therefore invalid.
Next time the software is launched, it checks for the existence of
the validated-flag-file-- if it exists, then the software launches,
otherwise it asks the user to contact the vendor for a new password.
Whenever a user needs to type in a new password, the software checks the "invalidated passwords" file. If the user types in the original password, the software won't launch, because it's invalidated. But the file also needs to exist in the parent folder, so it cant be deleted either.
The idea is that if a casual user copies the software either by itself, or with its parent folder the software wont work on another machine, even if they have the original password, but if they are legitimate (registered user who needs a copy for working at home etc) then they can contact the vendor for a new valid password, that will then work on the new copy.
Hope that makes sense.
Comments, suggestions?
Full disclaimer: I work for Link Data Security and is your competitor, but this doesn't stop me from giving a few advises, as badly made protection damage the whole copy-protection community.
First of all you need to look into how hackers crack your program and try to deffend against their usual attacks. That would be debugging, changing your code when testing for validation, copy of key/validation-file and many more. This is the things I can remember from the top of my head. There will always come new cracking methods, due to hackers being very creative people.
If I was you I would try to run my program in a sandboxed enviroment, see what it does. Then make sure that files created or such doesn't help the hacker to find a good way to hack your protection.
Next time the software is launched, it checks for the existence of the validated-flag-file-- if it exists, then the software launches, otherwise it asks the user to contact the vendor for a new password.
From your description of your program I find it worrying that copy/move of your validated-flag-file to a new computer seems to break the copy protection. Also finding invisible files is the first thing a new hacker will learn, so this is the same as no protection.
A colleague of mine wrote a tutorial on what to take into consideration when making copy-protection, maybe this will help you on your way to being a copy-protection expert: All About Copy Protection
I just finished my program, now I want to build a setup with Inno-setup that gets the hardware id and and stores it into a file in the CD so that the program can be installed in only one computer with only one license. Unfortunately i am not good at all at Inno-setup scripting language. Anything you guys can do to help me will do, anything, even small hints,
Please help i am out of options right now.
I want to build a setup with Innosetup that gets the hardware id and and stores it into a file in the CD so that the program can be installed in only one computer with only one license.
You want to create a unique Installer and CD for every client?
Wow, that's a lot of work. It only makes sense for a really small business.
Anyway, in regard to getting a hardware-id:
There is no function in InnoSetup to get a "hardware id".
You probably mean some kind of identifier, like a hard-disk or motherboard serial number, right? You could decide to fetch some serial numbers or identifiers by querying the WMI.
But wait? You compile Innosetup on the developer machine, right?
The only hardware-ids you could possibly get at that time are IDs from your own developer machine. How do you get the hardware-id of your client, which is later trying to install your software from CD?
The whole approach doesn't make much sense and is flawed.
In general, doing this kind of protection in the installer is kind of useless.
Please handle your protection in the application, not in the setup.
You might use one of the following approaches: "API-Key" or "license-code" or "license file" or "hardware-dongle".
In other words: its always the same installer on multiple CDs, but the additional separate license code makes the difference - not during, but after the installation. The user simply enters the key or loads the license-file into the application and gets "Application registered to XY".
My application currently writes files to its installation directory which means Program Files isn't a valid option (I know this isn't ideal). But I would also prefer my installer (Inno) not to require admin rights i.e. no UAC; I think Google Chrome does this.
Which common location would make sense to default to with both these restrictions in mind?
If you really want to make a per-user installer that does not require admin permissions, the correct settings to use are:
[Setup]
PrivilegesRequired=lowest
DefaultDirName={userpf}\YourAppName
Note that (addressing Glytzhkof's concerns) this is a local folder, not a roaming folder. If you want settings to roam then you will still need your application to keep them in (your language's equivalent of) the {userappdata}\YourAppName folder. Regardless, the user will have to separately install the software on each machine that they intend to use it on (but this is typically the best option anyway).
Some of the downsides of making a per-user application are:
You cannot use admin permissions when installing. In particular this means that you cannot install many other components (runtimes, libraries, etc) that you might have wanted to use in your application. You also can't use features like regserver and restartreplace. (This doesn't necessarily mean that you cannot still use these components, just that it's a larger hassle if the user does not already have them installed.)
If a single machine has multiple users (common for families and in some workplaces) then they will have duplicate independent copies of your application, which have to be individually upgraded by each user. This particularly annoys IT departments as they prefer doing central upgrades, and if your app is large it may waste disk space.
If the reason you don't want to make a normal {pf} based application is simply that you want to be lazy and store settings files in the program's folder, then it's probably better overall to rethink this decision. It's not hard to do it "right".
There are basically 3 types of files: 1: user data, 2: application settings, and 3: binaries. Plus a few exceptions. I assume Harry is suggesting to write to a user's application data folder with configuration and settings files, and not the whole application. Don't ever put binaries or data here, but do save settings files here.
The whole concept of "roaming files" is a bad idea in my opinion. It clogs your userprofile and increases logon time on each computer and causes all kinds of synchronization issues when people leave multiple machines logged on simultaneously for weeks at a time. The whole roaming concept works only in theory in my opinion - but it depends on user discipline and application quality in its data management. Rarely edited and mergeable files can work, if the application is good. I have seen it work well for spell checker custom dictionaries and similar. The real solution is client/server applications with back-end databases for the purpose of persisting settings. Everything else will eventually fail - if it's a light weight app that might not matter.
User data should be saved to the "My Documents" location only. and only a few configuration settings should roam. If a network is set up to allow "My Documents" to roam, the system administrator should be shot immediately :-). It must be a server share accessible regardless of the computer the user is logged on to.
I've flown off the handle here and answered too many questions you didn't ask. Just hate seeing people head for problems they might not know about. If you have a super small application that is basically "portable" as we call it in deployment. That means an application where you can run off a single folder on a USB stick, then save everything in User data, and keep the application small and lightweight with a single settings file and a binary. No UAC or admin rights should be needed.
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.
I'm developing a commercial project on an ARM based embedded board with a custom Linux kernel on it, using Ruby. Target workspace of the project and the device is a closed-environment, no ethernet, inernet, I/O devices etc... I want to protect my code/program so that; it'll only work on the specific machines I let (so; people cant just copy and paste my code/program on to their embedded boards and run it w/o permission). This can probably done with the machine's MAC address tho; I don't have any experience on the subject. I guess, just a simple if(device.MACAddr == "XX:XX....XX") wouldn't be depandable (not to mention people can just easily delete the check from my code). I can't use some ruby obfuscators, which I found thru google, beacuse; the device doesnt run ruby-external-C-libraries or such stuff, only pure ruby code.
So; what are your suggestions, what type of approach should I take?
you can't really protect it, its hard enough protecting native code! and even then that basically fails if someone really wants to copy the software.
basically do very little if anything to secure it, its mostly wasted time and effort
This is isomorphic to the problem of DRM. You're giving a person both a lock and the key to that lock, and trying to stop that person from using the key in a way you don't like.
Therefore, I suggest using the same methods that other DRM users do: put your terms in the license, and sue them if they violate it. You need to use the law to enforce the other terms of the license, anyway.