[net.micro.pc] MS-DOS cd command

cwc@mhuxd.UUCP (Chip Christ) (06/06/85)

Any one know how I might disable the built-in cd command?

Actually, I have two purposes in mind.  One is to allow me to
boot my AT&T PC6300 with a menu-driven suite of application
programs in such a way that if someone were to get out of the
suite, it would be difficult for him/her to go poking around
the hard disk and screw up the development stuff I keep in
other sub-directories.  The other purpose is to replace the
standard cd command with a more Unix(tm)-like version.

In the first case, I guess I want to completely kill the
built-in function chdir (and its alias, cd) and in the second,
just eliminate the alias.  Any ideas?

Chip

p.s. I don't think I have the time nor inclination right now
     to write my own command.com

lotto@talcott.UUCP (Jerry Lotto) (06/07/85)

> Any one know how I might disable the built-in cd command?
> ..... 
> 
> p.s. I don't think I have the time nor inclination right now
>      to write my own command.com
            ^^
	Not that hard, just modify the strings CD and CHDIR
to something like SD or whatever else is "natural" for you.
Of course, you could always name your routine something else.
If it is important to have them respond to cd (both), either
a batch file called cd.bat with the line:
sd
in the search path before your cd.com (sorry, I know it is
ugly) or put the string cd=cd or cd=sd alternately in the
environment and invoke with %cd% from the application.
Hope this helps.

-- 
____________

Gerald Lotto - Harvard Chemistry Dept.

UUCP:  {genrad,cbosgd}!wjh12!h-sc4!harvard!lhasa!lotto
       {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
ARPA:  lotto@harvard.ARPA
CSNET: lotto%harvard@csnet-relay

jchapman@watcgl.UUCP (john chapman) (06/07/85)

> Any one know how I might disable the built-in cd command?
> 
> Actually, I have two purposes in mind.  One is to allow me to
> boot my AT&T PC6300 with a menu-driven suite of application
> programs in such a way that if someone were to get out of the
> suite, it would be difficult for him/her to go poking around
> the hard disk and screw up the development stuff I keep in
> other sub-directories.  The other purpose is to replace the
> standard cd command with a more Unix(tm)-like version.
> 
> In the first case, I guess I want to completely kill the
> built-in function chdir (and its alias, cd) and in the second,
> just eliminate the alias.  Any ideas?
> 
> Chip
>      to write my own command.co

 A couple of suggestions : 
 1. I'm not near my system right now to check it out but it may
    be that MS-DOS checks for name.com, name.exe and name.bat
    files before it sees if a command is an internal one so that
    internal commands may be replaced by user versions (of course
    an intruder could always delete your version and get the system
    one back... unless it would also work with hidden files).
 
 2. Look for the string CD and/or CHDIR in command.com using
    debug and then change the names to whatever you want.....
    Now you'll have a secure version of command.com for users

g-frank@gumby.UUCP (06/07/85)

> Any one know how I might disable the built-in cd command?
>

   Inside command.com, there is a table of internal command names.
I think you can just go in with debug, find the command name you
wish to change (i.e., cd, chdir), and change it to something else
the same length or shorter.

   I've thought about this myself.  Shouldn't be hard to use the
environment space to hold an entry for home directory, and just
call dos to chdir to it when cd is typed with no arguments.  You'll
have to write pwd, too, though.


-- 
      Dan Frank

	  Q: What's the difference between an Apple MacIntosh
	     and an Etch-A-Sketch?

	  A: You don't have to shake the Mac to clear the screen.

bright@dataio.UUCP (Walter Bright) (06/07/85)

In article <2160@mhuxd.UUCP> cwc@mhuxd.UUCP (Chip Christ) writes:
>Any one know how I might disable the built-in cd command?

You will have to use DEBUG to patch COMMAND.COM. When in DEBUG, search
through COMMAND.COM till you find the CD command string. Replace the
CD with spaces, and write out the new COMMAND.COM.

tj@utcs.UUCP (tj) (06/07/85)

I can't tell you exactly, but I hear it is trivial. I think I read in PC or
PC world about a mobnth ago about how to replace DOS commands with your own.

The approach was to patch a copy of command.com and merely blank out the
place where you find chdir and cd in a table of all the dos commands. A Norton
utility would allow you to try this in a few minutes.
t.jones utcs!tj

nather@utastro.UUCP (Ed Nather) (06/07/85)

> Any one know how I might disable the built-in cd command?
> 
You can use the debugger to substitute space codes for the strings "CD"
and "CHDIR" in a version of command.com you intend to run with your
restricted system.  If command.com can't find a typed command in its
internal list, it looks along the defined path to find it.  The command
strings are found near the end of the command.com executable file.

-- 
Ed Nather
Astronony Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather%utastro.UTEXAS@ut-sally.ARPA

jnw@mcnc.UUCP (John White) (06/08/85)

> Any one know how I might disable the built-in cd command?

It is easy to munge any command.com builtin command. Just copy command.com
to a junk file, run debug on it, use the search command to find the command
in the string table, and edit it to be any sequence of chars (of the same
length) that you want. Write out the file, exit debug, and test it.
I expect that if you use bizzare chars (high order bit set, stuff like that)
you won't be bothered by the command again.
Hope this helps - John N. White
{duke, mcnc}!jnw

dad@aluxz.UUCP (DAPKUS) (06/09/85)

> > Any one know how I might disable the built-in cd command?
> > 
> > Actually, I have two purposes in mind.  One is to allow me to
> > boot my AT&T PC6300 with a menu-driven suite of application
> > programs in such a way that if someone were to get out of the
> > suite, it would be difficult for him/her to go poking around
> > the hard disk and screw up the development stuff I keep in
> > other sub-directories.  The other purpose is to replace the
> > standard cd command with a more Unix(tm)-like version.
> > 
> > In the first case, I guess I want to completely kill the
> > built-in function chdir (and its alias, cd) and in the second,
> > just eliminate the alias.  Any ideas?
> > 
> > Chip
> 
>  A couple of suggestions : 
>  1. I'm not near my system right now to check it out but it may
>     be that MS-DOS checks for name.com, name.exe and name.bat
>     files before it sees if a command is an internal one so that
>     internal commands may be replaced by user versions (of course
>     an intruder could always delete your version and get the system
>     one back... unless it would also work with hidden files).
>  
>  2. Look for the string CD and/or CHDIR in command.com using
>     debug and then change the names to whatever you want.....
>     Now you'll have a secure version of command.com for users

{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}

Chip,

I sent you mail directly, but I must comment on the above message.
Number one will NOT work, as COMMAND.COM looks in itself before
going to disk.  I read the order of .COM, .EXE, and .BAT files,
but I can't find it now.  COMMAND actually puts the .ext on the name,
because if you look at the execute function, you must specify
what the .ext is.  The second method works quite well as I said.


----

					Donald A. Dapkus
					AT&T Bell Laboratories, Allentown, PA
					{ ihnp4, allegra } aluxz!dad

"Ocean: A body of water occupying about two-thirds of a world made
        for man -- who has no gills."

metcalf@ucbmiro.ARPA (Chris Metcalf) (06/10/85)

To restrict a user from changing directories, blank CD and CHDIR in COMMAND.COM
(as discussed), and create a CD.COM file using MASM that allows access only to
certain subdirectories--not too hard in assembler; just use the DOS 2.00 hex 3D
function call, with string tests.  To make "CD" return to the home directory,
the cleanest way is probably to put a "HOME=" entry in the environment and read
it (the segment address of the environment is at hex 2C in the initial DS).

Chris Metcalf  	ARPA metcalf@ucbmiro.BERKELEY	UUCP ...!ucbvax!ucbmiro!metcalf

bishop@ecsvax.UUCP (Alan Bishop) (06/15/85)

I've already sent a letter to the original poster, so this is for
anyone whose followed the discussion and thinks they can get a "secure"
command.com with ease.

Many people have suggested making a "secure" COMMAND.COM by simply
blanking out CD and CHDIR in COMMAND.COM.  THIS WILL NOT WORK.
Because the commands CD and CHDIR no longer work, this will not
restrict the user ONE BIT if he escapes from the shell that the user
is supposed to be in.  He will still be able to execute any command
he wishes and include paths in any command.  For example:

1) DIR \
2) DIR \DEVELOP
3) ERASE \DEVELOP\*.*
4) FORMAT C: (assuming format is on the disk)

WILL ALL STILL WORK.  Even though CD will no longer work, if there
is a copy of BASIC, Crosstalk, Kermit, Debug, or any other recent
programs he will be able to CHDIR by going into those programs and
doing it from there (debug would take a bit more work, but not
much)

Enough of the problem.

Solutions:

1) Partial solution, would help some.  Add a small, resident program
to catch INT 21H and stop all CHDIR requests at the PCDOS level.  This
protects from #1 and #2 above, because DOS (at least PCDOS 2.1) does
a CHDIR to the directory before actually displaying it.  #3 and #4
would still be available, but this would stop everyone except those
who just wanted to get rid of lots of stuff at once without knowing
what they were getting rid of.

2) Closer.  Also trap all ERASE, CREATE, and OPEN (for write) requests.
However, the more you take away, the less the programs he wants to
be demoed can do also.

3) Perfect, but perhaps impossible.  Make the shell unbreakable.
This would require use of trapping Ctrl-Break, error interrupts,
divide-by-0 and overflow interrupts, and ANY OTHER abnormal termination
calls.  Shouldn't be a problem trapping normal exits.

If anyone wants them, I have code to do solutions #1 and #2.  I'm
working on a resident program so that a PC can be left open
on a COM line with input and output redirected to COM and have
no security problems (or at least VERY few).  Its not finished yet,
but the part that traps #1 and #2 is done.

Hope this helps someone.

-- 

				Alan Bishop
			     ...!{decvax,akgua}!mcnc!ecsvax!bishop