1

I have written a software as a student. All functionality was in the software and it was a 30 days fully functional version. After some years there were cracks around and my income was 10% of before. This was where I decided to switch the paradigm to full version vs. demo version with limited functionality (the function weren't even in the EXE using compiler switches). This in my case ended all piracy and worked very well.

Now you could ask what if a customer uploads his full version to a crack website? For this case I compiled the customer's full address visibly and invisibly into the EXE file so that I could see which customer was a bad boy...

After some more years I had a new problem: anti virus software. Since my software can set keyboard shortcuts, the heuristic algorithms of some anti virus apps started complaining. So I sent the demo version EXE to the anti virus companies to mark it as "safe". This worked very well. But only for the demo version which is fixed in bytesize. When I compile the customer's personal data into the EXE file, the filesize varies a bit and so the checksum differs and the EXE file isn't marked as "safe" by the anti virus software anymore and the complaining starts again for the customers.

Does anyone have an idea how I could solve this? I can't add a separate file because this could be deleted by the customer, of course.

Thanks in advance.

10
  • 2
    Does this answer your question? How can software be protected from piracy? – gnat Jan 4 at 16:32
  • @gnat: next time. please read the question before voting as a dupe. – Doc Brown Jan 4 at 16:42
  • 3
    The canonical solution for this problem is code signing, see jeff.wilcox.name/2010/02/codesigning101 As soon as you sign your Exe with an official signature, most anti virus software stops complaining. – Doc Brown Jan 4 at 16:43
  • 1
    If you manage to find a solution, there are big and rich companies which will pay big money for it. Translation : Don't bother. Big companies tried it. It is rarely worth the effort. If you don't want to give functionality to customer, keep it on your server and only provide an API. Which is what majority of SW makers are trending towards. – Euphoric Jan 4 at 18:04
  • code signing is good but not a full solution. hence the need for registering the app "signature" stackoverflow.com/questions/6773395/… – Ewan Jan 4 at 22:09
2

First, let me say the mentioned problem does not have much to do with any anti-piracy measures. The same problem will arise when you deploy different versions and variants of your software frequently (with or without any individual customizations).

Even if the "license files" approach will allow to send a full version of your software to all major AV companies (without providing a license file for them, or only one which allows restricted usage), you

  • probably don't want to register each new monthly or weekly version of your software by all of them

  • definitely don't want to wait for such a registering process when your customers are waiting for an urgent bugfix.

Hence your best bet is IMHO to buy a commercial certificate from a trusted Certificate Authority and sign your software with it (like described here). This is usually affordable and lowers to chance for most AV scanners to complain about your program.

However, as @Ewan and @GrandmasterB have mentioned in the comments correctly, this is unfortunately not a 100% solution - some AV scanners may still blacklist your program when their heuristics detect some "suspicious" activity. The reasoning behind this should be clear: over the last years, digitally signed malware has appeared, using stolen certificates, so a digital signature is no guarantee for a program not being malware, and AV scanners don't trust such signatures blindly.

Nevertheless, I would recommend to use a signature. If an AV scanner still does not like your program, try to convince its vendor that your signature was not stolen and that programs with your signature do behave well. Maybe it is enough to sign the demo version of your application and register that at the AV company? The AV companies should have a strong interest of not producing too many false positives, since otherwise their customers could be inclined to change to a different AV vendor. Moreover, it should be in their own interest not to enforce a time consuming registering and validating process on each and every software and each and every software vendor, but leave this to the CAs.

Another thing to consider is to check if it may be possible to reimplement the specific activity which caused the AV scanner to pop up, differently. Maybe your way of creating keyboard shortcuts was too low-level, using some deprecated OS API, and there is a new, more "official" way of creating such shortcuts today? Since the question has a "Windows" tag: AFAIK Windows has lots of such quirks and legacy issues, where some workarounds which worked in the past are not the way how they should be implemented today. But I am sure you will know best if that's a viable way to approach the issue.

4
  • I just wanted to let you know which solution I did in the end. Since the revenue of the software I wrote in student times is very low, buying a certificate each and every year wasn't an option. So what I came up with in the end was to write the customer data into registry while the setup runs, i.e. a new EXE setup file for each customer but the same main software EXE file which contains the hot key functionality detected by some antivirus software. So I could submit this main EXE file for review (Windows Defender) and it stays the same and Windows Defender won't complain about setup exe... – The_Unknown Feb 2 at 10:32
  • ... because the problematic functionality (setting hot keys) is compiled into the EXE as binary data (as always with setups). So having different setup EXEs will only result in warnings but not in deletions by Windows Defender because of some trojan found. At least the problem didn't occur again after I submitted the main software EXE file. Of course I can't submit each and every generated setup EXE file but this seems not to be a problem. Of course one might break the "copy protection" but since the customer data is built into the setup exe it's not too easy. – The_Unknown Feb 2 at 10:35
  • @The_Unknown: If you can afford submitting each new version of that "main software EXE" to all major AV vendors, this might work. So if you produce a new version every 6 months, this might be ok. If you produce a new version every 6 days, or want to be safe for urgent bugfixes, this is probably too risky. But YMMV. – Doc Brown Feb 2 at 11:45
  • I release a new version every year or so. Not regularly I must say ;-) – The_Unknown Feb 2 at 12:10
0
  1. Make your application require a login which is verified by a server you own.
  2. Have a non-executable licence file unique to the customer which the program checks.
  3. Continually release updates so pirated versions become out of date.

Requiring an internet connection makes things easier for you, as you can have the program phone home, and tell you stuff about the machine its running on and the licence file the customer is using. You can then keep track of how many copies each customer is using, disable licences/logins etc

Sure someone can hack out the checking code, but they could also hack out the customer details

4
  • 1
    This does not answer the question, which was how to stop anti virus software to complain (I guess we have to change the misleading title). – Doc Brown Jan 4 at 18:40
  • erm. if you dont encode the customer specific data in a executable file, you dont have the virus problem – Ewan Jan 4 at 22:02
  • The problem exists without the customer specific data as well. The OP surely does not want to send the full version to every antivirus software vendor, and they surely don't want to send each and every new release of that version - customer specific data, or not. – Doc Brown Jan 4 at 22:11
  • of course you dont want to, its just a fact of life that you have to. – Ewan Jan 5 at 0:21
0

If each customer's EXE is different, then you're not going to be able to get around that. Anti-virus software will always view each EXE as a new and unknown application, even if its signed.

Generally I'd recommend people not put too much effort into stopping piracy because its not going to be very effective. Best is to make it inconvenient for people to share the software to dissuade the 'casual copiers'.

That said, you might consider using a separate license file that contains the same information. Load the file & validate on launch. Then you won't have to have a different executable per customer.

4
  • "Stopping from piracy" is a red herring, the same problem arises when new versions are deployed frequently, even if there is no individual executable file for each customer. And code signing helps (but it must be a commercial signature from an official trust center, not some self-created test signature). – Doc Brown Jan 4 at 16:50
  • Right, code signing too. Without it, half the time apps won't run at all. But even with signed executables, my apps still get flagged from time to time. The default approach by some of these anti-virus vendors seems to be if you're not a Microsoft or Adobe exe, you're malware. – GrandmasterB Jan 4 at 17:02
  • "But even with signed executables, my apps still get flagged from time to time" - can you tell us which trust center do you use, and which anti virus software does not recognize it? – Doc Brown Jan 4 at 18:43
  • @DocBrown I believe they are Comodo code signing certs. I have many tens of thousands of copies of software out in the wild, so most of the major av's have given me grief at one point or another. – GrandmasterB Jan 4 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.