I'm a bit stumped at this. I have a pretty unique hashing algorithm, etc. for key/license creation; i'm not worried about that part.
what i do need ideas on is how to disable a product on invalid...er, validation.
it's on a linux platform and uses config files, etc.
i have a couple choices for action based on invalid license:
-wipe out config files (however, easily restored from backup)
-replace the binaries with non-functional binaries (but these can easily be restored from backup etc.)
-simply flag the support staff for later contact, but that still doesn't solve the problem of disallowing non-licensed copies.
ideas? i don't really have a satisfactory solution to this so far.
Whatever you do, don't mess with the to program to the point of breaking it. If your validation algorithm fails and a valid license is flagged as invalid, you have one angry paying customer who can no longer use his paid program.
I'll just display a modal window on startup that reads something along the lines:
This copy of the program has not
passed the license validation. It is
possible that you are running an
illegal copy (maybe purchased at an
unethical retailer). Please cal
1-800-whatever or send a mail to
licensing#whatever.com to put a
solution to this problem. If you think
that you are running this program with
a valid license and this message is an
error on our part, contact the above
phone/mail and we'll correct this.
Related
Firstly, I am not a professional coder. I am working for finance unit of an international firm, responsible of preparing financials etc. for regulatory bodies etc.
I have designed a PowerShell solution which looks for specific files in network drive and if it finds the files, sends them via outlook e-mail to my team members. But if it does not find the files, sends the e-mail with a warning text etc.
This was working fine until our IT admins applied a system-wide PowerShell Constrained Language mode. This mode prevents running of outlook-related e-mail automation commands in ps1 file and making my solution useless.
My 1st question is about bypassing this mode and the powershell itself. Can I design a similar solution in visual studio ? If so what kind of project should I work on, in which language?
My 2nd question is about insisting on my current solution. I can understand IT admins in my organization putting PowerShell Constrained Language mode into use, as there are risks of viruses and attacks with bad intentions. Is there any other way which eliminates these risks while keeping my solution still working.
p.s. I have excel vba codes of the same solution but I do not want to use it as it interrupts my work while I was doing something in excel (excel is nearly always open&busy in my PC).
As the comment thread contributors suggested, the way to solve this kind of issue is to talk to the management. Do not try to work around the technical safeguards, although it would be easy to do so. If you do, keep in mind that intentional violation of a security policy might be a fireable offence.
When dealing with your boss, a solution-oriented approach is often useful. Don't just complain about the policy, offer a solution. Write up max two pages memo explaining the issue. Include an estimate how much manual routine work you have to do, if they are error-prone, what are the effects of an human error and what more productive things you could do meanwhile. Even if it's five minutes a day, sum it up to yearly level.
The important thing is that you propose solutions. You could ask IT if they have any ideas. For example, IT could sign the script. They could take over the whole thing, so you wouldn't need to worry about running it anymore. Maybe an existing monitoring system could watch the files for you. Explore the options.
Don't overdo the memo, less your boss is going to wonder how many hours you've used to write a memo instead of, you know, doing your actual work. See The Workplace for further advice.
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".
I've used plenty of cocoa demo apps that stop working after 3 days or a month or so. How do they do that? What's the best way? Also, what are the limitations?
(Disclaimer: I've never made a trial version before, only read up on the subject and used a bunch of them.)
The limitations all come from the fact that anything on the user's system, the user can modify. So:
Clever cheapskates may alter your app's executable to stub out or otherwise defeat any check you make.
You have to store the amount of time used (or, more lazily but not as user-friendly, the date they started using your app) somewhere. Wherever you store it, the user must be able to change it (since your app runs as them), which means that if they find it, they can reset the clock.
It isn't possible if you run in a sandbox, unless you store the aforementioned time-tracking data in the user defaults or the Keychain, either of which might as well be in plain sight, or request the temporary exception entitlement for writing anywhere on the file-system. Time-limited trials can't be in the App Store anyway, but if either the App Store or sandboxing becomes required in a future version of Mac OS X, your time limit will break, and we can only hope it doesn't prevent the user from using your application entirely.
There's also the matter of handling payments. One way would be to sell the app in the App Store, without any trial-enforcement code, and distribute a separate build yourself that always enforces a time limit. If you do handle payments yourself, you need to store a record of the user's license on the user's system, and you need to check that license. This then becomes vulnerable to the same problem: The user may forge a license or “borrow” (e.g., download from a warez site) someone else's.
The upside, of course, is that the user has some amount of time to try the application for free without having to cough up any money, so at the end of that time (if your application is good and fills their needs), they'll be more likely to buy.
At the end of the trial period, you have a choice of what happens:
Lock the user out of the application entirely.
Cut out features. Acorn does this.
Let them open documents, but not save or print. (You can block screenshots, but then good luck handling bug reports.)
Let them save or (if applicable) print, but degrade part or all of the document in some way. For visual creations, such as images, a watermark may work. For audio, you can limit the sampling rate to something unpleasant like 20 kHz or less. (There's a case here for having your own proprietary format that you always handle losslessly, and only degrading exports to common formats such as TIFF, JFIF, or AIFF.) Fission does this.
Just nag them. (Can be combined with any of the above.)
Nag them and put a delay on the user's ability to dismiss it. You can even increase the delay the longer the user goes without paying.
One good alternative to the trial period is to have a separate “free” version with fewer features (or with ads). This is especially common on both App Stores.
Another consideration is whether the trial period is days used or days since first use. The latter is easier to implement, since you just record the date of first use and do subtraction. The former is more user-friendly, as it does not punish the user for launching the app once, playing with it for five minutes, and coming back to it for a real trial 31 days later.
You can also implement a limit on number of launches. It's as simple to implement as days-since-first-use, but doesn't punish only playing with the app once.
Some users just won't pay. Some users will do practically anything to not pay.
So you need to strike a balance. You need to provide a basic level of difficulty so that the laziest cheapskates cannot simply defaults write com.example.yourapp DaysSinceFirstUse -int 0 and keep using your app forever, while not making your app so onerous to try out (much less pay for) that they don't.
So here are some things not to do:
Attempt to enforce equality between the name of the user on their license (entered at purchase) and their name on their account or in the Address Book. There are a dozen different ways to write any name, and some people have multiple names (through marriage, aliases, legal name-changes, multiple languages, Star Trek fandom, etc.), so this or anything like it is a bogus check that will upset more legitimate users than discourage pirates.
Hold the user's data hostage. See my above point about the merit of a proprietary format that you always handle losslessly. If you do always degrade output during trial, make that absolutely clear up front in the app's on-launch “This is a trial version” dialog.
Require an internet connection. Not everybody has one (that can connect to arbitrary servers), and not everybody has one all of the time. Learn from the games industry: Don't alienate your users.
Install any sort of copyright enforcement software that runs in the background and/or is in a separate place from your application. Users will rightly hate you for this.
As for how to do it, here's what I recommend:
Implement a “days of actual use” check. This can be a selling point. It warms my heart when a trial explicitly says it uses this kind of check.
I'd say store it in hours. On launch, get the current number of hours from wherever you store it. Add two hours and write it back (so the user can't force-quit your app to defeat this). On quit, add the real number of hours since launch to the originally-read number and write the revised number back.
Store it in an invisible file in Application Support. Encrypt it (again, you want to defeat casual piracy), but don't waste too much time bulletproofing it. Remember, your app must contain everything to both encrypt it (to keep track) and decrypt it (to perform the check), so a sufficiently determined (and educated) cheapskate can break this no matter what you do.
On launch, get the current number of hours from wherever you store it and test whether it's over the limit. (If you take my add-two-hours-right-away suggestion, do that after you test against the limit.) 30 days is 30×24=720 hours. If it's over the limit, enact your trial-expired measures.
If you sell the software yourself, use symmetric public-key encryption for the license file. I think AquaticPrime does this. You encrypt licenses with your private key, and distribute the public key in the app, which uses the public key to decrypt and check the license. Practically unbreakable. You send license files to customers by email using the email address they provide at purchase. (Tell them that they will receive the license by email so they don't enter a made-up address.)
If you do this, make sure you test entering the license, both before the trial ends and after it ends.
Do the trial check only if there is no license.
If you can sell your app in the App Store, I recommend you just do that. If you want to also distribute a trial version yourself, do that with no licensing code in place, so the trial check simply happens unconditionally. The App Store version, of course, does not need (and must not have) a trial check.
Watch this. (Note: It pre-dates both of Apple's App Stores.)
In general, they save a count of days/hours/whatever used somewhere, e.g. in the app's user defaults.
Since it's fairly easy to change an app's user defaults, some write a simple hash to the file that has to match the number of days used. If not, they expire the build right then and there because a user obviously just mucked with that setting. Others keep several copies of the number of days used counter. If one is missing, they restore it based on the lowest number in one of the other locations.
Good locations are invisible files in locations the user wouldn't expect, maybe named so they look similar to a file by another app or a system file. But be careful that you don't litter files across the file system that then give the other app they look like a bad name. Also worth considering is writing a resource into a file's resource fork, where most people don't look anymore these days (one of your files! Another app or the system may replace their file and strip your info, or may use the same resource type and cause a collision).
Chances are, a casual hacker will try to edit the user defaults and then give up. A dedicated hacker will keep going no matter how much effort is put in the protection scheme, so it's not worth spending too much time on protecting it.
Some app developers instead generate a license key that has an expiration date in it and make the app refuse to run without a valid license key. There's a nice article by Allan Odgaard on how to sign information using OpenSSL (make sure you use LibreSSL or CommonCrypto.framework these days, which are very similar) to get the expiration date to your user without them being able to edit it: http://sigpipe.macromates.com/2004/09/05/using-openssl-for-license-keys/
Based on your ideas I made a short proof of concept in Java using Elliptic Curve Cryptography to generate a UUID on start up and then sign that UUID with ECC to create a registration key. The code is here if anyone wants it.1
I wrote a download manager (in the AutoHotKey language) for a client and it gets flagged by a minority of virus scanners (11% of the scanners used on VirusTotal) as being a trojan, malware, dropper, data stealer, etc. Since my software is none of those things I'd like to correct the erroneous flagging by these scanners. Has anyone dealt with this sort of problem before?
The real complication here is that since this is a download manager the actual signed binary I am delivering is different for each of thousands of downloads, so it's not practical that I could request each and every unique version be white listed or something.
I'd prefer not to try and use actual cloaking techniques to try and fool the anti-virus companies when I really have nothing to hide, but I'm not sure there is another choice (and I'm not sure I'd be successful). Any advice?
Trik has provided the following answer on the forums:
In the AutoHotkey folder (Held in
ProgramFiles) there is a sub folder
named 'compiler' in that folder is a
file named 'upx.exe' rename that to
something like upx.old (or any other
file extension). That should solve the
problem.
Please comment on whether this worked or not.
I'm answering my own question here, and sadly providing a less than satisfactory answer, but it seems the only one available...
From what I've found there is no way to prevent some anti-virus programs from falsely flagging Auto Hot Key, AutoIt, and other scripted/interpreted code. I tried numerous approaches and nothing worked.
The best approach seems to be to avoid using Auto Hot Key, AutoIt, etc. if you can, and if you must then use VirusTotal on the setup file you're planning to release in order to understand what warnings your potential users will receive. In my experience of the 40+ virus scanners that are used by Virus Total only 1-4 generally see an Auto Hot Key included code as suspicious, and those are typically unpopular, unfamiliar virus scanners which likely err on the side of caution because doing so requires fewer resources (in terms of their own manpower, in coding and signature use).