Hello

Iam releasing a Trial Version of a Program soon
instead of a Crippled Release i would like to Release a Full version that
will Expier after 45 days.
how could i get this done.

Hi

I've seen many programs that use this (expier after 30 days or 45 days), But there is one thing they don't
think of if you reset the Timer or the date the program still works, so whar you want to do is take a date and
store it as days after the, 1st of jan. 1996-97 ,and inc(date_tick) every time the program starts. If anybody
changes the date from 5. may 1996 to 2. may 1996 (with a ver. they started on the 1. may 1996) the date_tick
will still be at 6, 5 if they didn't start the program before the change of date, so they still have only 39 (
or 40) days to go.

- this was just a bug I started getting tired of seeing. :-)

-- Tom Schultz
  ******************************************
 ** Schultz  E-Mail : <rosch...@online.no> **
 ** NORWAY                                 **
  ******************************************

--
  ******************************************
 ** Schultz  E-Mail : <rosch...@online.no> **
 ** NORWAY                                 **
  ******************************************

Using this technique you assume that your program is started once and
only once per a day. I do not think it is quite correct. At least, you
should explain that the program expires after 40 runs, but not after 40
days.

Best regards!
--
Viatcheslav   <neste...@em.uni-frankfurt,de>
-------Knowledge is power. R.Bacon----------

---- Thanks for the tip.

and im sorry for any miss-information.
Well i'v forgot you only need to include a counter for the time and compare it. Lets say the day is the same as above but we inset a
clock_tick procedure which keeps track of the time, and a full day procedure if the clock has gone above the complete hours of one day then in
inc(date_tick) and inserts the day in an array so you cant 'use' it again. it should work. But it's a lot of work easier to do the 40 times
version i'v been so unfortenat to descride above.

---- And you're right knolege is power.

-- Tom Schultz
  ******************************************
 ** Schultz  E-Mail : <rosch...@online.no> **
 ** NORWAY                                 **
  ******************************************

This is a very good thought! Thank you too.

But there is a little problem. Where do you store the counter to make it
permanent? What if the user simply reinstalls the program after it has
expired, or what if he does a backup after installation and a restore
when the counter expires, or what if he just runs it from a RAM disk?

The solution I have found is to store the counter in a hidden file in a
different directory (such as C:\DOS, or C:\WINDOWS) along with some
unique data, such as the creation day and time of another directory,
WHILE keeping a copy of the counter and ID data inside the EXE file. If
the two counters do not match the program will know that something is
wrong. Also, if the hidden counter is not there or the ID data (such as
the other directory creation daytime) are not correct, the program will
know that it is on another hard disk!

What I describe is a rather sofisticated approach, which has proved to
stop a good deal of copy protection and expiration breaches. Of course it
is not foolproof, and it can not replace hardware locks, but it takes a
good programmer and some investigation and experimentation to break it,
so I believe most people will quit after a few unsuccessful tries.

Then there is the de{*word*81} problem: no matter how good your protection
algorithm is, if the program checks the lock/counter through a boolean
function, all there is needed to break it, is to locate the function
inside the EXE file and hack it to always return TRUE. But things
can get pretty complicated on this subject.

Votis

------------------------------------------

Votis Kokavessis
Mathematics teacher & pascal programmer
Thessaloniki, Greece
E-mail address: paratiritis.the.forthnet...@popper.forthnet.gr (votis)

I tried to solve this problem in my (protected) applications:

First, I've broken apart all the actions related to protection checking.
For example, one function may find and return the counter, another one
compares with some value, and so on.

Second, I always use strings instead of booleans or other simple types,
because the mechanism of returning strings in Pascal (and records - in
Delphi) is somewhat more complex, than for ordinal types.

And third, I put different steps of protection checking in such places in
my program, which are 'far' from each other, and where there are many other
string manipulation operators and function calls. For example, one step
may be in the initialization part of some unit, another one may be where
you read the configuration or create the main window (for Windows), etc.

And, at last, the better place is where your program is doing its *main*
*specific* work - process data, or... I don't know.

Hope, this may help you too.

Bye,
Hovik Melikain

There are at least two methods I have heard of, but not yet implemented.

First, include in your program an encrypted copy of the lock-checking
function (I understand it has to be written and linked as external) and
just decrypt it and copy it over the actual function during
initialization. So, if someone hacks the function, the next time the
program runs it will invisibly correct it, by replacing it with the
'secret' copy, and it will also know about the hack attempt.

Second, make your function 'de{*word*81}-resistant'. One way to do this is to
create a recursive function, which will be called a few thousand times
before deciding if the lock is in place. Nobody has the patience to step
through thousands of repeating instructions, and setting breakpoints will
not be any help, because it is the same code that gets executed, and the
de{*word*81} will stop thousands of times at the same breakpoint.

Now, about the nature of the recursive function, it could be just a
function that has to find a way out of a labyrinth. The real intelligence
is in the way the labyrinth-data are coded, including at random points
the actions needed to verify the lock.

It seems to me like a very good idea, but, as I said, these are
complicated matters and I have never had the time to try an
implementation.

Votis

------------------------------------------

Votis Kokavessis
Mathematics teacher & pascal programmer
Thessaloniki, Greece
E-mail address: paratiritis.the.forthnet...@popper.forthnet.gr (votis)

Yes, an excellent method, but sometimes it's possible either to
understand the encryption algorythm, or write a TSR which cracks this
module at run-time - I meet this method very often.

I can set a conditional hardware breakpoint. The 386+ CPU's *have*
patience if I only guess about the lock condition you set. Nobody really
will have patience if you just hide this procedure to places where the
program, for example, is printing or processing specific data. I've seen a
protected program, which 'spoils' printed documents with a {*word*193} message.

In all cases, the cost of protection algorythm must be comparable with
the cost of your program, of course. Nevertheless, I think most
programmers hate all of this...

Bye,
Hovik Melikian

Reposting article removed by rogue canceller.

Yes, an excellent method, but sometimes it's possible either to
understand the encryption algorythm, or write a TSR which cracks this
module at run-time - I meet this method very often.

I can set a conditional hardware breakpoint. The 386+ CPU's *have*
patience if I only guess about the lock condition you set. Nobody really
will have patience if you just hide this procedure to places where the
program, for example, is printing or processing specific data. I've seen a
protected program, which 'spoils' printed documents with a {*word*193} message.

In all cases, the cost of protection algorythm must be comparable with
the cost of your program, of course. Nevertheless, I think most
programmers hate all of this...

Bye,
Hovik Melikian

I agree with your last statement, but not always.

Sure, if I were Borland or Microsoft I would sell my programs unlocked.
The illegal copies are mostly owned by people who do not use them on a
professional basis and who would not buy anyway, or, on the other hand,
the illegal copies are an indirect adverti{*word*224}t of the program and their
illegal use is actually cutting the competitors' sales.

All this is nice and I will follow if I ever write such a killer
application as TP or MS-Word or anything close to that. Also I
always give for free the little utilities I write, because mostly I write
them just for the challenge or to solve a particular problem. I do not
believe that we should do everything for money.

But things are not always the same. One short example. Last year I wrote
for my employer, who owns among other things a local radio station, an
application to schedule and play comercials from a sound card. He
agreed that it is fair, if another radio station shows interest, to
allow me to sell my program to them. There are no more than 30 local
radio stations where I live. If I left the program unlocked soon every
one would copy the program and use it for free. Meanwhile I have sold one
copy and I am about to present the program to another station.

As I see it, the real trade off for a locked program is not for the
programmer but for those who want to break the lock: what is the cost of
breaking it? If it takes a programmer equally skilled or better than the
one who wrote the program, equipment like a hardware de{*word*81}, and a week
of effort, then there is no point. They would better choose the straight
way and buy the program, along with my support and free future upgrades.

The programmer's part, to help them decide between breaking or buying, is
modest pricing. If they have to sell their house in order to pay for my
program, then somebody sooner or later will break it. If the price is
attractive, it might well create a new market for the program (see the
success of TP, which launched Borland to the top).

Well these are my thoughts about locking programs, from the view of a
programmer. As a user, I certainly hate locked programs.

Votis

------------------------------------------

Votis Kokavessis
Mathematics teacher & pascal programmer
Thessaloniki, Greece
E-mail address: paratiritis.the.forthnet...@popper.forthnet.gr (votis)

Reposting article removed by rogue canceller.

I agree with your last statement, but not always.

Sure, if I were Borland or Microsoft I would sell my programs unlocked.
The illegal copies are mostly owned by people who do not use them on a
professional basis and who would not buy anyway, or, on the other hand,
the illegal copies are an indirect adverti{*word*224}t of the program and their
illegal use is actually cutting the competitors' sales.

All this is nice and I will follow if I ever write such a killer
application as TP or MS-Word or anything close to that. Also I
always give for free the little utilities I write, because mostly I write
them just for the challenge or to solve a particular problem. I do not
believe that we should do everything for money.

But things are not always the same. One short example. Last year I wrote
for my employer, who owns among other things a local radio station, an
application to schedule and play comercials from a sound card. He
agreed that it is fair, if another radio station shows interest, to
allow me to sell my program to them. There are no more than 30 local
radio stations where I live. If I left the program unlocked soon every
one would copy the program and use it for free. Meanwhile I have sold one
copy and I am about to present the program to another station.

As I see it, the real trade off for a locked program is not for the
programmer but for those who want to break the lock: what is the cost of
breaking it? If it takes a programmer equally skilled or better than the
one who wrote the program, equipment like a hardware de{*word*81}, and a week
of effort, then there is no point. They would better choose the straight
way and buy the program, along with my support and free future upgrades.

The programmer's part, to help them decide between breaking or buying, is
modest pricing. If they have to sell their house in order to pay for my
program, then somebody sooner or later will break it. If the price is
attractive, it might well create a new market for the program (see the
success of TP, which launched Borland to the top).

Well these are my thoughts about locking programs, from the view of a
programmer. As a user, I certainly hate locked programs.

Votis

------------------------------------------

Votis Kokavessis
Mathematics teacher & pascal programmer
Thessaloniki, Greece
E-mail address: paratiritis.the.forthnet...@popper.forthnet.gr (votis)