ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Harder to detect (theory) ³ Billy Belceb£/DDT ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Make your viruses harder to be detected: that's the objective of this little tute. There're some techinques that are very necessary to implement, such polymorphism and stealth. Without them, we are lost. So we need them as a base weapon for remain undetected. With stealth i mean full stealth, and with polymorphism i'm talking about a good engine. Well, before continue with all, let's see what help us to remain undetected more time: - Polymorphism - Full stealth - Tunneling - Anti-heuristics - Anti-bait - Anti-debug Please note that this article will be 100% theorical, so you all, lovers of code, don't have anything to do here :) And you must know that i don't only explain its building, i talk about some ideas and related shit. Enjoy! % Polymorphism : the touch stone % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ This is a way for hide from AV. The AVers will try firstly to search for a reliable scan string of your code, so if we code a good polymorphic engine we're just doing what they hate: make him work. If our polymorphic engine is very variable, we're doing their job easier, because they will infect thou- sands of baits, so they will catch a scan string (yuck!)... what we can do? The slow polymorphism appeared to save us. This was a good idea: the first engines tried to make the code very mutable, but they didn't think that they were making AV work more easy coz they will catch a goddamn scan string in a faster way, so if we don't show them all our possible mutations in a shot period of time we're just fucking them... they must work much more in order to found a reliable algorithm with a high level of accuracy. In the polymorphism is the present, and the future. I think that an enough powerful engine in the (i hope) near future will be the first step for the implementation of the Artificial Intelligence on viruses. I heard some time ago for an idea for make a very special kind of polymorphic engine: generate very randomic instructions, and after each instruction, emulate all the de- cryptor in order to see the register, stack and all other important values. This is the beginning, the first step... think about all the possibilities it brings to us... generate 100% different slow mutators in two different computers, almost billions of possible mutations... this is very interesting stuff, but it needs a lot of code (with a lot i mean more than 20K), and no- wadays is too early for make viruses to great... but it can be made with any problem :) Just do it. Well, seems that i have forgotten the initial target of this part of the article ;) Polymorphism is a tecnique that provides us the possibilities of generate each time different decryptors in order to avoid any possible scan strings in our code. I won't explain here how to construct a polymorphic en- gine, there are a lot of tutes that will explain this better. If you wanna learn, read the Lord Julus tute in 29A#2 or another one if you want, and if you wanna read interesting comments about ideas for polymorphic engines you can read the schurmz algorithm under the viewpoint of StarZero in Xine#3, or the Methyl tutorials about envolving polymorphism... there're a lot of inte- resting tutes in the net, just search for them ;) I think that the actual polymorphic generators, used only for generate a ve- ry little piece of code (decryptor) will change its usage in the future... the polymorphic engine will generate a full virus, changing each time some parts of one routine and such like... have you catched the idea? % Full stealth : hide symptoms % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The first target of stealth was to hide the symptoms of a possible infection to the user, but when full stealth appeared, with techniques like disinfec- tion on the fly, and such like, it become to a method for hide from AV, like the polymorphism wanted to. All we know the symptoms of an infection: a lit- tle increase in the infected file size, the "Abort, Retry, Fail" when we are accessing a write-protected floppy, the errors when executing CHKSDK and SCANDISK, when executing compressors like PKZIP, ARJ, RAR and else... well, all this kinda thingies that makes the user know that there is something wrong. This is probably the second most important enemy of the virus writers (after the AV) : the user. When an user thinks he has a virus, he will ins- tall all kinda AVs, call to 911 and such like :) I think that all the ways we can use in order to hide from user's eyes can be labeled as stealth. An example can be the always included INT 24h handler for avoid critical messages. The best thing that stealth bring to us is time Time remaining undetected... But show "correct" size and else ain't full stealh. Full stealth comes to use when we are able to disinfect an infected program at time as it is being read, opened and such like. Think... if we're resident, any kinda AV will be able to detect the virus. % Tunneling : againist watchdogs % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Well, we need tunneling for obtain the original INT 21h vectors by a lot of possible ways: tracing with INT 1, byte-to-byte, psp tracing, backdoors, emulations... Tunneling bring us the possibility to be unnoticed when a TSR watchdog is installed in our system, passing possible checks, by not using its hooked vectors. Ok, i'm gonna explain each kind of tunneling, but don't expect a complete description, this document was written for another purpo- ses. Tracing with INT 1 is a very weak way for make tunneling, because it can be disabled by a lot of ways: it really executes the code of the AV. It had a lot of success some time ago, but nowadays this kinda tunneling is obsolete. The way for do this kinda tracing is setting the Trap Flag (shortened to TF) to ON. Then, after each instruction that the processor executes, it calls to the INT 1, so if we've hooked this interrupt, all the work will be done. Byte-to-byte scanning is very weak tho. It can cause hangs, but it has some- thing better that the tracing: it doesn't executes each instruction. It loads byte per byte the interrupt handler code, in order to search for opco- des that can pass the control to the real interrupt handler (far jumps, call and such like). The most famous stuff that used this way for tunneling was the K”hntarK Recursive Tunneling Toolkit (KRTT). PSP tracing uses a good trick: we have at offset 5 a far call to the INT 21h dispatcher, a very strange way to access INT 21h functions. The function number is placed in CL, and they must be >24h. But we're interested in off- set where the far call points (offset 6), the dispatcher. I won't explain here how to catch the real INT 21h vector... anyways u can read the Satan's Little helper tute published in VLAD#3 for more information. I won't explain all the possible backdoors, the only thing you must know is that a backdoor are all the possible ways for obtain any interrupt via an undocumented function. For me, the emulation is the best way for perform tunneling. If you want to understand what emulation is you must know what it does. Basically the emu- lators follow the "flow" of the code, it simply makes what the instruction must do withou executing it. Seems difficult, but don't believe that. It ma- kes the calls, jumps and whatever you want it to do :) % Anti-Heuristics : anti-high tech? % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The heuristic scanners were a revolution in the AV side. The most important product of the AV was TBAV (argh!). But... what the heuristic analyzers do? They only search for routines ussually used in viruses, such as decryptors, write to files, wildcards and such like. And then... how we can avoid the scanners? They ussually don't watch the contents of the registers, so we can play with some math operations. There's always a solution for each flag: simply do some playing around when you find the routine that triggers it. So, if we think it with more care, we'll see that the heursitics aren't high technology or something alike; heuristics are just a good idea, but anything else. We'll have a lot of problems when the AV include an AI engine in their packages, but with the nowadays' products there isn't more problems. Call me "visionary" or whatever you want, but i think that the viruses will include artificial intelligence before the AV... The first step was done by StarZero and his idea of applying the schurmz algorithm to the viruses, or at least, the polymorphic engines... the crossbreeding. A nice future, don't u think? But for reach this point we must work, pals... % Anti-Bait : damned do-nothing progs % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Baits (or goats) are little do-nothing programs, that only exists for catch viruses. Yeah, the fool viruses will infect them, and the AV will have a co- py of our virus (yuck!). The way for avoid them can be as simply as refuse files that have numbers in their name (ussually baits are labeled 00000.COM or something alike). This method avoids us a lot of problems, but... what if the AVer uses names like AAAAAAAA.COM, AAAAAAAB.COM and such like? Simply refuse to infect consecutive files, by adding all the characters' ascii va- lues, and see if the next file is ñ10 (or another value you like, but always little), and if it is, refuse it. Another very good tricks make the AVers to have a headache ;) If our virus is polymorphic, the AVer will infect thousands of baits in order to chatch a reliable scan string and/or an algorithm for detect about all the possible mutations in the code. Just refuse to infect to little files (about >10000 bytes will be enough). Well, if AVer has made 10000 baits, and each bait use 10000 bytes... just think... we sucked a good amount of his HD. And, if we add slow mutation to our polymorphic engine, he will need to reboot a lot his computer, so we can use a timer that makes the virus refuse to infect files in about 10 minutes, moreless. Hehehe... at this point we have an AVer very angry, with a terrible headache and a deep hate of his work ;) We can use another cool addings, like search the file for a lot of NOP, or see if the first bytes are for terminate program... or zero calls/jumps... Use your imagination! % Anti-Debugging : stop that shit please % ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The debuggers are ussually used to fuck us... Everybody can see our code, our secrets, our ideas without any kinda permission ;) So... we need to avoid this shit. There are some ways for make them ear their own shit. I really recommend you to read, for example my virus writing guide, in its "armouring" section, or any other related article. There are a lot of tutes about this matter, so go and take a look to them ;) Billy Belceb£, mass killer and ass kicker