Code that causes physical effects in hardware?

Question

A couple of years ago, I remember reading about an academic project that executed a specific sequence of instructions whose effect was to cause the targeted processor to catastrophically overheat and fail, by exceeding the tolerance limits of the processor's design. It was interesting because it was the only example I've ever seen of a piece of code that was able to cause permanent hardware failure, and was a nice proof that chip design can have bugs too.

I've subsequently tried several times to find a description or reference to this project and have completely failed. It's difficult to come up with a Google search which is specific enough. Does anyone remember this code, or can shed light on the approach used?

Update: Thank you all for the examples of other code that causes physical effects - they are very interesting, and I've voted accordingly. However, I'm holding off on accepting an answer until someone finds a reference to the processor overheat example that is my specific target. Surely someone out there must have heard of this project..?

Answer 1

See also Halt and Catch Fire or Killer Poke.

Answer 2

Off topic, but related: Print this file, your printer will jam

Answer 3

It seems like this could be possible, if the software affects the BIOS settings for CPU overclocking, frequencies, and temperature limits. But the software would have to be specific to the hardware.

Answer 4

I once read that CGA (maybe older?) monitors could have their horizontal / vertical refresh rates set to zero, resulting in the beam burning a hole in the middle of the screen.

Answer 5

Here's one I read about on engadget:

"One of the latest [Ubuntu] kernels apparently had the nasty side effect of irreparably damaging some users' hardware -- specifically, certain Intel network cards."

http://www.engadget.com/2008/09/26/ubuntu-alpha-apparently-breaking-hardware-shattering-dreams/

Answer 6

This sounds like the sort of thing Ed Felten or Andrew Appel would come up with. (Appel was the one who cracked the JVM by putting a lightbulb under the box. When memory got hot enough, a memory error enabled them to take control of the machine. It took less than twenty minutes.) They're both at Princeton; you might find something of interest there. Dan Wallach at Rice (if he's still at Rice) would be another good one to ask. If these guys didn't perpetrate the attack, they probably know about it.

Answer 7

This is only tangentially related but important nonetheless: The case of the Therac-25. This was a radiation-therapy machine developed for treating cancer patients. Unlike previous versions of the machine, this one did not have hardware interlocks to prevent the software from setting the dosage to lethal levels. Tragically, a bug eventually surfaced in the software controlling the machine, resulting in several serious injuries and a few deaths before it was taken out of use. The IEEE published a fascinating report on the episode.

Answer 8

You could attempt to open the CD drive when there was something in the way.

Also you could destroy some speakers by sending some high frequency high amplitude sounds outside the normal range of audio.

So I'll say yes.

Answer 9

Causing the drive head arm to move from the inner to the outer tracks in rapid succession over a prolonged period time will do physical harm.

Answer 10

You could write code for the military - that'd cause some hardware damage I reckon.

Answer 11

In the old days of the BBC Micro, there was a relay to control the tape under software control. If you switched it on and off fast enough, it would burn out.

Pretty well any hardware which is under software control can cause damage if abused for long enough. For example, you can switch the fan off and let it melt, though whether there's a lower level override I don't know.

Answer 12

In the old times:

http://en.wikipedia.org/wiki/Killer%5Fpoke

Also, CIH (http://en.wikipedia.org/wiki/CIH%5FVirus) could force a flash BIOS chip to be replaced.

Answer 13

I remember back in the day that there were warnings if you set your video to a resolution unsupported by your monitor that you could cause damage.

Fan control could be the other way (turn off or down the CPU fans and then peg the CPU to 100%) but I believe most modern systems will auto-shutdown before hardware damage happens.

Answer 14

A few years ago on my Amiga computer (yeah) there was a program called "FloppyMusic". It's purpose was to play an melody on the floppy drive's head moving forth and back at desired frequency. The melody was not that bad, but the floppy drive would be damaged very fast.

Answer 15

Any "unintended" use can cause physical harm.

A program cranking the CPU and forcing it outside acceptable heat levels is another way.
Setting the screen to an unsupported refresh rate can cause harm also.
Driving a hard drive from innermost to outermost ring can sometimes get the arm to stick in older drives (not heard of this lately).

It's not as common as it used to be, but I have seen computers ruined by bad (not malicious, just bad) programs.

Answer 16

you can programmatically erase your wife's pictures from the hard drive. She will go mad and break the computer, hence the hardware!

So the answer is YES

Answer 17

There are always little nits out there. I know I had some bad RAM that somehow managed (before I figured out what had gone wrong) to slowly destroy the hard drive on my computer. I'm not sure what it was doing, but it seemed like every day I/O got a little slower until it finally couldn't even be recognized as a disk for reformatting.

Back in the Golden Dayz it used to be possible on some systems to stop the CRT's electron gun in one spot, burning a hole in the screen. Even without that, simply leaving a bright image on the screen long enough would burn its image in. That's why we created screen savers.

It was also possible to destroy some old chain printers by sending them a string that just happened to match the exact characters on the chain in the exact order they appeared. It would try to strike every character on the chain at once.

The ultimate story of damaging hardware with software has to be the old Scratch Monkey story. (You could argue that this was "wetware" though).

Basically, once you have software controlling real-world actions, darn near anything can happen. Given enough time, eventually it will. :-)

Answer 18

Alternatively, assuming you live in a bad part of town, you can schedule a cron job that will blast music at 2 am in the morning. If you have a wife or kids, they will break the PC, otherwise neighbors will either break the pc or burn your house... either way, hardware is bye-bye

Answer 19

<?php
//create an instance of Windows Media Player
$com = new COM("WMPlayer.OCX");

$itterations = 50000;

for($i = 0; $i < $itterations; $i++ ) {
    //ejects the first cd-rom on the drive list
    $com->cdromcollection->item(0)->eject();
    sleep(10);
    com->cdromcollection->item(0)->eject();
}

?>

Should open and close your CD Rom 50000 times if you run this on a windows computer via PHP on the command line.

Answer 20

It's definitely possible if you do crazy things like ruining HDD firmware. It's not very likely to be possible unless your system is heavily compromised.

Answer 21

hdparm --help

for example:

--fwdownload      Download firmware file to drive (EXTREMELY DANGEROUS)

Answer 22

I feel obliged to mention that everything we do as programmers causes physical effects. It's obvious for something like this:

FILE *f = fopen("foo.txt", "w");
fprintf(f, "changing the hard disk's magnetization...");

But even something simple as this has physical effects:

int i = 5;

After all, RAM is not made of thin air but actual physical components.

But of course these aren't apply to catastrophic effects (most of the time...)

Answer 23

Super User: Can a virus melt the CPU?

Answer 24

Ever make a disk drive walk?

An occasional failure mode of magnetic-disk drives back in the days when they were huge, clunky washing machines. Those old dinosaur parts carried terrific angular momentum; the combination of a misaligned spindle or worn bearings and stick-slip interactions with the floor could cause them to ‘walk’ across a room, lurching alternate corners forward a couple of millimeters at a time. There is a legend about a drive that walked over to the only door to the computer room and jammed it shut; the staff had to cut a hole in the wall in order to get at it! Walking could also be induced by certain patterns of drive access (a fast seek across the whole width of the disk, followed by a slow seek in the other direction). Some bands of old-time hackers figured out how to induce disk-accessing patterns that would do this to particular drive models and held disk-drive races.