Shareware Overload

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Overload / ShartewareOverload.cdr / virus / chkout11.zip / CKOT11.TXT < prev next >

Wrap

Text File | 1989-12-22 | 32KB | 622 lines

CheckOut Copyright(c) 1989 Saturn Software & John Bintz POB 309 Davis, CA 95616 On Fidonet: 203/910 Opus386 203/309 California Attorneys' Conference Results from Validate File Name: checkout.exe Size: 57,368 Date: 12-22-1989 File Authentication: Check Method 1 - 5729 Check Method 2 - 1E3F CheckOut is a virus protection program which is intended for use in environments in which many program reside in archives such as ZIP or LZH. It breaks open each archive and calls ViruScan by McAfee Associates to check the components for viral problems. If desired, it can then repackage the archive in a different format (e.g. convert .arc to .zip). Both the filelists of opus/fido systems (files.bbs) as well as PCBoard systems (DIRN, DIRNG) are converted in the process. It will also work on a much simpler level where the user has an occasional file to be scanned or re-archived. FEATURES: - Handles nested files to any level. - Desqview compatibility - Optionally moves infected files or bad archives out of the way. - Each file process is logged and identified as ok or bad in some sense. - Control is passed to named batch files at two times so that comments can be added to the rearchived file, or files can be added to the package, etc. - Sensitive to read-only files. - Processed files can be identified so the same directory can be processed each night and only the new files treated. - Single files can be specified for scanning, conversion or both. - Can be operated either in an interactive mode with menus or from the command line, or batch - Menu mode can be used to write a batch file for subsequent use. - Can be stopped anytime and pick up where it left off. - Handles Opus and Fido files.bbs automatically - Handles PCBoard DIRn and DIRng files automatically. - Moves good files along a specified path The quality of the program as well as the feature set, has been enhanced considerably by the beta testers who did everything that could be expected and more. These include: Merry Hughes, 204/869, Robert Michal, 386/451, and John Alton, 141/250. Special thanks are due to Merry Hughes who independently tested CheckOut with live strains of Jerusalem-B, AIDS, Alabama, Dark Avenger, MIX!/Saratoga, Zero-Bug, 2930 (Traceback), Yankee Doodle, 3551/Syslock, and DataCrime II. LIMIT OF LIABILITY CheckOut is distributed as is. The author makes no representation with respect to the fitness of the software for any particular purpose and disclaims all warranties, expressed or implied. The author will assume no liability for damages either from the direct use of this product or as a consequence of the use of this software. SUPPORT There is no staff employed for support purposes. If you have a problem to report or features you would like to see implemented, either send netmail to 1:203/910 or use the comment field on the registration form. All suggestions will be evaluated for the next version. SHAREWARE CheckOut is distributed as shareware. This means you can evaluate the product before you decide to register it. If you are using it after a couple of weeks, you should register it. You can copy CheckOut or any shareware program and distributed to anyone else, provided that neither the program nor the documentation is altered and that you do not charge a fee. Because there is no advertising, distribution, or packaging cost, the price of a shareware program is often less than an equivalent package sold through retail channels. The registration form is provided in a separate file. INTRODUCTION ViruScan or SCAN has become one of the most popular methods of checking for various types of viruses. It will check boot sector and each file potentially a virus carrier on a disk for the identifying characteristics of more than 50 different virus types. For most users, this is exactly what is needed. However, for people that operate a BBS or make extensive use of BBS files, most executable files reside within compressed or archived files and these can't be processed by SCAN. CheckOut makes it possible for SCAN to check the files within archives. It operates by stepping through each file in a subdirectory, looking at the extension, spawning the appropriate unarchive program (I.e. LHARC, PAK, PKUNZIP, ZOO, PKUNPAK) and then spawning SCAN to test each of the components of the archived file. As CheckOut decompresses files and checks the components for viri, a log is being written stating that the file has been checked and whether or not it is found to be infected. Additionally, the file itself can be marked as having been checked. If there is a problem with the integrity of the archive, that fact is also noted in the log. CheckOut will cause each EXE, COM, OVL, BIN, PIF, and SYS file as well as each ARC, PAK, ZIP, LZH, ZOO, SDN in the specified subdirectory to be scanned. The files which are not processed include those with a different extension than those noted above. Most of these will be data files, and since they are not executed, they can't do any harm. However, self-extracting archives are potentially harmful and are missed by both SCAN and the current version of CheckOut. CheckOut sees the "EXE" and thinks SCAN will check it and SCAN thinks it did check (it did, but for the wrong strings). The code exists now to process self-extracting archives, but was not included in this version because it can be outwitted fairly easily. It may be more muscular by the time the next version is released. SETUP: Each program that is to be used must be located on the path. No check is made, so if you don't use a compression type, you don't need the uncompressor. In the case of SCAN, a check is first made of the directory that CheckOut was executed from. If SCAN is located there, that one is used in preference to a version somewhere else on the path. The filenames that CheckOut might look for include: LHARC.EXE PKUNZIP.EXE PKZIP.EXE ZOO.EXE PKUNPAK.EXE PKPAK.EXE PAK.EXE SCAN.EXE These programs must exist on the path if they are to be used. They can not be renamed, and they must be recent enough to handle the files which will be processed. The version of SCAN must be 1.8V51 or greater (SCANV51) because CheckOut uses features introduced in that version. Attempts to use an earlier version will cause SCAN to display a help screen rather than actually scanning. OPERATION: A. Command Line Operation: CheckOut can be operated from the command line, from a menuing system, or from a batch file. Command line operation is intended for simple tasks like scanning or converting a single file or group of files. You can specify a single file for scanning, or group of files in the current subdirectory, just by naming it. If the files to be processed reside in a different directory, you must specify the path to be scanned with a -s command. CheckOut foo.arc Scan foo CheckOut foo.arc -rz -v Put foo into a zip archive CheckOut *.* Scan all files in current subdirectory CheckOut -sx:\test\*.zip Scan all zip files on path The parameters are defined below. For more complicated situations, it is suggested that you invoke CheckOut with no parameters. That will put you into a menuing system. B. Operation from Menu: If you invoke CheckOut with no parameters, the following menu will appear. Within the menuing system there are error checks that are resistant to mistakes and from the menuing system you can write a batch file for subsequent unattended use. Subdirectory to process -s K:\UPLOADS Logging active -L yes Log subdirectory -o K:\ Bad Files subdirectory -B K:\BADFILES Move bad Archives -A yes Move Infected files -I yes Re-archive files -R no Use Time stamp code -T :: PCB DIRnn Files -P no ViruScan active -V yes Move Good files -G no Write Batch File W Do It now D The Options are explain below. The command beside the menu option is the command to be used (and preceded with either "/" or "-") in a batch file. That letter will be displayed in a different color or otherwise enhanced on the screen display for most monitor types. The screen you see may look different as a result of where you execute the program. The default subdirectory to process is your location at execution. The default log directory and badfiles directory are off the root of the drive (physical or logical) that you start from. Subdirectory to process -s<path>[filemask] This entry specifies the subdirectory and files to be processed. The default is *.* in the subdirectory you specify, and the current subdirectory if you don't specify any. However, you can include a filemask identical to those used in DOS to select a smaller subset of files. For example that mask can be a filename, *.arc, etc. Unless you specify differently, each file (EXE, COM, OVL, BIN, PIF, SYS, ARC, PAK, ZIP, LZH, ZOO, SDN) in the subdirectory specified will be processed. SDN files are treated as the equivalent of PAK files Logging active -L Log subdirectory -o<path> By default, CheckOut.LOG is left in the root directory of the boot drive and looks as shown below. Each compressed file is given just one log entry. If, for example, A.LZH had three executable files and four embedded archives, it would have just one log entry and an "infection message" would apply to any or all three files. --testing D:\FILE\UP--------10/07/89 ABCDEFGH.LZH ok 10/07/89 A.LZH Virus detected B.PAK Missing files on path C.ZIP Problem in Archive D.ZOO DOS Error E.ARC ok 10/07/89 The command -L in a batch file stops logging and the -O<PATH> command provides a new path. On the menus, just hitting the carriage return will toggle the L-variable from yes to no. Bad Files subdirectory -B<path> Move bad Archives -A Move Infected files -I If a badfile is found, a subdirectory called badfiles is created and all infected files (as well as bad archive files) are relocated there. A note is also made in the log, of course. At any time, you can get rid of both the file and the subdirectory but there is no possibility of it causing a problem just sitting there. Another path is specified by the -B<path> command. The -A and -I are yes/no switches. Re-archive files -RL, -RZ, -RA, -RP, -RO If the archives are to be converted to something else, this switch is used to specify the target format as follows: -RL convert all files to Lharc -RZ convert all files to Zip -RA convert all files to Arc -RP convert all files to Pak -RO convert all files to Zoo If you specify the -r switch, CheckOut will re-archive all files in the specified format. Even if all files are already in the target format, there are some advantages to rearchiving. The advantages are all the files are put in the same archive format, you make sure that nested archives are consistent, that is that there are no "arc" files buried within a "zip" package; all comments advertising other boards are eliminated; all files are maximally compressed; your own comments can be added without negating the advantages of the time stamp and there are a number of operations that you can perform automatically as discussed below. Nesting is performed as deep as you will want to go. All archives within archives will be converted to the format specified. Since CheckOut processes each level of nesting by going one level deeper with subdirectories, the theoretical level is the length of the DOS command line (120 characters) which would allow for something more than 20 levels. It hasn't been tested that deeply, however, so there might be some other DOS limitation which I am not aware of. During conversion, a running total of starting size and finish size is kept which is printed to both the screen and to CheckOut.log. These totals should be accurate regardless of whether the conversion process is completed or you exit prematurely with ^x. Use Time stamp code -T<time> This is a very useful switch although its usefulness is not readily apparent. If you were to set the switch "-T5:55", the time stamp of all files would be changed to 5:55 as they are processed. Then if you were to execute the program upon the same subdirectory the second time using the same switch, any file which had a time stamp of 5:55 would be consider completed and would not be processed the second time while all other files would be processed. You must use a legitimate time; if you were to enter with 6:66, the process would not work. Using this technique, you can have CheckOut process the same subdirectory every night and process only the new files received that day. There are some disadvantages in using this technique for marking files. Obviously, a file might just happen to be time stamped at the specified time and get bypassed. Obviously the time stamping can't be used for anything else, if you use it for this purpose. However, it is not often used for any other purpose. Although not well known, DOS will time stamp a file by 2-second intervals as well as by hours and minutes. The seconds are not displayed with a "dir" command. Consequently, if you ignore the hours and minutes and check only the seconds, the time stamp of the file is not altered in any visible way. You can do that with the command "- T::ss" e.g. "-T::20". Since ss is really 2-sec intervals (instead of seconds), it can be no larger than 30. Additionally, it should not be 0 as this is the most common stamp. In the menu, you can specify hours, minutes, and seconds. If you want CheckOut to ignore, for example, hours and minutes, you can enter the character ":", or just hit the carriage return and it will be automatically entered. PCB DIRnn Files -P<path/DIRn> for OPUS and Fido Systems Most BBS systems maintain an independent list of files. Whenever files are rearchived, the filename on that list must be changed. Finding that list is easy in the case of Opus and Fido systems. It is always called files.bbs and it is always located in the same directory as the files. If you convert archive types and there is a file called files.bbs, the filenames on that list will be changed (e.g. from foo.arc to foo.zip) automatically. PCBoard BBS In the case of PCBoard, you must specify the path and the filelist to be changed since there is no way for CheckOut to know either. You should specify just the DIRn name. Given a DIRn name, CheckOut will look for a DIRng file and if it is there, it will change the filename there as well. Perhaps, the filelists of other BBS systems can be processed with this method. It doesn't make any difference where the filename is located within the line. However, it will not work on those systems on which the file stem and the file extension are separated by spaces. VirusScan active -V CheckOut calls SCAN automatically after all of the components are unarchived. If you simply want to change archive types, you can eliminate scanning with the -v switch. Move Good files -G<path> (-J<path>) If you select the -G option, only the files that have been identified as good will be moved along a path. At the same time the physical file is move, the file description in the files.bbs of the source subdirectory is moved to files.bbs of the destination subdirectory. The working model supported by this option is one where you don't allow immediate access to uploaded files until they have been tested. After testing, they go to an a subdirectory that can be accessed by users and subsequently to a categorized subdirectory. The -J option exactly duplicates the -G option, but it can only be activated from a batch file. It is not expected that many people will use it, but it can be useful for backup purposes. This version will not handle the four DIRn files involved in this option. Except for the fact it won't discriminate between good and bad files, this operation can sometimes be implemented with a few batch commands following the command that runs CheckOut. Write Batch File W Selecting this option writes the parameters you have selected to disk under the name CKOT.BAT. That batch file can then be run in an automatic procedure. It is easier to specify the parameters under program control and more reliable as well as there are a number of checks for proper format, correctly specified subdirectories etc. If an unattended batch file has errors, there is little that it can do but abort. Do It now D When you have set all the parameters, select this option and CheckOut will do whatever you have specified. If you have made a mistake and you can see that CheckOut is not doing what you wanted, you can exit with ^x and try again. C. Batch File Procedures The basic batch file is defined by the menuing system and the bat file it produces can be used in a nightly maintenance procedure subsequently. There are some additional batch controls as defined here (in addition to the -j command mentioned above). During the rearchiving process, there are two points at which you can do some extraneous processing. At the time all the files are about to be put into the archive, CheckOut will look for a batch file called CKOT$1.BAT and run it if it exists. At the time the files have been put into the archive, but before it has been time and date stamped, it will run a batch file called CKOT$2.BAT if it exists. If they don't exist, CheckOut will continue normally. These files must be located in the same directory that CheckOut is executed from and that directory must be on the path. For example, if: C:\Util Where CheckOut is located C:\Bink Is where you execute your batch file from Z:\Uploads Is where the files to be tested are Then, CKOT$1.BAT and CKOT$2.BAT must be located in C:\bink because CheckOut will look for them there at startup and if they are present, will hand control to them at the appropriate times. However, at the appropriate time CheckOut will be processing the files in Z:\Uploads and can execute your batch files only if C:\bink is on the path. CKOT$1 can be used for such things as adding a file to every archive, or deleting named files from archives, sorting files in an order, etc. CKOT$2 can be used for something like installing comments in every archive. The advantage of doing it at this point is that the commenting process will not change the time stamp. In the case of embedded archives, these batch files are called only at the first level. You can't comment each nested level or process each subgroup of files with batch files. Miscellaneous Notes When SCAN is called If you watch the program run, you will notice that SCAN does not check every archive. While this may seem like a program error, CheckOut examines the archive first and asks SCAN to check only when there is something to check. If all the files in the archive were *.doc or *.c, there is nothing for SCAN to do so it isn't executed for that archive. The first time SCAN is executed, it checks for all memory resident virus types it knows about. Subsequently, that step is bypassed and memory is not checked. This assumes that the version of SCAN is later than 1.8V51. Exit prior to completion: CheckOut can take a long time to complete the task it is asked to do. If there are 200 files in a subdirectory, the unarchiver must be called at least 200 times, as must be SCAN and the archiver. Whenever CheckOut is running you can stop it with control x. It will not stop right away, but rather it will finish processing the file it is working on, cleanup, and then terminate. If you are using the "-t" parameter explained elsewhere, the next time you execute it, it will start with the file that it left off with. If you are operating from a batch command, you can probably terminate with a control c, but you may wish you hadn't. Since CheckOut isn't in control, you may get a false log entry and you will certainly have a mess on the disk to clean up. Read only files Many programs which repackage archive files have trouble with read only files within an archive. It often happens that the stray read- only file is left in the work directory because it can't be erased. The file then is put into every archive subsequently processed. That problem should not occur with CheckOut since the read-only bit is checked, and changed if necessary, before it is erased. DESQVIEW DesqView is checked for and supported if it is present. Consequently, it should stay within its partition relatively well. On a 386 under Desqview, nothing burst through partitions in this version (it did in the last version which did not check for DesqView). CheckOut, with any of the programs specified except for PAK, will run in a 256K partition. If any of your programs are PAKed, you will need a 300K partition. This, of course, does not take into consideration anything you might run under CKOT$1.BAT or CKOT$2.BAT. LEGAL ASPECTS Many sysops have not considered their legal exposure caused by the presence of infected files on their board. If your board is hit with a virus, there is certainly a technical problem. But if you've performed the appropriate backup operations, under the worse set of circumstances, you probably can clean up the problem within a week. However, if someone downloads an infected file and chooses to take legal action against you, that problem certainly won't be cleaned up in a week, and it may involve years. Of course, the best way to deal with this problem is to prevent it. To my knowledge, there is not a better way to prevent it than using CheckOut and SCAN consistently, automatically, on all files before they can be downloaded by a user. If, despite your best efforts, there is an action against you, you have two basic defenses: (1) You didn't do it, or (2) You did do it but there are extenuating circumstances. If the file in question is not from your board, and every file on your board is stamped as 6 sec. past the minute and the file in question is not, that seems to me to be a strong argument. If you can't demonstrate that the file came from elsewhere, you must demonstrate "a reasonable standard of care" and that you did not deviate from that standard in this case. It is intended that the log should provide the documentation to make that claim. It has not been tested legally and it is not known to be convincing to any court. You should, on occasion, remove the file CheckOut.LOG and store it off system. Some lawyers would undoubtedly tell you to store it in a manner that you have no access, so that no one can raise the question of whether or not the data is honest. Finally, you should bring the matter up with your lawyer for advice. The author of CheckOut claims no legal expertise and nothing said here should be regarded as legal advice. NOTES on ViruScan As pointed out earlier, CheckOut will not work at all with versions earlier than 1.8V51 or (SCANV51). However, you should plan to keep SCAN up to date because new virus checks are installed continuously. The latest version of SCAN is always available on the HomeBase/CVIA BBS (Computer Virus Industry Association) at (408) 988-4004. It requires a separate registration and registration fee as explained in the VirusScan documentation. If, on the initial pass, SCAN finds a virus in memory, SCAN immediately stops operation and beeps until you do something. If you should get a warning about a virus in memory, you should POWER DOWN and reboot from a write-protected floppy disk and execute steps to remove the virus. The nature of these steps is beyond the scope of this documentation; however, by checking regularly in a scheduled procedure, you should never reach the point where the infection is already in operation at the time of testing. The simple unarchiving of a file with the Dark Avenger virus, of course, puts the virus in memory (in a nonoperative state) where it will be detected by SCAN. The operation of SCAN is fully documented and the documentation is updated with each new version of the program. Things to go wrong There aren't at present, any known bugs with CheckOut. There are a variety of circumstances that may produce results that look like bugs. If PAK is the only thing that fails to operate, it is likely that you don't have enough memory assigned to the task. If PKUNZIP asks questions about overwriting files, it is probably because you are working on an achieve in which paths are specified and there is more than one file with the same name and different paths. There are not many files like this, and there is no easy way of handling them. If you are running under DesqView, and SCAN start beeping with the first file, that generally means that your partition environment is not intact. That doesn't happen very often and doesn't happen at all, once CheckOut has gotten beyond the first file. Having two files of the same name in the same directory will cause problems. This can happen, if, for example, you start with myfile.arc and myfile.lzh and convert them both to zip. If the files are one level, the second myfile.zip will overwrite the first. If there are embedded archives, and CheckOut has to leave the subdirectory, it will come back, see myfile.zip, and and start processing the next file. The bottom line is all files between the two positions will be processed twice. If SCAN only shows you a help file, rather than actually scanning, it means that your version of SCAN is too old. You need to update to 1.8V51. It is also possible that the first file is processed correctly and the errors start happening on the second pass because older SCANs are not familiar with the commands being fed to it starting with the second pass. It should be said that the vast majority of files are handled by CheckOut without problem. Approximately 4000 files were processed during testing and only one caused a problem; that one being a file called PCWORLD which contained multiple files with identical names and different paths. We would appreciate being informed should you find any file that is not handled properly. HISTORY 1.1 Corrected a mistake in the validate data 1.00 Added the break key, ^x Added re-archiving, including filelist handling, passing control, etc. Added front end interactive processor and batch file writer. Added filemasks so that subgroups of files can be selected. Added switches -p, -v Added capability of handling nested files. Added Desqview support. 0.95 Bug fix version. .94 had a serious problem processing files located at the highest level (A:\ C:\) 0.94 First released version