anyone knows how to resolve this problem?

[amynguyen26]

I have a compiled C program (on UNIX) that this small business would
like to try out. They don't want to pay for it yet. So I'm willing
to let them use it for a month. If they like it, they can negotitate
on the pricing, and if they don't want to use it, then, after 30 days,
this program will stop working permanently.

Here's the question:

How can I make it work for a month only?

1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops. But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again. So I don't think
this method will solve the problem.

2) Or if I put a counter into a file somewhere on the computer. Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file. If they restore that file
back, the counter might be only at 1, 2, etc. So, the software will
run again. I don't think this method will solve the probem either.


Any suggestions to solve this problem? Thanks.

 

[Guest]

I have a compiled C program (on UNIX) that this small business would
like to try out.  They don't want to pay for it yet.  So I'm willing
to let them use it for a month.  If they like it, they can negotitate
on the pricing, and if they don't want to use it, then, after 30 days,
this program will stop working permanently.

Here's the question:

How can I make it work for a month only?

1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops.  But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again.  So I don't think
this method will solve the problem.

2) Or if I put a counter into a file somewhere on the computer.  Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file.  If they restore that file
back, the counter might be only at 1, 2, etc.  So, the software will
run again.  I don't think this method will solve the probem either.

Any suggestions to solve this problem?  Thanks.

You might try getting them to sign a contract that they will not
use the demo version after a certain date. At least you have some
legal
comeback if you can demonstrate they are in breach.

You might consider a dongle-based solution. The contract could
specify return of the dongle after a certain date.

This, of course, adds to your up-front costs. You may not be able
to afford dongles or legal costs.

 

[Sjouke Burry]

I have a compiled C program (on UNIX) that this small business would
like to try out. They don't want to pay for it yet. So I'm willing
to let them use it for a month. If they like it, they can negotitate
on the pricing, and if they don't want to use it, then, after 30 days,
this program will stop working permanently.

Here's the question:

How can I make it work for a month only?

1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops. But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again. So I don't think
this method will solve the problem.

2) Or if I put a counter into a file somewhere on the computer. Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file. If they restore that file
back, the counter might be only at 1, 2, etc. So, the software will
run again. I don't think this method will solve the probem either.


Any suggestions to solve this problem? Thanks.

Let the program get a validation code from your website.
It stops when you stop supplying codes, and when they buy
it , you supply the final activation code(by mail).
That stops it from asking for codes.

 

[Stephen Sprunk]

I have a compiled C program (on UNIX) that this small business would
like to try out. They don't want to pay for it yet. So I'm willing
to let them use it for a month. If they like it, they can negotitate
on the pricing, and if they don't want to use it, then, after 30 days,
this program will stop working permanently.

Here's the question:

How can I make it work for a month only?

1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops. But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again. So I don't think
this method will solve the problem.

2) Or if I put a counter into a file somewhere on the computer. Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file. If they restore that file
back, the counter might be only at 1, 2, etc. So, the software will
run again. I don't think this method will solve the probem either.

Any suggestions to solve this problem? Thanks.

You cannot stop them from using your software after a month, only make
it more difficult to some degree. Period.

There is an entire industry niche dedicated to solving this problem and,
to date, nobody has ever managed to pull it off in a way that can't be
defeated, sooner or later, by motivated (or bored) hackers. Heck, the
copy protection on Windows XP, designed by a multibillion dollar company
with thousands of great programmers, was broken before it even went on sale!

The "best current practices" for this problem are (a) to give them a
trial version that is sufficient to test but crippled so that it cannot
handle their full workload, or (b) to give them the full version after
they sign a contract promising to pay for it if they're still using it
after a certain date -- and then sue them if they breach it.

S

 

[osmium]

Heck, the copy protection on Windows XP, designed by a multibillion dollar
company with thousands of great programmers, was broken before it even
went on sale!

If they, in fact have, "thousands of great programmers", they aren't writing
code for anything I use. They are going to conferences, making speeches,
planning the future, scheduling vacations, giving raises, whatever.

 

[Gene]

I have a compiled C program (on UNIX) that this small business would
like to try out.  They don't want to pay for it yet.  So I'm willing
to let them use it for a month.  If they like it, they can negotitate
on the pricing, and if they don't want to use it, then, after 30 days,
this program will stop working permanently.

Here's the question:

How can I make it work for a month only?

1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops.  But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again.  So I don't think
this method will solve the problem.

2) Or if I put a counter into a file somewhere on the computer.  Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file.  If they restore that file
back, the counter might be only at 1, 2, etc.  So, the software will
run again.  I don't think this method will solve the probem either.

Any suggestions to solve this problem?  Thanks.

I agree with others that say it's not possible.

Shareware practice e.g. is merely to make the expiration mechanism
more expensive to get around than the license fee. But you can always
get around.

One thought is to have your program phone home via Internet and fail
to start if it can't make a required handshake with a service you
provide. If you do this with a secure hash, one-use challenge and
response, it won't be breakable by network sniffing. They would have
to reverse engineer your executable.

 

[Ben Bacarisse]

On 15/04/09 05:37, (e-mail address removed) wrote:

Well, they /can/ but thats likely to cause quite a few other issues
(such as paychecks being reprinted, invoices sent out with the wrong
date, webservers behaving very strangely, networked hardware getting
upset etc) that it may be too painful for them.

Much less painful in these days of cheap VMs.

 

[Stephen Sprunk]

One thought is to have your program phone home via Internet and fail
to start if it can't make a required handshake with a service you
provide. If you do this with a secure hash, one-use challenge and
response, it won't be breakable by network sniffing. They would have
to reverse engineer your executable.

.... and all a cracker needs to do is patch one branch/jump/test/etc.
instruction in the binary. Folks have been doing this to bypass
"copy-protection" schemes on games for over a decade. Putting it online
doesn't make it appreciably more difficult unless a critical part of the
program's logic (i.e. not just a validation code) is on a server you
control.

S

 

[BartC]

... and all a cracker needs to do is patch one branch/jump/test/etc.
instruction in the binary.

I had an application of which half was (custom) interpreted code. Any
attempt to bypass a conditional jump in the latter would also bypass *all*
conditional jumps, breaking the system. Single-stepping through the code
wouldn't be too productive either. Not impossible to break but adding a
useful extra layer.

The copy-protection module was unique in that, while all others were
updated, revised, simplified and improved, the copy-protection code was
deliberately left to fester over years into a mess even I couldn't make head
or tail of.

 

[Kaz Kylheku]

... and all a cracker needs to do is patch one branch/jump/test/etc.
instruction in the binary. Folks have been doing this to bypass
"copy-protection" schemes on games for over a decade.

s/decade/quarter century/

 

[BartC]

Thereby making it flaky for your paying customers? Or did it run in a
virtual machine that was entirely bounds-checked?

It wasn't too bad. And the copy-protect stuff and nearly all user commands
were interpreted in a virtual machine with bounds and other checks. And if
there was en error, that specific module (ie. command) was terminated and
the user could carry on and try something else.

The point is, if I found it difficult to follow how the protection worked,
even with source code, then hackers would find it even more difficult. Not
that my application was 'sexy' enough for anyone to want to crack it.

 

[Stephen Sprunk]

I had an application of which half was (custom) interpreted code. Any
attempt to bypass a conditional jump in the latter would also bypass
*all* conditional jumps, breaking the system. Single-stepping through
the code wouldn't be too productive either. Not impossible to break but
adding a useful extra layer.

That merely means that the cracker would need to learn your interpreted
code and patch _that_. As with any copy-protection system, you're only
making their job a little harder, not impossible.

The copy-protection module was unique in that, while all others were
updated, revised, simplified and improved, the copy-protection code was
deliberately left to fester over years into a mess even I couldn't make
head or tail of.

You're talking about guys that are used to reading assembly listings for
gigantic programs and stepping through them in debuggers to find the
exact patch necessary to bypass the copy protection checks without
otherwise affecting the program; obfuscated or spaghetti source code
(which has little bearing on what an optimizing compiler eventually
emits) isn't going to stop them -- it just makes it tougher for the
original programmers to maintain and improve to keep a step ahead of the
crackers. Many companies even switch their entire copy protection
method with every version to keep the crackers from reusing knowledge
they gained cracking the last version.

S

 

[Leo]

The best way I think is never give any piece of code to them, unless you get
paid.
You can only provide a web service for a month.