Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Daniel Ortmann]

Sirs,

With the intent of furthering the practical commercial use of O'Caml, or at
least eliminating some possible objections to its use ...  I submit the
following observations and questions for your consideration:


I have asked myself "How might companies object to Objective Caml?"

The thought occurs to me that companies may wish to:
- develop and sell byte-compiled O'Caml modules
- develop and sell applications which use dynamically loaded modules
- protect their actual source code

Because of the well-thought regularity of O'Caml bytecode, the ease of viewing
(for example) emacs elisp bytecode in emacs, and the unusual numbers of bright
people working with O'Caml ...

... it occurs to me that companies may be concerned about the ease of "reverse
engineering" their byte compiled software modules and thus object to Objective
Caml.

So.

How can companies protect their bytecode, at least their modules, from reverse
engineering?

1) The idea occurs to me that O'Caml might support various standard encryption
   modules using different types of encryption techniques (DES, PGP, etc).
2) Perhaps user encryption could also be supported.
3) Perhaps the encryption modules should be composeable, multiple modules
   being used to derive another module.
4) What about using public/private keys and key management?
5) Should this be integrated with licensing?  What licensing techniques are
   available on Windows?  Mac?  Unix?  Other?  (O'Caml WILL get big
   commercially, and WILL need to address this eventually.)
6) What things should be visible non-encrypted in cmi/cmo/other files?
7) Should such encryption be available via marshalling?  If not, might some
   needs be common?


Philosophically speaking, earning money and protecting the rewards of hard
work are not bad a priori.  There *will* be an exchange of value; that
exchange may be either with or without "concern for your fellow man".  In
fact, one way of looking at a dollar bill is as a type of "certificate of
service to your fellow man".

--
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

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Markus Mottl]

> How can companies protect their bytecode, at least their modules, from reverse
> engineering?

I fear that there is probably no way to prevent this: as soon as you have a
virtual machine that can (somehow) decode the byte code - it has to if it
wants to execute anything useful - you know the internal structure of the
code.

Since all the sources of INRIA are open (i.e. also the protocols),
everybody could "fake" a virtual machine that, instead of just executing
the code, emits the decoded byte code.

That's also the reason why you can (in theory) always break any kind of
copy protection: as soon as a program runs on your machine, you can track
any information about it you want. That may be lots of work (admittedly
less work for byte code) - but it can be done.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Max Skaller]

Daniel Ortmann wrote:
> 
> Sirs,
> 
> With the intent of furthering the practical commercial use of O'Caml, or at
> least eliminating some possible objections to its use ...  I submit the
> following observations and questions for your consideration:

The issues raised so far (where I work and use Ocaml) were:

	1) no one here knows it
	2) possible licence restrictions

Since I use the native code compiler exclusively,
there's no current problem involving bytecode.

BTW: people here read books. An English Ocaml book would provide
very strong support for industrial use.

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

OCaml book

[Joshua D. Guttman]

Max Skaller <maxs@in.ot.com.au> writes: 

>   
>   
>   BTW: people here read books. An English Ocaml book would provide
>   very strong support for industrial use.
>   

Right.  A number of people have volunteered to help translate the
French O'Reilly book into English.  We hope to allow it to be
retrieved freely via the net, and we're optimistic that O'Reilly will
agree to this.  Their preliminary response was positive.  The authors
have also shown enthusiasm, and are likely to give us access to their
sources for the text.

We're very grateful for all this support, but we need one more
important ingredient:  more volunteers.  

If you're reasonably confident about your grasp of technical French
and technical English, we'd be very grateful for your help with a
chapter or two.  Your help with this project will create an important
ingredient for the broadened success of OCaml in English-speaking
countries.  

Thanks.

        Joshua 

-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop A150 
	202 Burlington Rd.		Tel:	+1 781 271 2654
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 3816

Re: OCaml book

[Julian Assange]

guttman@mitre.org (Joshua D. Guttman) writes:

> If you're reasonably confident about your grasp of technical French
> and technical English, we'd be very grateful for your help with a
> chapter or two.  Your help with this project will create an important
> ingredient for the broadened success of OCaml in English-speaking
> countries.  

My technical French isn't so good, but I'm willing to do some proofing,
graphics or other such work.

Cheers,
Julian.

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Max Skaller]

Daniel Ortmann wrote:

> ... it occurs to me that companies may be concerned about the ease of "reverse
> engineering" their byte compiled software modules and thus object to Objective
> Caml.

I actually don't think this is a problem, although I'm not sure.
If it were, the solution would be to embed the runtime and bytecodes
inside an executable, and encrypt the bytecode. In that case,
being able to run the bytecodes _from a memory image_ rather than a disk
file would be the only real requirement. Configuring licence servers
etc should be left to the producer of the product.

