VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

EPO techniques under Win32

29a [4full]
March 2000

[Back to index] [Comments]

1. Disclamer

The followin' document is an education purpose only. Author isn't responsible for any misuse of the things written in this document.

2. Foreword

Hello everybody,

I decided to write this article after I successfuly finished my last virus Win32.Vulcano (special thanx to ShadSeek for his beta testing :D) becoz that virus uses EPO routines (as my only one virus). Blah, now without lies X-D. Darkman asked me if I would write it and I replied him that it's very good idea. Mmm, maybe I'm not the right human who could write it, there r many other coderz which have experiences with it, more than me (JQwerty, GriYo, Billy, Vecna, ...), however I hope this article will help ya, albeit it is short and 100% theoretical.

3. Introduction

Well, whatsa go? That's the main question. Entrypoint Obscuring techniques, also abrieviated as EPOs, r relatively new but very efficent ways how to make your virus undetectable by existing heuristic scanners. The main idea is: don't modify entrypoint, don't activate virus immediatelly when infected program is executed, dig the "JMP VIRUS" instruction into the center of program. For instance, virus won't be activated when the program will be executed, but when program will call ExitProcess API. Why do we do that? It's very simple. Heuristic scanners can't analyse whole Win32 program (in short words, it's just not possible for existing scanners) and if virus code will be hidden inside the program, heuristic scanners won't be able to reach the virus code and so, virus won't be detected. In my opinion, every modern virus should contain EPO routines. And if the ways of realising EPOs will be random, it would be impossible to clean the virus. Think about it.

4. The easiest way of realising EPO

If I am right, the first virus which implemented EPO was Jacky's Win32.Cabanas (hi Jacky :D). The virus infected program by appending to last section. Virus didn't touch the entrypoint in PE header, but it patched first five bytes of code by "JMP VIRUS" instruction (previous bytes were saved before they were overwritten and l8r restored). AVerz had to rebuild their engines to not only check entrypoints but also to check/trace the code. I believe it was big pain for them :).

It's very easy to implement this kind of EPO and I think in this time it hasn't sence. All good AVs have heuristic scanners which can trace the code and one jump as the first instruction ain't problem for anyone, nor for heauristic scanners.

However, this idea started everything what carry name EPO. Again I would like to greet JQwerty.

5. Another way of EPO coding

Ok, this is similiar way to the first one described above. But where we built simple jump or call instruction, here we will build whole polymorphic descryptor. The idea is same as in DOS.OneHalf, DOS.CommanderBomber, WM/Win32.Cocaine or Win32.Legacy for example. Virus will save the code and will overwrite it by polymorphic decryptor. Advanced polys can build many layers, jumps and calls over the all code section, but also it can be detectable. Not so easy as in previous case, but it ain't so hard to detect it for newer scanners. If u will try to code it, u will find some problems with implementation. For instance, u will have to save whole code before overwritting it, if u will randomly place decryptor along the code section. I think it ain't very lucky solution, there r better ways how to realise EPO.

6. EPOs in better light

Newer and newer viruses comming with newer and newer ideas. One of the best EPO techniques seems to be code patching. Imagine, virus will be activated after some API will be called (Win32.CTX Phage patches the random API, so it is much harder to detect it by heuristic scanner, if not impossible). It has many advantages, but also many problems with implementation. Advantages r clear.

Virus can, but needn't to be activated - many programs contain many calls to same API and only our patched API will be called in 1% of all cases - that can be advantage, but also problem. Virus can infect program and patch API call, where that API won't be ever called due to bugs inside that. Also, there r problems with implementation, coz u can't just patch the import address table. Address table will be overwritten by program loader before initialization, so your patched address will be erased. Solution is - explore code and search for API calls (JMP DWORD PTR [XXXXXXXXh] - Borland API call convention, CALL DWORD PTR [XXXXXXXXh] - Microsoft API call convention). It is perfect seen in GriYo's Win32.CTX Phage or my Win32.Vulcano virus.

Virus can also rebuild whole program so every call to API will cause the initialization of virus. It is nice idea (bi0logical viruses modify the celulas), but almost 100% of Win32 programs contains API calls on the beggining of the code, so the heuristic scanner would easilly find that virus. Many new viruses r patching ExitProcess API, so virus won't be initialized as the first, but as the last chunk of code.

But, u don't need to patch only API calls, u can just patch random code (and save previous bytes). It has also many advantages and problems. U don't need to search thru the Import table. Problem is that u can't just write jump into the code - u have to fit right between the real instructions. It can be solved by overwriting simple CALL and JMP instructions.

There r too many ways how to do that...

8. Closing

The mid-infection against AV cleaners and EPO against AV scanners. Ain't it nice combination? I hope this article woke some of your idea up and that u will show this world something kewl.

I would like to thank GriYo, JQwerty, Vecna and Billy, becoz they showed this world the first EPO routines in all their possitives and negatives. Please, think about everything I described here and gimme know about everything what u have in your head :). Have a good time reading 29A#4!

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