From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA10469 for caml-red; Mon, 12 Jun 2000 16:06:16 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA26222 for ; Sun, 11 Jun 2000 14:20:58 +0200 (MET DST) Received: from mail.ngi.de ([195.243.0.227]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e5BCKvn07731 for ; Sun, 11 Jun 2000 14:20:58 +0200 (MET DST) Received: from ice.darmstadt.netsurf.de (p3EE0D9C2.dip0.t-ipconnect.de [62.224.217.194]) by mail.ngi.de (8.9.3/8.9.3) with ESMTP id OAA67939; Sun, 11 Jun 2000 14:17:31 +0200 (CEST) Received: from localhost (localhost [[UNIX: localhost]]) by ice.darmstadt.netsurf.de (8.9.3/8.9.3) id RAA25747; Sat, 10 Jun 2000 17:28:00 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: "Daniel Ortmann" , caml-list@inria.fr Subject: Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml Date: Sat, 10 Jun 2000 16:41:36 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200006062047.QAA08876@northrelay03.pok.ibm.com> <20000608105446.A10624@lambda.u-strasbg.fr> In-Reply-To: MIME-Version: 1.0 Message-Id: <00061017280001.01513@ice> Content-Transfer-Encoding: 8bit Sender: weis 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 > x 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 ----------------------------------------------------------------------------