Mainframe madness as the snowflakes take control – and the on-duty operator hasn't a clue how to stop the blizzard
- Reference: 1595228405
- News link: https://www.theregister.co.uk/2020/07/20/who_me/
- Source link:
College-based antics appear to be a thing, based on the content of our inbox, and today's confession takes us to a Canadian technical college in the 1970s.
As the age of the personal computer was dawning around the world, "David" (which is not his name) was working with a Xerox mainframe, replete with teleprinters to input code and punched paper tape on which to save programs.
A curious fellow, David discovered the model name of the mainframe in use on campus and, keen to hone his skills, ordered the full programming manual from Xerox. It was, he said, "a goldmine of ways to program better."
It got to the point where David and his pals not only churned out impressively tight code, but they also understood the inner workings of the hardware better than their instructor. "He had only basic knowledge," sniffed David.
As with so many campus-based shenanigans, it did not end there.
"We discovered, hidden in the deep recesses of the manual, a way to bypass some basic controls and actually control the mainframe directly."
Armed with their newfound skills and some usernames and passwords liberated from discarded TTY print-outs, the gang headed into the lab to try out their work.
It all sounded innocent enough: "Our program was a variant of the snowflake program found in the manual."
How lovely – a simple snowflake would be spat out by the TTY.
Oh what a cute little animation... OH MY GOD. (Not acceptable, even in the '80s) [2]READ MORE
"We had the mainframe output the snowflake at every TTY machine on the entire campus. And each snowflake was unique. No duplicates. It would keep printing snowflakes until it ran out of paper or was stopped."
A 10-minute delay was added to allow David and his pals to scarper before the insanity began. "Since it was told to make sure each snowflake was unique it took up most of the computing power available," he added.
A perfect plan – except, as David ruefully admitted, "what we did not know was the operator for that day in the IT department had no idea how to stop it. None whatsoever."
For 30 minutes the program ran, burning through CPU time and spewing snowflakes. Not knowing what else to do, the panicked operator killed the power supply, stopping the program but causing all manner of other bad things to happen to the mainframe.
"If he had read the same manual we bought," said David, "he would have known how to create a master interrupt to stop the madness."
Access to the mainframe remained verboten for three days after the incident. When the ban was lifted, David discovered that the access he'd managed to get was now restricted to terminals in the same physical room as the mainframe itself.
Their method of nabbing usernames and passwords was also stopped as The Powers That Be realised that echoing logins on a printer was probably not a good idea. A sign-in and sign-out policy for the labs was adopted and access to the commands used to hijack the campus printers were also restricted.
The snowflake gang was never caught, and doubtless whiled away the years that followed chuckling about their prank over a bowl of poutine and a growler of ice beer.
Ever had your curiosity get the better of your instructors or sent a server into a tailspin of distress, but nobody ever knew it was you? Now is the time to confess all, with an email to [3]Who, Me? ®
Get our [4]Tech Resources
[1] https://www.theregister.com/Tag/who-me
[2] https://www.theregister.com/2020/07/13/who_me/
[3] mailto:whome@theregister.com
[4] https://whitepapers.theregister.com/
Reminds me of the day,
one April 1st in the mid-90s, when a wandering sheep mysteriously appeared on the desktop of every machine on my school network as part of the login script. It's amazing how easy it was to mock up a convincing Novell login screen in Visual Basic in those days. One could (hypothetically, of course) set it running on a machine known to be frequented by admins, and it would feign a BSOD and force a (normal) reboot once it had harvested the credentials. It was a simpler time.
Re: Reminds me of the day,
Hypothetically of course
SU Credentials
For some reason lost in the mists of time the Unix box used for programming our Operating Systems project* had a lock out set for all accounts at lunchtime every day, I guess it was to allow the operators time for any maintenance work needed.
Somehow one of our group managed to get the SU password from one of the supervisors which enabled us to override this. That's all we ever used it for, with a large number of students using the box for a marked project nobody would risk any shenanigans that could significantly affect final grades.
*Groups of 4 writing a multi-tasking operating system in out spare time over a couple of months, we did it and it worked!
probably a favour
At least the snowflake project made them secure the machine before anything worse could be done.
This reminds me of the BBC computer network we had at 6th form college at the tail end of the eighties. Part of the class (a level) covered assembler.
Two of our class (names withheld) wrote a keyboard logger that sat in RAM and looked for a sequence of characters - LOGIN I think, and then stored the following 10 keypresses to RAM. It was planted on a few PCs and at the end of the day the miscreants checked the RAM. Eventually they struck gold and found the teacher's credentials - I can still remember his username and password to this day, 30 years later.
Armed with the keys to the kingdom, and after much snooping around and high jinx messing with users details, the final act of fun was to change the "logout" screen.
Those of you with long memories of said BBC networks may recall the logout command was *FW, and it displayed a huge FAIRWELL screen. For the best part of the Friday of that week, the logout screen now showed FUC*WELL instead (with a K, obviously).
Much giggling took place, and the lab was shut for the whole of the following week.
The names of the guilty students were never identified, although I can probably be bought.....
Keyloggers
I swear writing keyloggers, or attempting to capture usernames and passwords was a rite of passage sort of thing. At school as an early-teen we had access to a lab of networked BBC computers and more than one of us attempted to write command prompt simulations where the unwary would come up to what looked like a freshly booted computer, and just type the login command followed by a username and password as prompted.
They were pretty basic (or often BASIC) bits of code, but so many people fell for it with it saving the details to 5.25" floppy ("Oh sorry, I've left a disk in that drive. *YOINK*) before simply resetting or sometimes using the information to do a login with the screen output hidden.
It got to a point where the first thing you did when you sat down was make sure the floppy was empty, and then 10 second power cycle the machine to be sure there wasn't a dodgy script running!
Re: Keyloggers
Yeah, it was an informal disciplinary offence to be caught using the break key to halt the Sparc workstations in our University lab but many of us did it anyway before logging on. That extra delay while it booted was felt worthwhile given the shenanigans we knew were happening around us.
Xerox mainframe
SDS Sigma - that's a blast from the past...became Honeywell I think.
Operator revenge
My first job was as an operator at a university. As well as the old mainframe gear in the server room I sat in, we also had some shiny new Sun workstations in the labs. Bored in a late shift, and with a view of all the labs from where I sat, it was fun to discover I could logon remotely to a student's workstation and run the "falling snowflake" utility on their screen, or occasional static, or ants running around, or turn their display upside down. Simpler times.
Re: Operator revenge
Simpler times indeed - I had a Win3.11 compter hooked up to our SPARCStation through the serial port, and could log in with a terminal program. Apart from the wonderful script I had that turned it into a cuckoo clock, I was also able to sample the CAD operator's very loud burping and play that back at random, or even replace the bongs on the afore mentioned clock. Oh what fun we had in those simple days ... and yes, I was the boss.
Re: Operator revenge
I remember when NeXT workstations were popular (well we got 'free' Mathematica with them for which Display PostScript was a default. Oh the fun that was had with emails that 'melted' the screen :-)
When snowflake meant snowflake
Those were the days, before people hijacked words like "gay" and "spastic" and "snowflake" and "cloud".
Restricted number of print jobs per semester
Remembering the very nice time when the printjob-queueing program on the PrimeOS (PR1MOS for the purists) machine was programmed to allow a maximum number of jobs per semester. The program took an integer as "number of copies" argument. Specifying -1 copies, or any other negative number, would increase your allowance. Good times :-)