From: skyhawk@cpac.washington.edu
Date: Wed, 23 Jun 93 11:31:39 PDT
To: cypherpunks@toad.com
Subject: Re: weak stenography and hiding readdat.exe
Message-ID: <9306231831.AA04870@bailey.cpac.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain


The simplest effective way I know of to hide an executable (such as
readdat.exe) is to have it masquerade as another program, preferably one that
is complex enough to justify its size.  (You couldn't hide PGP in cat, but you
could hide it in Mathematica.)  You'd want the original program to be something
you compile yourself, like some large X program, or gcc, or emacs.  (You can
hide *anything* in emacs.  In fact, you can make pgp a hidden *primitive* in
emacs.  Hmmmmmm...  Or Perl.  Hmmmmmmm.....)  That way you don't have a file
that differs noticably from your OS release (they might check sizes and
checksums), and you don't want to bother with patching a binary anyway.

Then you've got the problem of invoking the alter ego of your program.
Methods I've used in the past include new command-line flags, time of day,
multiple "normal" invocations with slightly strange flags (this would
save simple state information in /tmp), and special environment variables.

To avoid leaving a trail to the hidden goodies, it's important to wipe any
special arguments from argv[] (or your language's equivalent), insure that
any special environment variables look completely innocent since ps(1) will
display them to anyone who asks, (both assuming you're on a multiuser Unix
box), and to not leave an intact .history file where some bright
anti-subversive in the SS lab could see it on your confiscated hard drive, or
your university's confiscated backup tapes.  To make cleaning up simpler, you
could hack your shell's history mechanism to not put incriminating strings
into your .history.  Leaving a false trail is better than simply removing the
real trail, after all.  (You wouldn't really need to do the same thing for
your accounting log, if your machine keeps it at all, since it would only
have the name of the executable.  It would be important, though, that your
program's public function be something that you could credibly be using 20
times a day.  Compiler, linker, editor, finger, archie...)

I've never had to worry about someone running a virus-style checker for
naughty code, since mine's all been home-grown, but if there is a particular
routine (say, pgp) that's hidden all over, Nick Szabo's excellent idea for
using a virus-type mutation engine would be essential.

For distribution of something like this, all we'd really need to do is co-opt
some project that is distributing code on the net already, preferably something
big.  Then we could set up an ftp site for the binaries, for those people who
don't want to bother with compiling the program.  Wink wink, nudge nudge.  (And
many projects do this anyway.)  The development of the "cover" program could go
on in parallel, thus justifying continuous releases of the binaries, and the
source is available (sort of) thus making the ruse that much more effective.

Scott

--
Scott Northrop          <skyhawk@cpac.washington.edu>            (206)784-2083
ObVirus:   The demand for obedience is inherently evil.
ObVirus2:  As a juror in a Trial by Jury, you have the right, power and duty
           to acquit the defendant if you judge the law itself to be unjust.