VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Source code of computer viruses

MetaPHOR 1D - Virus for Linux by The Mental Driller

Virus for Linux

The Mental Driller
Show all viruses by this author


Download (123723 bytes) or browse online

Released in 29A#8

Author's notes

Win32/Linux.MetaPHOR v1D

Metamorphic Permutating High-Obfuscating Reassembler

This virus is only code. No tables, no indirect jumps, etc. etc. It doesn't uses the stack to construct strings, executable code or data: what I do is a reservation of 3'5 Mb of data (more or less) with VirtualAlloc/malloc and then use the decryptor to copy the decrypted virus there (or unencrypted, since it has a probability of 1/16 of being unencrypted, so the decryptor in that cases is in fact a copy routine). The reserved memory is organized in sections (as if it were a PE) where I do all the operations.

Undex Linux:

If malloc() nor exit() is imported by the executable, then it's not infected. If it has this two functions imported, then malloc is used in the decryptor

Under Win32:

VirtualAlloc will be retrieved by the decryptor if it's not imported by the host, and the host must import GetModuleHandleA/W or LoadLibraryA/W and GetProcAddress to be infected. This functions will be used by the virus to get the needed APIs.

The type of metamorphism followed is what I call the "accordion model": disassembly/depermutation -> shrinking -> permutation -> expansion -> -> reassembly, so the code can be bigger or smaller than the previous generation.

The metamorphism in this virus is complete: even the result of the shrinking can't be used for detection, because is different in every generation. That's the point where I introduce a new concept: dimensions in recoding (I mean, code that only get shrinked on two or more generations, but not in the immediate following; this would be the "third" dimension). This makes the disassembly to have always a different shape from generation to generation, but, when stabilized, never growing uncontrolablely.

I have added a genetic algorithm in certain parts of the code to make it evolve to the best shape (the one that evades more detections, the action more stealthy, etc. etc.). It's a simple algorithm based on weights, so don't expect artificial intelligence :) (well, maybe in the future :P).

I tried to comment the code as cleanly as possible, but well... :)

If the code isn't optimized (in fact, it's NOT optimized), it's because:

  1. It's more clear to see the code that the internal engine will deal with (for example, many times I use SUB ECX,1 instead of DEC ECX, although the disassembler can deal with both opcodes).
  2. What's the point for optimizing the code when in next generation it will be completely unoptimized/garbled? :)
  3. The obfuscation in next generations is bigger (MUCH bigger).

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