Code To Make Trial Version Software Release

[Ken]

Hi,

I need to modify an existing application that's written in C, C++ and
Visual C++ so the application can be released as a time limited trial
version, also the modifications must prevent the application from being
reinstalled on the same computer after the trial period has timed out.

Does anyone know of any C/C++ code that I could use directly or modified
to do this?

Thanks in advance,

Ken

 

[Charlie Gordon]

Hi,

I need to modify an existing application that's written in C, C++ and
Visual C++ so the application can be released as a time limited trial
version, also the modifications must prevent the application from being
reinstalled on the same computer after the trial period has timed out.

Does anyone know of any C/C++ code that I could use directly or modified
to do this?

This is so vain... If your application is not useful, it is not an issue, if it
becomes popular, your little timetrap will be hacked away and unrestricted
versions will pop up on p2p networks anyway.

A much more interesting approach is to make your application require Internet
access, retrieve something variable but necessary from your server every time it
is used. This way, you will have useful information about who is using when,
and you will be in total control about whom to stop and whom to give a free
ride. Famous virus checkers do this constantly, not to mention lame OS's.

 

[James Rafter]

This doesn't sound too complicated. There must be publicly available
libraries to do this. GNU, Sourceforge, etc?

Here's a way. You app reads an expiration date from a text file
installed with your app. Except the file contents are encrypted.
And the file contents are generated by a program which is
supplied a key (also encrytped) that contains the expiration date.
No need to recompile binaries or edit (hack) any binaries with a date.

 

[Gordon Burditt]

This doesn't sound too complicated. There must be publicly available

libraries to do this. GNU, Sourceforge, etc?

The GPL version of this, if it exists, requires you to distrubute
the *UNENCRYPTED* source code to your application. Time-limited
open-source code: interesting concept.

I think I've seen it actually used before where the author wanted
beta versions to die after the more stable version was expected to
be released, and wanted the bug reports on old versions to stop.
Mostly the people who are too lazy to upgrade are also too lazy to
edit and recompile from source to remove the limit, and upgrading
is likely easier.

Here's a way. You app reads an expiration date from a text file
installed with your app. Except the file contents are encrypted.
And the file contents are generated by a program which is
supplied a key (also encrytped) that contains the expiration date.
No need to recompile binaries or edit (hack) any binaries with a date.

The gotcha here is that if the PROGRAM can decrypt the file, so can
someone with a debugger. A counter to that is public-key cryptography:
the expiration date is SIGNED by the public key of the author.
Anyone can decrypt the file or verify the signature; only the author
can make a new one with a different expiration date. The counter
to THAT is to replace the public key of the author in the program
with one that you know the associated private key. There's also
the issue of just bypassing the code that does the check.

Gordon L. Burditt

 

[Richard Bos]

I need to modify an existing application that's written in C, C++ and
Visual C++ so the application can be released as a time limited trial
version, also the modifications must prevent the application from being
reinstalled on the same computer after the trial period has timed out.

That is entirely impossible. The first can be done (but the obvious
implementation is trivially foiled if your user is willing to go through
the hassle of changing the clock on his computer); the second basically
asks for a way to permanently modify the user's computer without the
user being able to undo these changes. Even if this _were_ possible (and
it isn't), let me don my sysadmin hat again and state that even an
attempt to do so would get _you_ permanently modified if I got my hands
on you.

Richard

 

[CBFalconer]

That is entirely impossible. The first can be done (but the obvious
implementation is trivially foiled if your user is willing to go through
the hassle of changing the clock on his computer); the second basically
asks for a way to permanently modify the user's computer without the
user being able to undo these changes. Even if this _were_ possible (and
it isn't), let me don my sysadmin hat again and state that even an
attempt to do so would get _you_ permanently modified if I got my hands
on you.

You would probably have a use for one of those instruments with
long arms (something like a set of diagonal cutters, but larger)
which used to be sold in the rural farm catalogs under the name
'nutting tool' and were used to convert bulls into steers.

 

[dandelion]

That is entirely impossible. The first can be done (but the obvious
implementation is trivially foiled if your user is willing to go through
the hassle of changing the clock on his computer); the second basically
asks for a way to permanently modify the user's computer without the
user being able to undo these changes.

Hmmm... Strictly theoretically you are right, but practically you can make
it quitehard to

a) find the change and
b) undo it.

For example by storing some value in non-volatile-ram, but there are other
ways.

Even if this _were_ possible (and
it isn't), let me don my sysadmin hat again and state that even an
attempt to do so would get _you_ permanently modified if I got my hands
on you.

I'd agree with that sentiment, although my UI prohobits major changes to
other peoples physiology.

 

[Keith Thompson]

That is entirely impossible. The first can be done (but the obvious
implementation is trivially foiled if your user is willing to go through
the hassle of changing the clock on his computer); the second basically
asks for a way to permanently modify the user's computer without the
user being able to undo these changes. Even if this _were_ possible (and
it isn't), let me don my sysadmin hat again and state that even an
attempt to do so would get _you_ permanently modified if I got my hands
on you.

I can think of ways to do something like this without modifying the
computer. Basically the user would have to specify some unique
characteristic of his computer before downloading the software, which
would be customized to run on that computer during a specific period
of time. The download site would refuse to generate a copy of the
program for the same computer for a later time period.

Such a scheme would likely be easy to break (either permitting
unauthorized access or denying authorized access) -- and of course the
details are off-topic.

 

[Richard Bos]

You would probably have a use for one of those instruments with
long arms (something like a set of diagonal cutters, but larger)
which used to be sold in the rural farm catalogs under the name
'nutting tool' and were used to convert bulls into steers.

Thanks for the offer, but that won't be necessary. I have a baseball bat
in my office, and I'm quite willing to hit people who mess up my
computers with it. Don't believe me? Come and see. I'll show it to you.

Ok, ok, it's actually a plastic blow-up baseball bat that an
ex-colleague brought with him from a trip to the left side of the pond.
But it's the thought that counts, isn't it?

Richard

 

[Richard Bos]

I can think of ways to do something like this without modifying the
computer. Basically the user would have to specify some unique
characteristic of his computer before downloading the software, which
would be customized to run on that computer during a specific period
of time. The download site would refuse to generate a copy of the
program for the same computer for a later time period.

What's to stop me from saving the installer, and then setting the clock
back to the required time when I want to use it a second time?

Richard

 

[Chris Williams]

This is highly platform specific and has nothing to do with C, but the
way I believe most people have accomplished something similar to this
(on Windows) is to store an encoded value in some hidden place in the
registry. This value will probably be some sort of time stamp. So, when
you install, you test if that value is in the registry, and if it is
you cease installation. If it is not, you grab the time, encode it, and
store it. When you run the app, you test against the timestamp in the
registry and stop running if they are over time. If they uninstall, you
simply have the uninstall program not delete the registry key.

Hack 1: Keep resetting the clock back.
Solution A: Keep a time ticker of total time the app has run, instead
of an actual time. Or if you keep an install date timestamp and a total
used time value, then you can:

if (total_time_used > (current_time - install_timestamp)) {/* Welcome
to Haxx0rs R Us */}

Hack 2: Manually delete the registry value after uninstall.
Solution A: I believe that the way pople have solved this one is just
to hide the keys well and in duplicates.

Hack 3: They disassemble, place a jump past your time-verification
code, and reassemble.
Solution A: Worlds ugliest spaghetti code =D

Certainly if you had RSA working on this, they could do better, but
unless this is a product that hackers will particularly want to crack
open I think that the above method will be sufficient for 99.9% of all
cases.

-Chris

 

[Chris Croughton]

Ok, ok, it's actually a plastic blow-up baseball bat that an
ex-colleague brought with him from a trip to the left side of the pond.
But it's the thought that counts, isn't it?

Do users have thoughts? I was under the impression that they only have
desires ("I need more disk space"). A big heavy LART is generally more
effective...

Chris C

 

[xarax]

That is entirely impossible. The first can be done (but the obvious
implementation is trivially foiled if your user is willing to go through
the hassle of changing the clock on his computer); the second basically
asks for a way to permanently modify the user's computer without the
user being able to undo these changes. Even if this _were_ possible (and
it isn't), let me don my sysadmin hat again and state that even an
attempt to do so would get _you_ permanently modified if I got my hands
on you.

Richard

The only way to do such things is for the application
to contact your website and register itself along with
some information about the installing machine. Your
website would maintain a (huge) database and a server
that will allow/disallow the installation. Similar
remarks for controlling the trial period.

 

[Stephen Sprunk]

Hmmm... Strictly theoretically you are right, but practically you can make
it quitehard to

a) find the change and
b) undo it.

For example by storing some value in non-volatile-ram, but there
are other ways.

A sufficiently motivated user would just remove the code to check for that
change, or (if the program were even moderately popular) download a "crack"
from the Web.

S

 

[Christian Bau]

This is highly platform specific and has nothing to do with C, but the
way I believe most people have accomplished something similar to this
(on Windows) is to store an encoded value in some hidden place in the
registry. This value will probably be some sort of time stamp. So, when
you install, you test if that value is in the registry, and if it is
you cease installation. If it is not, you grab the time, encode it, and
store it. When you run the app, you test against the timestamp in the
registry and stop running if they are over time. If they uninstall, you
simply have the uninstall program not delete the registry key.

Hack 1: Keep resetting the clock back.
Solution A: Keep a time ticker of total time the app has run, instead
of an actual time.

You should do this anyway. Otherwise what typically happens is this:

You create a trial version of your software and distribute it widely,
for example on some computer magazine cover CD. It sounds interesting,
so I install it on my computer and have a quick look whether it works or
not. Five weeks later I find some spare time, remember your software and
have a serious look with the intent to buy it if it is useful. Sorry,
too late: 30 day trial period has run out. I delete the program, no
sale.

 

[Alan Balmer]

You should do this anyway. Otherwise what typically happens is this:

You create a trial version of your software and distribute it widely,
for example on some computer magazine cover CD. It sounds interesting,
so I install it on my computer and have a quick look whether it works or
not. Five weeks later I find some spare time, remember your software and
have a serious look with the intent to buy it if it is useful. Sorry,
too late: 30 day trial period has run out. I delete the program, no
sale.

This has happened with me many times.

I've seen a few trial programs which will run on thirty days, even if
those days are a week apart. That works well for an evaluation.

 

[Richard Bos]

The only way to do such things is for the application
to contact your website and register itself along with
some information about the installing machine. Your
website would maintain a (huge) database and a server
that will allow/disallow the installation. Similar
remarks for controlling the trial period.

Meaning that you would need a permanent net connection to use this
program, and probably a gaping hole in your firewall? No way. Not even
at work where I _have_ a permanent connection and a firewall, let alone
at home where I'm on dial-up.

Richard

 

[Richard Bos]

This is highly platform specific and has nothing to do with C, but the
way I believe most people have accomplished something similar to this
(on Windows) is to store an encoded value in some hidden place in the
registry. This value will probably be some sort of time stamp. So, when
you install, you test if that value is in the registry, and if it is
you cease installation. If it is not, you grab the time, encode it, and
store it. When you run the app, you test against the timestamp in the
registry and stop running if they are over time. If they uninstall, you
simply have the uninstall program not delete the registry key.

Hack 1: Keep resetting the clock back.
Solution A: Keep a time ticker of total time the app has run, instead
of an actual time.

This is much better than the straight wall-time solution for other
reasons, as well.

Hack 2: Manually delete the registry value after uninstall.
Solution A: I believe that the way pople have solved this one is just
to hide the keys well and in duplicates.

Thanks a lot for spamming my registry with even more useless junk. When
I decide not to use your program, I want it _gone_, completely, not
adding to the ever-increasing bucket of outdated slop that is the
registry.
Oh, btw, I take it you've heard of registry snapshot programs? Compare
the snapshot before and after installation, plus first run, and you'll
know exactly where it put its keys. And then, of course, there are
things like <http://www.sysinternals.com/ntw2k/source/regmon.shtml>.

So, this solution is an irritant to your user; is easily circumvented;
and would not work on anything except M$-Windows even if it weren't
completely non-ISO-C.

Richard

 

[websnarf]

The internet is probably the most reliable dongle in existence --
that's how steam (the Half-Life distribution/unlocking system) works.
Though obviously you can do things far more simply. You will need to
think about the cryptography, but basically you want to encrypt
(rounded real-time, ip-address, a machine generated unique id) and use
this as some kind of hash against a decryption key that you make
available from a web server (roughly) for the duration of the trial.
The hack around this can be arbitrarily complicated, so presumably you
should expect it to work until it attracts really hard core hackers.
(But it requires that the end user have an active internet connection
to use your software.)

 

[dandelion]

A sufficiently motivated user would just remove the code to check for that
change, or (if the program were even moderately popular) download a "crack"
from the Web.

That would probably be the result. It would be hard(er) but not impossible.
In theory any check can be circumvented.