Code via Behaviour    [by Second Part To Hell]

  


	  *************************************************************
	  *************************************************************
	  ************                                      ***********
	  ************           Code via Behaviour         ***********
	  ************     by Second Part To Hell/[rRlf]    ***********
	  ************                                      ***********
	  *************************************************************
	  *************************************************************


  Index:
  ******

  0) Intro words

  1) The idea

  2) Structure / How could that work
       a) General Information
       b) Virus Part
       c) Random Code Generator
       d) Emulator
       e) Behaviour Checker

  3) All you need is time

  4) Last words





  0) Intro words

  'Code via Behaviour' is an idea for hard-way morphing of code, it's a kind of
  metamorphism, but much heavier than nowadays metamorphic techniques. Maybe
  it's a primitive way of AI, who knows? First of all I have to say that this is
  just an idea, nothing more. The whole thing could be trash, but I don't hope/think
  so. Past showed us that everything is born out of an idea, and that is my the
  inspiration for writing this article. The article itself is 100% theoretically,
  no codeing examples, nothing but the explained idea.





  1) The idea

     Nowadays metamorphic viruses chance one instruction with a static number of
     possibilities. For example setting a register ZERO:

       Possibility 1: XOR reg,reg
       Possibility 2: SUB reg,reg
       Possibility 3: MOV reg,0

     The reason for the static number of possibilities is the human author of the code,
     who must find different instructions, which are doing the same. And as a result
     that humans aren't perfect, the author doesn't find everything, and even if the
     author would find every, nobody would include it as there are too much. I'm sure
     that no author of a metamorphic virus would include these instructions for setting
     a register ZERO:

       MOV  reg2, reg1    ; reg2=reg1
       STC                ; Set Carry Flag
       SETC reg3          ; Set reg3 if carry: reg3=1
       ADD  reg1, reg3    ; reg1++
       SBB  reg1, reg2    ; reg1-=reg2-1: reg1=0

     Well, this is an extrem example, but that's exacly what I mean: There are nn(n) different
     instruction for everything, the only problem is how to find them, without including
     them to the code.
     Now the behaviour comes to the story:

     Let's consider the relationship between code and behaviour: Normally you have
     a piece of code, and this code is responsed for the behaviour:

             CODE --> BEHAVIOUR

     But for a virus you know what the code should do (what its behaviour is). As a result you
     could change this order and let the behaviour be responsed for the code:

             BEHAVIOUR --> CODE

     This will lead to an unknown code, which has the behaviour we need. That way you don't
     have to make the code by yourself, but create the virus' behaviour, and let the virus
     find its code by itself.





  2) Structure / How could that work

        a) General Information

           Such a virus could have three parts: The viruscode (for spreading/payload/...),
           the behaviour/code engine (for generating the different parts new) and the
           behaviour-information table (contains the behaviour of every part of the whole
           virus):

              ........  @@@@@@@@@@@@@@@@@@@@@@@  ############################################
             <- VIRUS-><-behaviour/code engine-><------------Behaviour Info Table------------>

           This simple graphic could tell you about the relationship of the part's size.
           Next step is a detailed structure of such a virus:

             -------------
             part1
             part2
             part3
             partN
             -------------
             RANDOM CODE GENERATOR -> Code
             EMULATOR: Code -> Behaviour
             BEHAVIOUR CHECKER: Behaviour & Info from Behaviour Table ->
                  if (code==good)  { exchange code; JMP to RANDOM CODE GENERATOR }
                  if (code==worse) {
                        if (part==N) { JMP to RANDOM CODE GENERATOR }
                        if (part!=N) { Get next part's behaviour; JMP to BEHAVIOUR CHECKER }
                                   }
             -------------
             Behaviour Info for part1
             Behaviour Info for part2
             Behaviour Info for part3
             Behaviour Info for partN
             -------------





        b) Virus Part

           There is one important thing you have to notice for each part of the virus:
           You have to reserve nn bytes (depends on how much bytes the RANDOM CODE GENERATOR
           generates) for every part in the code, even if the instructions needs less space:

             XOR  eax, eax -> 6631 C090 9090 9090 9090 9090 9090 9090

             MOV  ebx, 0
             XCHG eax, ebx -> 66BB 0000 0000 6693 9090 9090 9090 9090

             MOV  ecx, eax
             decrease:
             XCHG eax, ebx
             DEC  ebx
             XCHG eax, ebx
             LOOP decrease -> 6689 C166 9366 4B66 93E2 F890 9090 9090

           At that example every part has reserved 16 bytes. The rest are NOPs for filling
           the unused bytes.





        c) Random Code Generator

           The RCG creates a nn byte long value randomly. Maybe this value has the same behaviour
           as any other part, and then it replaces that equal, old part. But so far we are at
           creating a nn byte value. Let's say the parts are 16 bytes long, then the created
           values could look like that:

             0000 0000 0000 0000 0000 0000 0000 0000
             ...
             FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF





        d) Emulator

           The Emulator has to emulate the random generated code from the RCG, and check out it's
           behaviour. That behaviour has to be saved for the BEHAVIOUR CHECKER.
           It sould not compair the OPCODES, but run the code virtually, and save what the code
           did in the end:

           Code:
             XCHG eax, ebx      ; eax=ebx | ebx=eax
             SUB  ebx, ebx      ; ebx=0
             XCHG eax, ebx      ; eax=ebx | ebx=eax

           Result:
             EAX CHANGED: 0


           Code:
             XOR  edx, edx      ; edx=0
             PUSH edx           ; 0 to Stack
             XCHG ecx, edx      ; ecx=edx | edx=edx
             POP  ecx           ; ecx=0
             PUSH edx           ; edx to Stack

           Result:
             TO STACK: ecx
             EDX CHANGED: ecx
             ECX CHANGED: 0





        e) Behaviour Checker

           The Behaviour Checker has to compair the information from the Behaviour Information table
           with the result of the Emulator. If the code from RCG has the same behaviour or at least
           the important behaviour is existing, the original part will be replaced by the new one.
           If it has a false behaviour, the next part will be checked, until there are no more parts
           (than get new value by RCG) or one part is OK.





        f) Behaviour Information Table

           This table contains the Information for every part of the virus. There is one primary
           value which it contains for a part and maybe a secondary value. The primary value
           contains the behaviour of the part, and the secondary value contains all behaviours
           which are not allowed:

             CALL delta        <- 1st part
             delta: POP ebp    <- 2nd part
             sub ebp, delta    <- 3rd part

           Table:
             part1: + TO STACK: eip
                    + JMP delta
                    - JMP ???
                    - CALL ???
                    - TO STACK: ???

             part2: + FROM STACK: ebp
                    - TO STACK: ???
                    - EBP CHANGED: ???

             part3: + EBP CHANGED: EBP-delta





  3) All you need is time

     All you need is time: If a virus infects a computer, it spreads. After finishing, it
     waits for a hooked API or whatever, but it waits and that's the point. As the infected
     machine also don't use all of the CPU speed (normal using of WinWord.exe needs not more
     that 20% of CPU speed), the behaviour/code engine could use it, as it is a neverending
     story. There are two options you could do: Reserve 20-50% of the CPU speed for the engine
     or use the unused CPU speed, which is definitively a better solution.

     Another reason why the this idea could be very useful is that modern computer's speed increase
     continously, and the time of the engine won't be that problem.

     Next thing about the time: The bigger your buffer for one part is, the longer the emulator will
     take to check it's behaviour. But that's no problem, because the bigger your buffer the bigger
     the chance to get another code having the right behaviour.

     In the past nearly every virus author prefered, if the question of time and size rised, the
     smaller size of the code. Now you have to think different: The less clocks your engine uses,
     the faster your code will change.





  4) Last words

     This is, as I've already said, an idea. Nothing more, but also nothing less. I think, if
     it's possible to bring this idea to reality, it's the evolution of metamorphism, and maybe
     even a kind of primitive AI. The virus, who could include random code to itself, may include
     also other things to itself beside of the new generated code. Thinking about that makes me
     happy in one case, but scared in another case. I'm happy because I know that something generated
     by human could be intelligent. And I'm scared because I have to think at the beginning of
     TERMINATOR 3, where a computervirus becomes intelligent (you know the rest).
     But it's far from reality now. Nobody even know if it's possible at any date.
     Anyway, if this idea would become reality, AVs have to pray that they find something against it...



                                                        - - - - - - - - - - - - - - -
                                                          Second Part To Hell/[rRlf]
                                                          www.spth.de.vu
                                                          spth@priest.com
                                                          written in august 2004
                                                          Austria
                                                        - - - - - - - - - - - - - - -