Re: binary distributions

From: <>
Date: Sun, 26 May 1996 18:37:19 -0400 (EDT)

This solution may be the only fix in the short run,
I was unaware of how excellently STk keeps the program
internally. It would be trivial to reverse engineer any
STk program. Amusing. I am very fond of STk. More soon.

Still looking for a scheme solution for java, s.v.p.

On Fri, 24 May 1996, Alan G. Yoder wrote:

> Michael Warhman writes:
> >>
> >> The other interest that I have is to be able to distribute binaries
> >> only of my STk code (obviously to only specific target machines), in
> >> order to protect intellectual property.
> >>
> Erick replies:
> > A way that would achieve this goal (among others) would be to write a
> > compiler, but it could take some time ... Another way, could be to write a
> > special loader which reads crypted data and translate them in the normal
> > sexpr. Of course, you should also redefine functions such as
> > procedure-body or macro-body to void functions to avoid taht a user dumps
> > your application function by function. It seems to me that it should be
> > sufficient and very easy to implement, but it is possible that there is a
> > hole I have not seen. What do you think of this ?
> Back in the early days of AutoCAD, when Autodesk was selling architectural
> and mechanical application written in AutoLisp to run on top of AutoCAD,
> they used a tool called a Kelvinator. This tool simply mangled all the
> user-defined names in a program and took out all the extra whitespace.
> It was technically feasible to go through and unmangle all the programs
> by hand, but at a cost well in excess of what it cost to buy the
> application ($1000).
> This pragmatic approach works if you're worried about piracy, without the
> need for a special loader. If you're worried about competitors stealing
> your code for use in their own products, you'll need something more secure
> than the loader Erick mentions, unless you write your own and do not
> distribute it. If the loader is embedded in the publicly available
> version of Stk, what prevents an attacker from modifying Stk to load the
> encrypted source file, convert it to s expressions and pretty-print it?
> Alan
> ---------------------------------------------------------------------------
> Alan G. Yoder
> Dept. of Computer Science and Engineering
> 384 Fitzpatrick +1 219 631 5772 or 5273
> Notre Dame, IN 46556 +1 219 631 9260 dept. fax
> ---------------------------------------------------------------------------
Received on Mon May 27 1996 - 00:45:29 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST