Hacking the Decsystem 20
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 :)