|
PureBytes Links
Trading Reference Links
|
Alex, you have been a great help, along with several others. You know
who you are. Can't thank you enough, I'll do some work on it now.
Appreciate it!!!
:::::::::::::::::::::::::::::::
C O D Y B U R G A T
:::::::::::::::::::::::::::::::
-----Original Message-----
From: Alex Matulich [mailto:alex@xxxxxxxxxxxxxx]
Sent: Friday, February 14, 2003 10:27 AM
To: omega-list@xxxxxxxxxx
Subject: Re: Time Sensitive Password...
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
|