I know a question similar to this one has been asked before however it was about installing a 32bit OS on a 64bit laptop. My question is more about damaging the hardware.

I was wondering if there was a way of interfacing with hardware from the OS or Terminal layer in a way to damage it beyond repair (actual physical damage, not just faulty hardware).

  • Could you bypass security measures and run a CPU so hard that the ceramic actually breaks?
  • Could you write or interface with a HDD in a way that would cause physical damage to the platters?
  • Could you mess around with memory and fry RAM?
  • Can you blow a NIC?

I'm interesting in knowing the limit to which the software can reach when looking at a system as a whole.


20 Answers 20


When actually running programs, the load on the CPU can cause the core temperature to rise. While newer technologies have some effect (dynamic frequency & voltage scaling), this is still mostly because certain instructions use different electrical pathways in the microprocessor (as opposed to when the processor is simply in an idle or low power state). There have been various power viruses written in the past, which take advantage of this fact to repeatedly execute specific machine code which draws the most power, and thus produces the most heat (see the question Can a virus melt the CPU? for details).

While you could also extend this idea to other hardware in the system (which I'll cover below), another interesting one is storage devices. You could also write a virus to constantly read-write files to a drive, which will wear it out a lot faster (both mechanical hard drives and solid state drives). You will increase the likelihood of mechanical failure in a HDD, and decrease the drive longevity of a SSD. If the user is unaware of these constant read-write cycles, you can most likely damage their disks within a week or so if you implemented this properly.

Also, some Apple laptops have a microcontroller embedded in the battery. Nothing special, but in the past they released a patch that upgrades the firmware - and in turn, now the batteries themselves are susceptible to firmware hacks.

Now, back to the heat damage. Some new motherboards include the option to modify BIOS settings under Windows. You could theoretically write a virus that would increase the voltages in the system to artificially high limits, potentially damaging the components (RAM, CPU, north/southbridges). Raising the voltage and/or overclocking the PCIe bus could also damage some of those components.

One component in particular on a PCIe/AGP bus I would like to address is the video card. This is because most manufacturers provide overclocking tools to raise it's core speed and voltage. Taking that one step even further, you could also write a virus to use these tools to raise both of these things to dangerous levels, so you could either burn it up, overvolt it until it degrades, or both!

Do note that most computer hardware has overheating protection, and will reach "thermal shutdown" before any damage occurs. As for overvoltage protection, it's possible but far less common.

The point: It's possible to write viruses that take advantage of any computer system. If the target system has no access to external (or even its own) hardware, however, there's not too much damage you can do. The best analogy here would be like trying to hack someone who pulled their Ethernet cable out of the wall - you literally have no way access to that system.

That being said, most devices in our modern computer systems do have access to modify physical hardware parameters - namely, voltage and core speed. Since these things can be modified, it is possible for viruses to take advantage and possibly disrupt or destroy their operation altogether.

  • 19
    -1 I disagree on hard drives. Server hard drives run constantly and do not wear out within a week. static.googleusercontent.com/external_content/untrusted_dlcp/… Jul 22, 2011 at 20:35
  • 6
    Though on the CPU issue, any modern board will have thermal cutoffs that should kill the power long before the CPU is in danger of physical harm.
    – Phoshi
    Jul 22, 2011 at 20:45
  • 5
    @Bryon Whitlock I would argue that it depends on the usage pattern. Most servers cache the information they retrieve and perform write-backs sequentially. You could create a virus to write information at the very edge and very inner edges of a platter back and fourth very rapidly, causing excessive wear a lot faster. Finally, if you could continually write to a selected group of sectors, you may be able to cause a few bad ones much quicker then usual. Jul 23, 2011 at 13:47
  • 1
    @Breakthrough: Uhm... no. Continually writing to the same sectors will do absolutely nothing to those sectors. Magnetic platters don't "wear out from excessive bending". I'm a bit confused as to why you think this would cause a problem. If your drive has issues seeking between platter edges, you have a bad drive... once again that interface is electro-magnetic, not mechanical. To have a problem there you would have to literally wear out the sealed bearing that holds the arm assembly in place.
    – user11934
    Jul 24, 2011 at 8:58
  • 5
    Hard drives CAN be damaged by viruses, but not from any arm&platter related silliness. The most vulnerable point is the main spindle motor. Start the drive up, shut it down, start it up, shut it down, etc etc etc. This is (relatively) hard on the componants. This is the major reason (aside from physical shock) that laptop drives don't last as long as desktop drives, power requirements keep the things spun down as much as possible. So a virus could theoretically shorten a desktop drives lifespan to look more like that of a laptop drive.
    – user11934
    Jul 24, 2011 at 9:01

There was always that warning that some older CRT monitors, if given a video signal beyond the frequencies they could handle, might suffer damage. I don't know which ones but it was a common disclaimer given when you were adjusting refresh rates or manual resolution settings.

Basically unless a system doesn't have proper cooling or a proper power supply installed, you can't break a CPU by working it too hard. The cooling and power it is installed with should sustain it at 100% usage.

However all modern CPUs all microcode updates. Intel has always required their microcode to be encrypted, but AMD has not (don't know if that's changed). Might be possible to upload a microcode to a CPU that does something nasty.

Flash memory can be worn out with repeated writes. It's likely possible to "burn out" a BIOS flash chip with this method.

I'm sure hard drive manufacturers design their devices with hardware interlocks and no capability to adjust motor speed, since really the HDD motor just spins at a constant speed. However, spinning up and spinning down a HDD causes it stress and premature wear, which can be done in software. Also, it's likely possible to "burn out" a hard drive's firmware flash/EEPROM with repeated bogus updates or hacked firmware that repeatedly writes to internally accessible flash or EEPROM. Similarly for CD-ROM drives.

It's possible to disable fans by software but many modern CPUs will automatically shut down when a too-high temperature is reached. Older CPUs did not have this protection but such motherboards also didn't have fan control.

  • 2
    About the CRTs: I think it was possible with older ones. I already had some of mine set to levels where the screen was a pure mess. I always turned off the screen because I was afraid of breaking it. Newer ones just showed the "out of range" error.
    – sinni800
    Jul 22, 2011 at 21:35
  • 2
    Donkey's years ago I wrote low-level code controlling the (mono) monitor's electron gun. I was concerned that if I got it wrong the beam scan would be restricted to a tiny spot in the middle of the screen, which could overheat relative to the rest of the glass, and shatter. It never did, but I sweated a bit! Jul 22, 2011 at 23:17
  • 5
    On the old gameboy and gameboy color, if you zeroed bit 7 of FF40 (LCD Enable) in any period except a vblank it would permanently break the gameboy's lcd screen. Aug 10, 2011 at 21:57
  • This was an issue in the mid/late 90s when configuring X on a linux machine with certain combinations of video cards and monitors and outputting a specific resolutions/color depths/frequency updates.
    – ivanivan
    Sep 13, 2017 at 14:21

Your power supply, if it explodes, won't do quite the same damage as the one in Die Hard. Sorry to disappoint.

An engaging article highlighting a variant of software causes hardware damage recently appeared in Wired regarding the Stuxnet virus. Software causing command and control software to physically damage nuclear centrifuges. It's just kind of amazing.

  • 2
    While this is a very interesting virus, and it's implications were very large, I would argue that Stuxnet is not what @MaxMackie was looking for. In that case, the software had physical control of a physical device capable of causing harm. I think he is talking about just a basic computer system causing harm to itself, not any devices which it has direct control over. That being said, the Stuxnet virus was damn amazing at what it did - +1. Jul 22, 2011 at 17:10
  • 1
    I kept chortling and shaking my head as I read that article. I know it's not what he was asking, but apparently I wasn't the only person who thought it at least had theoretical relations with this topic. Jul 22, 2011 at 17:24

Historically, there have been a few cases where hardware design flaws have made it possible to directly and immediately damage a machine. In one case, a single-line instruction could cause a computer to short-circuit and catch fire, IIRC. But the cases I heard of were on old 8 bit micros.

Apparently, the term is "Killer Poke", but I just turned that up in a quick Google.

I wouldn't be surprised if these things can happen in embedded systems with buggy drivers for hardware, but it should be difficult to achieve on the most common hardware platforms - firstly because direct access to hardware is controlled, and secondly because these problems should be unusual and very specific to exact hardware platforms anyway. For example, a blow-up-your-graphics-card poke will probably only work for a specific graphics card.

See - http://en.wikipedia.org/wiki/Killer_poke

EDIT - I haven't been able to find any references to 8-bit micros short-circuiting and catching fire from a killer poke - maybe this was just an urban myth I picked up along the way somewhere. But the notes about HCG (Halt and Catch Fire) CPU instructions ( http://en.wikipedia.org/wiki/Halt_and_Catch_Fire ) are fun... The Motorola 6809 processor was used in the Dragon 32, IIRC, so maybe that's what I dimly remember.

  • AFAIK "Killer Poke" as copy protection on Commodore 64 (8 bit) was real. Jul 23, 2011 at 19:48
  • @Peter - If there was a way to do permanent damage to the C64 hardware with code, it would probably have been mentioned in the Raeto West "Definitive Guide" book - I don't remember anything, but that doesn't mean much. I'd place bets that there were ways to do permanent damage to the floppy drive, but I never owned one of those.
    – user31438
    Jul 24, 2011 at 11:38

Aside from overstressing the hardware, there are firmware viruses, which could wreck hardware not by physically damaging it, but simply by making it inoperable (which might as well be "physical," since the hardware can no longer be used in any system).


I damaged a floppy drive once, programing an assembly code to move the head out of the usual limits. The drive stopped working, and I could do that with 2 other drives.

But lots of people doubt it at that time and I never gave attention to the subject again.

There is some discussion whether rewriting a BIOS (like old virus did) is physical damage, but many people (including myself) take this out of the problems you mention.


run a CPU so hard that the ceramic actually breaks

No, it is impossible to do anything to a CPU in software to cause "the ceramic [to] break". Although it is possible on some CPUs to change frequency or power control modes such that the die overheats, or to change outputs such that the transistors sink or source too much current (which depends how external components are interfaced); either of these will damage the silicon or the pads. The ceramic will be unaffected.

It is also possible on a CPU which has EEPROM configuration registers (sometimes called 'fuses') to brick the CPU. For example embedded processors (not x86 class as in the original question) with internal flash which provide code protect options or other options (for example, Microchip PIC) which, if set improperly, could cause the code to break (if code protect is on, and software is attempting to read program memory, it would return all zeros instead of the actual values). This would 'brick' the system and reprogramming using an external chip programmer could be necessary (maybe even removal from circuit board to accomplish this).


Most of us just write code for simple little computers and it's unlikely that this could happen. When you're interfacing with mechanical machines it becomes more likely.

Recently the worm Stuxnet was created to attack Siemens software that controls gas centrifuges which is used in the process of enriching Uranium. It would make the centrifuges spin at speeds designed to damage them.


Many years ago, I had a DAT (digital audio tape) drive set up as a computer backup drive. You could only write to it indirectly, via Retrospect (backup software). Then I found some software that let you actually mount the drive -- use it like a hard drive. It worked... for a few weeks... and then the tape drive burned out. The tape heads just weren't designed for random access like a hard drive, and all that slamming around back and forth wrecked them.

So yes, software can damage (or even destroy) hardware.


Once you get away from regular desktop computers, even non-malicious software errors can cause spectacular hardware failures:

  • The Mars Climate Orbiter - over $500 million spent on misson, destroyed by a metric-to-imperial conversion error.

  • Ariane 5 Flight 501 - destroyed by an integer overflow bug, resulting loss of rocket and onboard spacecraft costing more than US$370 million.

  • Two $150million F-22 Raptor aircraft crashes - by different bugs.

  • Bugs in the FADEC software of the Chinook helicopter were at least partly to blame for the crash of ZD576 and death of 29 people.

  • One of the early moon shots went astray because of a coding error in the nav software. A missing *, IIRC. Mar 6, 2013 at 12:25
  • Let's not mention the aircraft that flew perfectly upside-down as soon as they crossed from one hemisphere to the other. May 8, 2016 at 20:20

Mandrake Linux had a bug with LG CDROM years ago http://www.linux.com/archive/feed/32318 . The bug was famous at moment.


It partially depends on the constraints imposed on the hardware when it was designed. If the computer is attached a bomb that it was designed to set off, you can probably pretty effectively destroy the hardware with software. Prevent direct access to the detonator, however, and the hardware is safe.

To damage hardware, with software, you'd need:

  • hardware that is capable of damaging itself
  • a way for the software to control that capability (ex: a UI, API, low level access, or bugs in access restrictions)
  • a way to modify/manipulate/install/execute software

Yes, at least for poorly designed hardware. However, modern hardwares have to comply with various safety regulations, which limits their ability to damage itself. Modern CPU will shut off when overheating, modern Harddisk/CD/DVD/Bluray drive have predefined speed, etc; there are all kinds of safety mechanism put in place by hardware manufacturers to prevent faulty software (including faulty drivers and firmware) from damaging the hardware.

While these safety mechanism are in no way foolproof, it is very difficult to damage a well-designed hardware by software alone. The most that software can do is to use the hardware in a way that will optimally increase its wear.


The most straightforward way to damage hardware is in the case of embedded systems, where you can access the individual pins of a microcontroller. You can just set an input to be an output or vice versa, and cause a short circuit. The only way I can imagine this being useful to damage PC is if you have access, and are being able to modify to the firmware of some of the hardware components.


Certainly it's possible to cause damage on many systems, if you can get into the BIOS level controls. Simply turning off the fan and then running a compute-intensive program will cause damage on many systems (though some contain hardwired thermal limiters). In some systems you can adjust voltages via program, etc, and in a few you can adjust processor duty cycles and the like. (This is especially true of laptops, where there is often extensive power control logic.)

And of course with older monitors there were ways to damage them by providing the wrong refresh rate, or even just shutting off the video entirely. (Most modern monitors contain self-protection logic.) And, as someone mentioned, on some floppy drives you could cause damage by driving the head beyond its limits. (I've encountered this problem.)

I had a Nokia n97mini phone that had its display damaged from overheating, when the CPU got caught in a tight loop and overheated. The heat caused the layers of the display to separate. I would guess that other phones have similar hazards.


Only if hardware is badly designed. For example software controls speed of electric motor by changing voltage, however motor is designed in the way that it will be burnt out if highest voltage used over 1 minute. You can imagine that software can easily exceed this limit. However if the motor has specific circuit cutting current if its temperature hits certain limit, then motor will survive whatever software is trying to do.

Returning to my some other post where I blamed Windows 7 + Dell BIOS capable to toast a hard drive.


Years ago I read a book about computer viruses and the one that caught my attention the most was the Turkey Virus which could actually kill hardware.

One variant of the virus would focus the beam in a CRT monitor such that it would burn it out. By burn it, I don’t just mean phosphor burn-in, although that was a side-effect, but the electron gun would fail, leaving the monitor completely dead.

Another variant of the virus would perform mathematical calculations in such a way that it would overload the co-processor and cause it to burn out.

Of course this was some time ago in the days of older hardware that was susceptible to this sort of attack. Thankfully, modern hardware is generally designed to prevent it, but that’s probably not going to stop someone who is determined enough.

Also, it would be relatively easy for a virus to kill the BIOS. There’s a reason that BIOS flashers always warn you not to turn off or reset the system during the flashing; it’s because an incomplete write would leave the BIOS corrupted, and since the BIOS is the Basic Input Output System of the computer, corrupting it would render the system inoperable. Once upon a time, the BIOS could only be flashed from pure DOS mode, but Windows flashers have existed for some time. There is nothing stopping a virus from writing some bad stuff to the BIOS and thus killing the system. CIH / Chernobyl did exactly this in 1999.

Luckily, some motherboards come with dual BIOSes so that the backup can be used in case of corruption of the primary, and others make it possible to reset or re-flash a corrupt BIOS, but not all do or can.


Generally the answer is software cannot damage hardware. However there are exceptions....anybody remember when software on the original IBM-PC could damage either the Monochrome adapter board or monitor? That was definitely an eye opener.

Software in many cases now has hardware control of devices attached to it therefore malfunctioning software can cause damage to the physical hardware.


A term relevant to this is the "killer poke" which describes putting a value in a register (the "poke" instruction) that the hardware could not tolerate. The Wikipedia page for "killer poke" lists several examples.

Early hard drives could suffer all kinds of damage. The read/write heads could sometimes be moved so far beyond the platter that they hit the spindle axis or the casing. This could either damage the read/write heads or cause them to go out of alignment.

Modern ink printers and scanners often have a limiting switch only on one side of their printing head's or CCD bar's track. Only firmware protects them from moving outside their intended range (and driving into things). Theoretically a firmware update could be engineered that not only bricks such a device, but also causes physical damage.

There are soft "killer pokes" as well. A hard drive's lifespan can be considerably shortened by maximizing stress and heat. Incidentally, Windows ships with such a "feature" - if you create more than one software RAID partition on an HDD, when the RAID needs to be synched (after an unexpected restart, for example), all partitions will sync at the same time, moving the drive heads forth and back between extreme positions at maximum speed, likely for multiple days since throughput in this state is minimal. SSDs, on the other hand, would need sustained maximum writes to fail early.


The older BBC Microcomputer came equipped with a relay which was used for starting and stopping a tape drive. Generally, you would enable the relay via a command before loading a program, and disable the relay afterwards.

When enabling or disabling the relay, there would be a loud audible click from inside the case, and rapidly toggling the relay state would generate a buzz. Different frequency of enabling and disabling would generate different tones of buzzing. You could then use this to play a tune.

The relay wasn't designed for so many power cycles however, and doing this could and would eventually damage the relay beyond repair, making the computer's owner go out and buy a new one which would have to be physically soldered onto the motherboard in replacement of the old one.

I learned this via personal experience, however didn't ever replace the broken relay as i had a disk based system and toggling the relay was purely for amusement.

If i recall, there were even warnings against this in the programmer's reference manual that came with the BBC Micro...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .