Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
[I have selected the following articles from a long discussion in the Usenet newsgroup comp.misc. My interpolations are marked like this. I have deleted some header lines, some text, and all signatures. —msb (Mark Brader)]
… is a piece of software that actually makes a computer blow up just like in the movies. This is long overdue. "Lay" people are extremely disappointed when a program or system grinds/wheezes to a halt with some wimpy message like "B037X: USER ERROR IN GAPX TABLE" or "CATASTROPHIC SYSTEM FAILURE: BUFFER OVERFLOW INDICATOR OVERFLOW" or "Bus error - core dumped". They want to see explosions! Paper spewing out from wherever paper spews out from! And gicky fluid oozing out of the machinery as the entire machine room collapses onto itself because someone either forgot to put a %*&#*$#&@ in column 92 or asked the computer an impossible question like “What's the meaning of life?”, “Why?”, “CAN you get there from here?”, “Calculate pi to the last digit” [THAT'S NOT A QUESTION!], or “Where's the bathroom?” That's a worthy goal for computer technologists everywhere. Forget artificial intelligence! Forget relational databases! Forget distributed network architecture proposal interface protocols! Forget documentation! Forget associative memory! Let's make computers explode in our lifetime!!!
[So how do you shut down a computer with no HALT instruction, without requiring hardware repairs? Like this… —msb]
From: rick@oresoft.UUCP (Rick Lahrson) Message-ID: <37@oresoft.UUCP> Date: Mon, 25-May-87 02:52:46 EDT Organization: Oregon Software, Portland OR
A small step was taken toward this end back in the early sixties, in IBM's System/360 model 30 CE school. Seems one of the better students had time enough to pore over the schematics and discover which cores (remember core memory?) were located just beneath the overtemp sensor. He wrote a small program that did nothing but abuse those particular cores by writing ones and zeroes alternately to them, until they heated up, and the temperature sensor shut down the machine.
First, of course, the program printed out “Programmed Power Down” on the console. Caused a lot of bewilderment among the students and instructors. Especially since the big feature being touted about the S/360 was that it was so oriented to multiprogramming that it didn't even have a HALT instruction.
[Then there was a string of articles (actually, this may have been a separate discussion in misc.misc, but what the heck, it fits in nicely here), pointing out that a number of modern computers have a software-handled OFF switch, and have to have their plugs pulled when they get totally stuck. These articles were then nicely topped by this one: —msb]
From: bill@sigma.UUCP (WIlliam Swan) Message-ID: <1261@sigma.UUCP> Date: 19 Jun 87 16:35:12 GMT Organization: Summation Inc, Kirkland WA
Some years ago I worked on a battery-powered instrument (it would run 24 to 48 hours on batteries) in which the project manager insisted that the OFF switch should be an interrupt to the CPU, which would then power itself down.
You guessed it.. the uP derailed and the only ways to get it back were:
Fortunately (:-) it never made it to market.
[This one must be the most devastating for a computer victimized by it. Imagine being the person who set it off by accident! —msb]
From: kmd@sdcsmb.UUCP (Karen M. Davis) Message-ID: <424@sdcsmb.UUCP> Date: Fri, 22-May-87 11:47:38 EDT Organization: System Development Corporation, Santa Monica CA
Um…. many computers built for military applications contain a "trap door" that can be reached by an assembly sequence that will direct the transformer or power supply input onto the motherboard. Manufacturers of this type of computer include HP and Litton. This "feature" is supposed to be used to destroy your computer as the installation is being overrun by the enemy. Since most of these suckers use large DC generators as input to the transformers/power supplies, you can imagine the fireworks that occur when this stuff reaches all those cute little ICs. ;-)
It was supposed to leave the attackers with molten sludge.
[There were a number of poorly documented articles about walking disk drives and "halt and catch fire" instructions, but the following ones seemed sufficiently well described to include here. Some relate to deliberate actions, but in every case there is the question, "what if this happened by accident?" —msb]
From: socha@drivax.UUCP (Henri J. Socha (x6251)) Message-ID: <1827@drivax.UUCP> Date: 11 Jun 87 18:59:22 GMT Organization: Digital Research, Monterey
The following story was related to me by employees of I.P. Sharp Associates (IPS). They, with Scientific Time Sharing Corp. (STSC) wrote APL for IBM back in the early days.
It seems that there started to be competitors to IPS/STSC's APL system. These companies would usually use IBMs APL (written by IPS/STSC) on their large IBM mainframes. Sometimes they would add extra bulletproofing so that APL would not bomb, get better performance, etc.
Now, IPS/STSC really knew APL (and the IBM implementation) very well. In fact, an employee living in Palo Alto would debug/enhance the production on-line APL system from his home!
There were people across North America and in Europe (at that time) using this single mainframe (360/158 I think). The computer was in Toronto Canada.
Anyway, a competitor named Manhattan APL (I think) called up IPS and said they were about to come online and if IPS wanted to, they could test the system. Manhattan said they had filled in all the holes and the system was unbreakable.
Manhattan APL came online for their customers about 2 months late. It seems that some of their disk drives had thrashed themselves to death.
I inadvertently wrote a BASIC program on an HP2000 at George Mason University that blew up the disk drive. It was an 8 player real time space war game. The problem was that all interprocess communication had to take place via disk. I used the documented LOCK function for serialization. It seems that this function loaded a special OS overlay whenever invoked and reloaded the file I/O overlay directly afterward. With 8 programs doing this as fast as possible, the disk would die.
The problem was solved by using an undocumented feature of the scheduler. A process was always assigned 1 sec of CPU following completion of a wait for terminal I/O. This allowed serialization with careful coding while not using the LOCK overlay.
BTW, an IBM PC program can blow up the monitor and video cards by programming nasty parameters into the video controller chip.
The CompuColor 2 personal computer of about the 1978-80 era could be made to fry itself from BASIC. A simple FOR loop outputting 1-255 into a certain I/O address (it's Z-80 based) caused the screen to blank in an entertaining fashion, followed by the smell of smoke. You had to pull the plug at the wall to get it to stop. I was totally amazed. Just think of the possibilities. I don't know exactly what was going on, but I suspect that they had too much trust in software and used the CPU to control such things as the power supply so they could save $5 worth of chips.
When I was in high school, we had several SWTPC 6800 machines, of slightly post-Altair vintage. They had 32k of RAM (a lot at the time), 5-1/4" single density drives that held around 90k, a CP/M-like operating system, and you had to boot them by calling the disk boot rom from the monitor.
Anyway, I saw demonstrated (not with the school's permission, as you can probably guess) a program called "DEATH" which did a number of destructive things including stepping the drives out of range and apparently using this opcode you mention. I remember the main board going in for service after that and coming back with lots of new chips. I never knew how a program could do this until now…
(Don't take everything I said as absolute truth… my memory is a bit fuzzy… I do distinctly remember the computer being fried by that program, though. And no, I was not the one who did that… I was only a spectator)
On another note, some of the earlier Commodore PET's had a register in their video controller that set the number of scan lines (or something like that). On some of them, you could tweak this register to get a better looking screen display. On others, doing so would toast the video circuitry. While this is not strictly in the "exploding computer" category, in the PETs the monitor WAS in the same case, so it has the same effect on the poor guy who watches it happen :-)
A few years back, PC magazine and PC World published claims that it was possible to program the video controller chip in the CGA (Computer Graphice Adapter) video adapter board so that an ordinary color monitor's flyback transformer would overheat and catch fire. Has anybody done this? Is it included in anyone's copy detection? Anyone's error handler?
It should be real simple to do. That chip gives you pretty good control over the video waveform, so you ought to be able to play with the timing of the horizontal sync pulse, (which, as I remember, was the way the trick was done.) has anybody extened these techniques to the more sophisticated EGA (Extended Graphics), and PGA (Professional Graphics).
[End of collection forwarded to Risks by Mark Brader—msb]
Please report problems with the web pages to the maintainer