Introduction:

  The idea of having an opcode emulator in a virus scanner to decrypt a
  very polymorphic virus isn't a novelty anymore. The more decent
  scanners can handle viruses that have a complex decryptor, using a
  generic decryptor to take the protective shell from the virus away,
  making the structures of the virus very visible to the scanner.

  So far, every polymorphic engine that is designed is able to make a
  certain type of decryptor, with variations in it's general behaviour,
  but not a generic encryptor.

  Since we, virus writers, also must adapt to newer programming
  technologies, a further step in virus advancement is generic
  programming. This generic programming can be used for any sort of
  virus related approach.

Background:

  Every polymorphic engine is based on certain rules that will be used
  in a random order and trash instructions and instructions that compose
  another opcode. But what about a polymorphic engine you can feed a
  piece of CODE to, and the engine generates mutations of that code?
  This would truely be a real polymorphic engine and will polymorph
  everything, regardless of what it does. Take this for an example:

        MOV AX,3D02
        INT 21

  If you feed this to the generic polymorpher, you might get the
  following result:

        SUB AX,AX
        ADD AX,3000
        CMP AX,78AF
        JE NEVER_JUMPS
        XOR AX,0D02
  NEVER_JUMPS:
        INT 21

  Or if you want to generate a decryptor, you can feed this to the
  polymorpher:

        MOV SI,OFFSET ENCRYPTED_VIRUS
        MOV AL,32
        MOV CX,VIRUS_LENGTH
  DECRYPT_VIRUS:
        XOR BYTE PTR [SI],AL
        ADD AL,4
        INC SI
        LOOP DECRYPT_VIRUS

  You might get this as a result:

        MOV SI,OFFSET ENCRYPTED_VIRUS+145
        ADD SI,-145
        MOV AL,33
        DEC AX
        MOV CX,VIRUS_LENGTH XOR 1234
        XOR CX,1234
  DECRYPT_VIRUS:
        XCHG SI,DI
        XOR BYTE PTR [DI],AL
        XCHG SI,DI
        INC AL
        INC AL
        INC AL
        ADD AL,1
        SUB SI,-1
        DEC CX
        JNZ DECRYPT_VIRUS

  As you have noticed, the polymorpher only puts random instructions in
  the place where it could compose more compact instructions, it doesn't
  swap opcodes. This should be generated by a separate module, because a
  the polymorpher doesn't know what it is allowed to swap and what's not
  allowed to swap. To generate a decryptor, you must call two engines,
  like in the diagram shown:

           ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿          ÚÄÄÄÄÄÄÄÄÄÄÄ¿
    (1) >>Ä´OPCODE SCRAMBLERÃÄÄÄÄ>>ÄÄÄÄ´POLYMORPHERÃÄ>> (3)
           ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ    (2)   ÀÄÄÄÄÄÄÄÄÄÄÄÙ

        (1)     Input parameters to generate a decryptor
        (2)     Generic Decryptor
        (3)     Polymorphic Generic Decryptor

  You can make both the opcode scrambler and the polymorpher as complex
  as you want. In it's most simple implementation, the polymorpher has a
  little drawback: since it polymorphs one opcode at a time, the random
  opcodes and not be mixed with random opcodes from the next operand.
  The advantage is that you don't need to track the registers, but it's
  polymorphic structure is still somewhat predictable. There are a few
  problems considering the polymorpher:

    þ Recalculate branch jump opcodes
    þ How to handle registers set to pointer
    þ How to fully mutate a virus? You must keep the original metavirus
      code, otherwise it would polymorph the polymorphed virus.
    þ How to set aside data from code while morphing?

  An approach to resolve the jump and register handling opcodes is
  making some sort of relocation table, as used in EXE files. If you
  want to polymorph a piece of program you feed the polymorpher the
  range of jumps it should adjust. You can put this on the stack while
  calling the engine, or setting some pointer to a predefined table,
  whichever approach you like most. Make sure you can relocate both 8
  and 16 bits addresses, both direct or indirect.

  You can also generate a range table which must not be morphed and to
  which references should be updates (pointer registers).

  A relocation/exclusion/resolve table (RER table) can look like this:

  enum RER_types {
    RERT_nil,           ; 0 - end of RER chain
    RERT_8rel,          ; 1 - 8 bits relative address (conditional jumps)
    RERT_16rel,         ; 2 - 16 bits relative address (call)
    RERT_16dir,         ; 3 - 16 bits direct address (pointers & jumps)
  }
  struct RER_table {
    RER_type    : unsigned char;
    RER_address : unsigned int;
  }

  After using this table on morphing the code you want, don't forget to
  update the table with the new addresses if you want to morph again the
  current result. You can, if programmed in a good style, call the
  morpher multiple times, and each time it will morph the routine
  specified.

  A bit harder is including the possibility to shrink a routine that was
  generated by a previous morph. To expand and add instructions that do
  the same thing is easier than shrink them into a compact instruction,
  as you need to know how a few instructions can be optimized into less
  instructions or a shorter variant. Some simple algorithms are
  possible, like changing an ADD <reg>,1 into an INC <reg> or even more
  complicated things like this:

  Unoptimized                                   Optimized
  CMC                                           JC ERROR
  JNC ERROR
  CMC

  XOR AX,AX                                     MOV AX,3D02
  ADD AX,3D02

  Maybe it's best to seperate the shrinker module too, so you first let
  the shrinker optimize the virus to what it thinks that is the shortest
  way, and next calling the morphing engine to enlarge it again. Both
  can use the same instruction table and RER table. You can also add an
  overlapping module that randomly calls both the shrinker and morpher,
  thus optimizing some parts of the virus while expanding other parts.

  Thus, the modules are like this hierarchy:
                       ÚÄÄÄÄÄÄÄÄÄ¿
                       ³Scrambler³(1)
                       ÀÄÄÄÄÂÄÄÄÄÙ
                        ÚÄÄÄÁÄÄÄ¿
                        ³Mutator³(2)
                        ÀÄÄÄÂÄÄÄÙ
                        ÚÄÄÄÁÄÄÄ¿(3)
                  ÚÄÄÄÄÄ´MorpherÃÄÄÄÄ¿
              ÚÄÄÄÁÄÄÄÄ¿ÀÄÄÄÄÄÄÄÙÚÄÄÄÁÄÄÄÄ¿
           (4)³Shrinker³         ³Expander³(5)
              ÀÄÄÄÄÄÄÄÄÙ         ÀÄÄÄÂÄÄÄÄÙ
                                 ÚÄÄÄÁÄÄÄÄ¿
                                 ³Garbage ³(6)
                                 ÀÄÄÄÂÄÄÄÄÙ
                                 ÚÄÄÄÁÄÄÄÄ¿
                                 ³Trasher ³(7)
                                 ÀÄÄÄÂÄÄÄÄÙ
                                 ÚÄÄÄÁÄÄÄÄÄÄ¿
                                 ³Randomizer³(8)
                                 ÀÄÄÄÄÄÄÄÄÄÄÙ

  (1) Will put instructions in a random order
  (2) Will choose other registers for the actions that must be done
  (3) Will call randomly the shrinker and expander to mutate the code
  (4) Shrinks code by optimizing instructions that it knows
  (5) Expands code by creating multiple random opcodes with the same
      functionality
  (6) Adds random do-nothing instructions
  (7) Adds plain garbage (random numbers)
  (8) Random number generator, must to able to do both slow-random and
      regular random (for slow and normal poly/mutating)

        Rajaat 29A, November '98