[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Time Sensitive Password...



PureBytes Links

Trading Reference Links

Pierre wrote:
>A few days ago, you asked how to unprotect an EL protected file.
>If you received a locked file, you do not have to open it without
>the permission of the developer. So why ask ?

Well, *I* have had a reason to ask.  I can think of two legitimate
reasons for wanting an EL protected file cracker:

1.  I once saved some of my own work "protected" then subsequently
had to replace my hard drive and re-install everything.  This bit
of work was archived only as protected code, and I had forgotten
the password.  So I could not get it back.  I really wished I had a
version of ELAcrack that worked with TS2000i.  Fortunately it wasn't
too hard to rewrite.

2.  If you know that there are utilities floating around to
unprotect files, and you want to ensure that stuff you release
to the public is secure, it behooves you to know how those file
unprotectors work so that you can perhaps figure out a way to foil
it.

Cody's recent question about a time-sensitive password makes sense
in light of him finding out recently that source cannot be recovered
from a protected file made with TS5 or higher.  At least as far as I
know, one cannot recover the source, and that's what I told him.

In fact, I'll answer his other question now:

>De : Cody Burgat [mailto:cburgat@xxxxxxxxxxxxxx]
>
>Does anyone out there know if it is possible to insert a TIME
>SENSITIVE password, for example, that would allow an indicator or
>strategy to be usable for 1 week, month, or whatever the desired
>time period was?

I would do it like this:

1.  Come up with a way to encrypt an expiration date into an
alphanumeric password, such that when you combine this password with
a predetermined key known only to you, you can extract the date.

2.  The password you give to the user must be passed as a parameter
to each signal and indicator and function.  When currentbar=1, the
expiration date is extracted from the password, and checked against
the computer's own date.  If it's expired, a variable is set so that
the signal or function doesn't do anything for the remaining bars.

Here's an example. Say you want something to expire on 13 March
2003.  One thing you could do is convert the date to the TS date
1030313.  Then you could take your numeric key (hardcoded into the EL code),
say 316217471, and perform some reversible operation with the date, such
as add them together (in reality you'd want to do something more
complex than that).

Take the combined key+date and convert it to a base-N number, using
the digits 0-9 and a-z to represent the number.  The result is the
password you give to the user as a text string.  In this example,
I'll use base 16.  Adding 1030313+316217471=316320484 which is
12daaae4 in base 16.  Base 16 is obvious so you would want to use
some arbitrary base up to 36.  This makes it just a little harder
for someone to figure out.  Even better, you could add a couple
digits to your encrypted date which contain the base to use, and use
a random base, so everyone has a differently-generated password.

When the user uses this password, it is converted character by
character back to a number.  In my example I would then subtract the
key from this number to recover the date.  On currentbar=1 I would
test whether the actual date (not the bar date, but the computer
date) is less than or equal to the recovered date.

The above procedure has the following levels of protection:

1.  The key used to recover the date from the password is known only to
you and is hardcoded inside a protected EL file from which the source
cannot be recovered.

2.  The algorithm used to combine the key with the expiration date is
known only to you.

3.  The numeric base that you use to convert the encrypted date to a
password string, is known only to you.

The above scheme would be difficult to break, but not impossible for
a determined hacker.  In my view, if you can make something more
difficult to crack than it's worth to buy, then anyone who does take
the trouble to crack it has earned it.

-- 
  ,|___    Alex Matulich -- alex@xxxxxxxxxxxxxx
 // +__>   Director of Research and Development
 //  \ 
 // __)    Unicorn Research Corporation -- http://unicorn.us.com