|
PureBytes Links
Trading Reference Links
|
It seems that it would be rather easy to reverse engineer DL by creating and
indicator and plotting the inputs and outputs on a chart, but only if the
DL code were viewable. Maybe?
-----Original Message-----
From: Gary Fritz [mailto:fritz@xxxxxxxx]
Sent: Tuesday, January 14, 2003 6:02 PM
To: Rivky
Cc: omega-list@xxxxxxxxxx
Subject: Re: Export ELS protected...Diamondlock
> Someone just sent me an email referring to a product called
> Diamondlock at http://www.investlabs.com/.
>
> Does anyone have any comments on/experience with this software?
I have a copy of DiamondLock, though I haven't used it in several
years. My recollections are:
DiamondLock provides a very low-level "virtual machine" that
executes a language that's roughly comparable to assembly
language, only it's harder to read and write. It's more like
looking at actual machine code. Each DL operand is represented
as a letter in an Easy Language string. Each DL owner has a
"key" that determines his mapping of "letter" to "DL operand," so
essentially each owner's DL code is encrypted by his own private
cipher.
The idea is that you take some key portions of your EL code and
encode them into DL operands. Since your DL operands are
encrypted by your private code, nobody is supposed to be able to
determine what it does (reverse-engineer it) even if they look at
the source. Since they can't find out what your code does, and
since the DL virtual machine won't execute the DL code unless the
user has the appropriate DL key, nobody can run your code unless
you unlock it for them.
In theory, this is pretty bullet-proof. It would be very
difficult for a hacker to decipher the DL gibberish to determine
what's in there, especially with a small sample of code. He
can't just patch around the DL code, because you've encrypted
critical logic in the DL operands. Supposedly he can't even
intercept the DL-decrypted logic, because DL decrypts it on-the-
fly in memory and immediately discards it.
In reality, could a determined hacker crack it? Maybe. I
suspect it would be difficult enough that he'd decide there were
much easier victims to attack, and leave your stuff alone.
Personally I'd guess it would be easier to crack most DLL code,
since the assembly language is easy to reverse-assemble and it's
not that hard to reverse-engineer the logic.
Main problem with DL: It's a huge PITA to encode your EL logic
into DL. The DL operands are very low-level, on the order of
"push var onto stack," "Add top two cells on the stack," "branch
if top of stack is zero," things like that. You can't call out
to EL or any other language. There is no "assembler" for DL, so
it's up to you to look up "push" in your unique code table and
determine that for your DL key it's "q". Then concatenate a
whole bunch of these operands into an EL string. The result
might look something like:
Result = DLExecute("xiD3sYFzhhDldfLDjflsETlKJqjl", Var1, Var2);
The gibberish is your DL code (which might be executing something
as simple as "if Var1 > Var2 then return Var1+Var2, else return
0" or something like that), and Var1/Var2 are inputs to the DL
code.
The encoding process is very painstaking, very slow, and VERY
error-prone.
However, if you're really paranoid about protecting your code, DL
may be just what you're looking for. As I said, I suspect it
would be harder to crack a decent DL program that to crack most
DLL's. Maybe a DLL wizard could make a harder-to-crack DLL, but
DL is probably easier for most humans.
Gary
|