22

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?

5
  • 3
    I don’t know about PCs but I remember a warning in the RML380Z manual. I don’t recall the specifics but I believe it was to do with the high-resolution graphics controller; if incorrectly configured it could result in the controller and the CPU both trying to drive the address but at the same time and this could cause hardware damage.
    – Frog
    Sep 14 at 20:07
  • 1
    I have a funny image in my head that, if you poke a value into a ROM location enough times, it will change :-)
    – paxdiablo
    Sep 19 at 12:11
  • If GW-BASIC or any other language could make a 'persistent' difference, how could that work? Don't 'persistent' changes mean ROM, not RAM POKEs? Didn't ROM POKEs require special software then, even more than they would now? Sep 29 at 19:18
  • @RobbieGoodwin really special software — even in the late 90s most PCs , if they used EPROMs rather than real ROMs, didn’t have the hardware necessary to rewrite them. Sep 30 at 18:51
  • How did EPROMS come into this, please? Sep 30 at 21:06

4 Answers 4

20

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.

6
  • 7
    I didn't know that the CMOS was also accessed by I/O ports, so that eliminates the only possible way of permanent harm that I could think of. Oh, and I would have paid serious amounts of pocket money for something like the "PC memory map" back then...
    – Schmuddi
    Sep 14 at 22:02
  • You could poke nonsense into the video controller. I'm not sure if there's an equivalent of C64's poke of death or not.
    – Joshua
    Sep 16 at 16:54
  • @Joshua care to elaborate? Sep 16 at 18:39
  • I've heard too many stories about getting the video card into bad video modes that would blow up old monitors if they were left in them too long.
    – Joshua
    Sep 16 at 18:44
  • 2
    @Joshua yes, but not by using POKE. To mess up a video card you need to write to its registers. Sep 16 at 18:47
14

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.

8
  • 2
    I think the storage-related points can be safely ignored: The computer didn't have a hard drive (way too expensive at the time), and a being completely disk-based system, installing or reinstalling software wasn't really a concept. With regard to video sync timings and moving drive heads to extreme limits: I think these were controlled by writing to I/O ports, not to memory, so that shouldn't have been a possible way to damage such a computer using POKE either.
    – Schmuddi
    Sep 14 at 21:52
  • 2
    But poking to memory corrupts memory, and sometimes the address what to execute is read from memory (return address from stack, interrupt vector; subroutine pointer) so code execution may go to some random address which can contain any code which may do anything. The code might end up executing the actual drive seek or display init code that writes to IO ports, with garbage data in registers. So definitely possible, but unlikely.
    – Justme
    Sep 15 at 4:14
  • 2
    There was a hardware ruiner in 386 era PCs that you could do by seeking the 3 1/2" floppy past track 80. If the hardware didn't handle tracks 81 and 82 the drive could be destroyed.
    – Joshua
    Sep 16 at 16:59
  • @Joshua have you ever actually seen a floppy drive destroyed in this way? I’ve seen heads knocked out of alignment by repeatedly seeking too far in some drives, but that can be fixed (laboriously). I’ve always wondered whether it was actually possible to really destroy a floppy drive like that... (I don’t think there’s ever been a virus which did this, which is perhaps a clue that it isn’t actually possible; if it were, given some virus authors’ destructive tendencies, there would likely have been one.) Sep 17 at 12:59
  • I have seen a short-circuit in a floppy drive set fire to the PC it was in, which counts as rather extreme permanent change to the hardware, but that wasn’t caused by software. Sep 17 at 13:00
10

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.

10
  • 5
    I know it’s Trixter telling that story, and who am I to contradict him, but it’s far more likely that the 5155 “killer poke” is really a “killer out”. Writing to memory, even CGA video memory, doesn’t change CGA settings; but writing to CGA registers can, and GW-BASIC can do that too (using the OUT instruction). Sep 15 at 15:03
  • @StephenKitt - Perhaps. As the first sentence on the WP link explains, "Killer Poke" is a bit of a term of art and doesn't have to be a literal BASIC POKE command (nor does it actually have to kill anyone). But this is clearly the kind of thing being asked about.
    – T.E.D.
    Sep 15 at 15:14
  • Yes, I wasn’t commenting on the “killer poke” terminology specifically (although my comment does look like I am), only the POKE reference in the 5155 story — that’s what ties it to the question as stated, and I think it’s incorrect (which would also make the start of your answer incorrect; again, in the context of the question which I understand as being specifically about POKE). Sep 15 at 15:26
  • @StephenKitt - I suspect it applies there too though. Its seems likely the OQ really just wanted to know if it was possible to do this kind of thing from BASIC, and specified "POKE" and "DEF SEG" because those are the commands they know about for doing that kind of thing. Classic requirements analysis problem of specifying an implementation rather than a requirement.
    – T.E.D.
    Sep 15 at 15:42
  • 2
    No, my question is very specific: All I want to know is whether what I did at the time had the potential of causing persistent harm, and that means: Using POKE and DEF SEG. I've done my fair share of low-level video programming in MS-DOS to know about registers, and I was aware back then of the story that manipulating CRT retrace timings was capable of causing actual damage to the monitor. But still, thanks for your answer!
    – Schmuddi
    Sep 16 at 7:13
5

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.

1
  • 1
    May I point out that the likelihood of this happening as a result of the program described in the question is about as good as one being able to type a dictionary by spilling coffee on their keyboard. Still, interesting read. Sep 25 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.