Protecting my work

  • Thread starter Thread starter Hogan's Goat
  • Start date Start date
H

Hogan's Goat

OK, I've written a pretty cool little app that I think would be broadly
interesting. Now I'd like to make money from it! Here are my options,
as I see them:

1) Advertise it heavily, then sell the finished product directly. I have
zero budget, so "advertising" would be in the form of viral marketing
such as Usenet, discussion forums, etc. People would have to buy it
sight unseen, and my support costs would go up if I don't set their
expectations properly up front.

2) Offer it as shareware, and hope people will like it enough to pay me
for my hard work. I hate to say it, but I have little faith in this.

3) Offer it as crippleware, with a reduced feature set which will help me
know if users like the UI and basic functionality. If they like it, I
enable the functionality through some sort of hash code activation.

4) Ship a fully functional but time-bombed version, that stops after
either ten days or ten uses, something like that.

I am leaning toward the fourth option, since they will get full
functionality for a little while and if they like what they see they'll
buy the full version. I'm wondering what the code would look like to
make that happen. Perhaps track the number of times the app has been
launched, decrement a counter until it reaches a limit and then execute
code which throws up a messagebox and blocks functionality (Cancel button
closes the app, OK button sends you to a web page where you put in your
CC number etc.).

Has anyone ever done this? If so, can you point me to a code sample that
would help me make this happen? I can get you an "employee discount" for
your troubles. ;)

Hogan out.
 
Hi Hogan,

I hate software which has a timed try-out. So many times you can install
something then not use it for a while and the days tick off. Then, when you're
finally ready it gets shut down. I think the count idea is better.

Whatever you do will need to be stored. Wherever you do that you will
need protection. If it is a Registry entry for instance, the User could simply
reset it. So you encrypt it! Ha! But then the user just copies the encrypted
setting from a few days back. What you need therefore is two (or more)
items which are independant, eg, use the name of the last file opened as the
encryption key (have to keep chaning the key when they save, though) or
embed it in something technical looking.

If your program is massively useful, it will get cracked. One method is to
step through the code until the security check is made then wipe out the call
and replace it with the all-clear result code. So multiple security checks
throughout your program may be better. But then the hacker will step <into>
the security routine and make it return immediately with the all-clear code.
This will break all your security checks wherever they are. So you need
either more copies of the core routine or (as with the encrypted info) to
mix it up with a routine that is essential to the correct running of the
program. Still crackable but harder to figure out.

I hope that gives you ome ideas.

What's the program by the way?

Regards,
Fergus

--
(Please ignore this - there's a feud going on)
==================================================
Quote of the day

Herfried:
I don't need/want human interaction.
==================================================
 
Here's a cheerful little earful from Fergus Cooney:
Hi Hogan,

I hate software which has a timed try-out. So many times you can
install
something then not use it for a while and the days tick off. Then,
when you're finally ready it gets shut down. I think the count idea is
better.

Whatever you do will need to be stored. Wherever you do that you
will
need protection. If it is a Registry entry for instance, the User
could simply reset it. So you encrypt it! Ha! But then the user just
copies the encrypted setting from a few days back. What you need
therefore is two (or more) items which are independant, eg, use the
name of the last file opened as the encryption key (have to keep
chaning the key when they save, though) or embed it in something
technical looking.

If your program is massively useful, it will get cracked. One
method is to
step through the code until the security check is made then wipe out
the call and replace it with the all-clear result code. So multiple
security checks throughout your program may be better. But then the
hacker will step <into> the security routine and make it return
immediately with the all-clear code. This will break all your security
checks wherever they are. So you need either more copies of the core
routine or (as with the encrypted info) to mix it up with a routine
that is essential to the correct running of the program. Still
crackable but harder to figure out.

I hope that gives you ome ideas.

What's the program by the way?
Click to expand...

Thanks for the feedback, Fergus. I don't want to give away the farm, so
to speak, just yet. Suffice to say that the target audience will not be
the general Internet public at large, but probably more business users -
distance learning, help desk, online training and so on. I'm not sure if
it will be all that revolutionary, but it will make a certain task fairly
simple to do, so that even the highest-level users can do it.

And no, I won't post my method to this or any other newsgroup! I can,
however, make you a beta tester if you want.

Hogan out.
 
Back
Top