Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!compilers-sender
From: rfg@mcc.com (Ron Guilmette)
Newsgroups: comp.compilers
Subject: Re: encripted source as an ANDF
Message-ID: <3991@ima.ima.isc.com>
Date: 27 May 89 21:31:35 GMT
Sender: compilers-sender@ima.ima.isc.com
Reply-To: rfg@mcc.com (Ron Guilmette)
Lines: 87
Approved: compilers@ima.UUCP
Posted-Date: Sat, 27 May 89 16:31:35 CDT

Recently, henry@zoo.toronto.edu (Henry Spencer) writes:
> Upon reflection, it occurs to me that there is a minor problem with using
> obfuscated source as an ANDF.  This problem turns major for most other
> ANDF concepts I can think of.  Consider:  at some level, one must leave the
> insides of libraries to the target system.  At the very least, how to do
> a system call is system-specific.  Moreover, different systems often have
> good reason to fiddle with the insides of, say, printf, to adapt it to
> the facilities and characteristics of the particular system.  One really
> wants an ANDF-distributed program to use the target's library, not one
> that the program hauls along.

This is perhaps *the* best argument IN FAVOR of using obfuscated source
code as ANDF, i.e. that it is *not* necessary to transmit some fully pre-
linked thing to the final destination system.  Rather, if you used some form
of "source", then, by definition, you would do the final "installation"
of a piece of ANDF stuff by compiling, and then linking with the local
libraries on the target system itself.  This solves lots of otherwise
UGLY problems that your would have with any system where the link-step
is done *before* distribution.

> PROBLEM:  what to do about things like putc(), which are macros -- that 
> is, are normally expanded before one generates obfuscated source, or
> tokenized source, or compiler intermediate form -- but must interface
> correctly with the local library?  This is a hassle even today on systems
> where some code is distributed as object modules to be linked on the
> target system:  one cannot improve stdio, for example, without risk of
> breaking such code.  The insides of those macros are really part of the
> target system's library and should be expanded on the target system.

A fair question.  I believe that a simple solution is available.

First, assume that we can build (or buy) a slightly modified C proprocessor
which will have the following minor extension.  It will have a "-u"
option, which is kinda like -U except that the given symbol *remains*
undefined even if a #define is subsequently seen for the given symbol.

Require the "manufacturer" of a given piece of software to identify
(before the obfuscation step, which includes preprocessing) the entire
list of "system-dependent" macros which are used within his code.  For
this list of macros (which will probably be quite small) the manufacturer
will perform the obfuscation step (with preprocessing) while using "-u"
options for each of the "system-dependent" macros which need to be
expanded on the "destination" system rather than on the original
"development" system.  This will causes any calls of the given macros
to be left "un-expanded" during obfuscation.

During "installation" on the "destination" system, appropriate "local"
definitions for the "system-dependent" macros could be supplied via
another (standard) preprocessing step and via -D command line options.


> Worse, it's not just function-like macros that are affected, but even
> plain old numeric constants, which can appear in places like array
> dimensions.  That means you can't just pretend that putc() is really a
> function and have the ANDF translator on the target machine do the
> code expansion -- that doesn't work for BUFSIZ.  To make BUFSIZ match
> that of the target machine (which it must if you want the target's
> setbuf() to work right), you have to do the preprocessing on the target.

Exactly right Henry.  As you correctly pointed out, some processing will
always have to be done of the "target" system.  Obviously, if you (as a
software author) make the choice to write your code such that it
depends on "system-dependent" macros, then you have left yourself no
alternative except to do (at least some) macro-preprocessing on your
intended "target" system(s).

I don't see any problem with doing preprocessing (for both function and
non-function macro expansion) on the "target" system(s) in an ANDF
distribution scheme.

> It seems to me that this kills any ANDF scheme which is not essentially
> based on obfuscated (but non-preprocessed) source.

In case you missed my point, I disagree very strongly.  You should be
able to do a (partial) preprocessing step on the "development" system,
and another (partial) preprocessing step on the "destination" system.
This will insure maximum portability and also maximum obfuscation.

// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request