Conference noted::hackers_v1

    I would have to say that I like hacking under TOPS-20 the most (obvious
    reasons) but I don't mind playing in VMS every now and then.
    
    RT-11 is nice when you have your own PDP-11 to use it on. You can
    write anything you want (your operating system if you really want
    to).
    
    Mike

    RSTS/E is my favorite... I find that I can make it do anything that
    I want to without anything getting in the way.
    
    Kevin

    This sounds absurd, but VMS is my favorite because that is what
    I have.  It is the first OS I've had source access to.
    
    VMS is so large and complex that hacking is more like a game
    of ADVENTURE.  You never quite know what is going to under
    the next rock you turn over.
    
    This doesn't mean I haven't had fun with other OS'es, but VMS
    is a big favorite.
    
    	KC

    TOPS-20...
    
    While loadtesting Rel 5.0 in marlboro, part of the "new" stuff was
    an addition to the microcode to support one-word global byte pointers.
    (when they extended the KL to support larger virtual address space,
     you had to specify "global" byte pointers in two words (72 bits).
    For Rel 5, there was new microcode to handle these in one word.
     
    Anyway, to get "even" with our favorite microcode writer, everytime
    he loaded a microcode version which was even, the monitor (hacked
    by Kevin Paetzold and myself) would print out all TTMSGs (broadcasts)
    backwards, so people would see "detelpmoC boJ" instead of "Job
    Completed".  He was convinced he had messed up these byte pointers
    somehow...
    
    (well, it was funny at the time)
    
    Danny

    re .4:
    
    Speaking of the microcode for byte pointers, I seem to remember
    a problem using global byte pointers when crossing a page (section?)
    boundary). Don't know the details....anyone care to fill us in?
    
    Mike

    There was a member of our group that played highly interactive games.
    One guy developed a patch that, when a scheduling interval had selected
    his job to run, would run it 1 out of n times.  That slowed him down
    :-). Another patch to the ANF10 front end that did a 1 bit shift of the
    current typed character put an end to it.  It was invoked by patching
    the line # into a magic location. 
    
    We also had a popcorn meeting everyday at 4 o'clock.  When popcorn was
    ready, we would run a program on the -10 that would send a message to
    the DN82 front end to ring the bell of the paid up members of the
    popcorn group.  It was great when all the terminals in one corner
    of the floor started beeping.
    
    -phil

Hum. I seem to be in a minority here, learning from Multics
rather than a DEC OS.

