home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / trojanpr / immunity.txt < prev    next >
Encoding:
Text File  |  1988-03-28  |  4.3 KB  |  100 lines
  1.  
  2. V I R A L   I M M U N I T Y   F O R   M S - D O S   S Y S T E M S
  3.  
  4. Copyright (c) 1988 J. Winslade.  This file may be freely
  5. reproduced and distributed no profit is realized by doing so.
  6.  
  7. 14-MAR-88
  8.  
  9. This technique is not presented as a 'cure-all', nor does it
  10. suggest that it, or any other technique will render a system
  11. totally immune from all types of virus and trojan attacks.  It is
  12. a technique that, when implemented and used properly, offers a
  13. system and user a certain degree of immunity from some of the
  14. 'virus' programs that are making the rounds in the MS-DOS
  15. community as of this date.
  16.  
  17. I won't get into the story behind it in this article, but several
  18. months ago I had reason to make a 'patched' version of MS-DOS in
  19. which the default command processor was not named COMMAND.COM.
  20. Although I did not realize it at the time, I had created a
  21. version of the operating system that had a certain degree of
  22. natural immunity from many of the current generation of virus
  23. programs.
  24.  
  25. Many of the virus programs do their dirty work by modifying or
  26. replacing the default command processor, COMMAND.COM.  There are
  27. been programs that will trap attempts to reference that file.
  28. There are techniques for thwarting attempts to modify it, such as
  29. setting it to read-only status, but all of them that I have seen
  30. can be bypassed by any virus writer who is anything but
  31. incompetent.
  32.  
  33. Memory-resident virus sniffers can protect against overt attempts
  34. to infect a disk, especially by those techniques that have been
  35. studied by their developers, but they cannot handle all cases and
  36. they necessitate the loading of Yet Another memory resident
  37. program at boot time.
  38.  
  39. Setting the attributes on COMMAND.COM to read-only does offer
  40. some degree of protection, thus causing a write protection
  41. exception when a write to COMMAND.COM is attempted, but any
  42. programmer worth his or her salary knows how to clear a read-only
  43. attribute from within an application.
  44.  
  45. Performing this modification is relatively simple for the user
  46. who has moderate experience in patching programs with DEBUG or
  47. another debugger or disk editor.  It is not for the rank
  48. beginner.  It is impractical to give step-by-step cookbook
  49. instructions, since the references to the default command
  50. processor name, COMMAND.COM, appear in different locations in the
  51. different versions and releases of PC-DOS / MS-DOS.  If you don't
  52. know what you are doing, find someone who does who can help you.
  53.  
  54. A modified DOS of this type has been running on a multi-station
  55. LAN for the past four months or so.  It appears to be well
  56. behaved and no apparent problems have been encountered.  All
  57. application software appears to function normally.  (A user
  58. program normally has no business referring to COMMAND.COM.)  As I
  59. stated before, this was not an attempt to immunize the system
  60. from virus programs.  We do not normally run games or public-
  61. domain utilities on the network, so we have no reason to believe
  62. that an attempt at infection has occurred.  After some thought,
  63. we realized that the immunity was a side effect of the earlier
  64. modification.
  65.  
  66. Four files in the standard PC-DOS / MS-DOS must be modified:
  67.  
  68. 1. IBMBIO.COM (PC-DOS) or IO.SYS (MS-DOS)
  69. 2. IBMDOS.COM (PC-DOS) or MSDOS.SYS (MS-DOS)
  70. 3. COMMAND.COM
  71. 4. FORMAT.COM
  72.  
  73. To perform the modification, examine the four files listed above
  74. using DEBUG (or whatever) and change ALL references to
  75. COMMAND.COM to the name you have decided to use for your new
  76. command processor.  For example, KOMMAND.COM may be used, and the
  77. modification may be done simply by changing all references within
  78. the four files from COMMAND.COM to KOMMAND.COM.  It is not
  79. imperative that FORMAT.COM is modified.  This is only to allow
  80. FORMAT to place the properly named modified command processor on
  81. new disks that are prepared with the FORMAT/S command.
  82.  
  83. It is recommended that the modification be performed on a scratch
  84. disk and the system on the scratch disk be thoroughly tested
  85. before the modified files are transferred to the normal system
  86. disk.
  87.  
  88. After the modified operating system is installed on the target
  89. machine, it should behave normally with the exception that any
  90. reference to COMMAND.COM will fail and any file appearing on the
  91. system under the name of COMMAND.COM will be ignored by the
  92. operating system.
  93.  
  94. Comments concerning this document may be directed to:
  95.  
  96. Sysop, DRBBS Technical BBS
  97. (402) 896-3537 (24h, 3-12-24)
  98.  
  99. Good Day!          JSW
  100.