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..?
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
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.
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.
Yes it is very possible:
- Overclock the CPU (including increasing the voltage)
- Overclock the GPU
- Overclock the RAM
- Stop coolers (works with new hardware that controls the coolers).
- Flip the input audio jack with output audio jack to redirect sound to microphone (it can ruin the mic)(works with new hardware that controls the jack sense).
- Blow the speakers - just keep them at maximum volume on a VERY loud audio sinus of low freq (works with fancy audio stations controlled by PC)
- Change monitor refresh rate (works REALLY well with old CRT monitors)
- Open/close CDROM tray until engine fails
- Spin the CDROM over the maximum speed (10000 RPM) and keep it like that for a while
- Print until out of ink (great for laser printers with expensive toners)
- Spool printer until engine fails
- Jam paper (works with fancy printers)
- Overwrite BIOS (really nasty and easy to do)
- Move HDD actuator continuously until it fails due to overheating (there was a library available on this site that allowed you to do that). Same for floppy disk head.
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.
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.
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.
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.
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.
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/
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.
You could write code for the military - that'd cause some hardware damage I reckon.
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.
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.
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. :-)
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.
I heard about this at hardware engineering class. The 6809 processor had one or more input/output ports that could be enabled or disablef by setting a psir of bits. Two bits = four states; no input or output, input only, output only, input and output simultaneously.
This was the most interesting state. When any bit was enabled, a power line was connected to the circuit. When two bits were set, two power lines were connected simultaneously with rather pyrotechnic results.
<?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.
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.
hdparm --help
for example:
--fwdownload Download firmware file to drive (EXTREMELY DANGEROUS)
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...)
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
You're probably remembering the story of the Atari "Self Destruct Vector" that was made famous in an April Fool's issue of ANTIC magazine in the 80's. A program called "Paperweight" claimed to invoke the SDV to turn your Atari into a paperweight (or in modern parlance, "brick" the device). It was, however, a hoax, but the headline spread far wider than the punchline.
I found details in this thread on snopes.com
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.
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..?
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
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.
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.
Yes it is very possible:
- Overclock the CPU (including increasing the voltage)
- Overclock the GPU
- Overclock the RAM
- Stop coolers (works with new hardware that controls the coolers).
- Flip the input audio jack with output audio jack to redirect sound to microphone (it can ruin the mic)(works with new hardware that controls the jack sense).
- Blow the speakers - just keep them at maximum volume on a VERY loud audio sinus of low freq (works with fancy audio stations controlled by PC)
- Change monitor refresh rate (works REALLY well with old CRT monitors)
- Open/close CDROM tray until engine fails
- Spin the CDROM over the maximum speed (10000 RPM) and keep it like that for a while
- Print until out of ink (great for laser printers with expensive toners)
- Spool printer until engine fails
- Jam paper (works with fancy printers)
- Overwrite BIOS (really nasty and easy to do)
- Move HDD actuator continuously until it fails due to overheating (there was a library available on this site that allowed you to do that). Same for floppy disk head.
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.
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.
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.
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.
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.
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/
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.
You could write code for the military - that'd cause some hardware damage I reckon.
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.
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.
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. :-)
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.
I heard about this at hardware engineering class. The 6809 processor had one or more input/output ports that could be enabled or disablef by setting a psir of bits. Two bits = four states; no input or output, input only, output only, input and output simultaneously.
This was the most interesting state. When any bit was enabled, a power line was connected to the circuit. When two bits were set, two power lines were connected simultaneously with rather pyrotechnic results.
<?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.
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.
hdparm --help
for example:
--fwdownload Download firmware file to drive (EXTREMELY DANGEROUS)
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...)
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
You're probably remembering the story of the Atari "Self Destruct Vector" that was made famous in an April Fool's issue of ANTIC magazine in the 80's. A program called "Paperweight" claimed to invoke the SDV to turn your Atari into a paperweight (or in modern parlance, "brick" the device). It was, however, a hoax, but the headline spread far wider than the punchline.
I found details in this thread on snopes.com
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.
0 commentaires:
Enregistrer un commentaire