Having access to the sources made all the difference.
Of course, Multics is a *large* operating system :-)

    Make that two votes for Multics!  It's also a great system to work
    on.
    
    	- Jerry

    re .4:
    
    I seem to remember a bug that left section 2 (DIRSEC) mapped
    incorrectly, so that a clever user program could read whatever 
    was left there.  Since this was before encrypted passwords, 
    he could just begin collecting passwords (since they're stored
    in the directory).  Don't remember what that had to do with 
    OWGBPs, but it WAS an interesting bug (good ol' CMU found more 
    of those kind of things...)
    
    Danny
    

    I also seem to remember byte pointers getting returned as updated
    byte pointers from the monitor. An easy way to guess someone's
    password. The way I understood it, someone could guess a password
    based on the returned updated byte pointer. If my password was FOOBAR
    and someone guessed FOOFOO, the monitor would give "?Incorrect
    Password" but would update the byte pointer all the way up to the
    mismatch (it would point to the second F in FOOFOO because the first
    3 letters are correct).
    
    Mike

    The next thing that happened was that they fixed that simple problem,
    and made the routine NEVER update the byte pointer.
    
    They thought they had heard the end of THAT problem, but oh no;
    hackers were hard at work !
    
    The system was still only READING enough of the test password to
    know whether it matched or not.
    
    Hence it was a simple matter to position the test password
    on a page boundary, where subsequent page was non-readable.
    
    Then, if you got a page fault, you knew your guess was correct
    through to its end.  If you got "invalid password", you knew your
    guess was wrong somewhere before its end.
    
    So, someone wrote a password calculater that printed out the partial
    results as it went.  Suppose your password was GHOST.  The hack
    calculater printed out the following lines as it tallied (one line
    every 3 seconds, since the system locked you up for 3 seconds on
    a wrong guess to make sure (!) you didn't get anywhere):
    
    A
    B
    C
    D
    E
    F
    G
    GA
    GB
    GC
    GD
    GE
    GF
    GG
    GH
    GHA
    GHB
    GHC
    GHD
    GHE
    GHF
    GHG
    GHH
    GHI
    GHJ
    GHK
    GHL
    GHM
    GHN
    GHO
    GHOA
    GHOB
    GHOC
    GHOD
    GHOE
    GHOF
    GHOG
    GHOH
    GHOI
    GHOJ
    GHOK
    GHOL
    GHOM
    GHON
    GHOO
    GHOP
    GHOQ
    GHOR
    GHOS
    GHOSA
    GHOSB
    GHOSC
    GHOSD
    GHOSE
    GHOSF
    GHOSG
    GHOSH
    GHOSI
    GHOSJ
    GHOSK
    GHOSL
    GHOSM
    GHOSN
    GHOSO
    GHOSP
    GHOSQ
    GHOSR
    GHOSS
    GHOST
    
    Well, system folks quickly fixed this one by making sure they
    read entire test password before checking anything.
    
    Who knows what hack will work next ?  Perhaps newer CPU will have
    super accurate accounting.  Then a hack might be able to figure
    out how much of password matched by measuring CPU time, since
    the correct password presumably takes more time to do the
    character comparisons !  (if you're a hardware designer about
    to introduce super accurate accounting, I bet you never thought
    of this security hole, did you now)
    
    /Eric

re accurate accounting as a security hole.

Ayup, it's been thought about.  You can get a pretty good data channel
between proceses by measuring the system page fault rate.  If you can
watch a process' CPU usage, you have an *excellent* data channel.  If
it's *your* process, ...!!!

    Unix carefully does the same amount of work whether a password test
    fails or succeeds (and it is deliberately expensive to make the
    number of tests per minute low)...
    
    Of course, there are many good ways of attacking Unix once you do
    manage to get logged in (at least on most versions of Unix before
    4.3BSD); these are usually much more fun...  And no, don't ask
    me what they are; I won't tell you....  On most Unix systems,
    becoming superuser should take less than a minute, given possibly
    a bit of prior preparation.

To return to the original question...it's been several years since I've used
it - and the withdrawal symptoms have pretty much faded by now - but I still
view RSTS as the best system for hacking around.  VMS is second, but that's
mainly because I'm so used to it now; on an objective scale, it's not a par-
ticularly close second.

It takes more than a whole bunch of strange things hidden away all over the OS
to make a good hacker's system; it also takes a convenient interface to what you
want to do.  By the time you can code up one argument list for one of the more
baroque VMS system services, I can have my whole RSTS BASIC PLUS program
written, debugged and running.

And, of course, what other system lets you use TECO as a CLI?  :-)

							-- Jerry

    	IAS lets you use almost anything as a CLI. I set up EDI as a
    CLI once....  :-)

Re .14:

Tops-20 (and presumably Unix) will let you use anything as a CLI.
				/AHM

    VMS is my favorite system for hacking purposes, with CDC SCOPE running
    a close second...
    
    Ron

I second hacking CDC systems.  I got _very_ good at hacking NOS before I left
college. The systems people were glad to see me go, especially since most of
the easier hacks were local mods to the system.  I haven't ever really gotten
to hacking VMS yet, there is so much to learn to get a serious start. 

Among my more nasty triumps:  reading execute-only files, how I outhacked
another (very good) hacker and stole his picture library (long story), changing
the username to blanks (and really confusing the system), my binary editor,
etc. 

-Madman-who-got-his-nickname-by-hacking-too-much

For general use and such I can't beat VMS.

For actual 'hacking' I've enjoyed my simple 8-bit CP/M.
It's allowed me to see my machine on an extremely intimate
basis.  I've hacked up the bootstrap to display my name
instead of CP/M, I've written sector read/write routines
for disk patching purposes, my own FMS type routines, and
many many other such wunderful things, much more difficult
to accomplish on a time-sharing system.

I've even broken security once or twice.
	(security on a single user system?)

Nothing illegal or unethical, of course.   8^)

SLH

    Ah, yes, another CP/M fan!  That old obsolete 8-bit system has been
    going down the tubes for years now (if you listen to 'those who
    know') but it just keeps hanging in there!  Z-80 assembly under
    CP/M for me any day!
    
    Willie [these_q-bus_machines_leave_me_cold]  :+)
    

I used to prefer RSX-11M for hacking.  Through my career of supporting and
doing system programming of that system I got to know the executive very well.
Features like the automatic invocation of a user-supplied "Catch-All" task to
process any commands the system did not recognize were a great benefit.
Since the sources to the RSX executive are supplied  and the executive is
assembled and linked as part of a SYSGEN, the tools are there for one who
wants to hack.

In my current job I no longer use RSX...PDP-11's are getting very rare here
(sigh)!  I now use VMS exclusively.  Although I occasionally hack VMS, (like
my undistributed hack to trace all logical name translations requested by any
process...great for finding hidden features/options) it is not as easy as with
RSX.  In particular, a typical hack to SYS.EXE loads some code into nonpaged
pool and then modifies the in-memory copy of SYS to invoke this code.  Or one
can patch an image and create a logical name which causes invocation of the
patched image rather than the original image...generally this requires some
fiche study too.

For the general program development aspects, I prefer the VMS user environment.
There are more utilities and the user friendliness are key to my greater
productivity than when using some system with three letter commands.

    I used to really like hacking TOPS-20 (anybody remember ITS-TECO?)
    when I was in college, but I had a lot of fun hacking, of all things,
    Data general AOS/VS (really easy to kill)...
    
    Now I have moved onto more familiar turf... VMS is my operating
    system of choice for hacking, since with some modest knowledge of
    the operating system you can stumble onto/calculate all sorts of twists
    on the design philosophy. Major areas to hack are the network, DCL,
    and using programs to do things they were not originally intended
    for, but they do anyway (capitalizing on design flaws is, of course,
    a true hacker's purpose in life, is it not? :-)
    
    /pjh
    

    Well, I also would say that VMS is my primary choice.  Of course,
    that probably has something to do with the fact that it and CDC NOS
    are the only two systems (aside from PDP-15 land) I recall hacking
    under.
    
    Little hacks to VMS to see every command typed by every user in
    order to find out who's been reading my mail; hacks to NOS to replace
    the timesharing executive with my own - stuff like that.
    
    #ken	:-)}

    All flavors of Unix (including Ultrix).
    
    Past favorite OS's to hack on:
    
   	TOPS-10		(the more bits to the word, the _____)
    	ETOS		(provided a virtual PDP-8)
    	OS-8

    Re .-2:
    
    A couple of people have sent me mail requesting that I `let them
    have' my hack for seeing all DCL commands on the system.  Well,
    if anyone's read _Malevil_, they'll know the sort of reception the
    phrase `let me have' should be awarded..  ;-)
    
    Seriously.  That hack was under VMS Version 3.7, and I haven't seen
    it in a couple of years.  I could probably re-create it as a midnight
    hack, but it would take more than a week, due to my time being
    constrained.  So I'll tell how I did it.  Or should I remain
    mysterious?  Hmmmmm.....
    
    
    
    
    
    
    All right, I'll give in - to a point.  It would only log those commands
    which invoked an image (SPAWN, EXAMINE, some SET and SHOW options
    - these wouldn't be logged).  I loaded a routine into non-paged
    pool and pointed the cell EXE$GL_USRUNDWN to it.  (JSB linkage,
    naturallement.)  The routine tried to assign a channel to a mailbox;
    if it succeeded, it wrote a fixed-format message into it, containing
    various process stats (PID, CPU time, image count, command line
    text, PCB flags, final image status, et cetera).  It then deassigned
    the mailbox channel.  If the mailbox didn't exist, no huhu - just
    ignore it.  A server process created the mailbox ($CREMBX PRMFLG=1, of
    course, followed by an immediate $DELMBX), read from it at AST level,
    and queued the record to the mainline code.  The mainline code wrote
    the records to a FOP=TMP file which it would enter into some directory
    or other on command, or upon exit.
    
    Got the picture?  Good.  DATATRIEVE could do wonders with reducing
    the data to amazingly damaging reports.  How to fetch the last command,
    in its final PARSED state, from P1 space is left as an exercise
    for the reader.  Besides, it's different now than in VMS 3.7, and
    I can't tell you how at the moment ;-)  As it stood, anyone who
    defined a logical name replacing the mailbox name, pointing to another
    mailbox or someplace even weirder, could lock up the ENTIRE system
    in a matter of seconds.  This hack is semi-supported; note the
    pre-existence of the executive cell I used.  However, caveat hacker.
    
    Go wild, you guys.  Let me know how it turns out.  And if someone
    stomps on you from a great height for invading privacy, I don't
    know you.�
    
    #ken	:-)}
    
    �I feel obligated to point out that, while you may record any
    non-classified telephone conversations you like, you are *legally*
    bound to inform the other party (or parties) that they are being
    recorded - BEFORE recording anything.  Make of this what you wish.
    :-)