Talk:Killer poke

Wanted: PET killer poke details

I have a question: How exactly did the PET poke damage the CRT monitor? --Anonymous 14:02, 28 October 2005 (UTC)

Thanks for asking! I will describe this in detail in the PET article itself shortly. Stay tuned. :-) --Wernher 02:20, 30 October 2005 (UTC)

It will set the length of line display line to be shorter. This would adjust the horisontal trace to be with one with higher frequency. This frequency is also driving the anode transfomer and thus increase the CRT anode voltage. Too high voltage that the tube will go ZIP at some time after this.

This is not limited to CBM PET HW, but you have do the same with at least with SVGA and VGA cards and NON MULTISYNC analog vga or even SVGA monitor. ( Some SVGA monitors may refuse to sync with wrong freqency to would turn of the tube. )

Multisync monitors turn the amplitude down, and thus end up not increasing anode voltage. — Preceding unsigned comment added by 193.184.83.230 (talk) 09:54, 19 April 2012 (UTC)

The article cites the damage must be physical then elaborates to advise that is should be permanent and irreversible - these seem unrelated definitions and serve therefore to confuse the issue (for me at least). Reading the article I cannot tell if I have even been the executor of a killer poke or not!

On the microbee computer one could poke to start ones basic code on startup, and one could poke to disable the keyboard handler, as the RAM was battery backed, one could effectively "brick" the unit by combining these into a 2 line BASIC program. When I tried the only solution was to remove the very large soldered on battery by sniping its leg and then resoldering the broken wire back together.

Though this was not a change of hardware it effectively required the hardware to be modified to restore the unit operation, it rendered the unit non-functional yet it could be repaired as cited. —Preceding unsigned comment added by 60.242.17.174 (talk) 15:30, 2 November 2007 (UTC)

About the note...

Could someone please add an explanation for the note ("Any system that meets Popek and Goldberg virtualization requirements is immune (or can be made immune) to any killer poke."). I don't understand, why this is the case, so I think an explanation would be useful for the readers of this article.

I just changed it by removing the "is immune" part, and I'll add an explanation now. Rbarreira 08:13, 11 July 2006 (UTC)

Virtual memory should be enough

It seems to me that meeting the mentioned virtualization requirements is more than is needed to protect against killer pokes. While it is true that a properly virtualizable machine can be protected from killer pokes, so can any virtual memory system with memory protection, which protects memory-mapped registers from unprivileged code, either by preventing unprivileged writes or by simply not mapping the registers into the code's virtual address space. Of course, this can be bypassed if the code is running without memory protection and outside a virtual address space (like device drivers or x86 real mode applications) or is somehow able (perhaps by mmap or a similar facility) to map the sensitive registers into its virtual memory space with privileges to write to them. Port-mapped I/O could conceivably also produce similar effects to a killer poke, but this is technically not a poke, and port-mapped I/O operations tend to be privileged anyway. —71.39.6.137 06:54, 25 August 2007 (UTC)

TRS-80 MODEL III

I corrected the reference to 80/40 characters to the correct values of 64/32 but the fact the original author had this bit of information incorrect makes me suspicious that he/she also has the whole thing wrong. We used to run programs that would toggle the display (PRINT CHR$(23) if I remember correctly) and although on the Model 1 you would hear a relay chattering away I never heard of any damage on a Model 1 nor a Model III machine.

This particular problem is doubtful.

(I had heard of a program that could jack up the floppy drive by continually running the head to step up... but again... nothing ever confirmed.)

Dcsutherland (talk) 10:15, 27 June 2009 (UTC)

Well, first off, both the Model 1 and Model III had the video control and cassette relay hooked up to I/O ports which are not memory mapped. No poke can change them directly and changing BASIC's in-memory shadow of those registers will, at best, cause a momentary change. The video display has no relay, but the relay that controls the external cassette motor is on the same port. Thus a careless program might activate it when changing video display modes.

An OUT command in BASIC could flip the relay continuously which is bound to wear it out. Not as dramatic as a single POKE to kill hardware but maybe that counts?

Changing video modes rapidly does scramble the display but I seriously doubt it could kill the monitor.

The TRS-80 Model 100 was alleged to have some killer poke that would damage the hardware, but I've never seen it verified.

Gp2k (talk) 03:27, 31 January 2011 (UTC)

IBM PC

The term is used especially of various fairly well-known tricks that can overload the analog electronics in the CRT monitors of computers lacking hardware sanity checking (notable examples being the IBM PC [...] ) [...].

We need proof for the IBM PC being poke killable. --Abdull (talk) 11:33, 9 December 2007 (UTC)

IBM PCJR

In my computer programming class freshman year of high school (1986), we had a lab of PCjrs. We programmed in Pascal. Anyway, there was a "motor" command that if placed into a tight loop would make the computer emit a sound similar to placing a playing card in the spokes of a bicycle tire. One day, I snuck into the lab and set up all the PCs to execute the loop, resulting in noise so loud it was heard outside the room. Needless to say, I received saturday detention for this. I think this is related to the Acorn tape thingy mentioned in the article. Anybody else heard of this? —Preceding unsigned comment added by Zenotek (talk • contribs) 20:59, 30 July 2008 (UTC)

