From: Terry Lambert <terry@lambert.org>
Message-Id: <199512191738.KAA14704@phaeton.artisoft.com>
Subject: Re: undump program
To: nate@rocky.sri.MT.net (Nate Williams)
Date: Tue, 19 Dec 1995 10:38:55 -0700 (MST)
Cc: terry@lambert.org, nate@rocky.sri.MT.net, questions@FreeBSD.ORG
In-Reply-To: <199512190401.VAA25491@rocky.sri.MT.net> from "Nate Williams" at Dec 18, 95 09:01:11 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@FreeBSD.ORG
Precedence: bulk

> > Wrong that "there is no advantage" or wrong that "the resulting 'binary'
> > will run at the same speed?
> 
> The resulting binary will run faster than a perl + script.  The
> resulting binary need never run through the syntax checker and
> optimizer.

It will start up faster.  It will not execute faster.  It is the same
core image... there is no difference between them at the point that
the dump() takes place.  That is the whole point, right?

> > If the second case, then you should arrange to dump the perl
> > interpreter and the token image 10 or more times to get even more
> > speed out of it.  8-).
> 
> Umm, once the syntax checking and optimizer is done, you can't optimize
> it more.  Even with the implicit smiley it makes abosultely no sense.
> Does that mean we should take the intermediate pass in gcc and re-run
> the results back through the optimizer 10 times to see if they run
> faster?

No, it means that your statement is tantamount to the claims of a 50%
size reduction for *any* file using a recoverable compression algorithm.

"Any file" includes one that has already been run through the compressor.


Basically, if you can establish state such that it exists in the core
image, you can establish the same state in core without generating an
image.  That is, all that is being talked about is storage format and
load time (including time to get back to the desired state).

> > > If I gave you an core/un-dumped perl program, you'd have almost as much
> > > (possibly more) difficulty in trying to re-create it as you would trying
> > > to re-create a C program from it's core image.
> > 
> > If I had sources to perl to determine the token values and memory
> > management, I could get the information out.
> 
> In the same manner as you could re-create the 'C' code given the
> original compiler sources and the resulting executable.

Yes.  There used to be an "uncc" program for the Berkeley Portable C
compiler (not the GCC stuff, the one with the register pop order bug).

The code wasn't terribly readable, but using cscope or some other
symbolic editor, it'd be pretty easy to rename symbols until it was
readable, and then comment that.

I believe the Internet Worm was decompiled this way.

The point is, it'd probably be cheaper than recreating your developement
effort (and more fun, too), so you aren't achieving anything but a small
level of obfuscation.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.