root@ozdaltx.UUCP (08/30/87)
I know this is probably simple, but for the life of me I can't figure out how to do it. I need to be able to monitor, at will, a port or tty and be able to see what the person using the tty is seeing and what they are responding. I'm running SCO XENIX V5. You'd think this would be simple to do... but... Any ideas? -- ************************************************ * Scotty * Adapt * * ihnp4!killer!ozdaltx!sysop * Enjoy * * "Ad Venerem Securiorem" * Survive *
root@ozdaltx.UUCP (root) (09/09/87)
A while back I'd asked if anyone has an effective tty watcher or "spy" program, or if they had suggestion as to how such a thing could be accomplished. The most common reply was; use 'cat < /dev/ttyxx', good idea, but the I/O gets confused and can't quite figure out where things are supposed to go. Several versions of *NIX must have had a "hook" or stub in the kernal as more than one person made mention of a 'spy' program that effectivally let you tune in on some one elses tty. To make a long story short, appearently it just can't be done. Looks like MS-DOS wins this round. Thanks for all the reply and suggestions. -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
dyer@spdcc.COM (Steve Dyer) (09/10/87)
It seems to me that you might be able to hack something up with a
new line discipline which paralleled the normal tty line discipline
with the exception that it replaced the l_input routine with one which,
before calling the standard l_input routine, enqueued its characters
on a private clist of a special device which could be read by the
'spy' program.
Another alternative is to take the public domain pty driver posted recently
and have your gettys running on the pty slaves instead of the serial lines
directly. You would then have a 'telnetd'-like process reading and writing
to the pty controller and the serial device. It could perform the logging
at that point in user mode.
None of these solutions are "free" without requiring some kernel work.
However, the pty solution is pretty simple to implement.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyerjosh@hi.UUCP (Josh Siegel) (09/10/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. Must have missed this posting... sorry. > >The most common reply was; use 'cat < /dev/ttyxx', good >idea, but the I/O gets confused and can't quite figure out >where things are supposed to go. Very true. Not a good idea. There are lots of better ways of doing this. > >Several versions of *NIX must have had a "hook" or stub in >the kernal as more than one person made mention of a 'spy' >program that effectivally let you tune in on some one elses >tty. It does exist in many forms... 1) Stealbuf - This code reads the input buffers of the user being watched and prints out everything he/she is typing. It doesn't work if they are in raw mode. I don't know who wrote it. 2) Spy - Kinda like a running ps. Fast and clean. Lets you see what commands a user is running. I don't know who wrote it. 3) eye - This is the gem of the bunch. Written for a Sun computer, it watches TCP/IP connections on the ethernet. This lets you see exactly what a user is doing... both input and output. Also, it lets you keep a transcript of the conversation. Triggers exist on it to start watching a connection when the user types "su\n" and when a connection starts up. Very useful for breaking into computer systems and watching what others are doing at any given time. I wrote this one.... > >To make a long story short, appearently it just can't be >done. Looks like MS-DOS wins this round. I am not sure what it won. Sorry... looks like Sun won again ;-) > >============================================================ >| Scotty | Adapt - Enjoy - Survive | >| ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | >============================================================ Before I get mail asking me for copies of the software, let me state my policy. I will not pass out stealbuf or eye to anybody. Stealbuf doesn't work on BSD43 and eye only works on Suns. The current version of eye is nothing but a machine cracker. I don't see a reason to pass this around. In a few weeks, I plan on posting a new version of eye that is a ethernet debugger. I never plan on posting my cracking version. -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers
kathy@bakerst.UUCP (Kathy Vincent) (09/11/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. > >To make a long story short, appearently it just can't be >done [ in *NIX ]. Looks like MS-DOS wins this round. Rather depends what your idea of "winning" is, doesn't it? I'd be just as glad to know you couldn't spy on what I was doing - and, no, I don't have anything to hide. Ergo, in my opinion, *NIX would win the round. Kathy Vincent ------> Home: {ihnp4|mtune|codas|ptsfa}!bakerst!kathy ------> AT&T: {ihnp4|mtune|burl}!wrcola!kathy
lamont@hpcupt1.HP.COM (LaMont Jones) (09/11/87)
/ comp.sources.wanted / root@ozdaltx.UUCP (root) / 7:15 am Sep 9, 1987 / > To make a long story short, appearently it just can't be > done. ... Now wait a minute! It's a computer. Of course it can be done. The question is how much you want to hack the poor thing up to do what you what it to do. (And there is always the hardware solution :-) LaMont Jones {hplabs,ihnp4,...}!hpda!lamont
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
<A while back I'd asked if anyone has an effective tty
<watcher or "spy" program, or if they had suggestion as to
<how such a thing could be accomplished.
Must have missed it; or ignored it assuming that somone more
knowledgeable than I would answer.
<Several versions of *NIX must have had a "hook" or stub in
<the kernal as more than one person made mention of a 'spy'
<program that effectivally let you tune in on some one elses
<tty.
Don't recall having seen them, but can easily believe it. But there's
a better way.
<To make a long story short, appearently it just can't be
<done.
It can be done. The trick is to wade through the kernel data
structures in /dev/kmem until you find where incoming characters from
that tty are being stored, and then watch that space. A program to do
this on 4BSD made the rounds about 3 years ago, causing a flurry
chmod 540 /dev/*mem* /vmunix
chgrp kmem /dev/*mem* /vmunix /bin/ps <and similar things>
chmod 2711 /bin/ps <and similar things>
commands to be issued
<Looks like MS-DOS wins this round.
When did MS-DOS start supporting multiple users so that such a thing
would make sense?
<mike
--
When logic and proportion have fallen soggy dead, Mike Meyer
And the white knight is talking backwards, mwm@berkeley.edu
And the red queen's on her head, ucbvax!mwm
Remember what the dormouse said. mwm@ucbjade.BITNETalvitar@madhat.UUCP (Phil Harbison) (09/12/87)
In article <249@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > It seems to me that you might be able to hack something up with a > new line discipline which paralleled the normal tty line discipline > with the exception that it replaced the l_input routine with one which, > before calling the standard l_input routine, enqueued its characters > on a private clist of a special device... This is similar to my implementation of a journal feature on a piece of UNIX-based test equipment at Boeing. The Air Force wanted a journal of every keystroke (before input processing) so they could study human factors and write better user interfaces. Each character was put in the raw queue and a copy was also placed in a clist owned by the journal driver if /dev/journal was open. This would be a trivial hack to almost any tty driver. -- Live: Phil Harbison USPS: 3409 Grassfort Drive, Huntsville, AL 35805-5421 Uucp: {clyde,uunet}!madhat!alvitar Bell: 205-881-4317, 205-837-7610x546
jhc@mtune.ATT.COM (Jonathan Clark) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: :A while back I'd asked if anyone has an effective tty :watcher or "spy" program, or if they had suggestion as to :how such a thing could be accomplished. This sounds lie a 3-line stream module to me. What's the problem? In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: : 3) eye - : This is the gem of the bunch. Written for a Sun : computer, it watches TCP/IP connections on the : ethernet. This lets you see exactly what a user : is doing... both input and output. Also, it : :I am not sure what it won. Sorry... looks like Sun won again ;-) You mean that Sun doesn't offer end-to-end encryption? What a piece of junk :-) -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy@sun.UUCP (09/12/87)
> :A while back I'd asked if anyone has an effective tty > :watcher or "spy" program, or if they had suggestion as to > :how such a thing could be accomplished. > > This sounds lie a 3-line stream module to me. What's the problem? 1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and S5R3.1's standard tty drivers aren't streams-based. 2) Streams modules live in the kernel, and not everybody can stuff an arbitrary streams module into their kernel. The tty watcher in question requires *some* kernel hacking (unless the vendor of your system has already done that hacking) even with a streams tty. 3) There is no such thing as a non-trivial 3-line streams module. :-) 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. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
tim@amdcad.AMD.COM (Tim Olson) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: +----- | > :A while back I'd asked if anyone has an effective tty | > :watcher or "spy" program, or if they had suggestion as to | > :how such a thing could be accomplished. | > | 2) Streams modules live in the kernel, and not everybody can stuff an | arbitrary streams module into their kernel. The tty watcher in question | requires *some* kernel hacking (unless the vendor of your system has already | done that hacking) even with a streams tty. +----- What about a new getty which, instead of exec'ing the user's shell, forks the shell with a pseudo-tty as a terminal, then "watches" the real terminal, sending the characters received & sent both to the pseudo-tty as well as to the snooper? That wouldn't involve hacking the kernal at all.
guy@sun.uucp (Guy Harris) (09/14/87)
> What about a new getty which, instead of exec'ing the user's shell, > forks the shell with a pseudo-tty as a terminal, then "watches" the real > terminal, sending the characters received & sent both to the pseudo-tty > as well as to the snooper? That wouldn't involve hacking the kernal at > all. Unless, of course, your kernel lacks pseudo-ttys.... This also requires you to hack "getty", although you could have the pseudo-"getty" set up the pseudo-tty and run the real "getty" immediately, thus obviating the need to duplicate all of "getty"'s functionality (painful to do without source). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jhc@mtune.ATT.COM (Jonathan Clark) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: >I wrote: >> This sounds like a 3-line stream module to me. What's the problem? > >1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and >S5R3.1's standard tty drivers aren't streams-based. Well, I *was* being more than slightly facetious when I wrote that comment, although I think you could actually do the guts of it in close to three lines: /* output */ /* input */ mblk_t *dup; mblk_t *dup; dup = copymsg(mp); dup = copymsg(mp); putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); putnext(down_to_device,mp); putnext(up_from_device,mp); [ I'm doing this from memory so the declarations &c may be wrong. ] A small amount of footling around to set this up would be needed, and the surrounding stream module code should be added, but it should be that simple. Unfortunately Guy is absolutely correct about the SVR3 and 3.1 tty drivers not being streams-based and hence this approach not being terribly useful. Perhaps some day this will come to pass (or we'll convert to v8). You could even stick this either above or below the line discipline module, depending on whether you wanted raw characters as typed or what gets passed up the the user process. >2) Streams modules live in the kernel, and not everybody can stuff an >arbitrary streams module into their kernel. True, alas, although one can in all the SVR3-based systems. Errr, can't you? >3) There is no such thing as a non-trivial 3-line streams module. :-) Right again! This one *is* trivial! >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. Yup. This is the type of problem which *ought* to be simple but which isn't in a non-streams environment. Streams was created to be able to handle this sort of thing - following the example above, it succeeds. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
jc@minya.UUCP (John Chambers) (09/15/87)
> 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)
brianc@cognos.uucp (Brian Campbell) (09/15/87)
In article <5070@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: ! In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: ! <A while back I'd asked if anyone has an effective tty ! <watcher or "spy" program, or if they had suggestion as to ! <how such a thing could be accomplished. ! ... ! <Looks like MS-DOS wins this round. ! ! When did MS-DOS start supporting multiple users so that such a thing ! would make sense? Well, although the posted message didn't specifically mention it, the original question related to watching what callers were doing on a BBS. [The reply-to field (sysop) hinted at this]. Since there are a number of BBS's running under MS-DOS, and it is quite simple to trap all incoming and outgoing characters, I guess MS-DOS just might have won this round. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: POB 9707, 3755 Riverside Dr., Ottawa, ON, K1G 3Z4 (613) 738-1440 fido: sysop@163/8
mikel@flmis06.ATT.COM (Mikel Manitius) (09/17/87)
>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. I saw this done on 4.1bsd once, I even had the code that did it. It was a simple program that figured out where the clist struct was for that user's tty driver, and scanned it repeatidly in /dev/kmem for changes. It would output his input line by line. This sort of thing should be feasable on most Unix systems... It's just a pain figuring out where to find his clist, especially given just a tty name. -- Mikel Manitius @ AT&T Network Operations mikel@codas.att.com.uucp | attmail!mikel
terryl@tekcrl.TEK.COM (09/18/87)
In article <198@flmis06.ATT.COM> mikel@flmis06.ATT.COM (Mikel Manitius) writes: >>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. > >I saw this done on 4.1bsd once, I even had the code that did it. It was >a simple program that figured out where the clist struct was for that user's >tty driver, and scanned it repeatidly in /dev/kmem for changes. It would >output his input line by line. > >This sort of thing should be feasable on most Unix systems... It's just >a pain figuring out where to find his clist, especially given just a >tty name. Actually, if you have a tty name, it is quite trivial to figure out where the C-list structure lives in kernel memory (assuming you have at least read access to /dev/kmem). ****WARNING, WILL ROBINSON!!! SPOILER AHEAD!!!**** It goes like this: first, do a stat(2) on said tty name. Inside of the stat structure returned is a field giving the major/minor number of the tty. Take the major number and use this to index into the cdevsw[] structure. One of the fields in the cdevsw[] structure is a pointer to the FIRST tty structure for the specific RS-232 device. Now use the minor number gotten from the stat(2) call to index into the tty structure. You now have a pointer to the tty structure for the tty name in question. It is left as an exercise to the student to find the appropriate C-list struc- ture. Terry Laskodi of Tektronix
martin@iris.ucdavis.edu (Bruce K. Martin Jr.) (09/18/87)
In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: >In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >>A while back I'd asked if anyone has an effective tty >>watcher or "spy" program, or if they had suggestion as to >>how such a thing could be accomplished. > >Very true. Not a good idea. There are lots of better ways >of doing this. > True! >It does exist in many forms... > > 1) Stealbuf - > This code reads the input buffers of > the user being watched and prints out > everything he/she is typing. It doesn't > work if they are in raw mode. > > I don't know who wrote it. > ...stuff deleted... >Before I get mail asking me for copies of the software, let me >state my policy. I will not pass out stealbuf or eye to anybody. >Stealbuf doesn't work on BSD43 and eye only works on Suns. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >current version of eye is nothing but a machine cracker. I don't >see a reason to pass this around. > >-- >Josh Siegel (siegel@hc.dspo.gov) > Friends don't let Friends eat Cherry Zingers Not quite true. We have successfully modified our home-grown version of stealbuf to work on BSD4.3 (of course, I'm assuming that you can read /dev/kmem) ..bruce Bruce K. Martin Jr. UC. Davis Div of Computer Science martin@iris.ucdavis.edu --or-- {ucbvax | lll-crg}!ucdavis!iris!martin
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <1431@cognos.UUCP>, brianc@cognos.uucp (Brian Campbell) writes: > ! <...an effective tty watcher or "spy" program, > ! <Looks like MS-DOS wins this round. > ! When did MS-DOS start supporting multiple users so that such a thing > ! would make sense? > Well, although the posted message didn't specifically mention it, the > original question related to watching what callers were doing on a BBS. > I guess MS-DOS just might have won this round. You can, of course, do the same thing on UNIX (watch what people are doing on a BBS), exactly the same way (have the BBS program echo stuff). I've seen two systems that do it (one of which not only traps the characters, but talks to called processes via pipes so you can have other programs do mail, etc, and have them echoed too). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.