Version française
Home     About     Download     Resources     Contact us    
Browse thread
Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Daniel Ortmann <ortmann@v...>
Subject: Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml
Note that althought I brought up the idea of such encryption, I don't really
have much opinion as to whether it is a good idea.  I *do* believe it should
be discussed.

... and not mainly philosophically.  But technically.  Hopefully that email
got some people thinking.  If so, then that small mission of mine has been
accomplished.


Also, isn't "information hiding" part of the purpose of .cmi files?  What I am
suggesting might be viewed as an stronger type of .cmi file ... with REAL
"implementation hiding".  :-)



Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:

> This surely is the philosophy of those who want to make more money using all
> the free software that other people have developped for free.

I brought it up precisely because I thought "Maybe this is an idea that occurs
to me merely *because* I work in a commercial engineering environment?  If so,
then it might not occur to people who are more academically oriented."

Your response shows the virtue of my email: you were motivated to respond.

(I wanted to post on this topic a couple of months ago ... but since I know
the high skill level of the people on this list I had to "work myself up to
it".)

> Anyway, i personnaly are not at all in favor for a scheme such as what you
> propose.

Ivan Galamian, violin instructor and long time head of the Julliard string
department said, "A particular technique might go out of style, but the
ability to do it never goes out of style."

The ability to manage encrypted byte code, even if provided, might not be
used.  But the ability to do so would not go out of style.

Today, even when companies "work together" and use each other's chips, models,
and other circuitry, they distribute encrypted SPICE models or blackbox driver
specifications called "IBIS".

We're stuck with encryption.  Worse, with multiple incompatible encryption.  :-(

> But then i am a Debian GNU/Linux developper and my opinion might be a bit
> biased on this.

I know MANY people inside IBM who are actively lobbying for much more use of
Linux ... as well as general support for the Open Source movement (i.e. more
than in words).  While I personally use FreeBSD at home, I would love to see
Linux and GNU use increase.  At work.  In homes.  Everywhere.

The problem is that many upper level people who control the money often
believe that the Open Source movement is anti-business.  (Hint, hint:-)

> Still, please remmeber a few things :

> 1) Reverse engineering is legal in many european countries.

I did not know that.

Is "making it hard to reverse engineer" illegal?  :-)

> 2) Encryption is illegal in many countries, or at least export restricted, i
> think france changed this some time ago, but if not, it would not be
> possible for inria to distribute such a product.

I believe the US has just lightened up on some of the restrictions.

... But the answer would be:  Don't distribute the actual encryptiong directly
with O'Caml, just the hooks.  Have the actual files containing the encryption
available from non-restricted sites just as FreeBSD does.  (I'd guess that
Linux does something similar?:-)

> 3) Well this would be a big step back in what the has been achieved in
> freedom of software and sharing of ressources.

I would interpret the idea as "allowing people do have control over what they
wish to share and what they wish to keep private."

> Caml has a too small community today that you can permit to hamper it by
> being overly protectionist. And despite what you may think, it would be more
> important fro ocaml to be adopted by the "free" software community (that is
> all the linux/*bsd/whatever users), than by the "non-free" one (that is the
> people you have in mind).

I believe you are correct.  However, the options are not mutually exclusive
for the following reasons:

a) I am NOT saying "Everything should be encrypted".  Absolutely not.  I am
   saying "Consider what might need to be done technically to make such a
   thing possible."

b) "Aiding the Open Source movement" is not the same thing as "restricting
   business possibilies".

c) If O'Caml is good for Open Source, it is certainly good for business.  Any
   territory gained by O'Caml in business is not taken from Open Source.

Are there specific ways and reasons how and why adding such possibilities
would hurt the Open Source movement?  I am especially interested in technical
problems.

> Since the former surely will contain all the programmers in formation who
> will later become programmers and decider of the second group.  Also
> remember that many big companies are going for the "free" movement, like IBM
> and SGI for example.

I've heard words and slogans ... and some larger plans.  But the real interest
is in the popular movement inside IBM.  In fact "the deciders" are most often
Myer-Briggs "ISTJ" types who think "long term" means "next month".  :-/

In fact I've seen people with ideas desparately avoid becoming managers, even
skipping meetings to establish a reputation as non-manager material.  :-)

> 4) Is there really a need for this, would the complexity of doing so not
> outweigh the benefit ?

I don't know.  I am admittedly the only one that I know of who has asked the
question.

But how hard would it be?
a) If it's easy, then why not do it?
b) If it's hard, does the difficulty point out any technical flaws in O'Caml?
c) If a) or b), then might the answer be "do it in either case"?

:-)

> 5) In particluar there is a theory that says that security though peer
> review permitted by open source developpment model is higher than security
> trough hiding which you are suggesting. Or else you will find yourself with
> a microsoftian type of product (buggy, hidden, expensive, ...), which i
> doubt is something the ocaml community wish to be associated with.

I believe you are likely correct.

> 6) If someone is good enough to reverse engineer your ocaml bytecode, i
> think he is good enough also to reverse engineer your encrypted stuff, or at
> least to find holes in the security of it.

I just "reverse engineered" emacs byte code by doing
<control> x <control> r ~/.emacs.elc ... and easily viewed actual lisp code.

That's how easy it was.  That's the kind of thing I was thinking about
avoiding.

> 7) If you think the bytecode security is not enough for you, just use native
> code, it is faster anyway, and i doubt you will have less hideance in this
> than writting in C or C++, ...

Yes, that is a possibility.

But what if someone wants to develop a special mathematical toolbox and
provide it via byte code?  The byte code is platform independent ... but in
this case you want it somewhat hidden.

After all, isn't that the purpose of .cmi files?  Hiding information?

What I am suggesting could be viewed as an stronger type of .cmi file ... with
REAL "implementation hiding".  :-)

If you don't agree with that, could you tell me why one type of hiding is good
and the other bad?  (The question is rhetorical, of course.)

> 8) Finally, if all the above don't convince you, Ocaml is now available
> under a free license, and thus you are free to implement such a scheme, if
> you want so. This may not be the best fro the ocaml community, but still you
> can do it.

Ummmm...  This suggestion troubles me more than any of the rest.  :-(
Leaving some things up to users is good, but *not* everything.

Consider what happened with Scheme.  Here is a quote from a news post by
Olin Shivers:

    Programming in Scheme is an extremely unportable task if you do anything
    serious. Scheme is much less portable than, say, tcl or C. So we are
    unable to build on each other's work, but must instead keep re-inventing
    the wheel.

    If you *union* up the technology and features in all the Scheme
    implementations out there, you have an amazing tool. But each
    implementation is different, and all lack some important features. You
    don't hear people saying, "I wrote my program in SGI's implementation of C
    -- I can't run it on your Linux box because the struct declarations are
    different, and Linux's C implementation doesn't have do-while loops. Also,
    the interface the Unix write() function is different, so I'd have to
    rewrite all the I/O."

    I couldn't solve my problem in Scheme. And I am tolerably well acquainted
    with the language and its implementations. I could solve my problem with
    tcl. The server we were running had a tcl interpreter linked in, and the
    tcl system had hooks to an RDBM interface. Took an evening.

    As long as this situation persists, the Scheme community can snipe about
    what a lousy, poorly-designed language tcl is, but they aren't in a
    position to offer a credible alternative. So it is just empty flaming. So
    why post?

    Go fix the problem.
                    -- Olin Shivers

I personally *am* a strong believer in "reinventing the wheel" ... because it
makes me good at reinventing.  :-)   But then I compare against standard
prefix stuff, re-work the code, and do it also the "right" way.

> As a personal note, if it is not confidential, what are the personal
> interrest that make you ask yourself this kind of questions, are you aware
> of a particular company which ask this kind of question when faced with
> ocaml ?

It's not confidential.  I'm the only one I know who has asked the question.
In fact, I've not yet implemented *any* actual solutions with it here at IBM
in O'Caml.  I've tried to be sensitive to the concerns of my colleagues and
hold back on some change for awhile.

(I am the sort of person who always helped everyone else with their homework
and forgot to do my own.:-)


The problems I've run into have included things such as:

a) Public relations about O'Caml, (informing people around me gains me more
   freedom to act in the future.)  I've had to hold back and limit myself to
   reading and informing ... I think I've built enough trust to start using it
   soon.

b) Compiling problems.  I've had very poor results with local versions of GNU
   GCC on our AIX/RS6000 systems.  Can't link to various libraries, problems
   with shared libraries, problems with compiler crashes, problems with
   crashes of programs compiled with GCC, etc, etc.  (It works great on
   FreeBSD.)

c) Whenever I recompile *anything* ... I recompile *everything*, including
   almost all supporting libraries.  I dread it.  :-(

d) Lately I've even had some problems compiling with using our own compiler on
my system.  I think I need to reinstall or upgrade the OS.

> And i hope this few remarks can contribute to this discution, please don't
> take them negatively, if i was unexact or maybe offending somewhere.

I actually have a GENERAL PURPOSE 2-step problem solving process which can be
used to solve ANY problem.  The advantage is that the second step is trivial,
and the first step applies to ALL problems.  The steps are, 1) learn
everything in the universe, 2) solve problem.

I'm still working on the first step.  :-)

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ortmann@vnet.ibm.com or ortmann@us.ibm.com and 507.253.6795 (external)
ortmann@rchland.ibm.com and tieline 8.553.6795 (internal)
ortmann@isl.net and 507.288.7732 (home)

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas