General notes for TbScan and TbScanX ------------------------------------ TbScan(X) does not mean TurBo-SCAN as some users assume, but stands for Thunderbyte Scan. TbScan and TbScanX are supplied on the Thunderbyte disk which makes part of the Thunderbyte hardware PC Immunizer package. If you loaded TbScanX in video-memory it is possible that TbScan detects signatures in upper memory. TbScanX does not always scramble the signatures to gain some speed when it is using (slow) video-memory or expanded memory. TbScan and TbScanX both need a signature file TBSCAN.DAT or VIRUSSIG.DAT. Because these files are updated a lot, they are not supplied with this package. Both of these files are available at Thunderbyte support BBS +31-85-212395 (2:280/200@fidonet) or at many other BBSs. Notes concerning TbScan ----------------------- Some users think that scanning for all viruses in all files is the best scanning method (by using "TBSCAN *.* -a +n"). This is not true: It only increases the possibility of false alarms. It is not usefull to scan for bootsector viruses in .COM files or to scan for COM viruses in .EXE files. Use this option only when you already encountered a virus and want to make sure that you really destroyed all infected files. If you run TbScan AFTER running another scanner, it is possible that TbScan finds signatures of viruses in memory. This does not mean that you have a virus, but is caused by the fact that TbScan detects the search-signatures left in memory by the other virusscanner. Due to safety routines in the TbScan program, it can not be compressed with programs like PkLite, LzExe, or Diet. This is not very painfull after all because the file isn't that big! Notes concerning TbScanX ------------------------ TbScanX is Windows 3.0 aware. It is possible to load TbScanX BEFORE starting a Windows 386-enhanced-mode session. TbScanX will not interfere with copies of it running in other DOS windows. It is even possible to disable TbScanX in one window while it is still enabled in another window. With other words, TbScanX maintains a separate data area for every DOS-window. Notes concerning the format of the signature file ------------------------------------------------- The format of the signature file (also called data file) is covered completely in the manual. However, there are more scanners using the same signature file (virscan.dat) as compiled by Jan Terpstra. Unfortunately, not all scanners use the same format. There is at least one scanner that has some extensions to the signature file. These extensions that will not be recognized by TbScan(X) are: - The virus type identifier "PART" or "MAIN". In my opinion viruses that infect only the partition table don't exist and will never exist. Why? Because floppy disks don't have a partition table and are therefore not suitable to carry such a virus. A virus programmer can be pretty sure that his/her victims never share and exchange their fixed disks, so his virus would not reach other systems. So we can conclude that viruses with the keyword PART should also have the keyword BOOT. Besides, there are many bootsector viruses that are also capable of infecting partition tables. The end result is that all signatures with the keyword PART should also have the keyword BOOT, and that viruses with the keyword BOOT should also be searched on the partition table, regardless of the keyword PART. Consider this and you will understand that in almost all cases the words BOOT and PART are functional equal. Even if a BOOT virus is not able to infect a partition table there is no reason why we shouldn't scan for it. There is only one partition table and it is only one disk sector in size, so scanning speed can not be the reason. Why then using two or even three synonymous keywords? I don't know, and I will not implement it. - The virus type identifier "OVL". Only a few people know that the viruses that are able to infect overlay files do so by accident, because there are some linkers that create overlay files which are in reality a kind of normal EXE file, and these files are also treated that way by DOS. The virus "thinks" the file is a normal EXE file, and infects it. The result is that some viruses that infect EXE files are also able to infect some OVL files, it all depends fully on how their infection routine is triggered. In my opinion there are no viruses that will ONLY infect OVL files, because if they do so, they don't have much chance to spread and they will not survive. Besides, infecting these OVL file is the same process as infecting a EXE file, so why should the virus writer add a special routine to prevent EXE files for becoming infected by their virus? I don't know. The result is that the OVL keyword should always be paired with a EXE keyword, and that many EXE viruses can accidentially infect a OVL file. Consider this and you will understand that in almost all cases the words EXE and OVL are equal. And even if a virus would infect only OVL files it is not a real pain to search for those viruses in EXE files too! TbScan scans all OVL files for all EXE viruses. Better safe than sorry! - The same story applies to SYS and BIN viruses. The only difference between SYS and BIN files are their extension, their internal layout is exactly the same! For reasons beyond my comprehension, the author of That Other scanner defined two keywords for the same virus type! Can anybody explain me why it is not a good idea to search for a BIN marked virus in a SYS file? And if so, why did he omit the third synonym "DEV"? - The keyword PIF. I'm not a Windows expert, but I have my doubts whether a file with the extension PIF contains really any executable code. - The nibble wildcard consisting of a single question mark. Wildcards are used for viruses that scramble themselves and to detect some mutations of viruses that uses some different but functional equal opcodes. In both cases it is very unlikely that only a nibble would change, and even if it happens, I don't see why we should not declare the complete byte being a wildcard rather than only half of it. TbScan requires therefore always a double question mark, avoiding the implementation of special time-consuming handling for the nibble comparison. Speed is what you want and speed is what you get! - The keyword UMB. The keywords LOW and UMB are actually the same, as I will explain below in "Notes concerning the scanning of memory". With the release of DOS 5.00 the keyword UMB becomes obsolete anyway. TbScan scans automatically the Upper Memory area for all viruses with the keyword LOW set. Note that these comments are not intended to anoy the author of "That Other scanner", nor to give you the impression that his product is less than mine. In fact, I'm surprised by the speed achieved by that scanner because it has been created with a high level programming language and is not very much slower compared to TbScan. I also borrowed some of the ideas implemented in that scanner. But I have to justify to the users of TbScan(X) why I don't implement these extensions to the data file. Defining a standard is always difficult, especially if the developers don't consult each other before introducing new extensions to the format of the shared input files. :-( Notes concerning the scanning of memory --------------------------------------- TbScan recognizes two types of memory signature: LOW memory and HIGH memory viruses. The keywords are choosen not very carefully: the keyword LOW means that the virus is a normal TSR-type virus which could reside in memory below TbScan, and in upper memory. Both locations are suitable for TSR-type viruses and TbScan will scan both areas for signatures with the keyword LOW set. The keyword HIGH is intended for boot sector viruses (that have to allocate their memory by decreasing the available memory value maintained by the BIOS) and by viruses that allocate memory by manipulating the DOS memory control block chain. Consider this layout: 旼컴컴컴컴컴컴컴컴컴컴컴컴커 0Kb � � � Low memory. � � � LOW � TSR's are loaded here � � � � also TSR type viruses � � are loaded here. � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 � � N/A � TbScan is executed here � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 � � � � � Free memory � HIGH � � � � � � � � � � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 End of DOS available memory � Top loaded software � HIGH � like MCB manipulators � � and some viruses reside � � in this area � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 640Kb limit � � � Video memory � � ROM's � � EMS page frames � LOW � and Upper memory � � TSR's (and also TSR type � � viruses) can reside here � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 � System BIOS � LOW � � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 1Mb limit LOW � HMA � 읕컴컴컴컴컴컴컴컴컴컴컴컴켸 Note that TbScan does not have a special keyword for Upper Memory Viruses. Viruses that are able to use Upper Memory should also be able to use normal LOW memory, because they can not rely that there is Upper Memory in every machine they will reach. Normal TSR-viruses on the other hand can be loaded in Upper Memory using an appropriate highloader as supplied with Qemm or even the future DOS 5.00. So "UMB-type viruses" are the same as LOW viruses! There is also no need to scan allocated pages of EMS. Viruses can never reside entirely in expanded memory. They should have at least a piece of code outside the EMS window. By using that piece of code as the search- signature also those (future?) viruses will be found, without the need to scan all EMS pages. Some users think it is usefull to scan the memory for all viruses using the -allmem (+r) option of TbScan. I think it is not a good idea, because memory signatures are not the same as disk signatures. There are many scrambled viruses, but in memory they reside unscrambled. The signatures for both instances of the same viruses could be totally different! The same applies to signatures that incorporate uninitialized data. In memory the data is used for some purpose, and the memory values are different. Searching memory for disk-specific signatures is likely to cause false alarms and the signatures will not match the memory image of the virus anyway.