The Protection Racket

Originally published on: Sat, 14 Nov 2009 02:29:15 +0000

If you ask the question in a given forum whether or not copy-protection schemes should be used in software, you'll get all kinds of answers. I won't try to tell you what to do, but I will describe my experiences with copy-protection as a software author.

Some of the products I will discuss are available here:

http://www.mailsend-online.com

Others have been retired.

Early Attempts

My first product, Keymac, used no copy-protection. I received very little in the way of compensation, but I really didn't do well at marketing the product. I had always wondered how many people were actually using it and were not paying for it.

Some time later, I developed MailSend, a command-line SMTP e-mailer. I had decided to leave the early versions of MailSend fully functional just to see what kind of acceptance I received. Early sales were okay. Not great, but I would get a few registrations each month. I decided that it was time to experiment with copy-protection.

I wondered what kind of protection I should use. A lot of my peers were using key files that would enable their products' features. I opted to go a different route. I didn't want registered users to have to deal with key files, so I decided to send registered users a fully-functional EXE file. The trial version of MailSend employed a copy-protect feature that allowed the user to send no more than about fifteen e-mails per Windows session. They had to reboot their machines to send fifteen more. I also have a nag message that was attached to each outgoing email. The recipients of the emails receive a message that the mail was sent with a trial copy of MailSend.

Unfortunately, I also added the attachments feature to MailSend at this time. My sales rose dramatically. I was never certain if the sales were due to the protection I had added or if the new feature was what sold them on the product.

I did converse via e-mail with one young woman who very openly told me that she had tried every way she could ( she was not an expert at reverse-engineering or anything like that ) to get MailSend to send more than fifteen items per Windows invocation. She finally paid the ten-dollar fee that I was asking for the software at the time.

Other customers had asked me if the nag message and fifteen item limit would go away if they paid. They often seemed oblivious to the fact that I was asking them to pay until they ran into these snags.

In a later version, I changed the trial version message embedded in each e-mail item so that it was encrypted in the EXE. I had finally made the big time; Someone had felt it necessary to provide a crack for the trial version of MailSend so that it would no longer spew forth this message.

In my mind, this approach worked nicely. I applied the same item-limit approach to MailGrab, a command-line POP3 e-mail reader. I don't believe I've ever had any complaints about the limit and am quite happy with the number of registrations I receive for that product.

I used to search Usenet via DejaNews to see if I could drum up sales and happened upon someone who had asked for a crack for one of my versions of MailSend. I responded:

From: Jim Lawless Date: 2000/03/21 Subject: Re: MAILSEND 6.50

{quote}Does anyone have a crack for MAILSEND 6.50 to get rid of the limitation {quote}of only being able to send 15 messages????

Hi, Frank.

I'm the author of the MailSend tool you're asking about. While I'm happy that you find it useful, I'm a little disappointed that you're looking for a crack for it.

I've tried to keep the pricing reasonable ($10 ). All upgrades are always free; the people who registered the earliest 1.0x versions are still receiving free upgrades as I release them.

I'm hoping that if you do find a crack ( or if someone builds a new one ) that eventually you'll join the ranks of many happy MailSend users.

Best wishes.

Jim Lawless

I suppose that I should have asked for a reply. I never did receive one. It just amazed me that some people would go to such lengths to avoid paying ten dollars. I know that the world is a big place and depending where Frank was from, ten dollars may as well have been $10,000. If this person was in the U.S. at the time and was able to work, they seemed to be spending more time hunting for a crack than they would have needed to work at a minimum-wage job to pay for a legitimate license.

I pondered this as the topic came up again in the shareware forums that I frequented.

A New Experiement

I created a few supplmental products that I no longer sell:

Run and Hide - A program that launches a console app in a hidden window.
TSched - Tiny command-line scheduler. I open-sourced this program on the blog without the copy-protection routines.
HangUp - Command-line Dial-Up-Networking HangUp utility. I also placed this program into open-source here on the blog without the protection routines.

These were all small C programs that really didn't take very long to write. I decided to write one protection function that I would include in them all. The new protection function simply wrote the current date to an INI file in the Windows directory in a scrambled form and used that date as a baseline to determine when the product should stop working. ( Usually thirty days from the first use. I later learned from my peers that 30 individual uses would have been a better choice. )

If one simply deleted the INI file, each of the above products would start their timer over again, allowing unlimited use of the product.

This seems like an approach that's too simple, but it really isn't. What I had come to conclude is that while some people will pay for your software, some won't. Those who figured out my scheme and willfully bypassed it were probably lost causes. Others were likely just procrastinators. In my mind, the protection-schemes I employed in my products were there to remind anyone evaluating my product that it's time to register.

The above protection wasn't fool-proof. I didn't like the idea that my apps would need permissions to write to the filesystem. Some users run with low privileges on Windows and may not actually be able to write to INI files. I did not want my products to fail because I needed to include protection. I had hoped that anyone having difficulties would contact me, but no one ever did. I still do not know how many users stopped using the trial versions of the above products because of side-effects of the protection.

Overprotection

Most of my products were geared toward a technical use of some kind. While a number of people had registered MailSend and MailGrab for personal use, a much larger number of my clients used these tools in a business setting. I wanted to see if I could create a product to sell to the general consumer.

I wrote a little application called WallShow that would periodically change the wallpaper to a random JPEG, BMP, or PNG image from a specified directory. I thought that this was a fairly interesting product that would be popular. WallShow probably brought in the fewest number of registrations of all my products.

I wrote my own installer, which one reviewer referred to as "weird" or "unusual" or something like that. I used the protection scheme from above ... the INI file with a thirty-day trial period. I also placed a "trial version" message on each image that appeared as wallpaper. I then added an image between the random ones that stated that WallShow was unregistered.

The same reviewer gave WallShow really bad marks because of this. The product itself never really took off, but I don't think that was a factor of the overprotection I had employed. I like to think that maybe I could have received a few more registrations before I retired the product completely.

Just before doing so, I saw a crack for WallShow that removed all of my protections. I tried the crack myself and ended up recompiling WallShow so that the crack would no longer work. Then, I placed it on my site for a while. Apparently, someone thought it was good enough to use without all of the protection.

The Philosophy

I've tried to stick with a philosophy of using copy-protection as a reminder.

The copy-protection that I employ with ScreenKap, my command-line screen capture program, is a simple date built in to the EXE file. The trial version expires on a pre-set calendar date so that no temporary INI files need to be used.

It's sometimes been a challenge to remember to update that value and re-release the trial version, but it's the easiest to implement.

I went a step further and encrypted all of the string literals in the program by building a custom preprocessor. The preprocessor would transform each string literal into a series of encrypted hex-bytes in a global data buffer and would replace the literal with a function-call to the decrypt routine in the literal's place. I wasn't necessarily trying to remind the procrastinators, a new threat of people ripping off others' software and reselling it under their own name had arisen. I doubt that ScreenKap had ever fallen into that trap, but it was again an experiment that I wanted to try.

I sell a program called CMD2EXE, which packages batch script files and other supporting files into a single EXE file. The copy-protection scheme I employ with CMD2EXE is that the output EXE will only run on the same day it was generated. This should allow people to test the software thoroughly for as long as they like. They cannot deploy an EXE that has been created with the trial version or it will cease to function in twenty-four hours. This also has been a worthwhile mechanism.

Wrapping it Up

I should state that my philosophy of sending the registered users a fully-functional copy has allowed some pirates to place fully-function versions of my software on their sites by purchasing a single copy. I've talked with some peers about a way around this, but it seems like anything that would be effective might be intrusive for a prospect who would legitimately license my software.

My programs will likely all have some form of reminder and/or mild deterrent in them. I'm not certain what new techniques I might employ, but I do revisit this subject from time to time.

Unless otherwise noted, all code and text entries are Copyright Š2009 by James K. Lawless

Save to del.icio.us
Save to StumbleUpon
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks