Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!necntc!adelie!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.sources.wanted,comp.unix.questions
Subject: Re: tty watcher
Message-ID: <139@minya.UUCP>
Date: Mon, 14-Sep-87 22:03:47 EDT
Article-I.D.: minya.139
Posted: Mon Sep 14 22:03:47 1987
Date-Received: Wed, 16-Sep-87 03:27:14 EDT
Organization: home
Lines: 54
Summary: It's easy....
Xref: mnetor comp.sources.wanted:2254 comp.unix.questions:4075

> 2) is the major point here; there are no tty watchers that consist solely of a
> user-mode program that drops on top of a non-hacked UNIX system.

Well, I've done it, and in such a way that it's obviously portable to just
about any Unix system.

It does take more than just a program.  It also takes two unused ports and
a cross-over (null-modem) cable between them.

What you do is write a little program (I call mine "conn") that takes the
names of two ports, opens them, and puts both into raw mode.  The program
then forks into two processes, each of which starts copying data as fast
as it can in one direction.

Before doing this, however, the original process has opened an audit-trail
file somewhere, and if you give it the right option, it writes messages to
the audit trail that includes a transcript of all the traffic, perhaps in
the form of a hex dump of each "packet", a timestamp, etc.  You can be quite
creative here if you wish.

The picture (such as can be done with ASCII graphics) is:

  +---------+               +-------+
  | program +<------------->| port1 |<-+
  +---------+               +-------+  |
                                       | (null-modem cable)
                            +-------+  |
     +--------------------->| port2 |<-+
     |                      +-------+
	 V
   +----+     +---------------+
   +conn+====>| Audit file(s) |
   +----+     +---------------+
	 ^
     |                      +-------+    +------+
     +--------------------->| port3 |<-->| USER |
                            +-------+    +------+

This technique worked just fine a while back when I decided I wanted to
study the uucp protocol.  It was real easy to get a complete transcript
of a uucico session, though figuring out what it all meant wasn't quite
so easy.

It takes a pretty sophisticated user to figure out that he's actually on
port3; everything indicates he's on port1.  The only real giveaway might
be the somewhat slower response due to the pipelining and auditing.


This technique oughta work pretty much anywhere you have a couple of free
ports.  Writing conn is left as an exercise for the reader.  (If you give
up, maybe I'll email you a copy of my solution.)

-- 
	John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)