Because the whole of the ocaml system is open, 
all of this is already possible. If there is a problem here,
it is the lack of availability of consultancy from ocaml experts 
to assist in the embedding task.

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Sven LUTHER]

On Tue, Jun 06, 2000 at 03:46:06PM -0500, Daniel Ortmann wrote:
> Sirs,
> 
> With the intent of furthering the practical commercial use of O'Caml, or at
> least eliminating some possible objections to its use ...  I submit the
> following observations and questions for your consideration:
> 
> 
> I have asked myself "How might companies object to Objective Caml?"
> 
> The thought occurs to me that companies may wish to:
> - develop and sell byte-compiled O'Caml modules
> - develop and sell applications which use dynamically loaded modules
> - protect their actual source code
> 
> Because of the well-thought regularity of O'Caml bytecode, the ease of viewing
> (for example) emacs elisp bytecode in emacs, and the unusual numbers of bright
> people working with O'Caml ...
> 
> ... it occurs to me that companies may be concerned about the ease of "reverse
> engineering" their byte compiled software modules and thus object to Objective
> Caml.
> 
> So.
> 
> How can companies protect their bytecode, at least their modules, from reverse
> engineering?
> 
> 1) The idea occurs to me that O'Caml might support various standard encryption
>    modules using different types of encryption techniques (DES, PGP, etc).
> 2) Perhaps user encryption could also be supported.
> 3) Perhaps the encryption modules should be composeable, multiple modules
>    being used to derive another module.
> 4) What about using public/private keys and key management?
> 5) Should this be integrated with licensing?  What licensing techniques are
>    available on Windows?  Mac?  Unix?  Other?  (O'Caml WILL get big
>    commercially, and WILL need to address this eventually.)
> 6) What things should be visible non-encrypted in cmi/cmo/other files?
> 7) Should such encryption be available via marshalling?  If not, might some
>    needs be common?
> 
> 
> Philosophically speaking, earning money and protecting the rewards of hard
> work are not bad a priori.  There *will* be an exchange of value; that
> exchange may be either with or without "concern for your fellow man".  In
> fact, one way of looking at a dollar bill is as a type of "certificate of
> service to your fellow man".

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.

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

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

Still, please remmeber a few things :

1) Reverse engineering is legal in many european countries.

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.

3) Well this would be a big step back in what the has been achieved in
freedom of software and sharing of ressources. 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). 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.

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

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.

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. 

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++, ...

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.

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 ?

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.

Friendly,

Sven LUTHER

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Daniel Ortmann]

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

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Sven LUTHER]

Just a quick repply, since i have not a lot of time right now, ...

First, i am a user like you, i have absolutely no relation to inria, apart
that i am a ocaml user, so things i say here are only my opinion, and to add
fuel to the discution, ...

> 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".  :-)

Well i think not, the .cmi files are there to not to hide information, but to
give the information needed by other modules.

> > 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.

The above lines where a bit provocative, and meant as humor, at elast
partwise, ...

> (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."

Well, but if you hide the techniques, so that nobody can do it, and people who
want ot are not permitted so by some patent and other such stuff, then the
technique may be lost forever, if the company holding the patent says so.

> 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".

Yes, as long as they can make money for it, and i don't think this approach as
had much success lately in the software industry, but then now that linux is
gaining acceptance, and microsoft is going to be split, maybe we will have
more chance on this.

But then, remember also how difficult it is to get a cheap ppc motherboard to
build a system, and you will see that even with hardware there is a problem in
this in that you limit sharing to those with money.

> 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:-)

This is begining to change, in truth, the seed has been planted long ago, and
the first fruit where the open sourcing of the netscape code 2 yaer ago.

> > Still, please remmeber a few things :
> 
> > 1) Reverse engineering is legal in many european countries.
> 
> I did not know that.

There was some talk to change that though.

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

Don't think so, ...

> > 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.

lightened some but not enough i think, at least Debian is not sufficiently
convinced by it to move encryption back to the main server in US from free
country where it is now, ...

> ... 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?:-)

Some argue that licence wise it is almost the same, ...

> > 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."

Even the GPL allow you to keep secrets, the only unethical thing is that you
are not permitted to hold secret from your customer, but then would you buy a
car which you don't would have the right to open the hood ?

> > 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:

Surely from what you described is happening at IBM, it is so, ...
> 
> 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."

