gatesl@romana.cs.orst.edu (Lee Ryan Gates) (06/07/89)
Hi, I have been wondering with all this talk about hiding the echo off, if
there is a way to disable the Control-C so that a person can't break out of
the autoexec.bat. I will be working this summer at a computer store, and
we have problems with people who come in and try to break out to the dos prompt
to do some nasty things to our hard drives, or copy software. So we are
using Direct Access (a very good hard disk menu program, which disables Control-C) and only have a problem with people who try to break out of autoexec.bat
while it is loading up.
A friend and I tried to disable it in the config.sys, but had no luck.
thanx
lee
**
'must be Oregon, look there's another person with rust on 'em.'
gates@romana.cs.orst.edu 'anybody got a job for an aspiring cs undergrad?' :-)snuzs@trsvax.UUCP (06/08/89)
One possibility would be to redirect you autoexec.bat to the NUL
device.
ctty nul
.
.
.
batchfile stuff
.
.
.
ctty con {redirect to the CON device DON'T FORGET THIS LINE}
(direct access program)
Redirecting the batch file to the NUL device would disable the CON
device i.e. the screen and the keyboard and not allow the user to
Ctlr+Break the autoexec.bat file. This will work fine as long as
you do not mind not seeing any of your autoexec programs being
loaded.
Scott
snuzs@trsvax.UUCPesulzner@cadev4.intel.com (Eric Sulzner ~) (06/09/89)
In article <10998@orstcs.CS.ORST.EDU> gatesl@romana.cs.orst.edu (Lee Ryan Gates) writes: > > I ... wonder ... if there is a way to disable ... Control-C If you have ANSI.SYS loaded, you can use 'ESC[3;255p' to reassign ^C (3) to null (255). 'ESC[3;3p' should put it back. This will work from a .bat file. The ESC is ASCII 27 (decimal). Eric Sulzner cadev4::esulzner 5-4177 SC3-17
tcm@srhqla.UUCP (Tim Meighan) (06/10/89)
In article <231@mipos3.intel.com> esulzner@cadev4.UUCP (Eric Sulzner ~) writes: > >If you have ANSI.SYS loaded, you can use 'ESC[3;255p' to reassign >^C (3) to null (255). 'ESC[3;3p' should put it back. This will >work from a .bat file. The ESC is ASCII 27 (decimal). An easy way to get DOS to ingest the strings above from an AUTOEXEC.BAT file is to use them as the argument of a PROMPT command: PROMPT $e[3;255p PROMPT changes $e to an ESC ($1B) code for you, so you don't have to fudge around with trying to enter a real $1B in a text string, which can be a pain. The problem with this method is that it does NOT disable the BREAK key; the BREAK key is not reassignable using ANSI.SYS escape sequences. The only sure way to shut off both CTRL-C and CTRL-BREAK is to redirect the BREAK interrupt vector. This can be done using DOS function calls. You have to write a simple COM program using DEBUG to point the BREAK interrupt vector at a FAR RET instruction. Then, you run this program from the first line of your AUTOEXEC, and your computer becomes un-stoppable. I'll dig out the source code that I wrote to do this and post it in a couple of days. BTW, The BREAK OFF command does NOT disable BREAK; it merely reduces how often DOS checks the keyboard to see if the BREAK key has been pressed. Just another example of misleading syntax from Microsoft. (On the other hand, how many OS's have YOU written lately?) Tim Meighan SilentRadio
baird@cod.NOSC.MIL (John M. Baird) (06/12/89)
From article <216100099@trsvax>, by snuzs@trsvax.UUCP: > One possibility would be to redirect you autoexec.bat to the NUL > device. > Redirecting the batch file to the NUL device would disable the CON > device i.e. the screen and the keyboard and not allow the user to > Ctlr+Break the autoexec.bat file. I would suggest you try this before recommending it. On NCR DOS 3.1 (which I tried the CTTY NUL approach on), keyboard interrupts STILL WORKED. Ctrl-C, Ctrl-Break, Ctrl-Alt-DEL, etc. Of course, the PC was useless, since no keyboard commands were read, but Ctrl-C was not disabled. Also, by entering Ctrl-Break at the right time in the boot process (before the CTTY NUL was executed), the unfriendly user can still do whatever damage he wants to do. John Baird, Naval Ocean Systems Center, San Diego
news@shuldig.Huji.AC.IL (news) (06/13/89)
to your config.sys. This will make command.com start with nul as the tty device. (This will also save you the echo off problem) If anyone try to Ctrl-C out of your autoexec.bat, he will hang the machine. You must remember to add a ctty coon in the end of your autoexec.bat. For ordinary batch files try command /c mybatch nul while your batch file can look like echo off do something ctty con You can even combine the two in the same batch file: if not [%1]==[%0] command /c %0 %0 nul echo off gfhfgfg kjhhjkjkjh hjghghgj etc etc etc ctty con exit From: yogi@shum.huji.ac.il (Yossi Gil) Path: shum!yogi
zu@ethz.UUCP (Urs Zurbuchen) (06/14/89)
In article <1553@cod.NOSC.MIL> baird@cod.NOSC.MIL (John M. Baird) writes: >From article <216100099@trsvax>, by snuzs@trsvax.UUCP: >... Also, by entering >Ctrl-Break at the right time in the boot process (before the CTTY NUL was >executed), the unfriendly user can still do whatever damage he wants to do. If you write a little program which intercepts to Ctrl-Break (Ctrl-C) handler as a device driver and have it included in the Config.Sys file, no user would be able to stop the machine with a ^C. Well, at least I think, I didn't test it. Anybody volunteering to write it ? :-) And, make sure your computer doesn't have a floppy drive or some user will walk in with his own boot floppy :-( ...urs
robwah@auto-trol.UUCP (Robert Wahl) (06/16/89)
In article <1241@ethz.UUCP> zu@bernina.UUCP (Urs Zurbuchen) writes: >If you write a little program which intercepts to Ctrl-Break (Ctrl-C) >handler as a device driver and have it included in the Config.Sys file, >no user would be able to stop the machine with a ^C. Well, at least I >think, I didn't test it. Anybody volunteering to write it ? :-) Not so. The interrupts dealing with keyboard input will still respond to Ctrl-C. The only way to get sure control over Ctrl-C is to replace all of these interrupts. (And even then, as someone pointed out, some programs will still replace YOUR interrupts. Hypothetically, interrupts should cascade, so that user-defined interrupts would call the interrupts they replace; but such clean encapsulation doesn't always exist, and most programs never consider the existence/desirability of TSR programs.) A good discussion of Ctrl-C handling is given in "Crafting C Tools" (I think that's the name), where the authors begin by replacing some of the standard interrupts to correct some of IBM's serious design errors. (Insert favorite IBM flame here.) =:-> -- Rob Wahl =:-> {...!ncar!ico!auto-trol!robwah}
d88-eli@nada.kth.se (Erik Liljencrantz) (06/16/89)
Newsgroups: comp.sys.ibm.pc Subject: Re: How can I disable Control-C? Reply-To: d88-eli@nada.kth.se (Erik Liljencrantz) Distribution: world Organization: Royal Institute of Technology, Stockholm, Sweden Keywords: security locking control-c Disabling Control-C can be done in many ways as discussed in previous messages (not qouted here). My solution is a devicedriver included in CONFIG.SYS, which captures control before AUTOEXEC.BAT is read. The device driver prompts for a password and if it's correct the devicedriver unloads most of itself and booting continues. It's not a complete login/ password system like in Un*x, but it keep intruders (without their own bootdisks) away. It is IMPOSSIBLE to boot from the harddisk without the password, but again, a dosdisk can be used... If someone would like a copy (including assembly source) please mail me, and I'll send an uuencoded arc-file! Erik Liljencrantz | "No silly qoutes!" d88-eli@nada.kth.se | Embraquel Tuta
dixon@sagittarius.crd.ge.com (walt dixon) (06/16/89)
In a previous article Erik Liljencrantz writes >Disabling Control-C can be done in many ways as discussed in previous >messages (not qouted here). My solution is a devicedriver included in >CONFIG.SYS, which captures control before AUTOEXEC.BAT is read. The >device driver prompts for a password and if it's correct the devicedriver >unloads most of itself and booting continues. It's not a complete login/ >password system like in Un*x, but it keep intruders (without their own >bootdisks) away. It is IMPOSSIBLE to boot from the harddisk without the >password, but again, a dosdisk can be used... Once the system is booted from a floppy disk, config.sys can be deleted or edited. The password protection has been removed. Walt Dixon {arpa: dixon@crd.ge.com } {us mail: ge crd } { po box 8 } { schenectady, ny 12345 } {phone: 518-387-5798 }
santol@cbnewsc.ATT.COM (shawn.r.antol) (06/20/89)
Erik Liljencrantz writes: > <extra stuff deleted> > If someone would like a copy (including assembly source) please mail me, > and I'll send an uuencoded arc-file! > I would like a copy. Shawn Antol AT&T Bell Labs. Naperville Il att!ihlpb!santol 312-979-5622
snuzs@trsvax.UUCP (06/21/89)
Erik Liljencrantz writes: > If someone would like a copy (including assembly source) please mail me, > and I'll send an uuencoded arc-file! I would also like a copy. Scott Parrish Tandy Corp. Fort Worth, Texas ...microsoft!trsvax!snuzs