TopWare Tools

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

/ TopWare Tools / TOOLS.iso / tools / top1557 / ckot20.txt < prev next >

Wrap

Text File | 1993-02-24 | 35.7 KB | 679 lines

CheckOut CheckOut Copyright(c) 1989-93 Saturn Software Copyright(c) 1989-93 Saturn Software //////////// /////// ////// //////// & John Bintz & John Bintz / //// ///// 1519 Redwood 1519 Redwood //// /////// Davis, CA 95616 Davis, CA 95616 ////// // ///// Results from Validate File Name: checkout.exe Size: 67,856 Date: 2-22-1993 File Authentication: Check Method 1 - 4F7E Check Method 2 - 004F 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 .zip to .arj). 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 - Pathnames are maintained on archievers that handle pathnames. 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: Patricia M. Hoffman, 204/869, Robert Michal, 386/451, and John Alton, 141/250. Special thanks are due to Patricia Hoffman 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, 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 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 hundreds of 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, ARJ, 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: LHA.EXE PKUNZIP.EXE PKZIP.EXE ZOO.EXE PKUNPAK.EXE PKPAK.EXE PAK.EXE SCAN.EXE ARJ.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 9.1V97 or greater (SCANV97) 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: 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 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] 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 Logging active -L -L Log subdirectory Log subdirectory -o<path> -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 Bad Files subdirectory -B<path> -B<path> Move bad Archives Move bad Archives -A -A Move Infected files Move Infected files -I -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, -RJ 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 -RJ convert all files to Arj 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 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 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. If SCAN is called, it is called in the default mode (with memory checking) on the first file checked and without memory checking on subsequent files. If time is important, for example when an upload is checked with a caller online, memory checking can be turned off in the batch mode with the -m 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 and the -m command mentioned above). During the rearchiving process, there are several points at which you can do some extraneous processing. To invoke this processing, batch files with specified names must be located in the subdirectory from which CheckOut is executed. CheckOut examines the filenames in its boot directory shortly after it begins. If the filename exists, control will be passed to the batch file at the appropriate time(s). If it does not, CheckOut will continue normally. These batch files are summarized below. CKOT$1.BAT: Subdirectory: Work directory When called: Just prior to rearchiving Parameters passed None Example: copy c:\myfiles\bbs.ad CKOT$2.BAT: Subdirectory: Work directory When called: After processing is complete but before new file is time stamped. Paramaters passed %1 = filename of file being processed %2 = filename of dirn file CKOT$3.BAT: Subdirectory: Files directory When called: After processing for each file is complete Paramaters passed %1 = filename of file being processed %2 = filename of dirn file Example: 4comment %2 %1 -c Remarks: In the example, 4comment is a program which installs the description in the dirn file as a archieve comment. The complete 4comment package is available separately. For the example to work, Checkout must be given the name of the dirn file via the -p switch. CKOT$4.BAT: Subdirectory: Files directory When called: After all processing is complete, just before exit Paramaters passed %1 = path of files directory %2 = filename of dirn file Example: attrib -h %1\descript.ion del %1\*.ion 4comment %2 %1\*.* -c -4 Remarks: In this example, 4comment is called just once rather than for each file. To illustrate how the arguments can be used, some 4dos processing is added. CKOTSCAN.BAT Subdirectory: Boot directory When called: At the time of scanning CKOTSCAN, if it exists, is called instead of SCAN. If you are doing something in addition to scanning, you must call SCAN yourself. Parameters passed %1 = The subdirectory which is the root of all subdirectories to be scanned. Any buffer which receives this parameter must be able to accept a subdirectory may be several levels deep. Remarks: CheckOut depends upon the error number returned by SCAN to process the log and to process bad files. If you use this routine, you must set the dos error level to zero on success, 1 on an infected file, 2 on a dos error. CKOTARC.BAT Subdirectory: Work directory When called: At the time of archieving each file, CKOTARC, if it exists, is called instead of the archiever. Parameters passed %1 = The filestem of the file to be processed. Remarks: You must set the dos error level to 0 if successful and to >1 if not. CKOTUARC.BAT Subdirectory: Work directory When called: At the time of unarchieving each file, CKOTUARC, if it exists, is called instead of the unarchiever. Parameters passed %1 = The qualified filename of the file to be processed. Remarks: You must set the dos error level to 0 if successful and to >1 if not. 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. If CheckOut is executed with the "-m" switch, memory is not checked even on the first file. This feature is intended for sysops who are testing uploads while the caller is online. 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 an external batch file. 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 9.1V97 or (SCANV97). 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 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 2.00 Added ARJ and changed Lharc to LHA. Added "-m" switch to call to Scan. Added pathnames and nested subdirectories. Reworked batch file controllers 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