Conference noted::hackers_v1

Here's a pretty good practical joke.  In a person's LOGIN.COM file,
if the mode is batch, define sys$print to be sys$batch:

	$ IF F$MODE() .EQS. "BATCH" THEN DEFINE SYS$PRINT SYS$BATCH

Thus, when the batch job finishes, the .LOG file will be queued to SYS$BATCH.

Jym,

	that is MEGA-nasty. I was going to do it, but decided not to out

	of the goodness of my heart. Why not just do

	$ Prompt = "$ " + Ctrl_e
	$ Set Prompt="''Prompt'"

	
	More fun is to put two $SUBMIT/NOPRINT LOGIN commands at the start

    	of someone elses LOGIN.COM !! The queue soon fills. On V3 the queue
                                                                  
	manager sometimes shut down in disgust at that sort of thing .....


	Another funny is to define

	$ Ty*pe :== "Read/prompt=""$ "" sys$command dir"

	and so on for other commands in the users login.com file. Then the

	commands all get re-assigned as he uses them !! You can even put

 	DCL error nessage in the prompt for extra fun !!!


Stephen


                                              

	[RE .2]:  I don't understand the point of making "$ ^E" the prompt.
What do you put in the answerback buffer?  My practical joke makes it look as
if the prompt is normal and makes it work normally for most cases.
		<_Jym_>

Well Jym,

	It basically only gets (naughty) people who have put

	username<cr>password<cr> into their answerback buffer !!
                                      

        Any they deserve ANYTHING !!!!

	Otherwise it does nothing.....


Stephen

SHAME ON YOU, THATS MEAN!

 I WANT MORE!

C.J. MILLER co CHUCK MILLER


                             /\
                             ||
                           /----\
                          /__||__\
                            A  A
               
                           / \/ \
                           ||||||
                          /|/||\|\

Back a while ago, we were having process name wars - calling each other
Twits.. this was my response:
$ set nocontrol_y
$ write sys$output "This will teach you to call me a twit!"
$ loop:
$ file_name = f$search("*.*")
$ if file_name .eqs. "" then goto bye
$ write sys$Output "%DELETE-I-DELETED, ''file_name' deleted."
$ goto loop
$ bye:
$ Di*rectory:=="Write sys$output ""%DIRECT-W-NOFILES, no files found"""

What is the "answerback buffer"??  How do you find out what's in it, clear
it, etc??

Joe

P.S.  Chuck...you've got an evil mind!

	The answerback buffer is a memory buffer in a VT100 or VT200 where you
can store some characters.  On a VT100 you go to Set-Up B and type a capital
A (using the SHIFT key on the left), then type your text between two delimiters.
On a VT200 you go into Set-Up and fiddle with the Keyboard menu.
	The answerback buffer is sent as input (i.e., as if you typed the char-
acters in it) when you hit CTRL-BREAK.  It's also sent as input when the term-
inal receives a ^E.
	Folklore is that the VT100 has an undocumented escape sequence to put
characters into the answerback buffer.  A true hacker could go far with this
information.
		<_Jym_>

I would be interested in knowing the undocumented VT100 sequence that causes
the answerback buffer to be loaded.. anyone out there know what it is?

GAS

	If the answerback buffer is stored in the Non-volatile ram
similar to set up params.... you could REALLY do nasty things.....

	The devices used in VT100/200 series are guaranteed to
operate for only so-many WRITE cycles. (In the 100/200 that number
is 10,000 cycles)... so if you really had a problem user, by doing
a looping write to the NVR... eventually the terminal would fail
powerup self test!

	-John

	re-.1

	After writing the note above, I looked thru the 240 and 100
books for a way to invoke set-up from software. Its either not mentioned
or said to be impossible. However, since this is the hacker file, any ideas?

	BTW Im curious for a technical reason too. Im a component engineer
in ABO, and it would be a neat project to loop-store to the NVRs
(an ER1400 in 100-series boxes, and a Xicor 2212 in 200's) to test
their spec'ed write lifetimes...

	John

I've asked a Real Programmer in the TBU to dig up the sequence, if it exists.

His initial impression (without looking at VT1xx microcodes) was that it was
supported on the 102 but not the 100.
				/AHM

	It definitely exists on the PC100s (emulate a 102). Our sen specialist
told me a while ago that you can insert something like "DEL [...]*.*;*" in
someone's answerback buffer then send the trigger to them while they are
logged in. With luck they will punch a <cr> and kablooie - hacked again.
	As to what the invoking sequence is, any ideas? It isn't in the tech
docs,
	Arohanui,
		Mike

	^E is the trigger.  All we need is an escape sequence to insert our
favorite DCL command into the answerback buffer (presumably with a broadcast
message).
	Another way to snatch the terminal from afar will work on VT100-type
terminals that have a printer port with a loopback connector plugged into it.
Broadcasting <ESC>[5i<text><ESC>[4i will send <text> to the printer, but the
loopback connector reroutes things so that input to the printer becomes terminal
input.  Thus, <ESC>[5i^Y^Y<DCL-command><ESC>[4i will cause your favorite DCL
command to execute!
		<_Jym_>

Re .6

Rick,

     I have to one-plus your nastiness contribution.  The definition
for Di*rectory should be 
$ Di*rectory:=="Write sys$output ""%DIRECT-W-NOFILES, no files found""!"

                                                                      ^
The exclamation point preserves the hack even if the user tries a 
particular file spec, like $ DIRE FOO.TXT.

Dave C.

Re: .15
I like it!

 The SETUP sequence was a real problem: several years ago I had to write
a CBI that had to get to the SETUP menu--I never did figure a way to do it.

 However, the DECmate I's used a modified VT100, or else they did have such
a sequence, because SETUP is disabled in that series.  Anyone remember how
that was done?

	    Here's another hacktical joke.  When Victim isn't looking,
	execute this command procedure at their terminal:

		$ set nocontrol=y
		$LOOP:
		$ spawn/nolog
		$ goto LOOP

	Every time Victim logs out, the cheery little "VICTIM logged out
	at . . ." message is displayed, followed by a short pause, and
	the prompt.
	    If you want to get real fancy, and to delay Victim's reali-
	zation that their process is actually a subprocess, you could
	throw in some code before the loop that grabs the parent's
	process name, changes it to something relatively unnoticable,
	and uses that process name when it spawns the subprocesses.
	    You might also want to delete the P1 through P8 symbols.
			<_Jym_>

    How about setting dcl commands to mean 'logout'.
 Put this in someones Login.com
    
    Dir*:== logout
    Type:== logout
    .
    .
    .
    Show:== logout
    
    
    All except Edit so it can be fixed
    
    

    An easier way to fix it is when logging, use the /NOCOMMAND qualifier
    and then fix it.
    
    Mike

    If you want to do something mean to someone, then try doing this
    to someone (I did it accidently to myself):
    
    $ DEFINE/JOB  SYS$SYSROOT DUZ255:[MISSING.], SYS$SPECIFIC, SYS$COMMON
    [Only include SYS$SPECIFIC if your on a cluster]
    
    This will prevent images being recognized as known and as such,
    the images won't have their privileges elevated.  LOGINOUT dies with
    an access violation.  Other strange things start happenning.
    
    Or for even more fun:
    
    $ SET COMMAND/OBJECT=NULL NL:
    $ LINK/SHARE NULL
    $ SET COMMAND/TABLE=NULL
    
    And you have totally wiped your command tables.  Logging out is left
    as an exercise to thew reader (it can be done).
    
    Happy hacking
    mad matt 

        Speaking from experience (done to me a few weeks ago), inserting
    a ^S into a file via EDT or EVE or even using sys$brkthru to send
    it to someone is a real mind bender.

        I was suckered into typing out a file called SEX.PIC which really
    wasn't as interesting as I imagined. It contained a ^S in the
    beginning. The net effect was that I got all messages sent to me
    (PHONE, MAIL, etc), but could do nothing from my terminal! Apparently
    the terminal thought the host told it to wait (XOFF), but the host
    thought the line was ready so I ended up with a half-duplex line
    in effect! Of course if you're on a dial-up and you need to do a
    reset ...

        My motto is COPY, then EDIT, then TYPE!
    
    mike

    [RE .21]:  Do I win a cookie?

		    $ eoj := $loginout
		    $ eoj

		<_Jym_>

    Yes, but you'll have to come to the bay area to collect. :-)
    
    If combine both hacks, the person won't be able logout by invoking
    LOGINOUT (or any other privileged program).

Another fun thing is to define SYS$DISK as a search-list, with the
user's device simply listed twice.  DIRECTORY stut-tut-ers.

    re .22 and getting XOFFed:
    
    If you have a VT100 terminal, hitting set-up twice will clear the
    XOFF. On a VT200, the CLEAR COMM set-up feature will.
    
    	Jon

    
    
    	Try:
    
    	$ SET PROMPT = "Username: "
    
    	And then clear the screen.  A less-accomplished VAX user
    	can become quite annoyed at the results.
    
    
    
    	Joe.
    
    

    [RE .28]:  A devious extension of this was possible on
TOPS-20 with PCL.  The MM mailer let you change its prompt (I
don't know if MS worked the same way), and you could change it
to "@" (the TOPS-20 prompt).  With PCL, you could change the
TOPS-20 prompt to "MM>" (the MM prompt, of course).
    Loads of fun.
    Alas, VMSmail is "too professional" to allow such a feature.
		<_Jym_>

I modified SOS on the -10 in college to have a /PROMPT:char switch.  I
initially set it to ".", the Tops-10 prompt, and idrove people nuts.
When I left a terminal in the editor while I went off to do something,
they would try to log in, and would get expert-level cryptic SOS error
messages.  The fascist system management complained, so I changed it
to "@", the Tops-20 prompt.

I hope it pissed them off even more.
				/AHM

    Another annoying prompt you could use is "<ESC>[H<ESC>[J$ "  which
    clears the screen and prints the normal $ prompt.  Keeps victim
    on his toes as he tries to read the screen before it gets wiped...
    Or, if you are slightly more cruel, use the "reset terminal"
    sequence, or the sequence that sends VT100's into siren mode...
    
    -Madman

    
    $ CTRL_S[0,8] = 19
    $ SET PROMPT="''F$ENVIRONMENT("PROMPT")'''CTRL_S'"

    Will definitely drive you nuts within a couple of commands as
    DCL locks the keyboard as it prompts for a command.

 My favorite odd prompt (put this into Prompt.txt and $set [email protected]):

    
    __Rich	(text follows this line)  
"(0lwwwk
xf.fx
x - x
mqqqj(B"

	And now some favorites from another OS...  I've worked for several
years as a system software support person, and in that capacity one almost
always needs and has full privileges.  And let's face it, occasionally one
strays slightly from the responsibilities inherent in the position and uses
those privileges for one's own amusement.


	On TOPS-10 and TOPS-20 systems it's fairly simple if you are 'wheel'
to write a little program that dumps text into any particular job's input or
output buffer.  These programs are remarkably handy and have a variety of
legitimate uses.  It's a neat way to issue commands at an operator terminal
without having to go into the machine room (from home even!) and one can also
carefully modify the execution of a batch job in mid-stream.  The text doesn't
get echoed on the users terminal yet the commands will be executed, so you can
imagine the possibilities.

	Putting stuff in the output buffers is great fun too.  My particular
favorite is bogus error messages.  Picture if you will the unsophisticated
user puzzling over some of these:

[PROCESSING AUTO DESTRUCT FILE]

a couple of moments later:

[AUTO DESTRUCT FILE COMPLETED]

These are good no matter the poor victim is doing.  If you do a SYSTAT and
find that say, they're in TECO, don't forget to add a CRLF and the right
prompt.

?TECBDA   Buffer deleted accidently

*

They may be at command level -- perhaps they've turned away for a moment
and look back to see:

 ?
?HALT AT EXEC PC 41

Or they're gazing at the screen, comptemplating their next command,
when without warning the system spits out:

?CPU0 IS ON FIRE -- OPERATOR ACTION REQUESTED


	Unlike TOPS-20, which came later, under TOPS-10 you can't really
'spy' on another job (well, you can, but not very easily).  You can learn
how to figure out what someone's doing pretty well by repeated SYSTAT and
TIME commands and the like, or else you may have a continous cursoring
job monitor program.  Once I noticed this new user who was repeatedly
running COOKIE.  Over and over and over again for two or three minutes.
They'd run the program, it'd print out a fortune, and there would be about
a ten second pause while said l-user (uh, that means local user, right?)
read the saying.  Quickly I whipped up a couple of command files -- one to
copy COOKIE to the system area and another to copy a COOKIE-clone that had
nothing but obscene sexual messages.  (Now, I know most of you have never
seen any of those programs... 8^>   )  I executed the latter file and
watched carefully.

	This time the poor sap runs COOKIE and there's a considerably longer
pause... during which I replace the proper image.  They run it, and there's
a long pause, but not quite as long as the last one.  They run it again, and
then again, and the pauses are getting shorter and shorter until they are
now going slightly faster than before.  I know this person is hooked; it's
obvious they're looking for more.  Dare I disappoint them?  It's time to
reel in the catch, though this time I will need to be quicker.  Again I
perform the substition, and again there is a long pause during which I
replace the original image.  Twice was all it took -- they are now running
COOKIE at an almost furious rate, as fast as they can discern there is
nothing shocking in whatever was just printed.  Finally I tire of the game
and I make one final switch, this time using LOGOUT.

    RE .24 -
    
    How about $STOP/ID=0
    
    

    Remember you have nothing in your command tables (no LOGOUT, no STOP,
    no nothing).  So the only way you can logout (or do anything) is by
    forcing a program to run via (a foreign command) which will log you out
    (like LOGINOUT).  But if you find a way to disable even those from
    logging you out then you are in trouble.
    
    BTW, running F11AACP will kill you just as LOGINOUT will.
    
    matt

    
    $ SET TERM/MODEM
    $ SET TERM/NOMODEM
    
    John

The variety of ways to logout brings up this little excersize:

Loop over all the .EXEs in SYS$SYSTEM, and try RUNning each.  Several
will log you off, some will ACCVIO, some say submit SPRs, some give
horrible error messages, but then exit with success.  Interesting.

    I happened to see the /MODEM /NOMODEM thing while I was in MAIL
    so I tried this:
    
    	MAIL> spawn
    	$ set term/modem
    	$ set term/nomodem
    
    I figured that the worst that would happen would be that the subprocess
    would get logged out.
    
    I was quite surprised to discover that the bug is so severe that
    my entire job got logged out !
    
    /Eric

    Doesn't sound like a bug to me.  Sounds like a security feature
    to prevent someone from dialing in and setting his terminal nomodem
    to avoid having the process deleted when he hangs up.
    
    Burns
    

With virtual terminals, you get disconnected instead of logged out.

-piper

    One of mine fav's is to write a very short program that sleeps for
    a number of minutes (random each time, about 10 is good) and then
    broadcasts ($BRKTHRU) to SYS$OUTPUT the escape sequence to go from
    white on black to black on white and then back, then go back to
    sleep.
    
    Take this an do a "$spawn/nolog/nowait/out=nla0:/in=nla0 run program"
    in some unsuspecting user's login.  After they've logged in, the
    terminal will flash (works better on VT100's than VT200's) every
    so often.  Drives 'em nuts.  Terminal will work fine for everyone
    else.
    
100	external long function sys$brdcst
	text$ = chr$(27%)+"[?5h"
	text$ = text$ + chr$(0%) for i%=1% to 50%	! slight delay
	text$ = text$+ chr$(27%)+"[?5l"
	while 0% < 1%
		stat% = sys$brdcst(text$,"sys$output")
		sleep (int(rnd*10)+5)*60
    	next
    

    The command should read:
    
    	$spawn/nolog/nowait/input=nla0: run program
    
    /output=nla0: changes the meaning of SYS$OUTPUT, so the escape sequence
    is written to the null device, and not the terminal, and make sure
    the colon follows nla0 in the input spec (this is so ^Y doesn't
    halt the subprocess also!)
    
    Wim

	What about SPAWN/NOWAIT/NOLOG on its own to confuse a 
	novice user ? The two processes compete with each other
	for input and so each gets every second input line.
	This can be very confusing if a different prompt is not
	specified for the created process. (Try typing DIR twice
	in rapid succession. - The two listings overlap.)

<CFM>

    TOPS-10 used to support a terminal front end called the DC76.
    The DC76 had a keep-alive dialog with the CPU it served, and
    when it detected the main CPU was in trouble, it would say
    
    %DECsystem-10 not running
    
    on your terminal.  Usually TOPS systems ran a display program 
    on a VT100 in the machine room.  Occasionally the operator would
    use that terminal for other needs.  I wrote a program that waited
    until the VT100 exited (i.e., operator hit ^Z or equivalent),
    and output the "%DECsystem-10 not running" to the screen, after
    the "." prompt.  Used sparingly, it was very effective as the
    "crash" message would happen soon as the operator took some
    action, which seems to be more effective than when random-timed.
    
    Things got very confusing when the rest of the system looked just
    fine and dandy -- I even "got" myself once.
    
      John

    Ah yes, SIREN mode.  I'd forgotten about that!
    
    What I'd like to know is what the character sequence is to get it
    started?
    
    Tnx.
    
    Mark (this could be fun :^))

    Siren Mode: (SET TERM/BLAST)
    <esc>[154q
    SET TERM/PIANO:
    <esc>[155q
    I may have these backwards..
    	-Rick

    re .47: I believe you have them correct.
    
    Mike

    The piano mode is only effective with KEY CLICK, ANSI, and AUTO
    REPEAT set in SETUP.
    
    When I inquired about this 'feature' being missing from the VT220
    the engineering types insisted that they knew nothing about its
    existence.  They claim that it HAD to be an accident.
    
    Hard to believe,
    
    Don