home *** CD-ROM | disk | FTP | other *** search
/ Frostbyte's 1980s DOS Shareware Collection / floppyshareware.zip / floppyshareware / USCX / DOSUT-16.ZIP / HIDE.DOC < prev    next >
Text File  |  1984-12-29  |  4KB  |  69 lines
  1. NOTE:  the names of the files referred to in this documentation
  2. were changed by the software librarian in order to keep them
  3. together on a disk with other files. These were the name changes:
  4.                   from:              to:
  5.               MDSECRET.COM       HIDE_MD.COM
  6.               CDSECRET.COM       HIDE_CD.COM
  7.               RDSECRET.COM       HIDE_RD.COM
  8.               HIDDEN.DOC         HIDE.DOC
  9.  
  10.  
  11.  
  12.    The three files MDSECRET.COM,  CDSECRET.COM,  and RDSECRET.COM
  13. are  trivial  programs  in  size  and  in  complexity,  but  they
  14. illustrate  a technique for utilizing a form of file  protection:
  15. locking   out  sub-directories  from  all  but   the   determined
  16. knowledgeable user.
  17.  
  18.    The  technique involves creating a subdirectory which has  the
  19. ASCII  DELETE  character  (07FH)  as  the  first  letter  of  the
  20. subdirectory's   name,   followed  by  up  to  7   user-specified
  21. characters.   MDSECRET (MakeDirectorySECRET) then sets the hidden
  22. flag for the directory entry through the DOS CHMOD function call.
  23. The  directory can only be set as the current directory by  using
  24. CDSECRET (ChangeDirectorySECRET) and can only be deleted by using
  25. RDSECRET (RemoveDirectorySECRET).
  26.  
  27.    Of  course,  any  super-directory program which  shows  hidden
  28. files   will  display  the  subdirectory  names  created  through
  29. MDSECRET,  and a determined user could then use the knowledge  of
  30. the  directory  name  to  write a program which  can  access  the
  31. subdirectory (just like CDSECRET and RDSECRET do).   Without such
  32. a  program,  the  user  will  not  even  know  the  name  of  the
  33. subdirectory,  or even that it exists.   If the DELETE  character
  34. were  not included in the file,  the user might try random  names
  35. with  the CHDIR command,  eventually finding one and successfully
  36. accessing it.   (Note that a hidden file is just as accessible as
  37. a  visible one,  if you know its name!)  By including the  DELETE
  38. character,  however,  the  user  will  not be  able  to  randomly
  39. generate  the subdirectory name from the keyboard,  and will  not
  40. even  be  able to issue the CHDIR command from the  keyboard  for
  41. this subdirectory name.
  42.  
  43.    One important point on the use of the DOS CHMOD function :  It
  44. doesn't  make  sense to try to change the "directory" bit in  the
  45. attribute  word in a file's directory entry.   If the bit is  on,
  46. then  the  file  was  created  as  a  sub-directory  node  (MKDIR
  47. function);  if the bit is off,  then the file is a standard  data
  48. file.  That much makes good sense.  What may not be as obvious is
  49. that  you  MUST NOT set the directory bit when calling the  CHMOD
  50. function,   even   if  the  file  in  question  is   actually   a
  51. subdirectory.  DOS apparently checks to see if you have requested
  52. setting  the directory bit before it "looks" at the file,  and it
  53. exits  with an error (#5 -- Access Denied) if you have  this  bit
  54. set.   The only bits which you are allowed to modify (as far as I
  55. know)  are the archive bit,  the read/only bit,  the system  file
  56. bit, and the hidden file bit.
  57.  
  58.    If  you  have any questions about these files,  feel  free  to
  59. contact me through the PCSIG or EMAIL.  I don't always access the
  60. PCSIG often to catch messages before they roll off, and this will
  61. get worse in the near future,  as I am due to be transferred to a
  62. new city by my employer (God,  I hope I can still get to a PC  or
  63. clone!).
  64.  
  65. -Charles Incaprera  (73105,1323)
  66.  
  67.  
  68. Press ENTER to continue:
  69.