Was it possible to cause persistent changes to a mid-1980s IBM-PC using POKE in GWBASIC?

Question

TL;DR: Using the DEF SEG and POKE commands in GWBASIC, was there any way to make changes to an IBM-PC compatible computer that would (a) persist even after a reboot and (b) cause an increase in crash frequency, thus effectively damaging the system?

This is probably a totally stupid question with a straightforward answer (presumably it's going to be "No, there's absolutely no way you could damage a PC in that way!"). But the question has haunted me for about 35 years now, and I need to put my mind to rest at last. So please bear with me...

When I was a kid in the mid-1980s, I learned that you could the POKE command in GWBASIC to write directly to the display memory of a computer. However, it was first necessary to use the DEF SEG command to select the memory segment containing the display memory. The address of that segment was not available to me, so I came up with a brilliant idea for an algorithm to find that segment address:

1. Use a FOR loop to iterate through all possible memory segments
2. Flood the current memory segment with random characters using another FOR loop in combination with POKE
3. Manually interrupt the program as soon as random characters started appearing on screen
4. PRINT the variable containing the current segment address

Needless to say, the algorithm didn't work. All it achieved was make the computer crash. The unending series of speaker beeps that accompanied the crash was absolutely frightening to the impressionable kid that was me. I was convinced that my program must have been very dangerous, and I was also convinced that the computer never fully recovered from what I had done to it, even after numerous reboots and power-offs. I firmly believed that there were now frequent random crashes and software failures, something that had never occurred before. This was particularly awkward as the PC was my dad's work computer that I was only allowed to use occasionally – I felt horribly guilty thinking I had broken this expensive piece of equipment for good with my stupidly dangerous program.

From my adult perspective, I'm pretty sure that all that my POKEs did was overwrite some essential part of MS-DOS or the GWBASIC interpreter itself – nothing that wouldn't have been restored after the first reboot. The weird behavior that I believed to observe back then was probably nothing but selection bias: Since I thought at the time that I had done something potentially harmful, I attributed any crash afterwards to my GWBASIC program, ignoring that MS-DOS and the programs running on it at the time weren't exactly robust despite the simplicity of the architecture.

And yet, whenever I think about that anecdote, there's still some lingering doubt. What if the increase in crashes hadn't just been my imagination – what if my program accidentally modified some BIOS settings (e.g. for memory refresh rates or something along these lines), and what if these BIOS settings were stored in CMOS RAM? Then, perhaps these modified settings could indeed have been persistent between reboots, and they could indeed have been responsible for a general system instability.

So, to sum up: Was there any way that my GWBASIC program that used POKE and DEF SEG to write to random memory segments made a persistent change to the computer, a change that increased the probability of system crashes?

Answer 1

Assuming you started at segment 0, you overwrote the interrupt table, and the next time an interrupt occurred (probably the timer interrupt), the CPU would jump to something which was in all likelihood not meant to be executed, leading to a crash.

As far as causing permanent harm, that would be extremely unlikely on an 80s PC or compatible. On old PCs, there’s no memory-mapped I/O, all access to hardware devices or anything other than memory involves specific I/O instructions. This includes CMOS for PCs that had CMOS storage (the very first PCs didn’t).

For lasting changes to occur, your BASIC program would have had to somehow cause I/O code to run, and have that code do something damaging. The odds of that are extremely small, dare I say negligible.

See the PC memory map for details of what your program could have modified.

Answer 2

Extremely unlikely, but certainly possible with a probability larger than 0.

For example the memory could be altered in a way that the crashed program ends up executing a piece of code somewhere that writes something to somewhere on the hard drive. Or anything else like writing something to somewhere in the BIOS settings RAM.

Unlikely anything in the hardware would be permanently damaged. Like crashing floppy or hard drive heads when moving them over their limits. And extremely unlikely to accidentally reprogram video card sync timings in a way that would blow up the CRT flyback transformer.

BIOS settings RAM is checksum protected, and corrupted file systems can be repaired with data loss, so reinstalling DOS and programs is possible. So likely you did not cause any hardware damage.

Answer 3

If the PC in question is an IBM "portable", then yes.

Causing permanent hardware damage via software is in fact called a killer poke. The stereotypical example was some early 8-bit systems that allowed you to stop the CRT (monitor) electron gun in one place, potentially burning out that area of the screen (or in extreme cases, burning a physical hole in the glass).

By the time of the PC most monitors had checking to prevent this. However, the IBM 5155, a "portable PC" released in 1984, apparently had this problem.

Answer 4

A well-prepared attacker can use POKE commands the following way to install custom software (a virus) which persists after a reboot, like this:

• On another computer, write a program B in assembly language, compile it to machine code bytes.
• On another computer, write a program P in assembly language, compile it to machine code bytes, print those bytes in decimal (suitable as arguments of the POKE command).
• Use POKE commands to write the machine code bytes of program P to some unused temporary part of memory (even video memory works), at address PA.
• Use POKE commands to modify the interrupt vector of the timer interrupt to PA.
• A few milliseconds later, the timer interrupt kicks in, and the computer starts running program P.
• Program P does the following: it uses BIOS interrupt INT 13h to read and write the boot sector of the floppy disk, and then reboots the computer. Between the read and write, it modifies the boot code (as machine code bytes) witin the boot sector to program B.
• The computer reboots, and as part of the boot process, it reads the boot sector from the floppy disk, and executes the boot code, which is program B written by the attacker. This is persistent, i.e. it happens each time the user turns on the computer with that floppy disk inserted.
• Program B does the following: keeps itself in memory, changes some interrupt vectors (such as the timer interrupt) to get its code triggered when needed, continues the regular boot process (i.e. reading the files IO.SYS and MSDOS.SYS from the floppy disk, and continuing running MS-DOS).
• Code of program B is triggered later like this:
  • From time to time it displays a prank message on screen.
  • From time to time it makes the computer crash.
  • When another floppy disk is inserted, it copies program B to the boot sector of that floppy as well the same way (BIOS interrupt INT 13h) as above.

Assembly programs are very fragile on old 1980s PCs, especially on those which are incompatible or partially compatible with the IBM PC. Thus the first attempt of the attacker will likely fail, i.e. program P would fail to write to the boot sector of the floppy disk, or the program B in the boot sector would fail to boot MS-DOS, effectively causing a boot crash loop until another boot floppy is inserted. However, after lots of frustrating iterations (with very limited tools for live debugging), it can eventually succeed.