home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.os.os2.apps:5948 comp.security.misc:1193
- Newsgroups: comp.os.os2.apps,comp.security.misc
- Path: sparky!uunet!sun-barr!cs.utexas.edu!rice!news.rice.edu!dens
- From: dens@sawwhet.owlnet.rice.edu (Dennis Allen Schmitz)
- Subject: Re: Self-Extracting Binaries dangerous? (Was: REXXShip: Self-Extracting UUEncode!)
- In-Reply-To: sip1@ellis.uchicago.edu's message of 6 Sep 92 17:56:45 GMT
- Message-ID: <DENS.92Sep8074930@sawwhet.owlnet.rice.edu>
- Sender: news@rice.edu (News)
- Organization: Rice University, Houston, Texas
- References: <1992Sep6.025645.5101@midway.uchicago.edu> <18cf8rINNmpl@agate.berkeley.edu>
- <dank.715798089@blacks> <1992Sep6.175645.24543@midway.uchicago.edu>
- Date: Tue, 8 Sep 1992 13:49:30 GMT
- Lines: 20
-
- In article <1992Sep6.175645.24543@midway.uchicago.edu> sip1@ellis.uchicago.edu (Timothy F. Sipples) writes:
-
- Incidently, a much more efficient version of REXXShip is awaiting just
- a few finishing touches. It uses a modified XXEncoding type scheme so
- that the binary file only grows by about four thirds (plus overhead)
- instead of double after encoding.
-
- Also, the REXXShip format does not preclude the use of a standalone
- decoder. Time permitting I'll be writing a standalone decoder (for
- reasons of speed), so people will have flexibility.
-
- It seems to me that since you are using the xxencode scheme, you could
- make it compatible enough that the file would actually BE an xxencoded
- file with stuff at the beginning and the end. This way could feed it
- to regular xxdecode program (one presumably smart enough to strip
- headers and trailers.
-
- Later,
- den
-
-