Conference noted::hackers_v1

Try doing a SYS$FORCEX(pid,prcnam,status) to the process.  That will call
SYS$EXIT in user mode in that process' context.  That will force the image
to exit and return control to DCL (Why isn't this a DCL command? EXIT/ID=pid)

If the process doesn't strange things with exit handlers, this might not
work.

Hope this helps
mad matt

	I'm not quite sure how DCL processes ^Y, but it probably uses
a supervisor mode out-of-band AST.   If this is the case, you can
queue a supervisor mode AST for process from kernel mode.  If you want
to do it non-privileged, make the routine into a user-written system
service (with some kind of security, of course).

	If DCL uses some other mechanism, you could probably fake that
from kernel mode too.

	KC

	I have a program (not created by me) which can force any character
(including control characters) to another process. It does this by writing
to the terminal's type-ahead buffer (just like the RSTS "UT FORCE" command,
I think).

	This works fine on VMS V3 but not any more. I imagine the memory
address of the type-ahead buffers has changed. Can anyone enlighten me ?


		Matthew Clarke (temporarily in Mass., normally in Australia)

Re: .3

When you get this program working please submit it to the toolshed.

Steve

I have a program to do this - but I consider it a SEVERE security risk.
It actually 'slaves' your terminal to the other one; you see what they see,
and what you type looks like they typed it. Very useful for troubleshooting
problems (i.e. the loose nut at the keyboard).

HOWEVER... as I said, I'm reluctant to make it public. Comments?
	-Rick

I used to have one of those programs when I worked on a RSTS system.  My
experience with them is that they can be quite useful in the right hands.

However in the hands of a paranoid system manager, etc they can be extremely
dangerous.

I finally took the version off our system because of that problem.

Steve

Well, you asked for comments...

It seems like a large amount of work went into this hack.  Rather than risk
losing it (when you quit DEC to go seek sunken treasure in the Bahamas),
could you submit it to the toolshed, as a repository, with the STC librarian
controlling access to it?

re .5

Yes, by all means, control access to it, and give it out only to known, trusted
individuals.  

Dave C.

P.S.  Can I have a copy for use in my job as a paranoid system manager? :-)

Hmm... hadn't thought of making the Toolshed Librarian the 'controller'.
Frankly, I'm nervous about taking the responsibility.
It was originally done as a poor-man's-LAT sort of thing; I have a uVAX with
a DZV11; it made me able to 'connect' to a port, start something off, and
go do something else. Now that I have a lat line, it's hardly used.

Anyway... were you serious about the Toolshed?
	-Rick

I'm not impressed by the concept, though I'm sure that getting VMS to
jump through the hoop was probably monumental.  Tops-20 straight off
the DUMPER tape lets any user advise any other consenting user's session.
WHEELed user can advise anyone without their consent.  However,
the victim receives a message that they are being advised.

So why not just make your hack type the message out to prevent
misuse, and submit the binaries to the toolshed.  Don't give them
the sources unless they agree not to distribute them without
someone's permission (your's, KO's, . . .).
				/AHM
P. S.  You might even place a string near the code to type out
the message that gives a short excerpt from the Personnel Policies
and Procedures manual which could be use to explain how hacking
someone's session maliciously by removing the message could result
in dismissal.  There are probably several sections to choose from.

 Our site has been working on a system called OZ (for "Wizard of...") that
does all the remote-local terminal controlling without being a major security
risk.  OZ is designed to help create prototypes, since a developer at one
terminal can watch how a subject at another terminal uses the system.  The
developer can intervene at any time to act as the CPU or the subject.  The
program also reords all "dialogue" for analysis later.

 The program is still under development, but you might contact SPRITE::OSMAN
for more information.

There's a company - the name of which escapes me - that sells a series of
programs to do this kind of thing.  They advertise the ability to watch what
someone is doing - including recording it to a file - without their knowledge.
I've seen their ads in the VAX Professional; one good marketing ploy they came
up with was to offer V3 versions of the programs for free at just about the
time V4 hit the streets - "Try it for free; buy when you upgrade".

To return to the original issue:  Yes, DCL intercepts CTRL/Y's by having a
CTRL/Y AST set at supervisor mode.  I don't know off-hand if it's an out-of-
band AST enable, or a special "CTRL/Y" enable.  In principle, you could find
the UCB for the terminal the process was talking to, then chain through the
AST enables to find DCL's and use a special KAST to fake delivery.  This would
probably end up being as complex as the code to actually force a CTRL/Y into
the terminal's input stream, especially since you don't care if you clobber
some real input characters.

If what you want is just to force the current image to exit, $FORCEX is the
way to go.  (For one thing, it only requires GROUP or WORLD to get at other
process in your group/any other process, and no privilige to get at your own
processes; the other hacks need CMKRNL.)

Below is a small program I pulled off the INFO-VAX mailing list at one point
that defines a FORCEX DCL command.
							-- Jerry

FORCEX.HLP:

1 FORCEX
 Queues a user-mode AST to force image exit for a specified process.

 Format:

      FORCEX [process-name]
