Re: code transformations?

albaugh@agames.com (Mike Albaugh)
26 Sep 1996 11:07:23 -0400

          From comp.compilers

Related articles
code transformations? lord@emf.net (1996-09-22)
Re: code transformations? null@diku.dk (1996-09-23)
Re: code transformations? cef@geodesic.com (Charles Fiterman) (1996-09-23)
Re: code transformations? ma@camcon.co.uk (1996-09-25)
Re: code transformations? darius@phidani.be (Darius Blasband) (1996-09-26)
Re: code transformations? meulenbr@prl.philips.nl (1996-09-26)
Re: code transformations? albaugh@agames.com (1996-09-26)
Re: code transformations? torbenm@diku.dk (1996-09-29)
Re: code transformations? ndc@icanect.net (Norman Culver) (1996-09-29)
Re: code transformations? kaz@nt.com (1996-10-03)
Re: code transformations? hdlambri@cs.arizona.edu (Henry Dan Lambright) (1996-10-20)
Re: code transformations? hogan@rintintin.Colorado.EDU (1996-10-24)
Re: code transformations? bill@amber.ssd.csd.harris.com (1996-10-24)
| List of all articles for this month |

From: albaugh@agames.com (Mike Albaugh)
Newsgroups: comp.compilers
Date: 26 Sep 1996 11:07:23 -0400
Organization: Atari Games Corporation
References: 96-09-094
Keywords: tools, comment

Tom Lord (lord@emf.net) wrote:
: Some time ago, somebody suggested to me the idea of writing a certain
: kind of C preprocessor. The gist of it was that the preprocessor
: would actually parse the program, make some changes to the AST and
: then write source back to disk. This got me to thinking -- suitably
: sophisticated transformations could preserve the semantics of the
: program, while completely disguising the text of the source.


I think you would need to really nail down what you mean by
"semantics". Many existing optimizing compilers are unfairly blamed
for "breaking" programs that have in reality been broken (in the sense
of depending on undefined or implementation defined behavior) since
they were written, but happened to work on the author's favorite
machine/compiler.


I have written a source-to-source processor of the sort I
believe you are suggesting, although it translated 68K assembly to
(drum roll) 68K assembly. The whole point was to produce a "silliness
reducer" for the output of a well-known "optimizing" compiler. It
typically reduced space and run time by about 10%, but it didn't do
anything very radical, because it was very conservative about only
making changes were guaranteed safe.


If one were to write a program that could, say, look at a C
file, and preserve ANSI/ISO semantics for all non-static functions,
one could apply the techniques to an optimizing compiler, with at
least potentially more income. If one were to write such a program
which "preserved" the semantics expected by the great unwashed, and
emitted "squeaky clean" ANSI/ISO C, one would stand a good chance of
being canonized by the poor SOB's who normally have to "maintain" the
mass of "rotted" software.


: This has obvious implications for anyone into intellectual property theft.


Not really. The courts typically sell justice to the highest
bidder (in legal fees) regardless of annoying details like facts,
especially in "intellectual property" civil suits. If somebody is
caught selling something even remotely like a well-known program,
he/she will be bankrupt loong before any judge gets to look at the
source code. Such cases as do get to court often turn on such things
as a single "oddly phrased" idiom, researched diligently by grad
students on the plaintiff's payroll, which is ultimately paid by the
loser (guess who.) Real pirates stay in business by not getting caught
in the first place.


: So the question is, has anybody written such a program?


Optimizers, sure. Pre-Processors (like the KAP preprocessor)
sure. Programs which really "understand" other programs enough to
produce a functionally equivalent but un-recognizable to its author
copy? The effort would be better spent elsewhere.


: Will anyone?


C-Intercal exists, so anything is possible.


: [There are certainly C obfuscators, but the ones I know of perform primarily
: lexical smooshing. -John]


And are not really intended to obscure authorship, just to
make fixing bugs in a purchased program marginally more annoying than
the vendor's voice-mail hell :-)


Mike


| Mike Albaugh (albaugh@agames.com) Atari Games (now owned by Williams)
| (No connection to Warner or any company owned by the Tramiel family)
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
[Please take the legal followups to misc.legal.computing, compilers topics
can stay here. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.