Viric life and die
theories
Billy Belcebu/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, reproduce 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 explain 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 possible 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 indexed 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 tables i think: one for the opcodes themselves, and another for have the information 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 wanted 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 resident 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 traversal 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 exterminating 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 Belcebu,
mass killer and ass kicker.