VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Per-process residency review: common mistakes

29a [7]
February 2004

[Back to index] [Comments]


Per-process residency is a TSR method discovered by Jack Qwerty in the early days of win32 platform. This great vxer got an alternative way to hook system calls instead of global residency, very common under DOS environments but so hard to obtain under win32 (win32 means win9x, ME, NT, 2000, XP, ?).

That method is well known and has been used in several viruses. At run time the import table is patched to hook API calls of the infected host and then perform viral actions each time a call is done.

I don't want to explain here how to do the per-process residency. I think there are yet so many infos about this topic (check references at the end of this article for more about this tech). This little article aims the result of the per-process residency. May be Jack Qwerty as pioneer didn't realize matters of efficiency, but at this point, we must analyze the method and (i hope) avoid some mistakes.

I've coded so many times per-process residency and i've tried to find some ways to apply successfully the method. I hope this little article provide a different scope of view to per-process residency.

State of the art: bad applied tech

When i read on irc one of the best vxers in the history of virus writing type: "bah, it won't go so far, it's just a per-process", i got confused. What's the problem of per-process residency? We are wrong thinking is a kewl tech to find new files to infect? That's true, but wrong under some basis.

Let's analyze what we understand by per-process residency:

  1. The virus patchs import table (does not matter at infection or run time)
  2. The API is called
  3. The hook gets the filename and tries to infect the file

May be theoricaly that seems ok. But we will see in practice that this won't work at all.

The classic per-process hook affects the APIs that can access a file:

 CopyFile* CopyFileEx* CreateFile* FindFirstFile FindFirstFileEx
 FindNextFile GetCurrentDirectory SetCurrentDirectory GetFileAttributes*
 SetFileAttributes* GetFileSize* GetFileType* GetFullPathName* LockFile*
 LockFileEx* MoveFile* MoveFileEx* SearchPath* UnlockFile* UnlockFileEx* ...

Lemme explain why this approach is wrong and it won't help your virus to spread.

At first place we must realize most of the APIs listed never (or quite never) are called from a usual win32 app over an executable file. How many programs installed in your comp use CopyFile? There's at least one that will copy an EXE? Following this idea all the APIs marked with * are not interesting to hook. Due: 1. those APIs are not used by user apps and/or 2. those APIs never will access an executable (and we infect executables).

At second place are the APIs not marked with *. Let's do two groups: find file and set/get directory. Find file APIs are a great way to infect files under windows nt if you affect cmd.exe. But since SFC is here to fuck us, i think those APIs are not usefull anymore (even them work fine under nt). Only that app is interesting, because the rest of the apps have a behavior that make them unusefull. And that behavior will fuck second group too, the set/get directory ones. Those APIs are not called from gui apps. Win32 provides a set of common dialogs to perform such task. If a gui app needs to open a file, it will ask the user for it using such common dialogs. Those apps never user find files directly to browse folders. And if them use its own dialogs (rare), they are implemented through DLL. Those common dialogs affect also the set/get directory, when you ask for a file to open, it's usual let the dialog change the work directory, so those APIs are not called.

So, what are the results? We have lots of per-process viruses that never, or almost never, infect files using its residency. It's believed that a per-process infector must have a run-time part due this residency method is not effective. In fact is not a bad idea: you get all windows files infected and then you have hosts to apply residency. In consequence most per-process resident viruses are just plain run-time direct action viruses. What a pitty.

But the problem is not in the residency but in the way we apply it.

Little ideas: open your mind

Those ideas are the result of my little research and my buggy viruses.

At first place i've proved the good results of run-time direct action methods over DLLs. When a DLL is loaded and its EP called, the work directory of the DLL is the same of the loader. So a simple scan of the work directory should give us new files to infect. But that's not perfect at all due the loader is running and then the file locked, so we cannot infect it and probably there is not other execultables to infect. However if an infected DLL from the system is loaded, it will be loaded before other local DLLs of the loader, so there is a chance to infect DLLs too. As you must realize, that idea is not nice under an environment with SFC fucking arround [SFC]. I played this idea 1st time with AOC [AOC].

That idea should be applied to per-process. If we peep into explorer.exe under win98 we see per-process residence is a bad idea. You will never affect an executable (or at least a little only). Most interesting calls to CreateFileA are performed by DLLs loaded by explorer at run time. So if you hook LoadLibraryA and then in that API hook all CreateFileA in the DLLs loaded by explorer, you'll get an awesome residency method with almost all files hit by explorer infected. I used this residency under BeeFree [BEF].

It's true explorer is a special case, and BeeFree was direct action vs it due that. Again SFC is a problem ;-) And this idea is not better than infect kernell32.dll on disk. But per-process applied to DLL may be is a good intermediate idea. That means you must implement DLL infection (sometimes not so trivial) and again your success is limited by SFC. I used that idea at 99Ways [99W].

Beefree idea can be used with in-memory infection, and there are some examples of viruses doing it. That should be a great answer to our prays, but i wanna discard it coz with that idea the important part is not the per-process but the in-memory infection. Check the stuff about that done by Griyo [GRY].

At this point we have two unusual ways to apply per-process residency that seem effective without SFC. But that apply is only about 'where', and we must discuss also 'how'.

Let's say that per-process residence over a simple CreateFileA in a PE EXE can be very effective. But we must change the 'how'.

Just change the chip: out aim is not a file but a folder. Ah! kewl XD Don't spect an EXE when CreateFileA is called. Peep the path. There are three kind of path possible in a CreateFileA: 1. it's an absolute path, 2. it's a relative path, 3. just a filename. In 1st case we get the path (yeah, discard the filename... i bet is not infectable), change directory to that path and scan the folder for files to infect. In 2nd case just do the same, and in 3rd just infect current folder because is prossible a commond dialog changed the folder intead the app. Tadaa! You got it. Per-process is now effective. Very effective! Just think that escenario:

  1. Notepad is infected
  2. User opens the readme.txt of a new installed soft
  3. Notepad opens the file and our virus gets a hot path
  4. The new app is infected

Pretty easy. Is true under SFC files that method will be more limited, but you don't need to infect a protected file to rock! Every app that needs to open a file to do something with it is able to get new paths to peep into.

In fact direct action vs windows folder is not really needed, but once you must code routines to scan directories, include a direct action part and let it work under system without SFC.

I used this approach under some viruses: 99Ways, Youngary [YOU], ...

To end this article i wanna comment another way i've used lately in freebird [FRB]. Since the folder idea looks for folders, that one looks for directory changes. It's a less effective method due it's more slow. Let's say is a slow infector. For this approach you must get work directory before release the control to the host. You can make this approach with threads and not use per-process hooks at all, but it won't be so fine due usual problems of threads running in an app that doesn't know that threads are running ;)

Then you choose an API that is called with a moderated frequency, or related to directory changes (not set/get directory due thos APIs won't be called and probably not available to hook). In last instance hook ExitProcess, but then it will be a slow-slow infector XD You won't do nothing with the API, so a GetDC or like should rock. When the hooked API is run, just get current directory, and if it's not the same than the stored... just infect current directory. Store the new one to test in the future and return the control to the host. Easy, isn't it? In that way we will infect on directory change even when we don't know where the hell is done that directory change.

You must be very carefull with the API you choose. We don't want to overload the app with calls to GetCurrentDirectory and checking code. And it must be an API suitable to be called in the app process after a possible directory change.

Last words

I hope you enjoy that article and you got the point.

I cannot end this article without a reference to the current state of the vx scene huehehe. It's true there are so few ppl able to code this tech but for those few beginners that are in the good way of the win32asm... do it per-process! XD

As you can see, per-process residency is still as kewl as Jack Qwerty got it so many years ago. We just need to do some tunning to make it more efficient and it is still a great alternative to the sanct sanctorum of the global residency under win32. Keep it ring3!



 SFC - Win2K infection, Griyo 29A-4
       Win2k.SFPDisable, Benny & Ratter 29A-6
 AOC - Win32.Anvil of Crom, Bumblebee 29A-4
 BEF - BeeFree, Bumblebee 29A-6
 99W - 99 Ways to die, Bumblebee 29A-5
 GRY - EXPLORER *in-memory* infection, Griyo 29A-4
 YOU - Win32.Yonggary!, Bumblebe MTX-3
 FRB - Freebird, Bumblebee 29A-7
[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka