Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!psuvax1!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: russell@bks.co.nz (Russell Page)
Newsgroups: comp.virus
Subject: Pipelines in DOS (Was Is this a virus? Help!) (PC)
Message-ID: <0001.9011271730.AA07735@ubu.cert.sei.cmu.edu>
Date: 22 Nov 90 23:44:30 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 41
Approved: krvw@sei.cmu.edu

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.