2 Parameters
 process-name

  Specifies the 1- to 15-alphanumeric-character-string name of  the
  process  for  which  exit is to be forced.  The specified process
  must have the same group number in its user  identification  code
  (UIC) as the current process.

  If you specify the /IDENTIFICATION  qualifier,  the  process-name
  parameter  is ignored.  If you omit both the process-name and the
  /IDENTIFICATION qualifier, the FORCEX command forces  image  exit
  for the current (that is, the issuing) process.
2 Qualifiers
/CODE

   /CODE=status-code

 Defines  a numeric value for the exit status of the image.  If you
 omit the /CODE qualifier, the value of SS$_OPRABORT is used.
/IDENTIFICATION

   /IDENTIFICATION=process-id

 Specifies the process identification number the  system  assigned
 to the process when the process was created.

 When you specify the process identification, you can omit leading
 zeros.

 If you specify the /IDENTIFICATION  qualifier,  the  process-name
 parameter is ignored.  The GROUP or WORLD privileges are required
 to control other processes on the system.


FORCEX.MAR:

	.title	forcex	hypothetical DCL command

	$climsgdef
	$dscdef
	$ssdef
	$stsdef

	.default	displacement,word

	.psect	forcex,nowrt,exe,shr,pic,long

	.entry	forcex,^m<r2>

	pushaq	nproc
	calls	#1,g^cli$present
	blbc	r0,2$
	pushaq	vproc
	pushaq	nproc
	calls	#2,g^cli$get_value
	blbc	r0,6$
	movaq	vproc,aproc

2$:	pushaq	niden
	calls	#1,g^cli$present
	blbc	r0,8$
	pushaq	viden
	pushaq	niden
	calls	#2,g^cli$get_value
	blbc	r0,6$
	pushal	iden
	pushl	viden+dsc$a_pointer
	movzwl	viden+dsc$w_length,-(sp)
	calls	#3,g^lib$cvt_htb
	blbs	r0,7$
	movl	#cli$_ivchar!sts$k_error,r0
6$:	ret
7$:	pushaq	viden
	calls	#1,g^lib$sfree1_dd
	blbc	r0,6$
	moval	iden,aiden

8$:	pushaq	ncode
	calls	#1,g^cli$present
	blbc	r0,20$
	pushaq	vcode
	pushaq	ncode
	calls	#2,g^cli$get_value
	blbc	r0,21$
	movaw	g^lib$cvt_dtb,r2
	movq	vcode,r0
	movzwl	r0,r0
	beql	20$
	cmpb	(r1),#^a/%/
	bneq	18$
	subl2	#2,r0
	bleq	22$
	cmpw	(r1)+,#^a/%D/
	beql	18$
	movaw	g^lib$cvt_otb,r2
	cmpb	b^-1(r1),#^a/O/
	beql	18$
	movaw	g^lib$cvt_htb,r2
	cmpb	b^-1(r1),#^a/X/
	bneq	22$
18$:	pushal	code
	movq	r0,-(sp)
	calls	#3,(r2)
	blbc	r0,24$
	pushaq	vcode
	calls	#1,g^lib$sfree1_dd
	blbc	r0,21$

20$:	callg	args,@#sys$forcex
21$:	ret
22$:	movl	#cli$_number!sts$k_error,r0
	ret
24$:	movl	#cli$_ivchar!sts$k_error,r0
	ret

	.psect	n,nowrt,noexe,noshr,nopic,long
nproc::	.ascid	/P1/
	.align	long
niden::	.ascid	/IDENTIFICATION/
	.align	long
ncode::	.ascid	/CODE/

	.psect	v,wrt,noexe,noshr,pic,long
vproc::	.long	<dsc$k_dtype_t@16>!<dsc$k_class_d@24>,0
viden::	.long	<dsc$k_dtype_t@16>!<dsc$k_class_d@24>,0
vcode::	.long	<dsc$k_dtype_t@16>!<dsc$k_class_d@24>,0
iden::	.blkl	1

args::	.long	3
aiden::	.long	0
aproc::	.long	0
code::	.long	ss$_oprabort

	.end	forcex

FORCEX.CLD:

Define Verb ForcEx
	Parameter P1,Prompt="Process",Value(Type=$Process)
	Qualifier Identification,Value(Required)
	Qualifier Code,Value(Required),NonNegatable

re: .12

The company is Clyde Digital.

	- Jerry

You can "eavesdrop" on another terminal with the PCDRIVER
(pseudo-terminal driver) that will ship with DTM.

Will it work on a workstation? The current PCDRIVER will crash the system
with a chage mode from the interrupt stack if you even breath hard on a WT.

	Jon

Latest version should work on a WT. (10-Oct-1985)

Where can I get it? It was not in the toolshed as of yesterday.

	Jon

This driver will ship with DTM.  Get a DTM field test kit, or
more simply, copy PCDRIVER.EXE from SYS$SYSTEM: on CLT::.

Is there any documentation around for PCDRIVER?  Internal-only?  Public (i.e.,
as part of DTM)?

BTW, what IS DTM anyway?
							-- Jerry

DTM stands for DEC Test Manager.  This had been known internally as TCS,
Test Control System.  DTM forms part of Digital's strategy of developing
and selling software development tools for all phases of the software
life-cycle.