Conference noted::hackers_v1

	KO strikes again.

	Actually, that brings to mind a story ...

<BORING STORY ON>

	I worked on a RSTS/E system that supported a bunch of
high school students.  There was a group of kids with privileged
accounts, and a group without.  One way to go from those that
have not to those that have was to break-in to the system.

	One of the novel ways was to turn the brightness of a
Beehive down.  At the time, there was someone logged it
under a privileged account.  The poor guy thought another Beehive
had died, and went home in disgust.

	That, of course, left someone with lots of time, and a
"one number".

	KC

 SET BORING STORY ON/another

 I was director of a computer porject for 6th-graders in Norfolk, Virginia 
back in the early 70's.  At the time we used TTY's and dialup lines to 
the central computer (110 baud, even!).  One bright student found an 
extension on one of the phone lines and plugged a TTY into it.  In a 
few hours, he had a list of passwords for everything, including the 
system manager's account (echo-off doesn't apply to a satellite 
terminal).

 SET BORING STORY OFF

Were I went school there were a bunch of hackers. They delighted in
writing login simulaters and breaking into the system. Its easy if
you have both a key to the data center and a CPU key.

Anyway, all those hackers that were there when I was DO work for
DEC now. KO sometimes gets what he wants.

Alfred

CONCERNING REPLY #1.  WHATS A BEEHIVE???

PAUL,

It's the name of a terminal.

<BORING STORY ON>

    The cutest password stealer I ever saw was a program written for
    TOPS-10 that had two functions:

    	1)  If run on a hardcopy terminal, it would print a relatively
    	    good nude picture.

        2)  If run under a privileged account, it would also copy the
    	    password file (not encrypted in those days) to a prespecified
    	    "innocuous looking" file.

    The name of the program?  NUDE.EXE of course.

    The next step was to cause the operator to "discover" the program
    apparently on his own (I use the word "his" here because the hack
    tended to work better with male operators).  You could usually do
    this by asking him to restore a different file in the same UFD.
    When the operator ran the program under [1,2], he would be satisfied
    that he understood the full functionality of the program, and therefore
    not suspect anything.

    <BORING STORY OFF>

    Q:  Is this what's meant by the term "Trojan horse"?

For what it's worth, you should avoid trojan horses while working for DEC
if you want to continue working for DEC.  It's cause for firing.

Even if the 'trojan horse' is in a hack program, be aware that a large number
of hack programs have made it to customer sites.  "April Fools" pranks should
not need the help of a 'trojan horse', and should not jeopardize the security
or function of a system -- it may be a customer's system.

As long we're reminiscing and showing our age, I thought I'd describe
a Trojan horse I wrote about fifteen years ago.

The very first computer I ever used was a timeshared PDP-8.  I was in
high school, and we had rented a terminal (ASR33) and a leased line
to a PDP-8/I running TSS/8.  There were about 40 other terminals
attached, and I once actually did a SYSTAT that showed 40 jobs logged
in!  The system was *not* blindingly fast.

