By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,899 Members | 1,066 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,899 IT Pros & Developers. It's quick & easy.

C dangerous?

P: n/a
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

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 14 '05 #1
Share this Question
Share on Google+
101 Replies


P: n/a
"Bill Cunningham" <no****@nspam.net> writes:

| 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?

The only way damaging the computer with C I can think of is
programming a bad kernel-driver trashing on some extremely fragile
hardware. Otherwise, your OS is broken. :-)

However, what is probably meant is that using C from cgi requires
quite some caution. Since a CGI program receives input from any (and
potential malicious) users, it must take a lot of precautions. For
example, passing your arguments unchecked to a shell is a bad idea,
for then a example "; rm -rf /" wipes clean whatever the http-user can
delete.

Perl has (in addition to dynamic arrays etc.) something called
taint-mode that can identify some of these issues and take appropriate
action (abort).

So to summarize: It is very unlikely that a C program actually damages
your computer, but a broken C program can mess
(read/forward/delete/whatever) the files the user running the C
program has access to. And since you through CGI let anyone run this
program, this is a major security concern.

Cheers
Chris.

--
email address available at http://www.ifi.uio.no/~erikd/index.cgi
Nov 14 '05 #2

P: n/a
Bill Cunningham wrote:
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


The issue is really that if you don't C, you could accidentally push
your computer off the table...

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Nov 14 '05 #3

P: n/a
> How
can C damage your computer?


Blah, just some language zealot. They're a dime a dozen.

--
gabriel
Nov 14 '05 #4

P: n/a

"Christopher Dyken" <fo****@uio.no> wrote in message
news:x6*************@lachesis.uio.no...
The only way damaging the computer with C I can think of is
programming a bad kernel-driver trashing on some extremely fragile
hardware. Otherwise, your OS is broken. :-)

However, what is probably meant is that using C from cgi requires
quite some caution. Since a CGI program receives input from any (and
potential malicious) users, it must take a lot of precautions. For
example, passing your arguments unchecked to a shell is a bad idea,
for then a example "; rm -rf /" wipes clean whatever the http-user can
delete.

Perl has (in addition to dynamic arrays etc.) something called
taint-mode that can identify some of these issues and take appropriate
action (abort).

So to summarize: It is very unlikely that a C program actually damages
your computer, but a broken C program can mess
(read/forward/delete/whatever) the files the user running the C
program has access to. And since you through CGI let anyone run this
program, this is a major security concern.

Cheers
Chris.

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. 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.

/* End Dennis's response */

Does anyone understand this a little better than me?

Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 14 '05 #5

P: n/a
Bill Cunningham <no****@nspam.net> scribbled the following:
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. 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. /* End Dennis's response */ Does anyone understand this a little better than me?


I think what dmr / Dennis / Mr.Ritchie (choose your style) is trying to
say is that actually damaging your computer programmatically requires
native machine code. This machine code doesn't have to be typed in by
hand though - it can have been compiled from C, Perl, or whatever.
Sometimes you don't even need that - some languages specify interfaces
to native machine code. That is, you call a function (in C terminology)
where the calling interface is in C, Perl, or whatever, but the actual
function code is in native machine code. Graphics cards drivers usually
do this. Doing things with your graphics card is way beyond C's
abilities, but it can be done in native machine code, and people who
write graphics card drivers usually write their code so that it allows
functions to be called through a C interface.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++. C++ run. Run, ++, run."
- JIPsoft
Nov 14 '05 #6

P: n/a
"Bill Cunningham" <no****@nspam.net> writes:
| 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. 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. | /* End Dennis's response */

| Does anyone understand this a little better than me?

I think I understand your question in the same way Dennis does: You
wonder if it is possible for a program written in C to physically
damage your computer.

And the answer to this is "very unlikely". And if you don't do kernel
programming, "not at all".

(However, poking around in the memory using perl is substantially more
difficult than doing it in C. But I have trouble seeing how this
relate to CGI.)

Bad design of a C/perl/python/assembler/whatever program can cripple
any data the user who is running the program has access to. What means
different languages/run-time systems apply to prevent this varies. But
perl can mess up your files as easily as C. But this doesn't
physically harm your computer.
Cheers,
Chris.

--
email address available at http://www.ifi.uio.no/~erikd/index.cgi
Nov 14 '05 #7

P: n/a
Bill Cunningham wrote:
Dennis wrote me back
Dennis who?
and I'm not quite sure I understood what he was trying to say
so I'll post his response.


Did you get his permission to post this response?

Nov 14 '05 #8

P: n/a
Bill Cunningham wrote:
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


The C language cannot damage your computer. An
executable program can, regardless of the language
it was written in. I can write a program in assembly
that will trash your harddrive and play havoc on
your graphics card. I could write it in C, C++
and Basic as well. The danger only lies in the
execution of said program.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Nov 14 '05 #9

P: n/a

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:c0**********@oravannahka.helsinki.fi...

I think what dmr / Dennis / Mr.Ritchie (choose your style) is trying to
say is that actually damaging your computer programmatically requires
native machine code. This machine code doesn't have to be typed in by
hand though - it can have been compiled from C, Perl, or whatever.
Sometimes you don't even need that - some languages specify interfaces
to native machine code. That is, you call a function (in C terminology)
where the calling interface is in C, Perl, or whatever, but the actual
function code is in native machine code. Graphics cards drivers usually
do this. Doing things with your graphics card is way beyond C's
abilities, but it can be done in native machine code, and people who
write graphics card drivers usually write their code so that it allows
functions to be called through a C interface.

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

Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 14 '05 #10

P: n/a
Bill Cunningham wrote:

<snip>
Are you saying device drivers should probably be written in assembly? Or
maybe straight binary?


That wouldn't make them any safer.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #11

P: n/a
Bill Cunningham wrote:
How can C damage your computer?


/* The social engineering technique */
#include <stdio.h>
int main(void)
{
puts("Please destroy the computer with an axe.");
puts("If you don't have an axe, at least");
puts("hit the monitor with a chair.");
puts("Thank you.");
return 0;
}

/* The system-specific technique */
#include <stdlib.h>
int main(void)
{
system("insert system-trashing command here");
return 0;
}

/* The undefined behaviour technique (not guaranteed, alas) */
void main() { gets(0); }

/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
#include <stdio.h>
int main(void)
{
int i;
for(i = 0; i < 1000; i++)
{
printf("\t\b\b\b\b\b");
fflush(stdout);
}

return 0;
}
Anyone care to add to the list?
Note: none of these problems is unique to C. If a programming language can
access your hardware, it can almost certainly /damage/ your hardware too.
And even if it can't, it might be able to trick the /user/ into damaging
your hardware. With an axe.

C is dangerous in the same way that any powerful tool can be dangerous if
handled maliciously or incompetently. A scalpel is dangerous in the hands
of an infant or a psychopath, but remains useful in the hands of a surgeon.

If you don't want to use a powerful tool, try some other language.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #12

P: n/a
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

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Nov 14 '05 #13

P: n/a


Christopher Dyken wrote:
Bad design of a C/perl/python/assembler/whatever program can cripple
any data the user who is running the program has access to. What means
different languages/run-time systems apply to prevent this varies. But
perl can mess up your files as easily as C. But this doesn't
physically harm your computer.


Cheers,
Chris.


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

--

"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

Nov 14 '05 #14

P: n/a
nrk
Richard Heathfield wrote:
Bill Cunningham wrote:
How can C damage your computer?
/* The social engineering technique */
#include <stdio.h>
int main(void)
{
puts("Please destroy the computer with an axe.");
puts("If you don't have an axe, at least");
puts("hit the monitor with a chair.");
puts("Thank you.");
return 0;
}

/* The system-specific technique */
#include <stdlib.h>
int main(void)
{
system("insert system-trashing command here");
return 0;
}

/* The undefined behaviour technique (not guaranteed, alas) */
void main() { gets(0); }

/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/


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???? Seriously, I
don't even see undefined behavior in there.

-nrk.
#include <stdio.h>
int main(void)
{
int i;
for(i = 0; i < 1000; i++)
{
printf("\t\b\b\b\b\b");
fflush(stdout);
}

return 0;
}
Anyone care to add to the list?
Note: none of these problems is unique to C. If a programming language can
access your hardware, it can almost certainly /damage/ your hardware too.
And even if it can't, it might be able to trick the /user/ into damaging
your hardware. With an axe.

C is dangerous in the same way that any powerful tool can be dangerous if
handled maliciously or incompetently. A scalpel is dangerous in the hands
of an infant or a psychopath, but remains useful in the hands of a
surgeon.

If you don't want to use a powerful tool, try some other language.


--
Remove devnull for email
Nov 14 '05 #15

P: n/a
Nick Landsberg <hu*****@att.net> writes:

| Christopher Dyken wrote:
Bad design of a C/perl/python/assembler/whatever program can cripple
any data the user who is running the program has access to. What means
different languages/run-time systems apply to prevent this varies. But
perl can mess up your files as easily as C. But this doesn't
physically harm your computer.
Cheers,
Chris.

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

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)
Cheers,
Chris.
--
email address available at http://www.ifi.uio.no/~erikd/index.cgi
Nov 14 '05 #16

P: n/a
Christopher Dyken <fo****@uio.no> writes:
Has anyone encountered a virus that actually harms the hardware of the
host computer?
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.
The virus-engineers usually quite clever when it comes to malicious
code.


Huh? Most viruses are created with a few clicks in a virus construction
kit. If virus writers were actually clever, the world would be very
different.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #17

P: n/a
nrk wrote:
Richard Heathfield wrote:
Bill Cunningham wrote:
How can C damage your computer?
/* The social engineering technique */
#include <stdio.h>
int main(void)
{
puts("Please destroy the computer with an axe.");
puts("If you don't have an axe, at least");
puts("hit the monitor with a chair.");
puts("Thank you.");
return 0;
}

/* The system-specific technique */
#include <stdlib.h>
int main(void)
{
system("insert system-trashing command here");
return 0;
}

/* The undefined behaviour technique (not guaranteed, alas) */
void main() { gets(0); }

/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/


I am not sure if you're joking or serious here.


Of course I am!
Did it really happen?
Yes. The machine restarted spontaneously, and failed to detect the hard
disks on the restart. (A cold boot fixed it, thank heaven.)
If
it did... well, I never... That code crashes the hard disk????
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.
Seriously,
I don't even see undefined behavior in there.


Gotta love Microsoft. Gotta.

Gotta.

Gotta love 'em. Right. Yes.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #18

P: n/a
Christopher Dyken wrote:

<snip>
Has anyone encountered a virus that actually harms the hardware of the
host computer?


There was an Amiga virus that played tunes on the floppy disk drive by
adjusting the stepper motor speed. This didn't do the drive any good.

You might want to take this to alt.folklore.computers or something.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #19

P: n/a
Richard Heathfield wrote:
Bill Cunningham wrote:

How can C damage your computer?

/* The social engineering technique */
#include <stdio.h>
int main(void)
{
puts("Please destroy the computer with an axe.");
puts("If you don't have an axe, at least");
puts("hit the monitor with a chair.");
puts("Thank you.");
return 0;
}

/* The system-specific technique */
#include <stdlib.h>
int main(void)
{
system("insert system-trashing command here");
return 0;
}

/* The undefined behaviour technique (not guaranteed, alas) */
void main() { gets(0); }

/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
#include <stdio.h>
int main(void)
{
int i;
for(i = 0; i < 1000; i++)
{
printf("\t\b\b\b\b\b");
fflush(stdout);
}

return 0;
}
Anyone care to add to the list?

Yes... you forgot viruses...

#include <stdio.h>
#include <stdlib.h>

int main(void) {
printf("Your system is affected by ancient virus\n");
printf("Remove all files from your computer\n");
printf(" and distribute this virus to your friends.\n");
return EXIT_SUCCESS;
}

:-)

cheers
e.j.s
Nov 14 '05 #20

P: n/a
On Wed, 18 Feb 2004 00:12:27 +0100, Martin Dickopp
<ex****************@zero-based.org> wrote:
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.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #21

P: n/a
On Tue, 17 Feb 2004 15:28:25 -0500, in comp.lang.c , "Bill Cunningham"
<no****@nspam.net> wrote:
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?"
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #22

P: n/a
On Tue, 17 Feb 2004 15:28:25 -0500, in comp.lang.c , "Bill Cunningham"
<no****@nspam.net> wrote:

(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?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #23

P: n/a
Alan Balmer <al******@att.net> writes:
On Wed, 18 Feb 2004 00:12:27 +0100, Martin Dickopp
<ex****************@zero-based.org> wrote:
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.


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!
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #24

P: n/a
>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
Nov 14 '05 #25

P: n/a
On Tue, 17 Feb 2004 22:40:08 GMT, in comp.lang.c , nrk
<ra*********@devnull.verizon.net> wrote:
Richard Heathfield wrote:
/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #26

P: n/a
Richard Heathfield <in*****@address.co.uk.invalid> writes:
nrk wrote:
Richard Heathfield wrote:
/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
#include <stdio.h>
int main(void)
{
int i;
for(i = 0; i < 1000; i++)
{
printf("\t\b\b\b\b\b");
fflush(stdout);
}

return 0;
}


I am not sure if you're joking or serious here.


Of course I am!
Seriously, I don't even see undefined behavior in there.


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.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #27

P: n/a
David Rubin wrote:
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 !-)

Nov 14 '05 #28

P: n/a
"Bill Cunningham" <no****@nspam.net> wrote in message news:<40**********@corp.newsgroups.com>...
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.
Nov 14 '05 #29

P: n/a
Bill Cunningham wrote:

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

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----


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
jv*@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
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".
Nov 14 '05 #30

P: n/a
"E. Robert Tisdale" wrote:
.... 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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #31

P: n/a
Richard Heathfield wrote:
Bill Cunningham wrote:

<snip>
Are you saying device drivers should probably be written in
assembly? Or maybe straight binary?


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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #32

P: n/a
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:
nrk wrote:
Richard Heathfield wrote:
Bill Cunningham wrote:

How can C damage your computer?

/* The social engineering technique */
#include <stdio.h>
int main(void)
{
puts("Please destroy the computer with an axe.");
puts("If you don't have an axe, at least");
puts("hit the monitor with a chair.");
puts("Thank you.");
return 0;
}

/* The system-specific technique */
#include <stdlib.h>
int main(void)
{
system("insert system-trashing command here");
return 0;
}

/* The undefined behaviour technique (not guaranteed, alas) */
void main() { gets(0); }

/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/


I am not sure if you're joking or serious here.


Of course I am!
Did it really happen?


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


Then, it was not a disk failure, it was an OS failure. Big difference!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #33

P: n/a
In <cL*****************@nwrddc03.gnilink.net> nrk <ra*********@devnull.verizon.net> writes:
Richard Heathfield wrote:
/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/


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???? Seriously, I
don't even see undefined behavior in there.


There isn't. Merely unspecified.
#include <stdio.h>
int main(void)
{
int i;
for(i = 0; i < 1000; i++)
{
printf("\t\b\b\b\b\b");
fflush(stdout);
}

return 0;
}


The non-obvious effect of printing "\t\b\b\b\b\b" on the console of
certain high end Windows flavours is a system crash. If the system
crashes at the "right" moment, it can leave the filesystem in a bad
state, so that part of it can become unusable.

Of course, this doesn't qualify as disk failure, but this is a too fine
point for RH.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #34

P: n/a
On Wed, 18 Feb 2004 13:35:03 +0000, Dan Pop wrote:
The non-obvious effect of printing "\t\b\b\b\b\b" on the console of
certain high end Windows flavours is a system crash. If the system
crashes at the "right" moment, it can leave the filesystem in a bad
state, so that part of it can become unusable.
According to RH it was worse than that. The machine didn't detect the
drive on a warm reboot but a cold reboot fixed the problem. That doesn't
sound like filesystem corruption but one or more out of:
1: the electronics on the drive "crashing" or shutting down because of
incorrect traffic on the interface
2: System memory beeing trampled (bios, disk controller, the drive itself)
and left in some kind of corrupted state that a warm reboot doesn't
reset.
3: Nasal demons finding a new habitat in the drive but leaving when
the landlord cuts the electricity for their video games.
Of course, this doesn't qualify as disk failure, but this is a too fine
point for RH.


Since a cold reboot fixed it, and scandisk wasn't mentioned I don't think
we're talking filesystem corruption here.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

Nov 14 '05 #35

P: n/a
On Tue, 17 Feb 2004, Bill Cunningham wrote:

"Christopher Dyken" <fo****@uio.no> wrote in message
news:x6*************@lachesis.uio.no...
The only way damaging the computer with C I can think of is
programming a bad kernel-driver trashing on some extremely fragile
hardware. Otherwise, your OS is broken. :-)

