I realise that this sort of thing was done in a crypt journal one time
but since then Franz has added four or five new flags and they haven't
been covered.  While working on my polymorphics for Hemlock I discovered
how the '@' flag was triggered and had to share my knowledge with the
world.


codeseg segment
main    proc    far
        assume cs:codeseg,ds:codeseg

        mov     ax,codeseg
        mov     ds,ax

        mov     ah,9                    ;Display a message.
        mov     dx,offset tbscan
        int     21h

;----------------------------------------------------------------------------
;    The TBSCAN '@' flag.
;
;    TBSCAN says "Encountered instructions which are not likely to be
;    generated by an assembler, but by some code generator like a
;    polymorphic virus."
;
;    To give you an example of how TBSCAN finds this you must understand
;    that in many circumstances it is possible to have two different ways
;    of representing the one instruction.
;
;    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.
;
;     |0   0   0   0   1   0 | 1 | 1  |   <- 0B
;     |0   0   0   0   1   0 | 0 | 1  |   <- 09 (triggers a tbscan flag)
;     |                      |   |    |
;     |      opcode          |dir|word|
;     |                      |bit|    |
;
;    Above is the format of the first byte of the OR instruction.  As you
;    can see the 'direction bit' is the difference between them.  If the
;    direction bit isn't set (which is what TBSCAN is looking for) it
;    means that the source and destination fields exchange roles.  A compiler
;    won't do this, but a polymophic engine will.
;
;    Likewise there are two ways of doing MOV AX,1234h
;       db 05h,34h,12h  or  db 81h,0c0h,34h,12h
;    The second one will trigger the '@' flag as well.  This is because
;    with AL/AX the instuctions are one byte less in size than with the
;    other registers.  An assembler will NEVER use the method that takes
;    more bytes, but a polymorphic engine will.  These are all things to
;    watch out for when constructing a polymorphic engine.  Remember to
;    make the instructions natural.
;
;    Franz deserves a clap for spotting these little things.  Most of the
;    other AV companies are content to sit on what they've got, but TBAV
;    is continually improves.  It is a good product.
;
;----------------------------------------------------------------------------


        db      0bh,0c9h                ;OR CX,CX
        db      9,0c9h                  ;OR CX,CX

        db      05h,34h,12h             ;ADD AX,1234h
        db      81h,0c0h,34h,12h        ;ADD AX,1234h



;----------------------------------------------------------------------------
;    The TBSCAN '1' flag.
;
;    TBSCAN says "Found instructions which require a 80186 processor or
;    above."
;
;    This is pretty obvious.  Just anything that won't run on an 8088.
;    Easy enough to avoid.
;
;----------------------------------------------------------------------------

        shr     ax,3                    ;This instruction only works on 286+

;----------------------------------------------------------------------------
;    The TBSCAN 'A' flag.
;
;    TBSCAN says "Suspicious Memory Allocation.  Program uses an unusual
;    way to search for, and/or allocate memory."
;
;    It just looks for a compare with 'Z' instruction.
;
;----------------------------------------------------------------------------

        cmp     byte ptr [0],'Z'                ;Often used while playing
                                                ;with MCB's.


;----------------------------------------------------------------------------
;    The TBSCAN 'U' flag.
;
;    TBSCAN says "Undocumented interrupt/DOS call.  The program might be just
;    tricky but can also be a virus using a non-standard way to detect
;    itself."
;
;    The only thing you have to watch out for here is calling int21 above
;    AH=6e or use interrupts that are obscure (above 80h probably).
;    There are plenty of unused int21 functions below 6e so it shouldn't be
;    hard.
;
;----------------------------------------------------------------------------

        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


        mov     ax,4c00h
        int     21h             ;Terminate

tbscan          db      'TBSCAN FLAGS ME$'

;----------------------------------------------------------------------------
;    The TBSCAN 'S' flag.
;
;    TBSCAN says "Contains a routine to search for executable (.COM and .EXE)
;    files."
;
;    This just means that '*.com' or '*.exe' is in the code somewhere.  You
;    shouldn't have to worry about this because wild cards are only used
;    in direct action viruses.
;
;----------------------------------------------------------------------------

wildcard        db      '*.com',0

main    endp
codeseg ends


;----------------------------------------------------------------------------
;    The TBSCAN 'K' flag.
;
;    TBSCAN says "Unusual stack.  The program has a suspicious or an odd
;    stack."
;
;    That flag can't be demonstrated here, but what it means is that the
;    SS:SP points past the end of the file.  This is only for EXE files
;    and can be seen in some of my viruses.  There isn't much that can
;    be done about this unless you change the stub/infection code to your
;    virus.
;
;----------------------------------------------------------------------------