ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ ÚÄ 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 º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