C dangerous?

A

Alan Balmer

While I have not personally encountered it, a virus existed which tried
to overwrite the BIOS of PCs which allowed BIOS upgrades without setting
a jumper on the motherboard. I'm not sure if this should be counted as
hardware damage, but it certainly had the effect that affected PCs
wouldn't boot.

One such was the CIH virus. It had a peculiar quality - it killed
Watcom-compiled programs, providing lots of warning before the
intended payload struck. I first encountered it as a problem report by
one of the major game development companies - they discovered it on
the Friday before the Monday release of a new game. I decided it must
be a virus, then we confirmed it by comparing executables on CD with
those on the hard disk. They got a brand new computer (did *not*
connect it to the network) and transferred their source to it so they
could burn the release master.

It was a fun weekend.
 
G

Gordon Burditt

Has anyone encountered a virus that actually harms the hardware of the
host computer? The virus-engineers usually quite clever when it comes
to malicious code.

(and I don't mean in an indirect way, e.g. annoying the user beyond
sanity so the user assualts the hardware from pure frustration)

Assuming you can solve the *VIRUS* part, the "harms the hardware"
part is fairly easy to construct for a certain class of hardware:
bombs, missiles, etc. that are *SUPPOSED* to blow up, but not
necessarily right now. It is also likely easy to screw up
safety-critical systems on board aircraft, automobiles, spacecraft,
or controlling nuclear reactors. That's why they are called
safety-critical.

I do know, and personally witnessed several times and caused at
least once, that an old TRS-80 monitor would start to smoke if you
had the TRS-80 connected to an in-circuit CPU emulator and did not
permit the startup ROM to initialize the video circuitry with
reasonable timing. (The emulator would power up with the CPU paused
just before executing the first instruction if you didn't tell it
to do otherwise) If not corrected within a few minutes, you had a
dead monitor, and a horribly-smelling room. I think you could
accomplish the same thing by removing the CPU chip and powering it
up. I believe that certain early PC monitors (e.g. 1984) also had
the same problem if given strange video frequencies.

Although no one ever tried it to my knowledge, explicitly setting
the video circuits to their power-up values would probably have
accomplished the same thing deliberately - and since TRSDOS ran
completely unprotected on a Z80 with no hardware memory protection
and no privilege required to do I/O instructions, if you could get
a user to run your program, you're able to fry the system. However,
the community of TRS-80 users wasn't connected well enough to really
make a virus workable.

XFree86 warns of possible hardware damage if you attempt to drive
a monitor beyond its capabilities, for example, 1280x1024 @80Hz on
a monitor only designed to do 640x480 @60Hz. I believe that modern
monitors are protected to the extent that they won't self-destruct. But
if they do, I won't be responsible for replacing your monitor.
This leaves open the possibility that hardware damage can be caused by
a few keystrokes or mouse clicks in the monitor configuration section
of your OS GUI.

On a modern PC there are probably a few things that can be done to
at least reduce the life of the hardware:
- Repeatedly spin up and spin down the hard drive.
- Shut off all the software-controlled fans.
- Run the CPU in a continuous infinite loop (e.g. SETI@HOME) for maximum heat
- Repeatedly power-cycle the motherboard, by setting an alarm for it to
wake up, then shutting off power.

There are a number of things that, while not necessarily "hardware damage",
would probably cause you to return your system to the factory for repair
or junk it, as a normal OS re-install wouldn't fix it:

- re-flashing the BIOS with nothing but HALT instructions.
- loading garbage firmware into devices such as hard disks, wireless network
cards, CD-ROM drives, etc.
- reformatting the hard drive with a strange format with, say, 387-byte
sectors.

Now for the C relevance: all of the above *MIGHT* be done
with the following program:

#include <stdio.h>
void main(int argc, char **argv)
{
fflush(stdin);
exit(0);
}

Gordon L. Burditt
 
M

Mark McIntyre

Dennis wrote me back and I'm not quite sure I understood what he was trying
to say so I'll post his response. Maybe someone will understand better.
/* Dennis's response */
At least some graphics cards were able to
destroy a monitor if the settings were wrong
enough.

I can vouch for this one - one of the early Linux drivers for the matrox
cards toasted my monitor.
/* End Dennis's response */

Does anyone understand this a little better than me?

Dennis response says
"Sure, but you can break your computer with pretty much anything - perl, a
bad driver, a cup of coffee, your spouse, children (esp when linked to jam
sandwiches) so why worry about C in particular?"
 
M

Martin Dickopp

Alan Balmer said:
One such was the CIH virus.

Yes, that's the one I had in mind; I just couldn't remember its name
(and was too lazy to google for it...).

Thanks!
 
M

Mark McIntyre

On Tue, 17 Feb 2004 15:28:25 -0500, in comp.lang.c , "Bill Cunningham"

(silly stuff)

Bill, given that you've been around in CLC for at least a year, and yet you
ask questions like this, I have to ask: Are you a Troll?
 
M

Mark McIntyre

I am not sure if you're joking or serious here. Did it really happen? If
it did... well, I never... That code crashes the hard disk????

In fact it should only crash the OS - it exploits a silly bug in the Win32
console handler -(if you backspace beyond the left margin, it indexes an
array with a -ve number and blammo. If it crashed RJH's disk then it was
a fluke.
Seriously, I
don't even see undefined behavior in there.

It creeps in when you have tabs set to 4 and backspace 5 from there...
Actually in some ways quite a cool example of it.
 
M

Martin Dickopp

Richard Heathfield said:
Of course I am!

Let's see what the standard has to say. 5.2.2#2:

Alphabetic escape sequences representing nongraphic characters in the
execution character set are intended to produce actions on display
devices as follows:

[...]

\b (backspace) Moves the active position to the previous position on
the current line. If the active position is at the initial position
of a line, the behavior of the display device is unspecified.

[...]

\t (horizontal tab) Moves the active position to the next horizontal
tabulation position on the current line. If the active position is
at or past the last defined horizontal tabulation position, the
behavior of the display device is unspecified.

Given this specification and that it is not specified where the "next
horizontal tabulation position" is, I think that the program could cause
unspecified behavior of the display device.

However, the disk is no display device, therefore I'd say if the disk
failed, the implementation is non-conforming.
 
B

Bruno Desthuilliers

David said:
Bill Cunningham wrote:

[snip - how to destroy your computer]
/* Dennis's response */
At least some graphics cards were able to
destroy a monitor if the settings were wrong
enough. And of course you can overwrite your
disk, but that's different.

However, it's likely that these things could
be done in Perl as well.


http://www.duk0r.net/matrix/107.jpg
Nasty boy... Now I'll have to clean up my keyboard (it does not drink beer).

So this was the proof that Perl can damage hardware !-)
 
R

Rob Thorpe

Bill Cunningham said:
I read an article in a book about Perl and Common Gateway Interface and it
mentioned C. It said that C could damage your computer. I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset. I sent Dennis Ritchie and email. I don't know if he'll respond if he
gets it. Sometimes he does sometimes not. How can C damage your computer?

Bill

There are many ways to damage your computer with software. Under
Linux if you edit your XFree86 config file incorrectly you can blow up
your monitor (I've only suceeded in making mine make funny whining
noises).
I think there might be bit patterns you can put in files that will
blow up the laser in your CD writer if you try to write them to CD.

When people say C is unsafe they mean that it's easy to make mistakes
that introduce bugs and security flaws into your software. Especially
if you're new to it or haven't had to write bulletproof software
before.
 
J

Julian V. Noble

Bill said:
I read an article in a book about Perl and Common Gateway Interface and it
mentioned C. It said that C could damage your computer. I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset. I sent Dennis Ritchie and email. I don't know if he'll respond if he
gets it. Sometimes he does sometimes not. How can C damage your computer?

Bill

It is not C, per se, as someone else mentioned, but any language
that lets you overwrite memory. Protected memory systems offer some
--well, protection-- against this by setting a permission level and
detecting attempted memory stores outside the bounds permissible for
that level of access. It doesn't work 100%, though, and can be
circumvented by a clever enough programmer. And it can happen by
accident, especially with over-complex and error-prone OS's like
M$ WinDoze.

In my case, a crashing program (I think it was written in C, but it
surely had some assembler) overwrote the CRAM that stored the settings
on my computer. Naturally I had never thought of writing them down.
And in those days there was no plug-n-play: the OS had to have stored
details about the hard drive, etc. Once that all was erased, I had
the dickens of a time getting everything working again. And that was
in the days when a decent machine with 4 Mb Ram and a 30 Mb hard drive,
running at 25 MHz, cost $3K. So I recall spending a very interesting
day on the phone with Gateway. Tod do them justice, the guy was very
conscientious about looking up the data on my obsolete (it was 2 years
old) computer and instructing me how to reset the CRAM.

Fortunately computers are better designed nowadays, and I don't think it
is possible to turn up the brightness on a CRT enough to burn out the
cathode or make a hole in the phosphor (it surely used to be possible).
I don't think a runaway program can plow up the ferrite coating by
grinding a disk head against it. The display has safety hardware to
prevent this, and drives do also. There would have to be an improbable
cascade of failures before a bad program could chew up a computer.

The worst that can happen is that it might reconfigure your machine
in unpleasant ways, since I think the configuration settings are
still programmable (otherwise you couldn't set them by hitting F2
or whatever during the bootup). This is inconvenient, but not
necessarily catastrophic. And of course you can print them out
by invoking the configuration program and hitting Shift-PrtScrn.
The Gateway guy taught me that trick after my fiasco. I now do
it on every new machine I acquire (even if it has a sytem restore
partition on the hard drive).

--
Julian V. Noble
Professor Emeritus of Physics
(e-mail address removed)
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/

"God is not willing to do everything and thereby take away
our free will and that share of glory that rightfully belongs
to us." -- N. Machiavelli, "The Prince".
 
C

CBFalconer

E. Robert Tisdale said:
.... snip ...

Did you get his permission to post this response?

Go away. Go far far away. Do something relatively nice like
pulling wings off flies.
 
C

CBFalconer

Richard said:
Bill Cunningham wrote:



That wouldn't make them any safer.

BC has a mental disability, which comes and goes. He has told us
this himself just once. He never gets annoyed, or flames.
 
C

CBFalconer

Nick said:
.... snip ...

Unless it has access to the assembly instruction
"HCF" - halt and catch fire :)

That is a privileged instruction. It is only available to
Microsoft over any network link, and only since they promulgated
their XP EULA. You did read that with care? So you realize that
any use of non-approved software or failure to upgrade on demand
may invoke HCF at any time.
 
N

nrk

Richard said:
Of course I am!


Yes. The machine restarted spontaneously, and failed to detect the hard
disks on the restart. (A cold boot fixed it, thank heaven.)


Your mileage may vary. On some Win2K machines, nothing happens,
apparently. On others, the machine restarts but without the disk problems.
It's not just Win2K. I believe NT4 and some versions of XP have the same
problem. It is entirely possible that this problem has since been
addressed by a bugfi\b\b\b\b\bService Pack.

Well, thanks for educating me here! I need to try this out the next time I
can lay hands on someone else's XP/2K box :) This one's even shorter than
the winnuke code (that I have seen in action crashing Win95/98 machines)
that exploited some mishandling of OOB TCP data.

-nrk.

<snip>
 
J

Joona I Palaste

Bill Cunningham said:
Are you saying device drivers should probably be written in assembly? Or
maybe straight binary?

No. What I am saying is that people who call device drivers from their
code must be careful. No matter what the drivers are written in.
 
J

Joona I Palaste

In fact it should only crash the OS - it exploits a silly bug in the Win32
console handler -(if you backspace beyond the left margin, it indexes an
array with a -ve number and blammo. If it crashed RJH's disk then it was
a fluke.

I've heard that it would be otherwise fine, but Windows treats the
console handler as a vital part of its kernel, and if the kernel notes
that the console handler has crashed, it instantly commits suicide.
 
E

Erik

I read an article in a book about Perl and Common Gateway Interface and it
mentioned C. It said that C could damage your computer. I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset. I sent Dennis Ritchie and email. I don't know if he'll respond if he
gets it. Sometimes he does sometimes not. How can C damage your computer?

Bill


I once wrote a buggy program that accessed the video system/card.
It blew up the screen.
Long time ago though.
But I have never heard of blowing up the computer...

frgr
Erik
 
D

Dan Pop

In said:
I can vouch for this one - one of the early Linux drivers for the matrox
cards toasted my monitor.

It was actually your stupidity that did the job. Windows worked as well
for this purpose, if you chose a video mode that was beyond the
capabilities of the monitor.

It is a thing of the past, however, because modern monitors can protect
themselves against this kind of abuse and most of them can also "tell"
their capabilities to the graphics card they're connected to. From
there, the information is picked by the graphics driver which can reject
any configured video mode that exceeds the monitor's capabilities (it is
usually the horizontal sweep frequency that is the critical parameter).

So, even Mark McIntyre will have a hard time repeating his stunt these
days...

Dan
 
D

Dan Pop

In said:
I read an article in a book about Perl and Common Gateway Interface and it
mentioned C. It said that C could damage your computer. I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset. I sent Dennis Ritchie and email. I don't know if he'll respond if he
gets it. Sometimes he does sometimes not. How can C damage your computer?

If you were not the patent idiot you are, you'd have realised that this is
a general software issue, having nothing to do with C.

So, IF it is possible to damage a computer via software, C is one of the
many languages that will allow you to do it. Any other low level language
or even high level language with an interface to the operating system
primitives will do the job. Or no language at all: ten years ago it was
perfectly possible to damage a monitor (fry the final transistor of the
horizontal deflection circuitry) with a text editor (under Linux) or the
mouse (under Windows). All you had to do was select a video mode the
monitor could not support.

It is also possible to abuse certain peripherals, e.g. hard and floppy
disks, by madly moving their heads for long periods of time. Depending
on their quality and age, this may physically damage them. But, again,
there is nothing C specific here.

The canonical example, 20 years ago, was an 8-bit Commodore home computer.
A single BASIC POKE instruction (the "right" value at the "right" address)
was enough to destroy something in the graphics hardware.

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

[C#] Extend main interface on child level 0
C language now truly universal 0
Dennis Ritchie -- An Appreciation 269
I'm tempted to quit out of frustration 1
C Bibliography 17
TF-IDF 1
Limbajul C 5
C Is Not Assembly 6

Members online

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,020
Latest member
GenesisGai

Latest Threads

Top