More technical response will be given be others than me, some have already, i
just wanted to make you feel what would be reaction of the "free" (in the
large sense, i don't make politics) software community would be to such a
move.

> 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.

Not, but it may hurt the ocaml perception in open source ? i don't know,
really, i think the main problem is that the inria guys want to restrict code
splitting, and maybe have not much time to devote to it, but as said i have no
idea about it, they will surely respond for themself, if they feel it is
needed.

> > 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".  :-/

Sure, ... but in the long term, they will be replaced by younger people whgo
believe in it, and as "open source/free" stuff gains more acceptance they will
look at it also, ...

> 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.

I think it is not as easy in the ocaml case, ...
but more competent people will or have responded already to you on this, 

> > 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.

All in all, i don't think that reverse engineering bytecode would be more easy
than reverse engineering assembler, especially since existing reverse
enginneering experience is more widespread in assembleur than in ocaml
bytecode, ...

> 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.)

I don't believe that the .cmi is hiding info, in my sense it is more showing
info, but then i am no expert of the content of it. maybe it does both,
depending how you sees it.

> > 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.

Well, another approach is you pay people to work with inria to do it. :)))

> 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.

I think reinventing the wheel (a part fro teaching and self teaching prupose)
is what hurt the software industry most, but then it makes for lot of job
oportunity for all those programmers out there, ... :)))

> > 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.  :-(

Use a good packaging system, ... :)))

> 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.

See above, ...

> > 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.  :-)

Good work then, i hope this has given you something to think about, ...

Friendly,

Svne LUTHER

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Vitaly Lugovsky]

On 8 Jun 2000, Daniel Ortmann wrote:

> > 1) Reverse engineering is legal in many european countries.
> 
> I did not know that.

 But, sure, it is completely legal, for example, in Russia. And license
conditions which prohibits reverse engeneering, like M$ license, is illegal ;)

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

 No. But I can't see a way to make it hard.

> ... But the answer would be:  Don't distribute the actual encryptiong directly
> with O'Caml, just the hooks.

 Yeah, like it was in Linux kernel: kernel from US, and concrete cryptographic
functions from Europe.

> 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."

 It is possible, but it is completely uneffectife.

> 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.

 Java reverse engeneering is not much harder than Elisp ;)
So, it'll be the same for OCaml. 

P.S. [offtopic] Fundamental science is just a reverse engeneering and violation
of God's intellectual property. ;)

--

   V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Gerd Stolpmann]

On Fri, 09 Jun 2000, Daniel Ortmann wrote:
>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.

>From a purely technical point of view: I think it is impossible to protect
executable code by encryption if the code itself contains the key: Simply start
the encrypted program, and wait until the bytecode is decrypted. The
unencrypted bytecode will be in memory, and it is possible to examine memory
contents and search the regions containing bytecode (which is quite simple).

There is no advantage if asymmetric encryption is used.

The only way to make it harder to get the bytecode is to permute the
instruction codes. The permutation is applied both to the bytecode and to the
virtual machine itself. However, the level of protection is not very high,
because you can compare the permuted VM with the original VM, and because you
can analyze the structure of the bytecode (which is still the same).

I think it is not possible to improve the level of protection by encryption.

>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".  :-)

But your "implementation hiding" has a different intention. Normally, such a
property is discussed to improve the maintainability of software; i.e. you can
exchange implementations without changing the module interface. In contrast
to this, your proposal has a commercial background.

>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.

This is not possible with OCaml bytecode which is relatively close to machine
code. This means: You cannot easily find out the structure of the source code
by analyzing the byte code because compilation "flattens" the structure to some
extend. Recursions are often transformed to ordinary 
loops. The memory layout of values can be difficult if some type of closures
are used. 

Perhaps some type of automated reverse engineering is possible (without tools
I cannot imagine it), but much of the structure of the source program will be
lost. 

I would suppose that it is cheaper to develop the program again than to crack
it.

Note that Java byte code contains even more structure than OCaml byte code, and
I have never heard that somebody complained about missing protection of Java
investments.

I hope my remarks make the discussion more to the point.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Julian Assange]

Daniel Ortmann <ortmann@vnet.ibm.com> writes:

> 1) The idea occurs to me that O'Caml might support various standard encryption
>    modules using different types of encryption techniques (DES, PGP, etc).
> 2) Perhaps user encryption could also be supported.
> 3) Perhaps the encryption modules should be composeable, multiple modules
>    being used to derive another module.
> 4) What about using public/private keys and key management?
> 5) Should this be integrated with licensing?  What licensing techniques are
>    available on Windows?  Mac?  Unix?  Other?  (O'Caml WILL get big
>    commercially, and WILL need to address this eventually.)
> 6) What things should be visible non-encrypted in cmi/cmo/other files?
> 7) Should such encryption be available via marshalling?  If not, might some
>    needs be common?