Anyway, in TSS/8 your filenames were three 12-bit words, containing
6 sixbit characters.  A PPN (project-programmer number, like a UIC)
was one 12-bit word, divided into a 6-bit project number and a 6-bit
programmer number.  (TOPS-10 types will recognize that this is all
a very cut-down verson of TOPS-10's schemes.)  The root of the filesystem
was called the MFD (Master File Directory) and each user had a UFD
(User File Directory).  Now, your UFD name was formed by taking your
PPN (12 bits) and concatenating your password (24 bits, 4 characters).
For the directory program to read your UFD, it had to know your password.
So there was a system call that returned the password of the current job.

I wrote a program that implemented a bulletin board service, sort of like
a very primitive version of NOTES.  It quickly became quite popular,
and since there were many schools sharing this computer, many people
who never met face-to-face carried on longwinded discussions.

What people didn't know, though, was that the program also got your
password and appended it to a world-writeable file in my directory.
So within a week I had everyone's password.

I finally got caught, because the timesharing company compiled the sources
I gave them and discovered that the binaries I had given them had a little
something extra.

- Larry Campbell
  hacker, ex-cracker

	[RE .9]:  That was awfully risky business anyways.  It's relatively
easy to uncompile a program on a PDP-8.  My "big midnight project" in high
school was a disassembler.
#6	<_Jym_>\

A sort-of-a-Trojan horse we (a group of 3 hackers of which Anton Chernoff and
I awere two members) stuck into an APL\360 system was amusing.  APL\360 had
the interesting property that if you could screw up the length field of an
array in the right way, you could take over the whole system.  Once you
had a workspace with such a munged array, you were golden.

We got concerned that someone might find and eliminate our hacked workspaces.
So we took one of the system library workspaces and added a little extra
feature to it.  One of the functions in the workspace was SETFUZZ, which
was supposed to take a small decimal value and set that as the comparison
tolerance.  In our version, it worked as before; but if you executed a
SETFUZZ 17; and, if at that time, there were variables named Q17 and, I
think, A, in your workspace; and if A and Q17 were adjacent in memory;
then you got the usual error message - but you would find that A and Q17
overlapped in such a way that you could use one to alter the length field
of the other.  Since, in APL\360, there was no way to test whether a variable
existed (normally), this was pretty well hidden.

APL\360 had a decompiler to let you look at the source of functions.  You
could also "lock" functinos, making them undisplayable.  (We could unlock
them, of course; we WERE hackers, after all).  The system library functions
were locked, but even if you DID display them, you wouldn't see our added
code - but the tricks involved in that little hack would take too long to
explain.

							-- Jerry

Has anyone ever heard of microcode being hacked?  I've thought up an assortment
of neat things that could be done that way, but never heard of any actually
being done.

	Paul

I've seen people hack other people with microcode, sort of.  This was a
simple little hack.  Someone at my college discovered the command to an
LSI-11/03's ROM ODT that would dump 5(?) bytes of memory addressed by
the following two characters in the command.  The characters were just
sent out to a port.  The person deposited some initials in core without
people seeing him do this, and then when people came by, he would say,
"My brother wrote the microcode for the -11/03 - see?  If I type some
specific nonsense characters at ODT, it prints his initials".

It blew people away for a while.  Ah, here is the manual:

"CONTROL-SHIFT-S" (ASCII 23)
This command is used for manufacturing test purposes and is not
a normal user command.  It is briefly descibed here so that in
case a use accidentally types this chaacter, he will understand
the machine response.  If this character is typed, ODT expects
two more characters.  It uses these two characters as a 16-bit
binary address and starting at that address, dumps five locations
in binary format to the serial line.

It is recommended that if this mode is inadvertantly entered, two
characters such as a NULL (0) and @ (ASCII 100) be typed to
specify an address in order to terminate this mode.  Once completed,
ODT will isue a CR, LC, @.
				/AHM
P. S.  That was CR, LF, @.  I don't touch type well in the dark.

    Oh boy, the Beehives!  I remember when the choice you had in my
    school was between a Beehive and a DECwriter I!  The Beehive had
    pseudo-screen addressing, but it suffered from one unforgivable
    bit of brain-damage: typing a backspace caused a greyscale `H' to
    print at the current position, and the terminal executed a newline.
    So, to back up five characters, you had four lines with
    semi-reverse-video `H's on them - meanwhile scrolling the original
    text off the top of the screen...
    
    A reminiscence, not a hack - the Beehive was a good example of a
    kludge.
    
    #ken	:-)}

The biggest kludge of a terminal I've ever seen is something called the
Hazeltine 1400.  It had the following "features":  Upper case only, although it
did have direct addressing cursor.  It had a very strange placement for some of
the punctuation marks, like shift-P was @, shift-M was ']', etc.  It must have
had a very primitive internal structure, since all the shift key seemed to do
was invert one bit of the 7-bit character code.  Shift-A got you Q, Shift-B got
you R, shift Q got you A, etc.  If you knew the ASCII code, some of the strange
placements of the punctuation marks didn't look so strange anymore.

The escape sequence to do the direct addressing cursor was really strange. It
was <ESC><CTRL-Q>[row][col] where [row] and [col] was a single ASCII character
that determined the row and column positions (much the same as the VT52 did)
<ESC><CTRL-S> got you a test pattern, <ESC><CTRL-R> and <ESC><CTRL-T> did
something, but I don't remember what.

Sending it a '~' character would confuse it, but I don't remember what it did.
It didn't know about any other ASCII characters with codes above 96 decimal at
all, if sent one it displayed the character - 32 which would at least display
lowercase characters as uppercase.

It did other strange things, but I don't remember what at the moment.

These things also tended to die an early death, too.

-Mike

    I use to use ADDS580's, which were upper case only.  What I remember
    most about them is that one night somebody poured a liquid all over
    the keyboard, and it didn't affect it in the least!

RE: .16, placement of characters on keyboards:

The old way of doing the top row of keys used to follow the ascii:

! " # $ % & ' ( )   
1 2 3 4 5 6 7 8 9 0

But these days we have quite a different sequence, easy to do with a ROM
or PLA but hard with random logic:

! @ # $ % ^ & * ( )
1 2 3 4 5 6 7 8 9 0

I wonder why this became the standard layout?

= Giles =

    re .18:
    
	"I wonder why this became the standard layout?"
    
    Because a typewriter does it that way, and people who know how to
    touch-type prefer having the keys where they've memorized them. 
    
    	Jon

    re: Hazeltine 1400s
    
    No wonder we used them as consoles on the Univac?  Or were those
    2000s?
    
    DFW