Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Hacking the Decsystem 20

Hacking the Decsystem 20

Rate This
  • Comments 14
A bit of truly ancient history today, and it's not even Microsoft related.

Back when I was in college, we did all our class work on Decsystem 20's running TOPS-20.  I've got to say that the dec20 is STILL my favorite processor architecture, even if it did have its quirks (like a 36 bit word size).  In particular, I LOVED the COMND% JSYS (Jump to SYStem, or system call) call - it integrated a command line parser and help system in a single system call.

Two of my friends in college, Alex Kluge (my roommate at the time) and Vince Fuller (there were several others, but Vince and Alex immediately come to mind) spent a fair amount of their time trying to hack the campus systems (hey, we were young and some of the more nuanced issues of the morality of that kind of action escaped us).  I was never particularly competent at it (lacking the right mental attitude), but Alex and Vince were rather good at it.  I distinctly remember the head of the computer center commenting that both Vince and Alex (mostly Vince) were responsible for finding most of the bugs in their system.  IIRC, after graduation, he ended up hiring Vince :)

There were two ways that Vince and Alex used to mess with the systems.  The first was to find a bug that would crash the mainframe and exploit it.

Nowadays, in this world of personal computers, we forget what a big deal this was.  The CompCenter Dec20's typically had hundreds of users logged into them at any time, most of us trying desperately to get work done for the assignment that was due the next day.  So when the computers crashed, it was a big deal - hundreds of people would lose their work.

On the other hand, immediately after the machines crashed, it would take several minutes for those people to log back on.  And some of them would give up in frustration and go back to their dorms until fewer people were on the systems.  So if, somehow, you could predict when the machines would crash, you could have a few minutes where the system was less loaded (and thus get more work done).

So knowing how to exploit a bug that would crash the mainframe was pretty handy piece of information.  And these guys tried every way they could to figure out how to crash the machine.  I vaguely remember that one of them exploited a bug in the addressing model of the processor - they set the "memory indirect" bit on the first word of every page in memory and then executed an instruction that then forced every page in the 18 bit data address space to be faulted into memory simultaneously.

The other thing that they'd do was to try to patch the kernel so that they'd be able to gain supervisor (root) access to the system.  But it wasn't enough to patch the running kernel - whatever patch they came up with had to be able to survive a reboot.  In todays terms, this is sort-of the equivalent of installing a rootkit on the machine.

So they took to patching obscure system calls that would never be used.  Their favorite call was the LIGHTS% JSYS, which was used to manipulate the non-existant console lights on the Dec-20.  As such, there was no legitimate code that would ever use the LIGHTS JSYS, so they would patch the LIGHTS JSYS code in the kernel image to enable superuser privilege, and then be on their merry way.  Eventually (fairly quickly actually) the system administrators figured out what they were doing and installed checks to ensure the integrity of the system binaries, which raised the bar for them.

I guess the bottom line is that some of the actions of hackers today aren't new at all - they've been going on for at least 25 years now, if not longer.

Btw, I in no way condone what these guys did, and I never participated in those activities.  They knew the risks when they took them.  I know of at least one person who ended up getting a degree in music composition from a rather prestigious university instead of getting a CS degree because he participated in some of this kind of activity when he was in college, so the risks of hacking systems are very real :)

  • I like your blog's new look Larry!
  • Geez... why are you trying to "out" all us old-timers?!

    Ah yes, the COMND JSYS... I knew it well. That was a truly amazing piece of work. Still nothing like it in the command line world.

    Actually, I never had any real opportunity or need to "hack" TOPS-20 or TOPS-10 for that matter since we always had full source available. I worked in the computer center at school (Stevens Institute of Technology using TOPS-10) and then started at DEC at the end of May 1976, a few months after the DECSYSTEM-20 came out.

    I was in "the language group" (compilers, like COBOL) and every once in a while I couldn't figure out a JSYS return code and when I walked to the next room to ask the operating system guys what the story was, they'd usually hear me out politely but also usually say the same thing: "Don't know... check the code." and off I'd go the the "listing rack" to read the system source code for that JSYS and figure out what control paths would cause the confusing return code. Every so often it was simply the code giving the WRONG return code.

    -- Jack Krupansky
  • Ah yes, yeah ol' TOPS! I was really fortunate to have worked with the crazies that wrote TENEX (aka 10X), which became TOPS-20. They were a wild bunch... The DEC-10 was in one room and in the adjoining room was an E&S Picture System 1 CGI system. It was an amazing system for producing CGI films in the early '70s. (This university was one of a very few that actually had computer graphics courses...) TENEX started out as a series of extensions to TOPS-10 to allow for bridging hetergenous systems together (like the E&S PS1), but ended up being a rewrite of the kernel, filesystem driver, terminal driver,.......ok, the whole damn thing!

    At the campus data center, which was spun off and incorporated as a revenue-making service bureau (named Chi Corporation), we bought a DEC-20 when it came out. By that time, most of the TENEX authors had gotten their masters or doctorates (from having written a portion of TENEX) and got hired at Chi. For a short while, I was the "system manager" of the machine, until I left to escape impending doom (as detailed below).

    Chi was one of those places that people would KILL to get into. During junior high and high school, I was using their time-sharing services and wrote several hundred programs. Before graduating high school I even did security consulting with Chi (and Datalogics, Chi's competitor right across the street!) due to the lousy bugs in the kernel of the OS that ran on the GE/Honeywell 400. (Curiously, the most noteworthy bug was in the FORTRAN IV compiler, which allowed negative subscripting in a form of "buffer underflow" security breach. I could actually overwrite all the program interrupt traps, cause system crashes, stop the machine, restart it, or install my own kernel mods. This was 1970...)

    When I was hired full-time at Chi several years later, I was only the non-degreed developer EVER hired there, amongst a staff of ~200, with over 150 of them holding masters or doctorates in Computer Engineering (from Case Institute aka Case-Western Reserve U., of course!). Chi was also famous for it's heavily modified serial #1 Univac 1108, which was the fastest uniprocessor in the world for about 5 years. (Chi was also infamous for it's own 110x OS, named Chi/OS...after having written large portions of EXEC 3 through 7 for Sperry-Rand, before they "got a divorce" when Sperry didn't like the idea of writing a modern OS in a high-level language. You see, Chi/OS was written in a language named "Chili", which looked similar to PL/I but was closer to XPL by McKeeman at Stanford.)

    The TENEX guys were constantly at war with the TOPS development group back at DEC HQ over whose code was going to be the "official" module(s) in the distro. After Chi was sold (by Case) to a wiener of a small company (named Ecotran), it p.o.'ed most of the TENEX guys into leaving in the first month after the buyout, as it was considered an end of an era.

    The last nail in the TENEX hacking era was when the management of the buying company (Ecotran) decided after a year of the DEC-20 being powered up (and selling time-sharing services on it), that they didn't want to pay the annual $500K TOPS-20 source code license fee to DEC. Thus, essentially, the remaining TENEX guys took this as the ultimate insult: the head of their own company didn't want them to have access to THEIR OWN SOURCE CODE they wrote 5 years earlier! (I remember that day when the decision was announced: another dozen quit and walked out. Only one last TENEX author remained out of 3 dozen...)

    And, thus...down the toilet went the great and mighty Chi Corporation... (When you piss off all the talent, there's not much left!)

    Meanwhile, the CompE department at Case still used their DEC-10 with TENEX for another 5-6 years, since it was the primary control system for the E&S PS1.

    Those that had a chance to hack around either TOPS-10 or TOPS-20 are truely blessed to have had the experience! (The only other OS that I think the same could be said was Multics...)
  • Oh, I forgot to mention that it appears as though the entire TOPS-10 and TOPS-20 source code now lives on at: pdp-10.trailing-edge.com

    Specifically, the COMND JSYS manual is at: pdp-10.trailing-edge.com/decuslib20-01/ 01/decus/20-0002/comnd.doc

    (Tripped over this by googling "COMND JSYS" just for fun!)

    Makes me want to goto the Computer Museum (here in Silicon Valley) to see if there's a DEC-20 that I can play with... Could be QUITE distracting!
  • > and it's not even Microsoft related

    Yes it is. The relationship between VMS and VMS++ is rather obvious, and there's almost surely some murkier relationship between TOPS-20 and VMS.

    > Alex Kluge [...] and Vince Fuller [...]
    > spent a fair amount of their time trying to
    > hack [...]

    Hey, not fair! How come half of all hacks aren't called Fullers?

    > So if, somehow, you could predict when the
    > machines would crash, you could have a few
    > minutes

    Oooh, more Microsoft-related stuff. If only we could predict when our machines will crash...
  • If any of you want to play around with TOPS-20, be aware that you can run it on modern computers via emulation. There is a good PDP-10 emulator called KLH10 available at http://klh10.trailing-edge.com/ (presently for Unix-like systems only), and TOPS-20 is available at http://pdp-10.trailing-edge.com/ (with complete source, as Steve mentioned). If you don't want to bother setting up an emulator, there is also a publicly-accessible TOPS-20 system available at http://twenex.org/ (accessible via telnet after registering at the website).
  • Reminds me of the shenanigans we played on the computer lab's sys admin in 10th grade ... one of which was to replace the Windows 95 startup bitmap with a picture of Beavis & Butthead.
  • Interesting enough, when I was in my university, although I know many people come from CS department(thanks to the bulletin board system of the Students' Union), the people who I know of that has this kind of ability are majorly NOT from the CS department.
  • We had a Decsystem-20 at the good ole University of Vermont. I had lots of fun with Tops-20 and that machine too. In fact, just the other day, I found a Pascal Reference Manual for the Dec-20 collecting some dust in my office. I am pretty sure I have a brochure from DEC too. I'll have to scan that post it.

    Those were the days!
  • For a while in the mid 80's, a Decsystem 20 was our email machine at Microsoft -- in the Windows group, at least. (I know that before my time ('84 - '87), it was used for more than just email of course.) I quite can't remember the machine name, but I'm sure someone else reading this will. It was disappointing at the time when we had to move off the Dec 20 to a Unix box for our mail.
  • Thinking about TOPS-20 makes me all misty. I still have all of my TOPS-20 manuals, purchased from the CMU bookstore. I've worked on a lot of different architectures over the years, but I still think TOPS-20 has it over most other architectures, and wish COMND% had been implemented elsewhere (in the OS!).

    I was thinking the other day about one of the changes in later versions of TOPS-20 where you could spawn multiple address spaces from a single process with fairly simple communication between the spaces. (IBM implemented a form of this about ten years later in their mainframe architecture). I loved the shared, memory-mapped registers as well.

    And, I much prefer the old TECO-based version of EMACS which we used for most of our work on TOPS-20 - it always struck me as strange that EMACS would evolve into a raison d'etre (sp?) for LISP. I stil use EMACS (uEMACS for Windows), but won't touch the pig that (GNU) EMACS has evolved into. (Now, if I can just hack Unicode support in...)

    Thanks for the (36-bit) memories...

    -- Bill
  • The school (Vanderbilt Univeristy) had a TOPS-10 and then a TOPS-20 while I was there. This was my first "official" exposure to computing and began what ended up being my chosen profession. I was one of those non-CS guys who liked learning about the system. I ended up as a TA in an non-CS FORTRAN course while I was there.

    Did you all have DecWriter Terminals? I remember that sound so well.
  • When I met Vince Fuller -- Christmas break 1982 -- he was already working for Computing Services, hacking on the 20s.

    By the time I was hired as an operator in 1988 Tops-B was already slated for retirement. [Hrm. According to my quotes file, it went down for good on Aug 15 1988.] Tops-B still had mountable disk packs attached, and a punch card reader. It also had a "problem" where every once in a while the Front End would disconnect from the system. The console would hiccup a few times, crying about the disconnect, then it would reconnect and move along as if nothing had happened.

    By that time most of the serious Tops-20 people were long, long gone [remember, they quit in a fit after being shafted by the then-upcoming Andrew Project; IIRC the boss came in one day and said, "We're phasing out the 20s and you're all going to work on this nifty new unix project!" and they were almost all gone within a few months]. The last guy hacking at the kernel images [*(#)%! I can't remember what the running kernel image was called] couldn't find the problem, and since it wasn't critical he didn't look hard.

    It wasn't for another couple years that some folks I know [some ex-ABTech], after they'd graduated, admitted to tickling a bug on Tops-B to cause that FE disconnect.

    Be damned if I can remember what it was, too. But I bet I'll think of it at 3 am.
Page 1 of 1 (14 items)