My god, this is awful.

(a) encryption will not help you if it is standardised. If it is not standardised,
then all it will do is delay understanding. If it can be decrypted by the vm,
it can be decrypted by the analyst. 

(b) Time to market penalties are so incredibly brutal now, I question
    whether obfuscating byte-code is at all necessary, simply because most people
    don't have time to analyse source code, let alone byte code.

(c) Ocaml applications are so rare (compared to C/++), you can consider not only
    Ocaml byte code, but the Ocaml source code an excellent obfuscater.

(d) Commercial programs rarely implement unpublished, hard to discover ideas.
    Patents are so easy to acquire you are far better off using patent protection.

(e) Those who are willing to rip you off by reverse engineering are probably
    willing to do it by sheer piracy. e.g 2nd and 3rd world markets.

> Philosophically speaking, earning money and protecting the rewards of hard
> work are not bad a priori.  There *will* be an exchange of value; that
> exchange may be either with or without "concern for your fellow man".  In
> fact, one way of looking at a dollar bill is as a type of "certificate of
> service to your fellow man".

The problem is there is a lot of value exchange that isn't represented by
the face of the bill. Ocaml itself is a case in point.

Cheers,
Julian.

Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Michael Donat]

>How can companies protect their bytecode, at least their modules, from
reverse
>engineering?


I believe that if someone has the desire to reverse engineer OCaml bytecode
someone will also have these other capabilities:

1) Be able to reverse engineer native code.
2) Be able to run the OCaml bytecode system in a debugger, stop after your
bytecode was decrypted, and reverse engineer it from there.

I don't see a benefit in having an OCaml module encryption system.

If you want to encrypt important portions of your app, you might consider
producing your own bytecode system. The main benefit of this approach is
that your bytecode is private, thus dramatically intensifying the effort
required to reverse engineer. I think this would be a much more effective
use of time than implementing an OCaml module encryption system.

Michael Donat

RE: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Brent Fulgham]

> BTW: people here read books. An English Ocaml book 
> would provide very strong support for industrial use.
> 
I'm in the process of reading "The Functional Approach
to Programming" (Cousineau & Mauny).  This book is not
strictly OCaml (it's based on CAML-Light), but it's
teaching me the basics I need.  It's also quite a good
book for learning functional programming techniques
in general.  It's not a bad price, either.  I found it
for $32 at Borders.com.

BTW -- Although it is a translation of a French book,
it is quite well-written.  Their editor/translator was
quite talented.  I can find very little in the way
of French syntax in the volume ;-)

Hope that's helpful,

-Brent

RE: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Brent Fulgham]

> > I'm in the process of reading "The Functional Approach
> > to Programming" (Cousineau & Mauny).  This book is not
> > strictly OCaml 
> 
> That's part of the problem. People here are short of time:
> while education in functional programming techniques is 
> useful, a description of Ocaml is more pointed: remember,
> Ocaml is _not_ a functional programming language, but an
> Algol like language with functional, procedural, and object
> oriented components... just like C++. 
> 
> In ocaml, the 'orientation' is more functional, but the biggest
> obstacle isn't the functional paradigm as such, but the actual
> concrete syntax used.
> 
Yes.  An O'Reilly-style "Nutshell" handbook would be quite nice.
However, I have not seen such an animal.  I'm afraid the C&M book
is all that's available for those of us whose French skills are
sub-par.

It will probably take a killer app to get such a book published...

-Brent

RE: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Brent Fulgham]

> 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".  :-)
> 
Regarding your later anecdote about the Lisp source being available
under Emacs, I think we may be comparing apples to oranges.

Pulling up a .cmi file in a text editor does not provide me with
the same ease-of-analysis of Lisp sources.  I would have to sit
down and understand the byte value meanings for the OCaml VM,
parse the bytes in the .cmi file, and then discern the meaning.

This is no different than "decompiling" the byte code from a Java
VM (the compiled "class" modules).  Certainly one of us could write
a utility to "decompile" .cmi files (such beasts exist for Java).

I guess my point is:  The .cmi files seem to be obfuscated enough
for general distribution.  I mean, someone with enough interest
in your 'secrets' to learn the byte code and write a decompiler 
will be capable of doing the same to native object code as well.

I guess I'm just not sure your proposal would provide sufficient
value for the effort and performance hit required.

[ ... snip ... ]
> > 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 

Please note that under the US's current law (well, current prior
to the most recent potentially-temporary relaxation), it is also
prohibited to provide encryption hooks in your code.  You could
get around this by calling them "compression" hooks.

Regards,

-Brent