                                                   ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ 
          ÚÄ InterProcess Communication ¿          ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ
          ³              by             ³           ÜÜÜÛÛß ßÛÛÛÛÛÛ ÛÛÛÛÛÛÛ
          ÀÄÄÄÄÄÄÄÄ Benny / 29A ÄÄÄÄÄÄÄÄÙ          ÛÛÛÜÜÜÜ ÜÜÜÜÛÛÛ ÛÛÛ ÛÛÛ
                                                   ÛÛÛÛÛÛÛ ÛÛÛÛÛÛß ÛÛÛ ÛÛÛ




 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
 ³ 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 ³
 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

 Hi dear reader,
 
 another 100% theoretical article on the world, huh? Perhaps u r saying these
 words when u r reading this. Yeah, it is truth. But continue reading. It ain't
 only next theoretical article, but it's futuristic article as well :). I like
 futuristic ideas and I like their realisating. And this article discuss both
 of that. I know what I'm talking about it. I had crazy idea about InterProcess
 Communication (l8r only IPC) and I couldn't sleep until I finished it :). Yeah,
 again, I'm talking about my Win32.Vulcano. But that idea is for me a kewl one
 and I think 29A#4 wouldn't be complete without it. Please keep on reading this,
 u will find here very interesting ideas... Blah blah blah, the forword I
 usually write is really b0ring, don't u think? :)) Let's skip it...



 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
 ³ 3. IPC in the real world ³
 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

 My thoughts r very crazy :). Yeah, and u want probably ask me what the IPC
 is and what relation has it with viruses. Believe me, it's all about viruses :).

 IPC doesn't mean anything else than communication between two or more
 independend processes. I said independend, becoz u know that in Win32
 environments every process has its own address space. That's a small "problem",
 becoz u can't simply overwrite memory which is in use by another program, becoz
 all addresses r valid only for one process. Another process may have code,
 datas, resources, handles and such things placed on another place. For instance,
 CALC.EXE and NOTEPAD.EXE r loaded to same virtual address (0x400000), but code
 on address 0x400000 ain't same in CALC.EXE as in NOTEPAD.EXE, becoz every
 process has its own private address space. So, the sharing of the resources
 ain't trivial. That's why so many Win16 application doesn't work in Win32
 environments.

 Becoz of those things, Microsoft had to implement mechanisms for sharing data
 between various applications. And believe me, there r many ways how to share
 datas between appz. Let's see how many options we have:
 
 -	Clipboard (well known by users, eh?)
 -	Dynamic Data Exchange (DDE)
 -	File Mapping
 -	Mailslots
 -	OLE (Oleeeeee :D)
 -	Pipes (not water pipes, unfortunately :P)
 -	RPC (Remote Procedure Call)
 -	Windows Sockets (aka dirty sox :D)
 -	WM_COPYDATA (sharing via windows message)
 -	Named kernel objects (such as Mutexes, Semaphores, Events, ...)
 -	Hooks (useful for monitoring windows messages)
 -	and other shitz

 As u can c, there r many ways how to share data between applications. And
 Microsoft made it for us! I won't talk here about similar shitz like OLE, DDE,
 Sockets and such things becoz I don't like it and I don't understand it :).

 Well, what will be this article all about then? :)
 I will talk about File Mapping and Named kernel objects. So ...

 When I started to coded BeGemot virus, I wanted to allow virus to share some
 data with communication interface. Communication interface (BGVCC - BeGemot
 Virus Communication Console) was coded as simple Win32 console application
 which is used for monitoring virus actions in memory and for changing some
 parameters. I decided to use share memory as system table. Everytime the
 content will be changed, virus will send back some messages or change its
 behaviour (higher priority, deactivation of virus, ...). I think it was nice
 sample of interprocess communication. User can communicate with virus in
 memory and virus can communicate with user...

 Apart of all features, I wasn't fully satisfied. I wanted to make virus with
 true IPC. I coded Vulcano. Vulcano shows one feature, never seen before and
 that's how what I call "TRUE IPC".

 Some days after the releasion, StarZer0/iKX was very angry, becoz he said that
 his Aldebaran is the first virus with IPC (his virus uses explorer's memory to
 stay resident under Win32). We talked a lot about it and StarZer0 didn't want
 to hear what I was saying. He asked me "why Aldebaran doesn't use IPC then?"
 Problem was in "what we called IPC". My Vulcano virus uses TRUE IPC, I'm saying.
 And when I mean IPC, I mean TRUE IPC. In my opinion, if Aldebaran really uses IPC,
 then my BeGemot virus used IPC before Aldebaran, but also Int13h's virus Borges
 used IPC before my BeGemot becoz that virus used Clipboard (in payload routine,
 but anyway...) etc... and on the end would be some DOS virus which can
 kill TBMEM by calling INTs (it can be also called as IPC). Ain't it silly?
 I think it is...

 And what I call TRUE IPC? Virus should be able to communicate with another
 virus in memory, send and request informations, work with informations,
 do property actions dependending on recieved informations, send back results
 and such things. Virus should be also able to work in both of client and
 server mode (once client, once server). That's what I call true IPC.
 Vulcano does it. Vulcano tries to do everything possible in another process
 using IPC (very hard to debug that virus then). It tries to "connect" to
 another instance of Vulcano virus and make all possible actions (file check,
 infection stage, anti-debug routines, ...) inside it. Virus can recieve
 requests and make property actions depending on recieved informations (check
 file, infect file, kill debugger, ...) without any problems. Vulcano also uses
 advanced techniques to synchronize threads so it is also well protected against
 unexcepted crashes.

 Ok, apart of all those private problems, both of BeGemot and Vulcano show
 interesting ways, how to use IPC in viruses. Well, how to realise IPC then?

 Becoz virus with IPC should be able to communicate with another virus in memory,
 u should find out how will your virus do that. Think about "communication
 interface" - thru that interface viruses will be communicate. I solved it
 by creating shared memory area. BeGemot and Vulcano create table in shared
 memory. All items in that table r used for communication. Here is an example,
 how BeGemot uses shared memory>

 
 BGCB (BeGemot Control Block):
 
     00 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
        ³     "BGCB"     ³ Signature		- used by search engine (BGVCC)
     04 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³    New flag    ³ Boolean value	- signs if request has been sent
     08 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´			  (1 if new, 0 if not)
        ³       ID       ³ ID of request	- identifies request
     0C ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³      Data      ³ property data	- needed data
        ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ


 As u can see, BGCB structure is very simple. BeGemot after execution tries
 to create new system thread (which will be present in memory for whole windows
 session). That thread will create BGCB and wait until New flag will be changed.
 When New flag is changed to 1, virus will check ID and dependending on that
 number, virus will do property action - for example, virus will decrease thread
 priority by number in Data item.

 And who will change that New flag? BGVCC will do that. When u will run BGVCC,
 it will try to find BGCB by searching the virtual memory for "BGCB",0,0,0,0
 string (it is able to trap GP faults). If u will send command to BeGemot thread
 using BGVCC, BGVCC will change ID to property command number, write datas to
 Data item and change New flag to 1. BeGemot thread will woke up and do
 property action.

 This is very nice example of IPC.  Imagine that, u can "talk" with virus!!!
 It 100%-ly worx and I didn't find any problems (also noone other) using it.
 Vulcano uses much more difficult way to communicate between processes. Let's
 have a look on the structure, which is placed in shared memory after virus
 execution>


 VLCB (VuLcano Control Block):

	Common block                 		- only for integrity checx
    000 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
        ³     "VLCB"      ³ Signature
    004 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³        0        ³ Alignment
        ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

	Thread 1 block               		- every communication thread
    008 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿			- has its own record
        ³   Mutex name    ³ Name of mutex	- used for synchronization
    00C ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³       ID        ³ ID of request	- identifies request
    010 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³      Data       ³ Data		- Win32 Find Data and such structurez
        ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

	Thread 2 block				- if there is another virus
    150 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 			- present in memory, then
        ³   Mutex name    ³ Name of mutex	- it also has its own record
    154 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³       ID        ³ ID of request
    158 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
        ³      Data       ³ Data
        ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

	       ...

	And finally some NULLs.			- if no more viruses in memory


 Every part of VLCB is stored (as I said) in shared memory using memory mapped
 files (swap file). When virus will be executed, it tries to create/open VLCB
 and add new structure for new thread (which will be created then and which will
 monitor requests for itself). When virus will exit, it will overwrite allocated
 structure by NULLs, so when another virus will try to add new structure, it
 will be able to use that space. When virus will try to kill debugged process,
 it will get first available thread structure (check if Mutex name is not NULL),
 fill ID with right service number, Data with current process ID (got by
 GetCurrentProcessID API), SIGNALISE mutex (more informations about
 synchronization mechanisms described in SDK or in book "Advanced Windows". I
 strongly recommend u to buy that book!) and wait until thread will finish its
 work. By signalisation of mutex, property thread (can be whatever Vulcano
 thread in whole system! - IPC) will woke up, check ID (if it is VLCB_Debug1),
 get Data (ID of process), get handle to process ID (by OpenProcess API) and
 kill it by TerminateProcess API. Then, when everything will be done it will
 write result to Data item (this will wake up waiting processes).

 As u can see, Vulcano has much more difficult algorithm and potential problems
 with synchronization. It's all becoz Vulcano can communicate with many viruses
 in memory (and if there's only actual process, Vulcano can communicate with
 itself) and becoz Vulcano has to sleep all not needed threads (or it would
 cause about 95% CPU usage in idle time). When I started to code it, I coded
 many algotithms for IPC, but this one seems to be best of all previous. There
 ain't visible any CPU usage and it's much stable becoz of usage mutexes as
 kernel synchronization object.

 The main reason why I coded Vulcano with IPC was to show IPC in virus and to
 fuck emulators and AVerz. Imagine that, u trace virus in memory, u see how
 program writes to memory, then waits, then again, again, again and quits.
 "It's not virus" can emulator/Aver say. But all actions r executed not only
 in separated thread(s), but in separated process(es)! That's very hard to debug
 that if there is another instance of virus in memory. U have to attach debugger
 to another process, and how many AVerz will do that? Ehrm, how many AVerz will
 do that in first contact with virus? None. To code virus which is able to
 execute its code in another process was really needed.



 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
 ³ 4. IPC inside my head - thoughts and ideas ³
 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

 That was about reality. Now, I will discuss here my ideas, futuristic ideas
 which will be perhaps "somewhere in time" realised. Maybe by me, maybe by u,
 maybe by someone else. Following ideas r really futuristic, but not impossible
 to realise. It plays with idea "what's a virus?" and it can make revolution
 between so standard viral mechanisms, such as direct-action, per-process
 residency, etc... Let's break a rules!

 The main question is: "what advantages will we have if we will use IPC in our
 viruses?" Answer is: "anti-heuristix, anti-debug, anti-AVer, internet viruses,
 neural-nets, ..." Here r some ideas, which (as I expect) will be realised
 (some of them r much higher than simple IPC)>


 Viruses, which will be able to communicate between themself (such as Vulcano),
 exchanging informations and creating neural-net, creating a colony of viruses
 which will be able to do everything needed in a group. For example, if
 one virus will want to infect one file, the another virus will do that. If one
 virus will be debugged, another virus will kill debugger. That's all done in
 Vulcano, but it can be much improved. Viruses would be able to "remember and
 learn" things and (as I said before) create colony of inteligent viruses (AI),
 something like organisated society.

 Complementar viruses. Virus separated to many parts, where one part ain't
 anything, but all parts r one complete virus. This would make real problems to
 heuristic analysis, if not fuck it all.

 Modular viruses, using Modular Virus Architecture (MVA). Virus will be able to
 use modules from another virus (thru IPC). Virus won't get old, u will only
 add new module and virus will be newer and improved. If u will code some smart
 modular interface, u won't have problems with it. Similar ideas r described in
 BumbleBee's article about Modular Virus Interface (MVI). Maybe I will try to
 code such virus, in the near future.

 Internet viruses. Maybe in the "near future", where every computer will be
 connected to Internet (or another (better) world-wide network), where Microsoft
 will cover all layers by user-friendly interface, forgetting to security, it
 will be able to code viruses which will be able to communicate not only
 between processes (IPC) but also between computers connected to internet,
 exchange informations and create so world-wide viral neural-net.

 Viruses with communication interface (with much advanced engine than BeGemot).
 Viruses will be able to be controlled and recoded by communication console.
 Viruses will be password protected (using some secure crypting algorithm) and
 so only a few ppl will be able to use its features (such as all 29Aerz :DD). If
 the virus will be able to work with Internet, u will be able to control
 infected computers, and that's not small target! (hey GriYo, let's code it!!!)

 
 Uuuufff, I can't remember all those ideas I have when I'm st0ned :). I think
 these ideas r enough for ya now. I hope u will research on it and code some
 kewl virus using those techniques.



 ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿
 ³ 5. Closing ³
 ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ

 Uh, we r on the end. I hope u enjoyed my ideas and if u have also some kewl
 idea about IPC or such technique which I didn't write here, then why don't u
 realise it? U have my full support.
 Very very thanx to all my Internet friends (I l0ve u all!) and ppl which helped
 me on my beginnings and which r still helping me. I also would like to thank
 all my real friends (u know, who u r), which r helping me morally and which r
 making so gewd thing as friendship is with me. I won't ever forget ya!




                                                    ÚÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
                                                    ³  Benny / 29A,  1999 º
                                                    ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
