snguyen@nprdc.arpa (Son Nguyen) (03/18/89)
Hello, every one. I just wonder if (possibly done) we could write a program to detect the pressing of these three keys: CTRL-ALT-DEL. In other words, can I write a software in the "C" language or in IBM assembly language to detect and maybe disable them ? You may say that I am a little crazy. The reason I would like to achieve so is because I would like to implement a password program hat allows only the authorized users to access my IBM PC XT computer. I know how to disable the interrupts but my friends are smarter. When they turn on my computer and notice that I have installed this program, they then press the keys CTRL-ALT-KEY and insert their own MS-DOS disk on the drive A:. It may seem silly that why they don't put their system disk initially when they try o turn it on. Well, that is another problem. This raises my second question: Can we configure the computer to boot only with "C:" drive ? Thanks a million every one. Son Nguyen PS: Please, don't tell me to buy an IBM AT which has the key lock. My questions are posted to achiee both points: for learning, and for my IBM PC protection.
rong@cwsys2..CWRU.Edu (Rong Chen) (03/19/89)
How about to change IBM BIOS so that it will not look for drive A: when boot up, but you face a problem when your hard disk crashes ... Rong
wales@valeria.cs.ucla.edu (Rich Wales) (03/20/89)
In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes: I just wonder if (possibly done) we could write a program to detect the pressing of these three keys: CTRL-ALT-DEL. In other words, can I write a software in the "C" language or in IBM assembly language to detect and maybe disable them? I sent Son a reply via e-mail -- then decided that it might well be of general interest, so I'm posting my comments too. My understanding is that the CTRL/ALT/DEL combo is detected in the ROM BIOS "interrupt 09h" handler -- the routine that, among other things, translates keyboard scan codes into the corresponding characters. Hence, writing a normal program to intercept CTRL/ALT/DEL wouldn't work, since your program would never get a chance to see the offending key combination. You've got to hook up to the Int 09h vector and check for CTRL/ALT/DEL *before* the BIOS routine does -- or else write your own complete Int 09h handler and run it in place of the ROM BIOS code. If you are willing/able to work with assembly language, you might grab a copy of a program called FASTBUFF (available via anonymous FTP from WSMR-SIMTEL20.ARMY.MIL; file name PD1:<MSDOS.KEYBOARD>FASTBUFF.ARC; about 28K bytes long). FASTBUFF is a keyboard buffer extender for PC's and XT's, and it interposes its own processing ahead of the system's own Int 09h handler in the BIOS. By modifying FASTBUFF, you can definitely do some novel things. I, for example, added an option to my copy of FASTBUFF so I could rearrange the ESC, BS, and `/~ keys on my XT clone's 84-key keyboard. These keys are now in the same places as the corresponding keys on my Sun workstation at school (I even pried off and rearranged the key caps!). You might be able to add some code to FASTBUFF to check for CTRL/ALT/DEL and prevent a call to the BIOS Int 09h handler as long as that combina- tion was held down. I haven't tried this myself, but you would check for the DEL key's scan code (53h), plus the CTRL and ALT bits in the status byte at RAM location 00417h. If you aren't familiar with SIMTEL20, remember that it's a DECsystem-20 with 36-byte words. To FTP a binary file from SIMTEL20 to a UNIX sys- tem, use the command "tenex" (*NOT* "binary" or "bin") first to set the proper data transfer mode. -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "Now, drop your weapons, or I'll kill him with this deadly jelly baby."
brown@nicmad.UUCP (Vidiot) (03/30/89)
In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes:
<
<Hello, every one.
<
< I just wonder if (possibly done) we could write a program to
<detect the pressing of these three keys: CTRL-ALT-DEL. In other words,
<can I write a software in the "C" language or in IBM assembly language to
<detect and maybe disable them ? You may say that I am a little crazy.
<The reason I would like to achieve so is because I would like to implement
<a password program hat allows only the authorized users to access my IBM
<PC XT computer. I know how to disable the interrupts but my friends are
<smarter. When they turn on my computer and notice that I have installed
<this program, they then press the keys CTRL-ALT-KEY and insert their own
<MS-DOS disk on the drive A:. It may seem silly that why they don't put
<their system disk initially when they try o turn it on. Well, that is
<another problem. This raises my second question: Can we configure the
<computer to boot only with "C:" drive ?
<
<PS: Please, don't tell me to buy an IBM AT which
<has the key lock. My questions are posted to achiee both
<points: for learning, and for my IBM PC protection.
Sorry, to stop drive A: from being booted requires a rewrite of the BIOS ROMS.
So, the end result is that any diskette in drive A: will be booted. Even
stopping the ALT-CTRL-DEL won't work; just turn the power off and on.
Newer machines not only have the key, but also have password protection built
into the BIOS.
--
harvard\ att!nicmad\
Vidiot ucbvax!uwvax..........!astroatc!brown
rutgers/ decvax!nicmad/
ARPA/INTERNET: brown%astroatc.UUCP@spool.cs.wisc.eduwcurtiss@x102c.harris-atd.com (Curtiss WC 67625) (03/30/89)
In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes:
< [stuff deleted]
<Can we configure the computer to boot only with "C:" drive ?
<
I once heard of a virus that supposedly did this. It was supposed to have
mucked around with the partion information in such a way, that when the
hard disk was initialized, it seized control and never allowed the floppy
to boot. Since it was a virus, it also erased the hard disk, and is of
no use by itself. To recover your system, you had to remove the hard drive
cable, boot a floppy and then reinstall the drive cable (not a good thing
to do with the power on, but I'm only repeating what I heard). You then did
a low level format of the drive.
I never saw this virus, so I do not know if this is true. Perhaps someone
else can substantiate it. As I recall, it was discussed my some fairly
knowledgable people so it wasn't a novice who destroyed his low level format
and wasn't patient enough for the drive init to time out.
-------------------------------------------------------------------------------
William Curtiss 407/984-6383 | "The only good martyr
Harris GISD, Melbourne, FL 32902 | is a dead martyr."
Internet: wcurtiss%x102c@trantor.harris-atd.com | - Standard disclamers apply -ralerche@lindy.Stanford.EDU (Robert A. Lerche) (03/31/89)
How about unplugging the power & signal cables from the floppy drive? I haven't tried this but it might work.
jmv@sppy00.UUCP (Jim Vickroy) (03/31/89)
=>In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes:
=>
=>Hello, every one.
=>
=> I just wonder if (possibly done) we could write a program to
=>detect the pressing of these three keys: CTRL-ALT-DEL. In other words,
=>can I write a software in the "C" language or in IBM assembly language to
=>detect and maybe disable them ? You may say that I am a little crazy.
=>The reason I would like to achieve so is because I would like to implement
=>a password program hat allows only the authorized users to access my IBM
=>PC XT computer. I know how to disable the interrupts but my friends are
=>smarter. When they turn on my computer and notice that I have installed
=>this program, they then press the keys CTRL-ALT-KEY and insert their own
=>MS-DOS disk on the drive A:. It may seem silly that why they don't put
=>their system disk initially when they try o turn it on. Well, that is
=>another problem. This raises my second question: Can we configure the
=>computer to boot only with "C:" drive ?
=>
=>PS: Please, don't tell me to buy an IBM AT which
=>has the key lock. My questions are posted to achiee both
=>points: for learning, and for my IBM PC protection.
=>
I don't think you're crazy. There are *very* good reasons for disabling the
softboot keys. Systems which maintain database can't tolerate a reboot right
in the middle of an update, for example. At any rate, to disable this key
press you will have to write your own keyboard interrupt handler. A formidable
task indeed! Essentially you will have to 'steal' interrupts 9 and 16 hex
and watch for that keypress and throw it away when you get it.
In order to have your machine boot only from C: will require your own
bootstrap.
Good luck
P.S. Have you thought about bodily harm?
!==================================================================!=========!
! Jim Vickroy | cbosgd!osu-cis!sppy00!jmv !/././././!
! Online Computer Library Center, Inc. |---------------------------!././././.!
! Dublin, Ohio 43017 | jmv@sppy00 !/././././!
!------------------------------------------------------------------!././././.!
! "That voodoo stuff don't do nothin' for me" -jrr !/././././!
!==================================================================!=========!dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/31/89)
In article <234@sppy00.UUCP> jmv@sppy00.UUCP (Jim Vickroy) writes: >I don't think you're crazy. There are *very* good reasons for disabling the >softboot keys. Systems which maintain database can't tolerate a reboot right >in the middle of an update, for example. A philosophical point: For an application to trap keystrokes so they bypass the ROM is bad practice for several reasons. 1. This introduces incompatibility with many of the machines on the market. 2. The user may already have deliberately installed special software to trap ctrl-alt-del, your application may cause chaos when it tries to trap the same key sequence. Don't second-guess the user by adding your own keyboard driver. 3. If the database is so fragile that a power outage will cause unrecoverable damage, then it is badly designed, and trapping ctrl-alt-del is no solution. The right way to avoid corruption of a database is to make sure that any partial update of the database is reversible even if a system crash or a reboot occurs during the update. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
jmv@sppy00.UUCP (Jim Vickroy) (04/01/89)
In article <6414@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
=>A philosophical point: For an application to trap keystrokes so
=>they bypass the ROM is bad practice for several reasons.
=>
=>1. This introduces incompatibility with many of the machines on the
=> market.
I doesn't create incompatibility with those machines which boast IBM
compatibility. These "many machines" you speak of will have many other
problems if they can't handle a keyboard interrupt handler. I have placed
interrupt handlers in IBM's and compatibles (some of the compatibles used
Phoenix BIOS) and had no problems. Of course, because the interrupt handler
is operating a such a low level, you do have special conciderations in terms
of incompatibility. In the end these have to be weighed against the benifits.
=>
=>2. The user may already have deliberately installed special software
=> to trap ctrl-alt-del, your application may cause chaos when it
=> tries to trap the same key sequence. Don't second-guess the
=> user by adding your own keyboard driver.
If the interrupt was 'stolen' properly and the handler was written in such a
way as to maintain the overall design of the interrupt, you won't have
problems stacking another handler on top. In fact if you steal an interrupt
and do the IRET yourself, the previous handler will not gain control. Also,
assuming that the PC is still a single-user workstation, you are the user. Any
second guessing that is going on will be aimed at yourself. You will be in
control of what is being loaded.
=>
=>3. If the database is so fragile that a power outage will cause
=> unrecoverable damage, then it is badly designed, and trapping
=> ctrl-alt-del is no solution.
=>
=>The right way to avoid corruption of a database is to make sure that
=>any partial update of the database is reversible even if a system crash
=>or a reboot occurs during the update.
Your point is well taken but you use what is available in the environment you
are working in. I tend to believe that a database of the sophistication you
imply would probably not be able to function under an application of any size.
To go further, some of this, in many mainframe sights, is handled by fault-
tolerent hardware. Indeed, many of the largest database systems still have
problems that are compinsated for by fault-tolerent hardware.
jim
--
!==================================================================!=========!
! Jim Vickroy | cbosgd!osu-cis!sppy00!jmv !/././././!
! Online Computer Library Center, Inc. |---------------------------!././././.!
! Dublin, Ohio 43017 | jmv@sppy00 !/././././!
!------------------------------------------------------------------!././././.!
! "That voodoo stuff don't do nothin' for me" -jrr !/././././!
!==================================================================!=========!bobc@killer.Dallas.TX.US (Bob Calbridge) (04/01/89)
=>In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes:
=>
=>Hello, every one.
=>
=> I just wonder if (possibly done) we could write a program to
=>detect the pressing of these three keys: CTRL-ALT-DEL. In other words,
=>can I write a software in the "C" language or in IBM assembly language to
=>detect and maybe disable them ? You may say that I am a little crazy.
=>The reason I would like to achieve so is because I would like to implement
=>a password program hat allows only the authorized users to access my IBM
=>PC XT computer. I know how to disable the interrupts but my friends are
=>smarter. When they turn on my computer and notice that I have installed
=>this program, they then press the keys CTRL-ALT-KEY and insert their own
=>MS-DOS disk on the drive A:. It may seem silly that why they don't put
=>their system disk initially when they try o turn it on. Well, that is
=>another problem. This raises my second question: Can we configure the
=>computer to boot only with "C:" drive ?
=>
=>PS: Please, don't tell me to buy an IBM AT which
=>has the key lock. My questions are posted to achiee both
=>points: for learning, and for my IBM PC protection.
How about investing in a new computer? :-) I went to a roll out of some
AST computers a couple of weeks ago and learned that they have some high
end computers that have password protection built into the system. The
password is put into CMOS and the only way to defeat it is to open the
machine and diddle with some liddle switches. A case lock would be needed
for more secure safety.allbery@ncoast.ORG (Brandon S. Allbery) (04/07/89)
As quoted from <234@sppy00.UUCP> by jmv@sppy00.UUCP (Jim Vickroy): +--------------- | =>In article <1623@arctic.nprdc.arpa> snguyen@nprdc.arpa (Son Nguyen) writes: | => I just wonder if (possibly done) we could write a program to | =>detect the pressing of these three keys: CTRL-ALT-DEL. In other words, | =>can I write a software in the "C" language or in IBM assembly language to | =>detect and maybe disable them ? You may say that I am a little crazy. | | I don't think you're crazy. There are *very* good reasons for disabling the | softboot keys. Systems which maintain database can't tolerate a reboot right | in the middle of an update, for example. At any rate, to disable this key | press you will have to write your own keyboard interrupt handler. A formidable | task indeed! Essentially you will have to 'steal' interrupts 9 and 16 hex | and watch for that keypress and throw it away when you get it. +--------------- A program for doing this is listed in COMPUTE'S MAPPING THE IBM PC AND PCjr -- a reasonably good reference, although invariably at least *one* thing I need to know isn't listed and I end up digging in ncoast's archives for interrup.arc.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser