Date: Tue, 19 Dec 1995 10:38:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@rocky.sri.MT.net, questions@FreeBSD.ORG Subject: Re: undump program Message-ID: <199512191738.KAA14704@phaeton.artisoft.com> In-Reply-To: <199512190401.VAA25491@rocky.sri.MT.net> from "Nate Williams" at Dec 18, 95 09:01:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512191738.KAA14704>