VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Crazy ToDo list for VXers

Belial, SPTH
Valhalla #2
March 2012

[Back to index] [Comments]

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:

Talk on another conference:

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 ( 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

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

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 :-)

[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka