Per-process residency review: common mistakes

 by Bumblebee


 Introduction

 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!

 Regards.


 References

 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

**