Chip Hitware 7

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

/ Chip Hitware 7 / Chip_Hitware_Vol_07.iso / chiphit7 / _viren / 95tbav / tbav.fa_ / tbav.fa

Wrap

Text File | 1997-01-10 | 12.9 KB | 248 lines

This is a list with Frequently Asked Questions. If you have a question about our product, or want to know why our product differs from some competitive products, please check out the questions below. Design philosophy ----------------- Why does TbSetup create an Anti-Vir.Dat file in every directory, instead of generating just ONE reference file for the entire system? 1) It is more intuitive. For a user it is much easier to see whether a directory is already processed by the checksummer or not. You can see in one glance what the last time was you modified the Anti-Vir.Dat file, and whether this matches with the most recent timestamp of the executable files. 2) Maintenance. If you delete an entire directory, the checksum base will be gone too. Automatically! With a single file approach, you will have to run an update utility or to accept that the database file will continue to grow for ever. The same applies if you move a directory to another disk or subdirectory: don't worry about the checksum files. They will travel automatically wherever the executable files go! 3) Security. If a company decides to introduce a new software product, they can make a backup of the diskette, scan it for viruses, and put the checksum file on the diskette, and multiply it and distribute it within the company. Now, whoever gets this diskette, the checksum file will already be there. The user won't have to bother with it himself. The new checksum file with not interfere with the already existing ones. 4) Networks. In a LAN, different users may have access to a directory via another path. One user may see the directory F:\JOHN, while someone with more access rights may refer to the same directory as G:\USERS\JOHN. With a single database approach, you will have to create a separate database for every user. With the checksum-file-per-directory approach, the supervisor just creates ONE checksum base per directory, and no matter the access rights or mappings of a specific user, if he has access to that directory, he automatically has access to the checksum file. So, if the supervisor updates a product on the network, he just creates a new checksum file for that directory, and EVERY user on the network immediately has the correct checksum information. Why does TbScanX not scan a file if I rename it, or when I move it to another directory? If you rename an executable file to another executable file, you actually do not introduce a new file on your system. The file was originally already there, and should have been checked by TbScanX already when the file was introduced on your system. If you rename a non-executable file to an executable file, you actually introduce a new executable file on the system. This quite unusual way to introduce a new executable file on the system is detected by TbFile (attempt to rename a non-executable file to an executable file). If you move a file to another directory, using the 'move' command, the file doesn't get actually copied when the destination drive is the same as the original drive. What happens is that the file gets 'renamed' to a different directory, i.e. the file remains physically where it is, but just the name reference is moved from one directory to the other. TbScanX does not scan the file in this case, because the file was already there, and has been checked when it got introduced to your system, and doesn't need to be checked again just because it is moved to another directory. Why does TbScanX, unlike some other products, not scan a bootsector if you press Ctrl-Alt-Del? First of all, TbScanX scans a bootsector immediately if you try to access a diskette. Most people insert a diskette because they need a file from it, or want to copy something on it, or just look into the directory. TbScanX will then check the bootsector, long time before you press Ctrl-Alt-Del. So there is not much need for TbScanX to check it when you reboot, the job has already been done. A second reason is that it can be dangerous to scan a diskette while trying to reboot. You usually don't reboot just for fun! In many cases, you reboot because the system became instable, or because a program instructed you to reboot the system, after it changed some vital information on the harddisk. If the system became instable, you can damage data by accessing a disk, and it is quite questionable anyway whether an instable system is still able to perform a reliable disk scan. If a program asks you to reboot, the reboot is often necessary because the system is not aware of some changes in the configuration, and it is dangerous to continue accessing the disks, without - for example - the appropriate drivers. A third reason is that it could cause people to believe that rebooting with a diskette inserted into the drive is OK, because the diskette will be scanned anyway. Unfortunately, checking a diskette can only be done before a SOFT boot, and not when you hit the reset button. It is only a partial solution. For many people, the difference between a hard and a soft boot is not clear, and they will just assume that rebooting with a diskette inserted is now always safe. So, it is dangerous, unreliable, confusing, and unnecessary in most cases. Therefor we decided not to scan a diskette after pressing Ctrl-Alt-Del. Why does TbClean not clean ALL files at once? Let's look what happens if your system is infected by a virus, and you run an 'automatic' cleaner on it. With one and the same virus, every executable file will be in one of the following states after the cleaning is terminated: 1) Files that have not been affected by the virus at all. 2) Files which were infected but have been successfully cleaned. 3) Files that have been damaged (not infected!) by the virus and can not be 'cleaned' because they have been deleted or are overwritten. 4) Files from which the cleaner says that they have been successfully cleaned but still don't work anymore (because of copy protections or various other reasons). 5) Files from which the cleaner says that it failed to clean and thus are still infected and need replacement. Now, are you going to sort things out after the cleaner is done? A much better approach is to work through the files on a one by one approach. Clean one file, judge the result, test the file, and proceed with the next one. Tedious? Yes, an even better approach is to take that backup tape, and restore all executable files. Remember, viruses are not written to be bug free, and to be compatible with all the complex configurations we are using these days. No cleaner can repair the files incorrectly infected by a buggy virus. Automatic cleaning is an illusion. If you really insist on using a cleaner, you have the best chances if you work through your files one by one. Remember also that even viruses that are known not to damage data still very often damage data because of interference with disk caches, Windows, or other system software for which the virus was not written for or properly tested against. I have seen on Internet some information how to fool TbScan. What are you going to do about it? This is nothing to worry about. We know that it is possible to fool heuristics. We know that it is possible to design a virus that TbScan can not yet detect. We have seen many examples of this in the past. Encrypted viruses have been invented to make signature scanning useless, until the AV industry invented signature wildcards and entry point tracers. Polymorphic viruses have been invented to make signature scanning completely impossible, until the anti-virus industry invented generic decryption. It is an endless battle. Some strategics are involved as well. Sometimes it is better to leave an easy to close door open, and let a virus writer spend weeks to write something that exploits this 'loophole' and then just slam this door without any trouble and any damage, than to attempt to foresee all possible future virus-writing-developments and to close all doors in advance, and let someone discover something that is much more difficult to solve. Someone who wants to attac a specific anti-virus product will finally discover something that can be used. This applies to all anti-virus products, no matter how clever they are. That's why all serious anti-virus products have to be frequently updated. If a virus is able to escape heuristic detection, we will find it with a signature. If some information leads to a virus that indeed succeeds to remain unspotted, we will do something about it. We have been doing so dozens of times in the past, and we will keep doing so. So far, there is no reason to believe that virus writers will finally come up with something that we can't handle. Why is your scanner not scanning .DLL files? So far, we have been following the approach that we don't scan something if there are no viruses yet to infect it. We could have scanned for macro viruses for years, but it didn't make sense until someone actually created a macro virus. Technically, it is possible to infect a .DLL file, but there are no viruses which are doing this. As soon as there is a virus that infects .DLL files, we will have to create a signature for that virus anyway, and this is the right time to include the .DLL extension in the default scan list as well. Granted, there are a few viruses which think a .DLL file is a DOS executable, since it contains an EXE header. They might add their virus code to the .DLL file. But since you are never going to execute the .DLL file from the DOS command prompt, you are not going to introduce a virus on your system this way. The virus won't get activated when you use the .DLL file in a Windows environment. Of course, if you have a standard executable file (.EXE or .COM) which is infected by a virus, this virus may 'infect' the .DLL file, so once you have a virus, it is a good idea to include the /allfiles option. Network related questions ------------------------- We have TBAV installed on a server, and we use TbScan with option 'once'. However, if we turn on the machines in the morning, TbScan only scans one workstation, and skips on the other workstations. If TbScan uses the 'once' option, information will be written to TbScan.Exe. The first PC scans, and updates the information in TbScan.Exe. The next PC's will conclude that TbScan has already been used this day, and proceed without scanning. To avoid this problem, you can specify a filename behind option 'once'. Instead of putting the information in the TbScan.Exe program, TbScan now records the information in the specified file. Use, for instance, 'TbScan once=c:\config.sys' to make sure that every PC maintains its own 'last time scanned' record. Note: TbScan does not alter the contents of the specified file, but records the information in a different way. Therefor you can specify any existing file. We have TBAV installed on a server, and we use TbScan with option 'once'. However, if we boot the machines multiple times a day, TbScan always scan the workstations, instead of only once. The users probably don't have write access rights to the directory where TbScan.Exe resides. Excellent! Use the method as described in the previous question. Is it possible for the supervisor to receive messages about viral activities anywhere within the network? Not with the standard TBAV utilities. There is a special network version available which features centralized anti-virus control. Contact your local vendor for more information.