A similar concept, but not necessarily related to the Acorn tape loop and not really a killer poke. We did something similar in class with the Apple IIe where we would sit at one station and program it to start making an endless raspberry fizz-type noise after including a delay long enough to safely get away from the machine and avoid all suspicion. Twalls (talk) 22:00, 30 July 2008 (UTC)

i remember downloading a program for my c64 back in the day that would make my 1541 floppy drive actually play a song by somehow vibrating the read/write head at different frequencies. again, not really a killer poke, but that couldn't have been good for the drive's health :) --Kvuo (talk) 04:22, 13 October 2008 (UTC)

the Amstrad CPC 464 8-bit computer had a built-in cassette tape drive which could be controled by turning a specific bit on an I/O port on and off. I wrote a program which did exactly that in an endless loop. It didn't take long to realize that this could damage my precious computer so I stopped :) —Preceding unsigned comment added by 93.86.225.127 (talk) 06:24, 2 September 2009 (UTC)

Citations please...

Any documentation on this? Beyond blogs? —Preceding unsigned comment added by Otterfan (talk • contribs) 17:22, 14 June 2009 (UTC)

Linux bricking Intel network adapters

A couple of years ago, Linux users who were using bleeding-edge kernels started seeing their Intel e1000e gigabit ethernet adapters die. Some users were able to re-flash the firmware on their adapters, but many adapters were permanently destroyed. It took a long time for kernel developers to discover the source of the problem, which is documented in this article on lwn.net: http://lwn.net/Articles/304105/

Given the profile of the problem and the scintillating complexity that caused it, I think it deserves a mention in this article. Naptastic (talk) 04:57, 15 June 2010 (UTC)

Samsung UEFI bug

What about the bug found in some Samsung Notebooks where the hardware could be destroyed by software? I guess it's an exmaple from present-day time. — Preceding unsigned comment added by 217.247.82.17 (talk) 14:26, 20 May 2013 (UTC)

"El Cóndor Pasa" video is from emulator :)

This is NOT from the real thing! Maybe it would make sense to mention this in the article? The floppy motor sounds as if it was reading a very worn-out disk. And yes, i can recall these sound samples! They were recorded by user hal from English Amiga Board and are now part of WinUAE. So if you think that's the real thing playing E.C.P., you're wrong. :) -andy 77.190.40.209 (talk) 02:50, 6 February 2014 (UTC)

Commodore 1541 statement that it is a dumb drive is entirely false

The 1541 actually has it's own CPU and operating system (firmware). It was the Apple 1 / Apple 2 drives of that time period that were entirely dumb. The Commodore drive could be forced out of alignment by repeat reset commands from a host - but that's not much different than a host computer forcing a printer to jam up in some way (most printers of the era had no tray full detection/etc).

An example of how the 1541 drive can copy disks without the host computer even turned on: http://en.wikipedia.org/wiki/Fast_Hack%27em — Preceding unsigned comment added by 97.77.97.146 (talk) 15:44, 21 August 2014 (UTC)

Game Boy section

In "Game Boy" section: "The Game Boy's LCD screen can be turned off by game software. Doing so outside of the vertical blanking interval can damage the hardware.". There seems to be no confirmation of this statement outside of Pan Docs. Official Game Boy programming manual mentions that doing so (turning LCD screen off outside of the vertical blanking interval) can leave horizontal black line on the screen, but do not mentions any hardware damage. 84.244.22.100 (talk) 12:27, 17 March 2015 (UTC)

It's me again. I decided to remove this section from page until there are any evidence or official sources for this. 84.244.21.4 (talk) 14:44, 24 June 2015 (UTC)

iPhone epoch 'brick' issue

Hi there. Plenty of references out there state that the iPhone epoch hack will 'fix' itself when the battery is allowed to discharge and 'die'. I'm not about to update the article as I have a WP:COI there, but someone should look into that ... - Alison ^❤ 03:25, 19 February 2016 (UTC)

FurMark?

Could it be considered to be another method of inducing killer pokes (i.e. on GPUs)? Well since it stresses the GPU to the point of blowing up hardware components by running intensive fur simulation stuff, one case being a certain user's GTX 295 having its VRM circuitry damaged after a stress test. Blake Gripling (talk) 06:12, 19 June 2016 (UTC)

2017 Linux bios bug

In 2017 Ubuntu 17.10 had a problem [1] where some sort of Intel hardware drivers caused a number of buggy Lenovo laptop models to flash their BIOS and render it nonfunctional (though UEFI still worked). Supposedly, the actual change to the bios was very small but one of the very few surefire ways to fix it was to replace the physical chip.

Would this be considered an example/notable?

SougonNaTakumi (talk) 10:47, 13 March 2018 (UTC)

Metroid on NES

Apparently on the NES title Metroid, typing the password "ENGAGE RIDLEY MOTHER FUCKER" caused a software bug that can crash the console, and in some cases, permanently damage it. This may be worth looking into a little more Tomrow (talk) 18:39, 25 February 2020 (UTC)