However, what is probably meant is that using C from cgi requires
quite some caution. Since a CGI program receives input from any (and
potential malicious) users, it must take a lot of precautions. For
example, passing your arguments unchecked to a shell is a bad idea,
for then a example "; rm -rf /" wipes clean whatever the http-user can
delete.

Perl has (in addition to dynamic arrays etc.) something called
taint-mode that can identify some of these issues and take appropriate
action (abort).

So to summarize: It is very unlikely that a C program actually damages
your computer, but a broken C program can mess
(read/forward/delete/whatever) the files the user running the C
program has access to. And since you through CGI let anyone run this
program, this is a major security concern.

Cheers
Chris.

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. 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.

/* End Dennis's response */

Does anyone understand this a little better than me?


In repsonse to your first question, years ago the average computer user
could get a computer system that allowed them to trash it. The operating
systems twenty years ago did not have as much protection as they do
today. On something like Windows or MacOS it is a lot harder to program at
the raw hardware layer. The operating system gets in your way and protects
you. By the time you figure out how to get around the operating system and
to the hardware directly, you should have enough knowledge not to damage
anything.

Bottom line, if the book was published 15 or 20 years ago it was valid
back then but it is not as much of a concern today.

In response to what Dennis Ritchie indicates, twenty years ago I have a
computer with a video chip. I could write directly to the video chip. I
wrote a program that tried various combinations of values on the video
chip registers. I didn't have any documentation on the video chip so I was
trying to learn by trial and error. My monitor was a fixed sync rate NTSC
video monitor. I accidently told the video chip to send a signal to the
monitor that the monitor was not capable of handling. The monitor caught
fire.

On another computer, it was possible to run some memory mapped code that
would format the hard drive. If my code accidently got corrupted and
program execution got misdirected to that memory location, it would format
my hard drive.

Again, this was twenty years ago. Today's monitors are much more resilent
and the operating system will not let me address the video card directly.
Hard drive controllers are also protected by the operating system. It is
less likely that a badly written program will corrupt your system, damage
the monitor or format your drive. This is not to say it is impossible,
just not likely.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov
Nov 14 '05 #36

P: n/a
Bill Cunningham wrote:
[...]
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. 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.

/* End Dennis's response */

Does anyone understand this a little better than me?


If you are running an O/S that allows direct access to the video
hardware, then you can program it to do "bad things" as far as the
monitor is concerned. For example, give it a sync signal that is
far enough out of the monitor's range, leave it in that state for
long enough, and something bad will happen to the monitor.

Such things are easy to do with platform-specific extensions to
"C", and Dennis is saying that it may be possible to do the same
things in Perl on such a platform.
<WayBackMachine year="1979">

The TRS-80 Model 2 had its video memory bank-switched with the top
16K(?) of "normal" memory. To access it, you bank-switched it in,
did what you had to do, and switched it out back to "normal" memory.
During this time, the video signal was cut off.

As everyone knows, using the BIOS to display text is much slower
than simply writing to video memory, so that's what was done.

Fast-forward a year to the release of TRS-DOS 2, which included a
print spooler. It's code was placed in the "normal" memory bank
that was swapped out when accessing video memory. It was executed
on the (maskable) clock-tick interrupt.

Put the two previous paragraphs together, and imagine what would
happen if the clock-tick interrupt occurred while the video memory
was swapped in, and interupts are enabled.

The interrupt occurs, and the O/S calls the spooler. Unfortunately,
at the spooler's address there is video memory instead, which does
not make for very good executable code. The machine freezes, with
the video signal still off. Well, the hardware wasn't designed to
run that way for more than a few milliseconds, and (as I recall)
the flyback transformer would overload and explode. (Well, maybe
not "explode", but "die a horrible death" at least.)

</WayBackMachine>
Now, to put this back on-topic... :-)

The following program may cause hardware damage, though the results
are not guaranteed.

======

void main()
{
char *pt, c;

*( pt = pt++ ) = c;

}

======
--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+
Nov 14 '05 #37

P: n/a
Christopher Dyken wrote:
[...]
| Does anyone understand this a little better than me?

I think I understand your question in the same way Dennis does: You
wonder if it is possible for a program written in C to physically
damage your computer.

And the answer to this is "very unlikely". And if you don't do kernel
programming, "not at all".
It depends on the O/S. Any "real" O/S will provide hardware abstraction
at some level. Some, like MS-DOS, allow you do to anything at any time
with any piece of hardware that you like.

Could a user application on a Unix box damage hardware? As you say,
"very unlikely", unless there is a poorly written device driver that
will allow bad control data to be passed to it without checking.
(However, poking around in the memory using perl is substantially more
difficult than doing it in C. But I have trouble seeing how this
relate to CGI.)


CGI is more likely to damage files than hardware, if it doesn't protect
itself from malicious user input. But, as someone pointed out, Perl
has a mode to detect most of these automatically, whereas in C you
would have to code the protection yourself. (This is obviously doable.
After all, isn't Perl itself written in C?)

[...]

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

Nov 14 '05 #38

P: n/a
Martin Dickopp <ex****************@zero-based.org> wrote:
\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.


_Unspecified_, not undefined. And I don't think putting the hard disk or
even the screen in temporarily-out-of-action mode is one of the options
allowed by the Standard for this instance of unspecified behaviour.

Richard
Nov 14 '05 #39

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Martin Dickopp <ex****************@zero-based.org> wrote:
\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.
_Unspecified_, not undefined.


Yes, that's actually what I said. :)

In case I haven't been clear enough, my point was that the program does
*not* cause undefined behavior, but unspecified behavior of the display
device.
And I don't think putting the hard disk or even the screen in
temporarily-out-of-action mode is one of the options allowed by the
Standard for this instance of unspecified behaviour.


I agree. That's why I concluded in my previous posting that an
implementation doing that is non-conforming.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #40

P: n/a
Martin Dickopp <ex****************@zero-based.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
And I don't think putting the hard disk or even the screen in
temporarily-out-of-action mode is one of the options allowed by the
Standard for this instance of unspecified behaviour.


I agree. That's why I concluded in my previous posting that an
implementation doing that is non-conforming.


Ok; but my point was that even if the semi-crashed device is the display
device itself, it still is non-conforming. Doesn't matter wether the
disk is not the device written to; crashing is not, AFAICT, part of the
acceptable unspecified behaviour even for the display device.

Richard
Nov 14 '05 #41

P: n/a
Kenneth Brody <ke******@spamcop.net> writes:

| Christopher Dyken wrote:
| [...]
(However, poking around in the memory using perl is substantially more
difficult than doing it in C. But I have trouble seeing how this
relate to CGI.)

| CGI is more likely to damage files than hardware, if it doesn't protect
| itself from malicious user input. But, as someone pointed out, Perl
| has a mode to detect most of these automatically, whereas in C you
| would have to code the protection yourself. (This is obviously doable.
| After all, isn't Perl itself written in C?)

I pointed that out. The taint mode in perl is essentially a
requirement that that anything you pass to "dangerous subroutines"
(e.g. system()) is from your own data or the result from a regular
expression. Quite handy when doing CGI stuff, but it requires your
reg-exp'es to be bullet-proof.

Throwing input into a regular expression is ofcourse do-able in C, but
to keep track of which variables are tainted and which is not
automagically is IMHO not that easy. Atleast not in a idiot-proof way
in out-of-the-box style.
Cheers,
Chris.
--
email address available at http://www.ifi.uio.no/~erikd/index.cgi
Nov 14 '05 #42

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Martin Dickopp <ex****************@zero-based.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
> And I don't think putting the hard disk or even the screen in
> temporarily-out-of-action mode is one of the options allowed by the
> Standard for this instance of unspecified behaviour.


I agree. That's why I concluded in my previous posting that an
implementation doing that is non-conforming.


Ok; but my point was that even if the semi-crashed device is the display
device itself, it still is non-conforming. Doesn't matter wether the
disk is not the device written to; crashing is not, AFAICT, part of the
acceptable unspecified behaviour even for the display device.


Unspecified behavior is defined in 3.4.4#1 as "behavior where this
International Standard provides two or more possibilities and imposes
no further requirements on which is chosen in any instance". Although
5.2.2 does not really provide two or more possibilities of acceptable
behavior for a display device, I tend to agree with you.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #43

P: n/a
In <pa****************************@spam.for.me.invali d> Nils Petter Vaskinn <no@spam.for.me.invalid> writes:
On Wed, 18 Feb 2004 13:35:03 +0000, Dan Pop wrote:
The non-obvious effect of printing "\t\b\b\b\b\b" on the console of
certain high end Windows flavours is a system crash. If the system
crashes at the "right" moment, it can leave the filesystem in a bad
state, so that part of it can become unusable.


According to RH it was worse than that.


I was not even trying to describe what happened on his system. I was
merely pointing out the worst that could realistically happen when
executing that program on one of the affected Windows systems, because
RH offered it as an example of dangerous C program.
Of course, this doesn't qualify as disk failure, but this is a too fine
point for RH.


Since a cold reboot fixed it, and scandisk wasn't mentioned I don't think
we're talking filesystem corruption here.


See my comment above. Filesystem corruption is the worst this program
can normally do, whether it happened or not to RH.

On my laptop, it is impossible to hot boot Windows after Linux: the
booting process will systematically freeze in the same place and the
power button is the only way out. Linux hot boots after Windows without
any problems. Does this mean that my laptop is somehow physically
damaged after booting Linux?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #44

P: n/a
"sellountos euripides" <fa**@address.com> wrote in message
news:c0**********@nic.grnet.gr...
Richard Heathfield wrote:
Bill Cunningham wrote:
How can C damage your computer?


/* The social engineering technique */ <snip> /* The system-specific technique */ <snip> /* The undefined behaviour technique (not guaranteed, alas) */ <snip> /* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
I've actually tried this one, it was fun! No harddisk failure though,
only blue screen. Cold restart was necessary. After that, the system
started fine, not even scandisk was launched.
Anyone care to add to the list?

Yes... you forgot viruses...

#include <stdio.h>
#include <stdlib.h>

int main(void) {
printf("Your system is affected by ancient virus\n");
printf("Remove all files from your computer\n");
printf(" and distribute this virus to your friends.\n");
return EXIT_SUCCESS;
}


This is also a social engineering technique. Moreover, it has a flaw
that could fortunately be fixed by swapping the last two pritf()s.
Possibly with some minor fine-tuning ;-)

Peter
Nov 14 '05 #45

P: n/a
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c0**********@sunnews.cern.ch...
....in his usual friendly style:
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.
Of course, otherwise it would be... well... useless.
[...] 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.


Or simply by pulling the video cable with the monitor still on.
That was fun!

Peter
Nov 14 '05 #46

P: n/a
"Bill Cunningham" <no****@nspam.net> wrote in message news:<40**********@corp.newsgroups.com>...
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

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----


The only thing that will make C dangerous is if the patent offices
gives Microsoft permission to own it.
Nov 14 '05 #47

P: n/a
Em Wed, 18 Feb 2004 10:13:46 -0500, Kenneth Brody escreveu:

<snip>

The following program may cause hardware damage, though the results
are not guaranteed.

======

void main()
{
char *pt, c;

*( pt = pt++ ) = c;

}

======


I think this program would only segfault on an *operating* system...
--
Quidquid latine dictum sit altum viditur

Nov 14 '05 #48

P: n/a

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


I had an old TRS-80 Color Computer and one day I decided I was going to
start "poking" values into addresses. The monitor shut off. The computer
began to make "grunting" noises I turned it off immediately. It still worked
after that but one day I turned on the CoCo and there was a loud pop and a
puff of smoke. I blew the transformer.

Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 14 '05 #49

P: n/a
On Wed, 18 Feb 2004 16:43:47 +0000, Dan Pop wrote:
See my comment above. Filesystem corruption is the worst this program
can normally do, whether it happened or not to RH.
On my laptop, it is impossible to hot boot Windows after Linux: the
booting process will systematically freeze in the same place and the
power button is the only way out. Linux hot boots after Windows without
any problems. Does this mean that my laptop is somehow physically
damaged after booting Linux?


No, but neither is the filesystem.
I didn't say that anything was physically damaged, I said that it didn't
sound like "leaving the filesystem in a bad state" and offered an
alternative shot in the dark about what really happened.

I cannot imagine how the filesystem could be broken in such a way that a
cold reboot will find it while a hot reboot won't, that's why I don't buy
the filesystem corruption idea. Unfortunately RH didn't state if the bios
saw the drive wile the os didn't.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

Nov 14 '05 #50

101 Replies

This discussion thread is closed

Replies have been disabled for this discussion.