

            ****************************************************
                           Crazy ToDo list for VXers
                        by Belial & Second Part To Hell
            ****************************************************



  Index:
  ******

  0) Introduction

  1) Going to space

  2) VX Fairy tales of ELFs and DWARFs

  3) Fitness functions

  4) Communication protocoll

  5) Brainfuck-like virus







  0) Introduction

     We present a set of crazy ideas for VXers which came to our minds in the
     last couple of months. Even it would require a lot of work, realisation
     of any of these ideas would have a great impact.

     Idea #2 (about DWARFs) has been written by Belial, the others by SPTH.

     We hope you enjoy it!

                                              Belial & Second Part To Hell
                                                                March 2012







  1) Going to space

     In 29a#1, Mister Sandman wrote a text called "Life in Saturn!", where he
     talked about sending a virus to Titan/Saturn with NASA/ESA Cassini-Huygens
     space mission. In the space craft there was a CD which are filled with
     data people sent via internet. Mister Sandman proposed to send in a virus,
     which will travel 1.5 billion kilometers for 7 years. How great!

     I dont know if Mister Sandman (or somebody else) did it - but the idea
     has burned into my brain.

     So I want to give another possibility for going out to space.

     There is an operation system called VxWorks developed by Wind River Systems.
     (Yes it has a cool name, but lets focus on something else) It is designed
     for enbedded systems, and is used in printers, hardware firewalls, trains,
     car controll systems (iDrive), and even controll systems for airplains
     (Airbus A400, Boing 747) or attack helicopter Apache Longbow(!). This is
     an extremly impressive list.

     But the real interesting systems which use VxWorks are spacecrafts! It is
     used in recent projects such as comet mission Deep Impact and Stardust,
     in space telescopes (James Webb Space Telescope), or Mars missions such as
     Sojourner/Pathfinder or Mars Science Laborator/Curisity.

     (You can find a free trial at Wind River System's homepage for downloading)

     A virus going to space - wow...







  2) VX Fairy tales of ELFs and DWARFs

     Long ago in the early years of the second age great elven smith forged 
     the rings of power ... No, this is not the fairy tale i'm going to tell
     you. My story does not take place in the second age but in the year
     2011 when i was visiting the ph-neutral conference.

     The talk "Exploiting the hard-working DWARF - Trojans with no Native 
     Executable Code" influenced me to write this short article. The title 
     made me very curious and  while sitting in the audience i was immediately 
     thinking whether it would be possible to use this technique for virii, 
     worms and other malware. So here we go:

     DWARF is a data debugging format and its name is a medieval fantasy 
     complement to "ELF". Its main features are:

     1) A plattform independent byte code for exception handling which is 
        embedded into each ELF file created by the gcc and other compilers.

     2) A virtual machine located in the libgcc which executes the DWARF code.

     At the time of an unexpected procedure termination (when an exception is thrown
     from within the procedure) it is necessary to restore the registers and pass
     control to the exception handler. The DWARF byte code is turing-complete
     and used to restore the different register values. For DWARF manipulation, the 
     speakers introduced KATANA, a tool which allows it to disassemble the DWARF byte 
     code, modify it and copy it back to the corresponding ELF file.

     You may think now: Wow, a plattform independant byte code in every ELF 
     executable, just give me the documentation, the KATANA tool and
     let's rock. But the presentation of a simple dwarf-trojan during the talk
     which is placed into a small application and which starts a bash as a 
     proof of concept showed also the limitations of this approach:

     DWARF is not comparable to other byte code like java for example. It can be used
     to perform complex computations and set register values but you can not jump into
     sys-calls directly. Instead you have to find some code in memory which jumps
     to a sys-call and uses registers to set up the sys-call parameters (return to libc
     technique). Therefore, the elf file is modified the following way: 

     1) Dwarf byte code is injected to set up registers which are necessary for the 
        sys-call. 

     2) The address of the code snippet in memory which jumps into the sys-call is 
        written on stack (thats possible because DWARF allows us to modify the stack 
        pointer).

     3) The exception handler is overwritten with a simple "ret" instruction.

     This shows that simple modifications of an ELF file with DWARF byte code injections 
     are possible but its difficult to implement a complete trojan/virus. Nevertheless, 
     may be one day the ring erm DWARF of power will be crafted ;).

     For further information read:

     Complete Paper: http://ph-neutral.darklab.org/talks/tr2011-680.pdf
     Talk on another conference: http://www.youtube.com/watch?v=nLH7ytOTYto







  3) Fitness functions

     Nondeterministic algorithms for problem solving are fascinating. By pure
     randomness and a clever selection system one gets solutions to given 
     problems, which are nontrivial.

     Now we have a nontrivial problem: How to avoid detection of the virus by AV?

     We could try using nondeterministc algorithms to reconstruct our own code,
     and apart some other problems (like what are legal mutations) one mayor
     problem appears: 

     How could we know that our new created code is indeed not detected by AVs?

     In my artificial Evolution project I used nondetermistic code mutations
     (after defining a language which is robust under mutations - see Evolus or
     my texts about it in vwb2011 and valhalla1), and relayed on Darwins
     idea of natural selection: the mutations which were letal or which didnt
     avoid detection of AVs get killed, the others continue spreading.

     A more concrete and relayable realisation of a selection system would be
     awesome - but how would this look like?

     One solution would be: You create with a nondeterministic code generator
     your new generation, and automatically upload it to pages which scan an
     uploaded file with many different online scanners, such as VirusTotal
     or Jotti's malware scan. With the output of the scan, you can define a
     simple fitness function:


        fitness = 1 - (detected by how many scanner)/(number of scanners)


     This solution relies on extrinsic properties (the availability of online
     scanners). Shouldnt there be a better way to define a fitness? Maybe
     just by relying on intrinsic properties to be independent?







  4) Communication protocoll

     There has been a very interesting article "Virus infects worm by mistake"
     by Loredana Botezatu (http://www.malwarecity.com/blog/virus-infects-worm-by-mistake-1246.html).
     In the article, she talks about the symbiosis between worms and viruses.

     For the virus, infecting a worm is an advantage as it can spread much
     faster. For the worm, the advantage comes from a higher change to avoid
     detection due to the new infection. A scanner might just detect and
     desinfect the virus - as the virus might have changed some minor things
     in the file, simple checksums (which are used mainly for constant worms)
     do not work anymore.


     Now some questions raise:

     1) I wonder how a virus could search intentionally for worms and infect
     them, to travel faster. How can it identify worms on a system? By running
     processes? Via autostart-options? or hook some network APIs? Would be a
     pretty great technique.


     2) I wonder how a worm could become a host for viruses more often
     intentionally, to change its form slightly when an AV desinfects the virus.
     This might be harder, because how can you identify a virus on the system?
     Most likely you would search for viruses that search for worms (from #1)...


     Maybe the best thing would be a silent agreement between viruswriters. 
     Like the worm writes a Reg-Key HKEY_CURRENT_MACHINE\TravelOffer = "C:\wormfile.exe".

     A virus searchs for this agreement-string, and infects that file. The worm
     spreads the infected file.

     Pros: Virus can travel; Worm gets infected and changes its form, gets 
           undetected (for simple searchstrings).

     Cons: AVs can interfere. This has to be solved.


     Of course such agreements can be extented to a bigger protocoll. Two
     things have to be solved:

     What information is worth to share with an unknown entity? Things like 
     "Hey, IP something is very nice, try it"? Or "Be aware of program XXX, it
     might be a honeybot". What more clever things could be useful to share?

     One big problem is of course the interference of anti virus software. As
     soon as some protocoll is defined (and it should be defined publicly I
     think), AVs could use the same informations or spread misinformation. A
     sort of "skepticism" would be required.







  5) Brainfuck-like virus

     Brainfuck is a Turing-complete language with an very small instruction
     set with 8 entries:

               >         ++ptr;
               <         --ptr;
               +         ++*ptr;
               -         --*ptr;
               .         putchar(*ptr);
               ,         *ptr = getchar();
               [         while (*ptr) {
               ]         }

     A "Hello VXers!" looks like this:
     
       ++++++++++++[>++++++>++++++++>+++++++++>+++>+++++++<<<<<-]>.>+++++.>..
       +++.>----.>++.++.<<<.>+++.+.>+.


     This is beautiful - but writing a virus for Brainfuck is not possible as
     there is no connection between the interpreter and the operation system.

     However we can write a Brianfuck-like virus - namely a self-replicator
     with an extremly small instruction set.

     There are two things that we can do:

     1) Create a virus for the smallest possible subset of x86 instruction set

     2) Create a virus for an one instruction set computer


     ad 1)
     I've played with this idea for some time, my goal were 8 instructions (as
     this is the number in the Brainfuck set).

     My first idea was merge push/pop/mov by using the stackpointer, and access
     all registers by using pushad/popad, somehow like this:

             inc byte[esp]
             inc esp
             popad
             pushad

    In contrast to Brainfuck, there is not need for dec esp/byte[esp] as the
    source (esp or byte[esp]) are cyclic. It turned out that including logic
    and a jump instruction leads to a too big instruction set.

    My second attempt was a more "natural" instruction set. It roots on my
    language for Artificial Evolution with 43 instructions, which has been
    reduced by Peter Ferrie in his text "Flibi: Evolution" in VB May 2011,
    where he showed that 18 instructions are enough for having a similar kind
    of language.

    I reduced it to 8+1 instructions, where i believe (but can not proof) that
    the set is complete:


             xchg ecx, eax
             xchg dword[ecx], eax

             and  eax, ecx
             xor  eax, ecx
             rol  eax, 1

             push eax
             pop  eax

             jnz  dword[Mem1]      ; *


    It uses using one calcultor-register (EAX) and one parameter register (ECX).
    Read/Write of memory is done by an XCHG; setting a parameter is done with
    another XCHG. Logic and setting of parameters is done with AND,XOR,ROL. The
    stack is used as temporary memory.

    The addresse of (conditional) jumps comes from the memory. There is the big
    problem: This instruction "jnz dword[mem]" does not exist and have to be
    replaced by a combination of "jz + jmp", which leads to 9 x86 instructions.
    Therefore the set is still not the one I would like to have.

    If you have an idea for solving this problem, please contact me :)



    ad 2)
    There are several macro-instructions which themselve are Turing-complete,
    (see http://en.wikipedia.org/wiki/One_instruction_set_computer).

    Let's look at one example (from wikipedia):

        Subtract and branch if less than or equal to zero:

        The subleq instruction ("SUbtract and Branch if Less than or EQual to
        zero") subtracts the contents at address a from the contents at address
        b, stores the result at address b, and then, if the result is not
        positive, transfers control to address c (if the result is positive,
        execution proceeds to the next instruction in sequence).

        subleq a, b, c   ; Mem[b] = Mem[b] - Mem[a]
                         ; if (Mem[b] <= 0) goto c

    Two examples:

            ADD a, b == subleq a, Z
                        subleq Z, b
                        subleq Z, Z

            MOV a, b == subleq b, b
                        subleq a, Z
                        subleq Z, b
                        subleq Z, Z


    As its complete, we can write whatever we want (and most likely we want to
    write a self-replicator :) ). Just define a macro SUBLEQ and write your
    code only with this macro.


    Except of its pure awesomness to have a brainfuck-like virus, I presume
    that there are a very big set of freedom HOW to write it. Freedom in the
    way of coding always means possibility for mutations. In this case, most
    likely alot of possibilities :-)


