,---,               ,'  , `.   ,---,       ,--.'|    ,---,.                     ,--,     ,--,  
  .--.,   '  .' \           ,-+-,.' _ |,`--.' |   ,--,:  : |  ,'  .' |               ,---. |'. \   / .`|  
,--.'  \ /  ;    '.      ,-+-. ;   , |||   :  :,`--.'`|  ' :,---.'   |              /__./| ; \ `\ /' / ;  
|  | /\/:  :       \    ,--.'|'   |  ;|:   |  '|   :  :  | ||   |   .'         ,---.;  ; | `. \  /  / .'  
:  : :  :  |   /\   \  |   |  ,', |  ':|   :  |:   |   \ | ::   :  |-,        /___/ \  | |  \  \/  / ./   
:  | |-,|  :  ' ;.   : |   | /  | |  ||'   '  ;|   : '  '; |:   |  ;/|        \   ;  \ ' |   \  \.'  /    
|  : :/||  |  ;/  \   \'   | :  | :  |,|   |  |'   ' ;.    ;|   :   .'         \   \  \: |    \  ;  ;     
|  |  .''  :  | \  \ ,';   . |  ; |--' '   :  ;|   | | \   ||   |  |-,          ;   \  ' .   / \  \  \    
'  : '  |  |  '  '--'  |   : |  | ,    |   |  ''   : |  ; .''   :  ;/|           \   \   '  ;  /\  \  \   
|  | |  |  :  :        |   : '  |/     '   :  ||   | '`--'  |   |    \            \   `  ;./__;  \  ;  \  
|  : \  |  | ,'        ;   | |`-'      ;   |.' '   : |      |   :   .'             :   \ ||   : / \  \  ; 
|  |,'  `--''          |   ;/          '---'   ;   |.'      |   | ,'                '---" ;   |/   \  ' | 
`--'                   '---'                   '---'        `----'                        `---'     `--` 

 ///// August 25th, 2010 ///// 

Tristram is more or less done, and its source is in the link I provided in my last post back in June. A few weeks ago I stopped debugging it and started working
on my neglected and long-overdue advanced meta engine. Anyways though, the shit that happened with Tristram:

I ended up implementing a technique that I do not believe has ever been used before, which I have been calling "reincarnating nanomites:" the idea is that as the
virus executes it crashes hundreds of thousands of times as it hits exceptions it has generated (these take the form of invalid read/write memory violations,
division by zero, and standard int3). When an instruction is replaced with one of these metamorphic exceptions, its original data is placed in a table stored
along with the  virus. This table contains the address of the instruction that was replaced with the exception, the original data, and the address where the exception
itself is going to occur.

As the virus hits these exceptions, it loops back into its own entry point (which is set as the main exception handler through AddVectoredExceptionHandler, a call
added to the OEP of the infected host through a call to the IAT). In other words, to initially receive control the virus calls AddVectoreddExceptionHandler and
sets its viral entry point as the handler. It then generates an exception and crashes control into the virus code. The virus handles this initial redirection like it
handles all exceptions: it locates its nanomite table in the infected host, compares the address where the code just crashed to every entry in it, and if there is a
match, it patches back the original bytes and resumes execution as if nothing ever happened. In this sense, the virus brings itself back to life hundreds or
thousands of times throughout its execution, gradually fixing all of the bugs in its body and creating an uncontaminated copy of itself in-place that will eventually
carry out the full viral operation without crashing. The nanomite structure used by the virus looks like this:

typedef struct _NANOMITE_POOL
{
    PBYTE pNanomiteAddress;
    PBYTE pExceptionAddress;
    DWORD dwOffset;
    DWORD dwSize;
    BYTE Data[1];
}
NANOMITE_POOL, *PNANOMITE_POOL;

With an orientation/self-awareness structure that looks like this:

typedef struct _ORIENTATION_POOL
{
    DWORD dwRawVirusSize;
    DWORD dwAlignedVirusSize;
    DWORD dwSizeOfNanomites;
    DWORD dwNumberOfNanomites;
    DWORD dwSizeOfPreservations;
    DWORD dwNumberOfPreservations;
}
ORIENTATION_POOL, *PORIENTATION_POOL;

And thus the location of the array of nanomite structures stored at the end of the viral body can be calculated using  the orientation pool structure.

This method is 100% original and differs from traditional nanomites because control is not returned to the point  at which the code crashed after an exception
occurs and is fixed by the vectored exception handler (virus entry point). Instead, the virus completely re-runs itself every time there is an exception, and this
caused a LOT of issues, some of which may have already entered your mind as you have been reading this...

What if the host is activated, the VEH is set and the virus receives control, it goes through a few dozen nanomites and then resolves an API like CreateFile and
crashes before it can close the handle it opened? In such an instance, when looping back upon itself (reincarnating) Tristram would fail to open the file for
a second time. A similar situation can/does occur if the virus allocates memory on the heap and then crashes before it gets a chance to free it. The solution to
these problems took me several weeks to fully realize and implement. Briefly, my solution is this: the virus contains an addiitional internal structure (generated
along with the nanomites table):

typedef struct _PRESERVATION_POOL
{
    DWORD dwValue;
    DWORD dwStartOffset;
    DWORD dwEndOffset;
    DWORD dwType;
}
PRESERVATION_POOL, *PPRESERVATION_POOL;

dwValue: acts essentially as a global variable to store each handle/heap memory pointer after it is opened or allocated. I stored these values in the preservation
pool struct because it corresponded to the preservation offsets (will be discussed shortly), and also gave me the ability to initialize this value to
INVALID_HANDLE_VALUE and 0, so that the field is initially invalid before being set by the virus as it reincarnates at runtime.

dwType: specifies the type of value stored in dwValue. This is used when the virus loops through its preservation pools and needs to decide whether to call
CloseHandle or GlobalFree on dwValue, immediatly setting it back to INVALID_HANDLE_VALUE or 0 after it has done so.

dwStart/EndOffset: so, this was my solution to the problem within the problem of having the virus clean up after itself when it reincarnates. After all, what if
the virus calls CreateFile, but then crashes on a nanomite directly after this call before it can store the returned handle to fix itself up the next time it reincarnates?
So, I had to define ranges within the viral body that are to be "preserved" ie. not contaminated with nanomites during the mutation phase. These little windows
of code also need to have their start/end offsets updated during the mutation phase, since the metamorphism engine changes instruction lengths within the
code and consequently the locations of the preservation window changes from generation to generation.

I really can't fully explain Tristram in English so if you have any interest in this new type of virus I'd suggest reading my source code, which still contains
very odd/unnatural debugging code (try debugging a virus designed specifically to make debugging/analysis difficult/impossible and see if you don't go crazy).

I'll upload the initializer code shortly so that initial infections can be made by curious virus writers and a clearer insight can be given into how this entire process
works from start to finish. 

For the most part, the virus works (nanomites/reincarnation/preservation all work, and so does file scanning and mutation, however some infected files come
out looking tainted and sometimes mutations of this virus will simply not run. I've dedicated a lot of time to hunting down and eradicating all of the little
bugs in the code but it is extremely difficult due to the reincarnation and I just didn't have the patience to see it through to the very end... maybe when I'm bored
or finished with my other projects and have spare time).

So  for now I'm calling it quits on Tristram since I explored the new idea that I had, and am now back to working on my metamorphism engine Istari, which should
eventually be able to work on any arbitrary binary, expanding/shrinking the .text section if nessecary as the code mutates, and fixing the target PE in a way akin
to code integration. Right now, the engine basically just has a lot of synonymous mutations and some nice/organized/expandable mutation models for generating
obfuscation and fixing the Jxx/Call as it does so. The source for that engine is here.

 ///// June 14th, 2010 /////

In the time since my laast entry I've written the foundation for my meta virus Tristram. The source code so far is here, and at its present stage it does technically
qualify as a meta virus since it performs synonymous instructions swapping: right now the instruction lengths don't change though, since I'm still working on
integrating the Jxx/Call patching and garbage insertion seamlessly into the engine and translating them to C. I modified z0mbie's old LDE32 and got rid of that
static flag table that it uses. I also optimized it down pretty significantly using patterns that I found in certain opcode ranges and instruction types. The virus
at its presennt stage can scan the local drives, infect executable files as an appender and mutate its body using light meta in between generations. The EPO at
present is just a randomly generated/randomly encoded Mov Reg/Jmp Reg or Cmp Reg, Reg/Je or Push/Ret sequence that is placed at the  OEP of the host file
and redirects the flow to the virus, which then pathces back the original bytes and executes the OEP as a new thread before continuing its own execution.

There are three main things that I want to add/improve upon for the actual release of this virus:

1)  Metamorphism engine will be drastically improved upon, capable of changing instruction lengths and mutating long sequences. Sophisticated garbage code
will also be integrated into tthe virus, along with fixup information describing the start/end ranges of garbage data so that it can be removed in future generations.

2) The afformentioned executable trash generator will also be used to generate garbage at the OEP of an infected host file preceeding the redirect to the virus
code. This should make it much more difficult to recognize an infected file by looking at its OEP.

3) I am going to use the VEH that I have already built into the virus to implement a trick I thought up to obfuscate the viral body. Basically my idea is this: when
the virus disassembles and mutates itself while infecting a target file, it will also have a random chance of overwriting a segment of its own code with a mutated
exception sequence. An example of the code used to overwrite several instructions would be:

Xor Reg1, Reg1
Mov Reg2, Imm32
Mov Dword Ptr [Reg1], Reg2

Such a sequence could also be accompanied by garbage data, since the values of flags/registers up to the exception make no difference. Mutated variations of
exceptions/garbage like this could be integrated at random into the viral body prior to where it calls RtlAddVectoredExceptionHandler, and so when the virus
executed it would re-execute its main routine with the exception data as a parameter (already coded into virus source I posted) and then lookup the address
where the virus crashed. So, when the meta engine generated these exception/garbage sequences, it would keep an internal table of where it inserted the
sequences and what their original data was. Now, the virus that has crashed due to one of these exceptions uses the exception pointer address as a lookup
value to find what data it should overwrite this exception/garrbage sequence with in its own code. Once it has done this,  it re-executes itself and the cycle
repeats until all exception/garbage sequences originally generated by the meta engine have been replaced with their original values. Using this method, no
signature would be reliable because nearly any part of the virus body could have been overwritten with garbage/exceptions. So, an AV would need to emulate
the code, following exceptions through the VEH until the entire body was to its original state, which would have been heavily mutated to begin with. It couldn't
ever even really know for sure if it had dealt with all the exceptions, could it? This trick is somewhat similar to nanomites I suppose, although I've never seen
it in a virus before... if you have, please email me so I can take a look at the code.

The virus at its present stage already has a foundation that would make adding these features relatively easy (random sequence at OEP, light meta engine, VEH)
so I think implementing them within the next month or two is a pretty realistic goal.

Of course, evading signatuure detection is hardly the cutting edge here in 2k10. Maybe once I can effectively/consistently evade signature detection I can begin
working on anti-heuristic and anti-emulation methods. Kaze/FAT used a great trick in his Win32.Leon virus where he generates random do-nothing API calls
with random parameters and integrates them into his poly decryptor. If I were to do something similar but to my entire viral body, it could be quite effective.
Also, I could  have the virus randomly select between ntdll andd kernel32 exports to perform its basic functions (NtQueryDirectoryFile vs. FindNextFile,
LdrLoadDll vs. LoadLibrary, NtCreateFile vs. CreateFile, etc.) and also Ansi/Unicode variations of functions, which would make the code look and also behave
significantly differently between generations. This would be a very solid anti-heuristic capability... as far as anti-emulation goes, I have fewer ideas. How does one
go about evading something like a register or  stack signature? The best way I can really think of is to generate/integrate oceans of equivilent and/or garbage
code to tax the emulator and make the code take a very long time to emulate and also take a huge number of clocks to get anywhere. For example something like a
Mov Reg, Imm32 could be replaced with a loop that would  take the longest possible route to set that Reg to its Immediate. Do-nothing loops that rely on register
overflows and calls to functions like Sleep could also be randomly added to the code.

Combining all of these methods could result in a virus immune to signature detection (highly metamorphic, overwrites segments of itself with garbage/exception
sequences) behaves differently (uses equivilent versions of API calls exported by differently modules, and also adds do-nothing API calls with random
parameters) and that takes millions of clocks to get to any given point in its code where AV might have set a reg/stack signature. Yea, it'd be slow
and a bitch to code down to a bug-free state but I think it would take a bit of doing to detect it 100%. 

  ///// June 3rd, 2010 /////

As I find more time to code more creations flourish into being. I'm looking forward to completing a major virus very soon... it will include a C translation of
the metamorphism engine I posted several months ago in Win32 .Kurast with some improvements. Also I'm leaning towards a patch/restore EPO method
of infection to an appended viral body, also compiled from C.

Why is it that what should be a second enlightenment is an ocean of hedonistic exploitation and profiteering? The people who develop the technology, make
the advancements, and study the wisdom of the past are seen not with gratitude but with contempt and greed. They are sent to slave for  corporations who
serve only the masses with not a thought to a greater cause. We gave the masses their electricity, their computers, their televisions, their internet, their cars
and their cellphones and all for what? They have turned these gifts into tools to perpetuate their own decadence. They have turned from religion and now
embrace only the dollar. The words of those who extolled the end of religious fundamentalism and the dawn of Promethean enlightenment have been
ruthlessly disregarded and now we live in an ocean of alien beings, their only goal to live in as small and comfortable a  box as is possible.

When will we ascend to a Type One civilization? When will we recognize that only unity and scientific/technological avancement are worthy of our attention
at this delicate phase of our development. The masses kick back and relax as if we've made it. As if we have successful made the transition from small tribes
to wordly civilization. In the meantime the true forms of simple life perish in polluted graves, the sky fades with smog, and mankind gnaws at its appendages
like a hideous animal caught in its own cruel trap. We are losing. The animals die, the Promethean gives his gift of true knowledge to the ignorant masses
and they turn it against him in the form of weaponry and even deeper ignorance.

In the midst of a technological revolution, still countries censor themselves, repress freedom of spech and information, wage brutal wars against people
of all nationalities and against themselves. Knowledge is power and those who hold it need some solidarity.

///// April 5th, 2010 /////

No I'm not dead... still here, and despite a lack of progress with my major virus project from last year, the unfinished code for which is here, I have been doing
quite a bit of VX-related programing lately. It's good to see that EOF has another skilled coder (pr0m1x) who I've talked to several times, and is actively writing
advanced assembly viruses and mutation engines. VX is great but it is a tough trade-off these days, because there are no legidimate profits to be made. Projects
worth pursuing take months and sometimes years to fully complete and inspiration comes in fleeting bursts. It would help if there was a more active VX
community, but I'm not about to complain about that... because I have been more a part of the problem than the solution.

In the next EOF ezine I'll be releasing some very nice code (in C, but with some metamorph and other low-level stuff) relating to advanced botnet C&C and
hopefully an assembler virus or two. Whether or not my Kurast virus will be done by then I have no idea, but I'll be making a contribution to keep the art alive
and that is what inspires me.

To fellow hackers and VXers who stumble accross this page in the void, I would say never give up and never forget that feeling you got when you wrote your
first creation or hacked your first server. Show this world your originality and never give in to our dying society and its  pressure to sterilize
your soul. Either you think, or you have others think for you. Fight mediocrity and ignorance until your dying breath.


///// August 24th, 2009 /////

Well, almost two months since my last entry, I've decided to add another: I had intended  to do this sooner but there simply hasn't been enough interesting news
in my virtual life lately to make it worthwhile. I spent most of July on vacation, and since getting back I've allocated most of my computer time to finishing my
Win32.Kurast virus, which I started writing almost 4 months ago. I'm fairly confident that I will have it finished and debugged within the next few weeks, however
some larger and more complex aspects of the project I have had to simply abandon, due to lack of motivation (working on the same piece of code for months on
end can do this). At this point I would like to produce a fully-functional copy of the virus, and move on to a new project. 

Having long since finished the internal metamorphism engine for this virus, I have been struggling with writing a very small, optimized, and yet easily morphable
and simplistic infection routine. One of the more difficult challenges for this virus was the ability to relocate itself accross multiple segments (code branching to
other code in other cavities) but I ran into several problems here. Perhaps the biggest of these problems is that due to the way I coded the relocation functions
for this virus (I used a very unusual but entirely original method) I cannot change the size of a Jxx displacement (8bit not big enough? make it 32bit, or vice versa).
It is somewhat difficult to explain, but it boils down to this: the virus has no way of knowing if a displacement is too big or too small until the relocation phase,
where my engine looks back over its recorded changes in instruction length  and modifies all Jxx/Calls that are effected accordingly. The obvious problem is that
the virus would have to relocate after relocatiing a Jxx inside the relocation phase... which may then have to be relocated yet again, and again.

This basically meant that I had to use 32bit displacements universally for all Jxx instructions... which is where I hit my second big problem: there is no such thing
as an inter-segment Jcc instruction. After writing macros to fix both of these problems, the code size grew by almost 1KB, and I felt as if my original vision for this
virus was simply flawed, and would need a lot more effort to correct and realize properly.

Overall I'm disappointed at not being able to finish this virus in the way I first envisioned it, but I'm happy to be finishing a large virus project, perhaps the first
code that I can ever truly say I am  "proud" of.

I'm hoping that the metamorphism, EPO, and epic payload of this virus make up for its poor infection routine.


///// June 29th, 2009 /////

After some procrastination, I went ahead and wrote a program to collect cavity statistics for Windows systems. The results that I am publiishing here represent
culmulative data collected on two of my personal machines running under Windows XP. I am currently in the process of collecting these same statistics on a much
broader range of Windows machines, however I am still unsure of when these statistics will be meshed and completed. In any case, the idea here is to give a cavity
virus "in the wild" a good idea of its chances of survival, based upon its size:

Cavity scanner results:

In Windows system directories (SFC protected executables):
Average number of cavities: 2
Average size of code cavity: 402
Average (combined) size of other cavities: 603

In Program Files directory (regularly executed applications):
Average number of cavities: 4
Average size of code cavity: 748
Average (combined) size of other cavities: 1256

A closer look at the logs shows that a significant majority of common user programs, such as games, software such as Adobe (Flash, Acrobat, Photoshop) and
Microsoft Word/Works, Open Office, Internet Explorer, Java, and even Windows Media Player contain executables that consistently carry a section allignment of
4096 bytes. This is important because nearly all of these programs are installed on Windows systems by default. A 4096 allignment means many potential KB of
cavity space, and an almost garunteed infection, or even double-infection for even a bulky cavity virus.

Conclusively, Windows system executables contain a solid average of about 1KB of cavity space. Program files, on the other hand, carry an average cavity space
of around 2KB, and can potentially carry a cavity as large as almost 20KB. A complex cavity virus will consistently have a high chance of infecting commonly
executed files on an average Windows XP OS.


  ///// June 23rd, 2009 /////

Greetings and welcome to my homepage: here I will be posting articles and source codes relating to computer viruses, code mutation, and similar topics in time to
come. Huge thanks go to VXHeavens for hosting my page. Kicking off my membership to EOF I've written my first classical file-infector in assemmbly here.


f4m1n3 [at] hotmail [dot] com