Re: weak stenography and hiding readdat.exe

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.

Scott Northrop <skyhawk@cpac.washington.edu> writes: < 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. these are interesting ideas. but it seems to me you can't beat just using a pre-existing popular application for steganography. in other words, choose an algorithm which doesn't require you to create a new program to do the job.
participants (2)
-
Chuck Lever
-
skyhawk@cpac.washington.edu