russell@bks.co.nz (Russell Page) (11/23/90)
Robert E. Mee sees strange files when he pipes a MS-DOS directory
listing through more.
> dir | more
There are essentially two ways to implement pipelines. UNIX creates
two concurrent processes. The kernel (at least I think it is the
kernel) keeps the two processes synchronized. One process pours stuff
into the pipe until it fills up, and then goes to sleep while the
other empties the pipe. The other then sleeps while the first refills
the pipe.
MS-DOS doesn't support concurrent processes. There are no kernel
facilities for managing interprocess communications. Pipes are
implemented directly by command.com.
The mechanism is something like this.
1. Command.com creates a temporary file and attaches it's standard
output to it.
2. The first program then runs. It inherits it's standard files
(including it's standard output) from command.com. So it's output
gets dumped into the temporary file.
3. When the first process (dir in your case) exits, command.com attaches
it's standard input to the temporary file, and starts the
second process (more). When this process finishes, command.com
deletes the temporary file.
Thus at the time dir runs, the temporary file has been created, but
still has nothing in it. So you see a zero sized file with some weird
system generated name.
The second file is related to it in some weird unspecified way. My
guess is that it contains data that command.com must keep around to
implement all the redirection. It probably saves this in a file rather
than memory. There are a number of good reasons why this is a sensible
way to do it in DOS. The basic one being that memory is unprotected in
this environment, and a child process can do terrible things to memory
owned by it's parent.
The bottom line on your trojan is that you were seeing the files that
DOS created to implement your pipeline.