,---, ,' , `. ,---, ,--.'| ,---,. ,--, ,--, .--., ' .' \ ,-+-,.' _ |,`--.' | ,--,: : | ,' .' | ,---. |'. \ / .`| ,--.' \ / ; '. ,-+-. ; , ||| : :,`--.'`| ' :,---.' | /__./| ; \ `\ /' / ; | | /\/: : \ ,--.'|' | ;|: | '| : : | || | .' ,---.; ; | `. \ / / .' : : : : | /\ \ | | ,', | ':| : |: | \ | :: : |-, /___/ \ | | \ \/ / ./ : | |-,| : ' ;. : | | / | | ||' ' ;| : ' '; |: | ;/| \ ; \ ' | \ \.' / | : :/|| | ;/ \ \' | : | : |,| | |' ' ;. ;| : .' \ \ \: | \ ; ; | | .'' : | \ \ ,'; . | ; |--' ' : ;| | | \ || | |-, ; \ ' . / \ \ \ ' : ' | | ' '--' | : | | , | | '' : | ; .'' : ;/| \ \ ' ; /\ \ \ | | | | : : | : ' |/ ' : || | '`--' | | \ \ ` ;./__; \ ; \ | : \ | | ,' ; | |`-' ; |.' ' : | | : .' : \ || : / \ \ ; | |,' `--'' | ;/ '---' ; |.' | | ,' '---" ; |/ \ ' | `--' '---' '---' `----' `---' `--` ///// 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: Sub/Xor Reg1, Reg1 ; Attempt to write data to address 0: this could be replaced with any invalid memory address Mov Reg2, Imm32/Push Imm32/Pop Reg ; Write a random value to the second register Mov Dword Ptr [Reg1], Reg2/Push Reg2/Pop Dword Ptr[Reg1] ; Attempt to write to invalid address. Any operation could be performed here. 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 ///// 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 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. 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. ///// 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.
fAMlNE [at] yahoo [dot] com