(fwd) Re: Limiting the time of an executable created with PerlApp.

Jan,

I'd also like to point out here that this method is actually
very good
because unlike programs written in C, C++ or other true
compiled
programs, the Perl app executable would be very hard to
"crack" in order
to remove the expiration.   

With other languages, someone with the appropriate knowledge
of
assembler and the right tools could change the expiration
date to some
really far into the future date.   But with a Perlapp it's a
lot harder
to get at the code due to the compression/encryption that is
done.  


-----------------------------------------------------
James Harris
Enterprise Application Analyst/Programmer
Information Technology Division
Frederick Community College 

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

>>> Jan Dubois <jandActiveState.com>
2/14/2007 12:54 PM >>>
I wrote this earlier today in a private message, but thought
maybe
someone on the mailing list might be interested in this
technique too:

On Wed, 14 Feb 2007 08:53:06 -0800, Jan Dubois <jandActiveState.com>
wrote:

>can I put a time limit on my executeable which I create
with PerlApp?
>When I evaluated the PDK my executeables where limited
to the time my
>trial period ended. Now that we bought the PDK is it
possible to set
>such a time limit deliberately? If not, I think this
would be a great
>feature in future versions.

You can implement this easily yourself.  This sample program
will run
normally when you invoke it as `perl expire.pl`, but will
refuse to
run
after the expiration date when it has been compiled with
PerlApp.  You
could hardcode the expiration data in your program, or you
can supply
it
when you build the executable and retrieve it inside your
application
from a bound file:

------------------------------------------------------------
-----
BEGIN {
    return unless defined $PerlApp::VERSION;
    my $expire = PerlApp::get_bound_file("expire")
or return;
    my($y,$m,$d) = (localtime)[5,4,3];
    my $today = sprintf("%04d-%02d-%02d",
$y+1900,$m+1,$d);
    return if $today le $expire;
    print "expiredn";
    exit;
}
print "okn";
------------------------------------------------------------
-----

c:tmp>date /t
Wed 02/14/2007 

c:tmp>perlapp -f --nologo --bind expire[data=2007-02-13]
expire.pl

c:tmp>expire
expired

c:tmp>perlapp -f --nologo --bind expire[data=2007-02-14]
expire.pl

c:tmp>expire
ok

Cheers,
-Jan

_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com 
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs 

_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

James,

Perlapp may make it harder to alter an executable.  But that
is
not the only way to bypass the limit.  Disassemblers and
esoteric
knowledge aside, the technique in question is easy to defeat
by
anyone who has access to the system clock (that's everyone
at home;)
and knows how to roll it back.

So, I did not think Jan had implied that was a hard to
crack
solution.  An easy and quick one, yes.

There are special tools that would turn any executable into
a protected one; sustainable to clock rollback attacks,
too.
And, this is really quickly getting off topic..

By the way, I am not an expert on protecting ware!  I just
know it is futile;)

Cheers.  -vi
_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs