D E F E A T I N G T B S C A N F L A G S by Havoc The Chaos One day while removing all possible ThunderByte AV flags from one of my viruses, I discovered a way to remove just about all flags. I will begin with the flags I removed myself, and then proceed with flags others have found, in order to create a full document on TBSCAN flags. Original credit is due to myself, except where noted. F Suspicious file access; this file might be able to infect a file mov ax, 5701h int 21h ; flagged as 'F' mov ax, 5700h inc al int 21h ; not flagged mov ax, 4301h int 21h ; flagged as 'F' mov ax, 4300h inc al int 21h ; not flagged ie, anything that restores the original state of the file might be tagged. E Flexible Entry Point; this file is designed to be able to be linked anywhere in a file. Very common for viruses. call $+3 pop bp ; flagged as 'E' call $+3 int 3 pop bp ; not flagged B Back to entry point; this file is designed to restart the program once finished. Very common for viruses mov ax, 100h jmp ax ; flagged as 'B' mov ax, 200h shr ax, 1 jmp ax ; not flagged S Contains a routine to search for executable (.COM or .EXE) files. comspec db '*.COM',0 ; flagged comspec db ').COM',0 ; not flagged, therefore inc byte ptr [bp+offset comspec] lea dx, [bp+comspec] int 21h dec byte ptr [bp+offset comspec] ; This effectively changes a search for ').COM' to '*.COM'. Get the picture? T Incorrect timestamp. Some viruses use this to mark infected files. Having the year higher than 2000 or the seconds higher than 59 will set it off. Z EXE/COM determination. The program tries to check whether a file is a COM or EXE file. Viruses need to do this to infect a program. cmp word ptr [bp+buffer], 'ZM' ; flagged! cmp word ptr [bp+buffer], 'MZ' ; flagged! cmp byte ptr [bp+buffer], 'Z' ; not flagged cmp byte ptr [bp+buffer], 'M' ; not flagged G Garbage instructions. Contains code that seems to have no purpose other than encryption or avoiding recognition by virus scanners. I have only found this when using A86. When I complied the same virus with TASM (2 passes), the flag disappeared. @ Encountered instructions which are not likely to be generated by an assembler, but by some code generator like a polymorphic virus. As quoted by Qark of VLAD: "We will take 'OR CX,CX' as an example. It can be represented by: db 09h,0c9h or db 0bh,0c9h The first two-byte combination sets off the flag, the second does not. TBSCAN is correct in flagging it, because the first 'or cx,cx' is never produced naturally. " In otherwords, when coding your polymorphic engine, do NOT USE DEBUG TO GET THE OPCODES! Instead, use an assembler. When I tested mine, I got flagged. I read this, and used debug to find "or cx,cx", and sure enough, it was 9, 0C9h. Under an assembler, or was 0Bh, 0C9h. U Undocumented interrupt/DOS call. The program might be just tricky but can also be a virus using a non-standard way to detect itself. Reference: Qark/VLAD mov ax, 6e00h ; This one is ok. int 21h mov ax, 6f00h ; This one causes a flag. int 21h mov ax, 09191h ; This one is ok. int 13h mov ax, 09191h ; This one causes a flag. int 0b6h A Suspicious Memory Allocation. The program uses a non-standard way to search for, and/or allocate memory. Reference: Qark/VLAD cmp byte ptr [0], 'Z' ; Direct MCB-Chaining ? Inconsistent exe-header. Might be a virus but can also be a bug. Does anyone have any information on this? I know if the value in the exe header in locations 10-18 are higher than 50 (or so), it will be flagged, but I fail to see why. Frans must be on to something. It is not the checksum (as I thought). I can say that much. The file that flagged it had nothing out of the ordinary that I could see, as in the stack was not odd, it was allocating the proper amount of memory, and the CS:IP entry point was fine. L The program traps the loading of software. Might be a virus that intercepts program load to infect the software. Simply put, trapping int 21 function 4Bh will cause this flag. A better idea for tsr viruses is to infect on file close, and TRUE clean it on anything else. M Memory resident code. The program might stay resident in memory. mov word ptr ds:[21h*4], offset int21 mov ds:[21h*4+2], es ; flagged Direct manipulation always causes the flag to be tripped. Another way to get the int handler established, is to tunnel (trace) and then just call the original int 21 to do the job for you. It's either that, or have a flag. Well, that should take care of the most common TBScan flags. Many people probably see the amount of Anti-Thunderbyte information that is out there and think it is a personal attack. This couldn't be further from the truth (at least from my standpoint). It _IS_ a good product, although it has several things that could have been tightned up. C'est la vie. I would like to thank Qark for additional flag information, and also Dark Angel of Phalcon/Skism for his help (even though it didn't lead to much information) with the inconsistent exe-header flag. 's been fun.