旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Viric life and die theories � Billy Belceb�/DDT 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Well, if you read the "Heuristic technology" in this same magazine, and you didn't like that kind article, just keep your hands away of this article too because i'm going to talk about some other related stuff like that one. Yes, this is one of an article serials, dedicated to oddities :) % Brief Introduction % 컴컴컴컴컴컴컴컴컴컴컴 After seeing the article's name you can think that this document is going to talk about the virus die in AV hands. No, this article won't discuss that (interesting anyway) theme, it will talk about the matter of make viruses to have human features (born, grow, reproduce and die). Seems sci-fi huh? :) Well, this is a circle, as the life is. Let's see a little diagram. 旼� Virus infects a new system v 旼컴컴커 � Born 쳐�컴 Grow 컴�컴 Reproduce 컴�컴 Die 읕컴컴켸 �> Born 컴�컴 Grow 컴�컴 Reproduce 컴�컴 Die �> Born [...] In this article i will discuss each one of that points, specially born, re- produce and die. Grow is as well very important, but i will comment it less, as it's a normal statement (well, you will see it later). so, it's time to begin. % A new virus has born % 컴컴컴컴컴컴컴컴컴컴컴컴 We can arrive to this point in two ways: the virus has just entered a new computer, an unexplored land, another world, or the parent-virus created it and it has to adapt itself to the system. In the first case, the virus has to adapt quickly to the system, because the critical process of the infection happens just at this time, when the virus has just begun to infect the system. If the user don't notice the virus the first days, everything is easier. The second thing that could happen is that the virus is the "son" of another one, then if the parent remained undetected, we can have less care (anyway, we must make it to follow rules), but without passing the line, because at this time there'll be two viruses in the system, and if the user notices, everything will go hell. The process of how we can make a virus to create another one will be explained in the "reproduction" part. New infection.- 旼컴컴컴� � Virus � 읕컴쩡컴� � [arrives to a...] v 旼컴컴컴컴컴커 � New system 쳐컴컴캑 Adaptation process 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴> [...] 읕컴컴컴컴컴켸 Because parent's reproduction.- 旼컴컴컴컴컴컴커 [...] 컴컴컴�> � Parent virus 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴�> [...] 읕컴컴컫컴컴컴켸 � [reproduces...] v 旼컴컴컴컴컴� � New virus 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴> [...] 읕컴컴컴컴컴� % Grow, my little baby % 컴컴컴컴컴컴컴컴컴컴컴컴 Well, this statement is quite simple. I mean with "grow" the steps of the evolution of the virus related to its own polymorphic engine, or, said in another way, its self process of polymorphy. Also, at this point the virus is saving useful information for its own safety. % Let's fuck! Reproduce! % 컴컴컴컴컴컴컴컴컴컴컴컴컴 This is the most (under my viewpoint) important part of the life-die game. I think that could be done as i'm going to explain. Imagine we have a (big) code generator, that always travel with the virus. That code generator must be able of generate a whole new virus from zero. Well, let's see a diagram of how the code generator could be: 旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커旼커 � 납 납 납 납 납 납 납 납 납 납 납 납 납 납 납 � [0] Opcode 읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸읕켸 � � � � � � � � � � � � � � � � V V V V V V V V V V V V V V V V 旼컴컴커旼컴컴커旼컴컴커旼컴컴커旼컴컴커旼컴컴커旼컴컴커旼컴컴커 � 납 납 납 납 납 납 납 � [1] Routine 읕컴컴켸읕컴컴켸읕컴컴켸읕컴컴켸읕컴컴켸읕컴컴켸읕컴컴켸읕컴컴켸 � � � � � � � � V V V V V V V V 旼컴컴컴컴컴컴커旼컴컴컴컴컴컴커旼컴컴컴컴컴컴커旼컴컴컴컴컴컴커 � 납 납 납 � [2] Big R. 읕컴컴컴컴컴컴켸읕컴컴컴컴컴컴켸읕컴컴컴컴컴컴켸읕컴컴컴컴컴컴켸 � � � � V V V V 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴커旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � 납 � [3] Blocks 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 � � V V 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � � [4] Main 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 읕쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 �> This diagram represents the code of the code generator, that the virus calls. If after the diagram, you still have any doubt of what i am trying to expla- in just read the following lines. BTW, as you have realized, the size of the boxes of above is symbolic: the biggest one is what does the most general job, anyhow, it's the smalles part in bytes of the code, so bigger the box is, smaller is the code. Main.- This code represents for the "life and die" idea the main branch, as it should have the right calls for generate a whole new virus starting from nothing... it must set up all the variables, look up for where the new virus will be placed in memory, etc. The calls for generate the new virus just go to the routines for generate the big parts of the virus. I called here this routines "Blocks". For example: [...] call InitVariables call GetMemory call GenerateVirus [...] Blocks.- This code must be able to do the appropiated calls for generate the blocks that form a virus, such as the "Go TSR" part in a TSR virus, the poly engine, the infection, and the "return control to host" part. That code as well is formed of subroutines too, that are from the Big Routines part. Big Routines.- This code must be dessigned for do more specific job than the above. Here would be included the algorithm for search files in a runtime, the algorithm for allocate memory, the interrupt handlers, etc. Routines.- This code will do the functions such as put the required values in the right places, and then perform an action, such as open a file, close it, map, unmap, set end of file, append viral code, etc. Opcode.- We are in the base, and the biggest part of the code. We must be able to regenerate all the required instructions, in machine-code, and we must be able to generate here the MOVs, ADDs, SUBs, XORs, i.e all the possi- ble instructions that a virus could use. There is required high knowledge of the lowest level of programming. I recommend you to have the whole list of opcodes, and to have a clear idea about what you must do for generate inde- xed movs, adds, and such like. I think that this part of the code generator would be full of calls, that put a simple opcode, two opcodes, all depending of our needs. gen_MOV_E??_imm32: ; Reg given in AL add al,0B8h stosb mov eax,ebx ; Imm32 given in EBX stosd ret Hmm. It could be also done (and really more optimized) with tables. Two ta- bles i think: one for the opcodes themselves, and another for have the info- rmation that should use each opcode. So one step wouldn't be nothing without all rest. The structure of the code as i described before would be very unoptimized, but what the fuck: the computers nowadays have a lot of HD space, so... I think that nothing would happen if our virus is about 30K :) Of course, for test at build time if it works or not, we must use a very powerful code emulator, and correct what's wrong. I suggest you that is better if we try to do it good from the beginning. Could our code generator life without an emulator? Yes. But i consider that if we randomize more the whole thing, we need it in order to avoid some possible fails and don't wan- ted crashes. 旼컴컴컴� � Virus � 읕컴쩡컴� � v 컴� Main 유- Blocks level 유- Big Routines level 유- Routines level 유- Opcode level 컴�컴 Emulation % There's a time to die % 컴컴컴컴컴컴컴컴컴컴컴컴� Yeah, our virus reached the end of his life. We must decide how many time it should live (we can use for count da time how many times the virus goes re- sident since born, time since born, etc.) and then, if it reached its end, and it had descendence, kill him. How? Many things could be done. Now, in my mind there are to possibilities: act like a runtime with its directory tras- versal routines, and disinfecting all files that seem to be infected by the virus itself, or intercept its way of checking if it's already resident (if the virus generated is TSR), detect the program owner of the process that is requesting such check, and disinfect it. Could seem that we are extermina- ting ourselves, but take note that the virus have to have a virus-son. If it hadn't do it, simply refuse to die. Of course, as i think you are enough clever, the virus-son have to have a different way for test its residency, and a different mark for infected files. Why kill a virus? Well, many explanations could be done, but better i should out you an example: imagine that people doesn't die... we would have the world full of unproductive persons around... Same with this, we kill the virus just because: a) we don't like to have many viruses trashing around, coz it would slow down the system, and b) we have to evolucionate. That's the main target of this document: make you think about the utopic idea of da virus evolution. Well, now you have many things for think about. % Last words % 컴컴컴컴컴컴컴 Well, in addition to this little article there is only one thing left to say and that is the fact that i will TRY to make this theory to be a fact, i.e., i'll try to code a virus with this. Anyway, i can't promise anything :) Billy Belceb�, mass killer and ass kicker.