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