Copy Link
Add to Bookmark
Report
Chaos Digest Volume 01 Numero 59
Chaos Digest Mardi 22 Juin 1993 Volume 1 : Numero 59
ISSN 1244-4901
Editeur: Jean-Bernard Condat (jbcondat@attmail.com)
Archiviste: Yves-Marie Crabbe
Co-Redacteurs: Arnaud Bigare, Stephane Briere
TABLE DES MATIERES, #1.59 (22 Juin 1993)
File 1--40H VMag Number 7 Volume 2 Issue 3 #000-003(1) (reprint)
Chaos Digest is a weekly electronic journal/newsletter. Subscriptions are
available at no cost by sending a message to:
linux-activists-request@niksula.hut.fi
with a mail header or first line containing the following informations:
X-Mn-Admin: join CHAOS_DIGEST
The editors may be contacted by voice (+33 1 47874083), fax (+33 1 47877070)
or S-mail at: Jean-Bernard Condat, Chaos Computer Club France [CCCF], B.P.
155, 93404 St-Ouen Cedex, France. He is a member of the EICAR and EFF (#1299)
groups.
Issues of ChaosD can also be found from the ComNet in Luxembourg BBS (+352)
466893. Back issues of ChaosD can be found on the Internet as part of the
Computer underground Digest archives. They're accessible using anonymous FTP:
* kragar.eff.org [192.88.144.4] in /pub/cud/chaos
* uglymouse.css.itd.umich.edu [141.211.182.53] in /pub/CuD/chaos
* halcyon.com [192.135.191.2] in /pub/mirror/cud/chaos
* ftp.cic.net [192.131.22.2] in /e-serials/alphabetic/c/chaos-digest
* cs.ubc.ca [137.82.8.5] in /mirror3/EFF/cud/chaos
* ftp.ee.mu.oz.au [128.250.77.2] in /pub/text/CuD/chaos
* nic.funet.fi [128.214.6.100] in /pub/doc/cud/chaos
* orchid.csv.warwick.ac.uk [137.205.192.5] in /pub/cud/chaos
CHAOS DIGEST is an open forum dedicated to sharing French information among
computerists and to the presentation and debate of diverse views. ChaosD
material may be reprinted for non-profit as long as the source is cited.
Some authors do copyright their material, and they should be contacted for
reprint permission. Readers are encouraged to submit reasoned articles in
French, English or German languages relating to computer culture and
telecommunications. Articles are preferred to short responses. Please
avoid quoting previous posts unless absolutely necessary.
DISCLAIMER: The views represented herein do not necessarily represent
the views of the moderators. Chaos Digest contributors
assume all responsibility for ensuring that articles
submitted do not violate copyright protections.
----------------------------------------------------------------------
Date: Tue May 11 09:24:40 PDT 1993
From: 0005847161@mcimail.com (American_Eagle_Publication_Inc. )
Subject: File 1--40H VMag Number 7 Volume 2 Issue 3 #000-003(1) (reprint)
40Hex Number 7 Volume 2 Issue 3 File 000
Welcome to 40Hex issue 7! As you may have noticed, we are a little
late in releasing this issue. This is mainly because very little has
gone on for us to write about. Enough of the excuses, on with the show.
We are going to start by giving you a little news update on what we've
been up to.
First of all, Hellraiser is back in New York. He moved back towards
the end of May. Once he gets settled and I give him his computer, I am
sure he will be back writing more virii, and possibly editing 40Hex (not
sure if he wants the task of editing 40Hex). Anyways, to say the
least, its great having him back where he belongs.
Second, we have several new virii out, these will NOT appear on
Virus BBSs. Not even ours. The reason is simple. Anti-Virus people
are not in the dark anymore. They are on Virus BBSs. Since we want our
virii to remain as undetectable as possible, giving them to the general
public is just no longer an option. Nonetheless, the new virii will be
sure to surprise everyone.
Third, LandFill BBS is back online. The number won't be given out
in the mag, I don't want it getting posted on FidoNet. I am silly that
way. The other reason I am not putting the number in it is because I
don't want 100+ lamers reading it, and giving the BBS a call.
Fourth, a new installment of Dark Angel's Virus Writing Guide came
out, get it, it is chunky.
Finally, greetings to three new members, Black Mischief (Hacker), and
iNVALiD MEDiA (Hacker, SysOp Of Unphamiliar Territories, which is now
invite only!), and Stingray (Ex-VIPER).
Table Of Contents
40Hex-7.000................You've Just Read it
40Hex-7.001................Virii in the News Part I
40Hex-7.002................Code Concealment [2]
40Hex-7.003................An Introduction to Non-overwriting Virii
40Hex-7.004................Enough Tinys to Sink a Ship
40Hex-7.005................MtE News Stories
40Hex-7.006................Virus Spotlite:Dissassembly of Leap Frog
40Hex-7.007................Spammies Reminder
40Hex-7.008................Virii in the News Part II
40Hex-7.009................Debug Script for Pogue Mahone
Greets to: [NuKE], VIPER, All of the Spammies Entries,
All -=PHALCON/SKISM=- Members, Dark Avenger
and anyone else that keeps the virus scene
going strong.
->GHeap!
+++++
40Hex Number 7 Volume 2 Issue 3 File 001
WISHFUL THINKING WILL NOT MAKE PUBLICITY-SEEKING VIRUSES GO AWAY
[Hmmmm, a publicity seeking virus. I had a virus like that. It
infected my computer and called every news agency telling them what it
had done.]
By: Paul Melka for Infoworld 4/27
We have all heaved a collective sigh since March 6 came and went
with little computer damage from the Michelangelo Virus. But this sense
of relief obscures what I believe is a very important fact: Michelangelo
was a turning point in the industry, as much as Microsoft's Windows 3.0
was.
Prior to March 6, the trigger date for the virus, many people hours
were spent in organizations large and small trying to prepare for
attack. [Gimme a break. An 'attack'.] And when all said and done,
PCs in the United States fared pretty well. Still everyone's memory of
the Michelangleo virus has begun to fade, and the press - which
thoroughly covered the looming threat - is now focused on how little
damage was done or how much money virus-protection vendors made.
That frustrates me. It misses a subtle yet more important aspect of
viruses: With all the publicity that Michelangelo generated, it was
the forerunner of more powerful and more destructive viruses.
The publicity from Michelangelo threw down the gauntlet to virus
writers to create newer and more destructive viruses. Gone are the days
when letters simply fall to the bottom of your screen or you get
prompted by messages asking for cookies or birthday greetings. The
industry is just beginning to see the emergence of polymorphic viruses
that change their signatures with each infection.(Already a working
version of the self-mutating engine that creates polymorphic viruses is
available on some bulletin boards, along with manuals.) And we are
beginning to see viruses that are specifically designed to foil various
detection applications. Finally there are shrink-wrapped applications
infected with viruses; now there is no "safe" way to purchase software.
The virus software authors also have an advantage over all antivirus
authors in that they can see exactly what they are going against, while
the antivirus developers still have to react to new, unknown viruses.
What types of viruses are next? I don't know, and probably most of
the experts don't know either. But you can certainly speculate on the
various directions that could be taken in the very near future. We have
already seen the evolution from file infecting viruses, boot sector
viruses, and stealth viruses to polymorphic viruses.
The increase in the number and occurences of viruses is real.
Products less then a year old that search for "over 300 viruses" are
almost laughed at today, as security specialists cite documentation of
more than 1,000 different strains of viruses. The National Computer
Security Association estimates that by the end of 1994, there will be
almost 40,000 different virus strains. [A shame they will mostly be
Tiny variants and Jerusalem Hacks]
With that kind of explosion, new protection methods will be needed.
Most of today's scanners would spent more time scanning each file for
viruses than there are working hours in a day. We will see better and
more efficient methods of detecting and preventing viruses that still
allow full use of the computer.
As a security analyst for a large utility company, I try to keep
everyone educated on the dangers of viruses and how best to avoid them.
I also try to keep myself and the company as up to date as possible on
what is happening with viruses. But unless everyone realizes that
viruses are real and takes reasonable action against them, there will
come a time when a new "super virus" that cannot be detected by any of
the existing packages is developed. [Wonder who is gonna write that one?]
It will literally cripple some major corporations, while destroying other
businesses completely.
I don't advise going back to paper and pencil, but I do think that
all PC users have to be vigilant about the threat of viruses, to educate
themselves on the prevention of viruses, and to institute "safe"
practices, including backing up data and using virus-protection
software.
The official patented 40-Hex rebuttal:
Paul Melka seems to be fairly accurate. However, there are some
things I feel are wrong. For example the estimation that there will
be 40,000 virus strains by the end of 1994. Let's just say for example
that it is about 2 years away. That would mean that there would be 53
viruses written a day, or 2.2 viruses written an hour! Jeez, we all
have a shitload of work to do. Do you find this hard to believe? I do.
Of course, the way the virus scene is heading, we are becoming like the
warez scene. All the half-assed fools spreading stuff to other BBSs, not
even seeing what they are, or if they are real. Ahh well, enough of my
complaints.
When Mr. Melka mentioned that there was no "safe" way of purchasing
software, it got me thinking. He is definately correct. Of course, I feel
that it is the responsibility of all software publishers to check their
disks before packaging them.
At first, he seemed to be very neutral, but as the article
progressed, I noticed that even Mr. Melka seemed to fall down the
endless pit of ignorance, and resorted to a scare tactic: a virus that
nothing can detect or kill. He started off saying that he was
speculating, but when he said "...there WILL come a time when a new 'super
virus' that cannot be detected by any of the existing packages is
developed. It will literally cripple some major corporations, while
destroying other businesses completely." he said WILL. It bothers me
that a member of the computer security community would be so close-
minded.
We are not trying to justify the writing of virii, mainly because we
don't have to. It isn't illegal. Making it illegal can't be done; it
takes away our rights. Of course, we want to distinguish that we don't
spread our virii to anyone who doesn't know that they are virii. It is
what they do from there that may be against the law.
If you think it stopped here, here is a letter to the editor of
Infoworld about the above article:
Both Steve Gibson and Peer-to-Peer columnist Paul Melka have hit on
the reason for the current explosion of viruses. The key is in the title
to Mr. Melka's column: "Publicity-Seeking."
Virus writers have the same mentality as chain mail writers: They
like to see how far their viruses spread and they track the spread of
their virus by its nickname. The glory from this spread would be
greatly diminished if viruses were referred to by mundane serial numbers
like 7B386621C rather than captivating nicknames like Michelangelo.
I would like to lead a campaign [The Anti Virus Crusades! Ha! I
love it!] on two fronts:
First: Establish a no-nickname rule. The National Computer
Security Association and other groups should start referring to viruses
with nondescriptive serial numbers rather than glamorous nicknames.
Second: Ask other readers to write representatives and demand
legislation that would impose suitable penalties for malicious computer
crimes. These penalties would include jail terms. [GULP!]
In closing, I believe that this is a perfect opportunity for BIOS
manufacturers to sell BIOS upgrades. Mr. Gibson's observation that the
best defense mechanism for existing viruses lies in the ROM BIOS is
absolutely correct. Seventy-four percent of virus infections could be
eliminated by a simple BIOS change. I am part of a support center for
more than 5,000 PCs; I have yet to detect a virus on those few PCs that
boot only from the hard drive.
Marvin Bullock [Buttock?]
Nashville, TN
Rebuttal part ][
----------------
Ok, this guy I don't really respect. The no-nickname rule. W0W!
What a concept. Because you take the name away from my program, I won't
recognize when some one posts "Oh yeah, The virus 7XZ23576B upon
activation a siren is heard as a ambulance is displayed across the
screen." We'd never pick up on that. I also want to know where he got
the 74% figure. It may be true, but it wasn't documented. I am not
going to argue the anti-virus issue, as I can only speculate.
Basically, it takes a twit to catch a virus. Watch what is put on your
system. If you are a system administrator, don't allow standard write
access to the network drives. If you do, expect a message like "Your
computer is stoned". In reality, YOU should be.
PS:Gibson's article refered to the Dark Avenger's MtE, worthwhile if
you don't know about it, otherwise, it is pointless.
->GHeap
+++++
40Hex Number 7 Volume 2 Issue 3 File 002
% Code Concealment %
% -Demogorgon/PHALCON/SKISM %
In the previous issue of 40hex, I wrote about how a programmer can
keep his code from being stolen by others. Ways of doing this are
endless, and I will talk about a few more methods in this installment.
Part I : Fun with int3
Part II : Fun with int8
Part III: The Prefetch
Part_I : Fun with int3
Int three is the debugger breakpoint. Every time a debugger breaks
while tracing through a chunk of code, it will call int3. Int3 is
called after every instruction is executed in trace mode, and after
a breakpoint is reached. Note that protected mode debuggers do not
execute int3 in trace mode, but they will break when int3 is called from
your code. You can use this to your advantage. Simply install a new
handler for int3 and it will execute instead of the debugger if a thief
tries to trace through your program.
start: mov ax, 2503h
mov dx, offset int_start
int 21h ;put in the new handler at ds:dx
... ;rest of real code here
int 20h
text db 'Smoke Mah Ass!$'
int_start:
mov ah, 9
mov dx, offset text
int 21h
int 20h
As soon as the first int21 call in this program is made, the code
at int_start will execute if it is being traced in a debugger.
Otherwise, the int call will be ignored and your normal code will
execute. The program can do whatever you want if a debugger is found.
For example, you can format the hard drive or display a message. The
possabilities are endless. By the way, it might be wise to restore the
old interrupt handler before you exit the program, because it is bad
programming practice to leave interrupts pointed into non-allocated
memory.
compatability:(works against all debuggers marked with an X)
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X
-------------------------------------------------------------------------
Part_II: Fun with int8
The next segment will show you how to make a program nearly
impossable to trace. The concept is simple. All you need to do is
place the main body ofyour program into an int8 handler. Int8 is the
timer interrupt, and it is called 18.2 times a second. Debuggers do not
execute int8, so whatever you put there will only go when it is run from
dos. The only drawback to this is a short delay before the main program
is executed. It will probably go unnoticed, in most cases. Here is
some code:
thyroid:mov ax, 3508h
int 21h ;get int8 handler
mov word ptr [int_store], bx ;store it
mov word ptr [int_store+2], es
mov dx, offset prog_start
mov ah, 25h
int 21h ;install new int8 handler
yip: cmp flaag, 1
jne yip ;wait for int8 to be called
;int8 must set the flaag to 1
push bx
pop dx ;restore
push es ;old
pop ds ;int8
int 21h ;handler
int 20h
flaag db 0
int_store dd ?
prog_start:
_main_program proc far
;save all the necessary registers here
;... your code
mov flaag, 1
;restore the registers
jmp dword ptr [offset int_store] ;chain to real int8 handler
_main_program endp
This code is quite useful in that if some guy tries to trace
through it, he will be stuck forever in the 'yip' loop. The main code
will never be executed. If he tries to get out of the loop by
'executing to' the next instruction, he will end up running the entire
program. No debugger I know of can trace through this, because int8 is
not called from within the debugger.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
Part_III: The Prefetch
My favorite way to confuse debuggers is to mess with the prefetch
queue. All intel processors have a small queue where the next
instructions to be executed are stored. In this way, the CPU does not
have to waste clock cycles by fetching the next instruction, except in
the cases of branching instructions such as jmps and calls. The next
chunk of code makes use of this:
eapple: mov ah, 9
mov word ptr [offset ear_lobe-2], offset sukk_debug
mov dx, offset text
ear_lobe:
int 21h
int 20h
text db 'snee!$'
sukk_debug db 0Ah, 0Dh, 09h, 'blow a goat!', 07h, 0Ah, 0Dh, '$'
All this program does is print out a text string. If it is run
from dos, it will print out 'snee!'. If it is traced through by any
debugger, however, it will print 'blow a goat!', and beep the PC speaker
(07h is ctrl-g). Let me explain how this works.
When any chunk of code is executed by dos, the first few bytes are
sent into the prefetch queue. The actual number of bytes depends on the
model of intel chip, and what year it was made in. My computer is a
386DX-20 (early model), which has a 16 byte prefetch. Be sure to check
your code on several machines to insure compatability.
When the second instruction is reached, it places the offset of
sukk_debug into the next instruction. That is, the next instruction
becomes 'mov dx, offset sukk_debug', rather than 'mov dx, offset text'.
The system memory will be changed, but the prefetch will not, therefore
only a debugger will respond to the new code. Dos will execute it as if
the instruction had never changed, because the instruction will already
have been loaded into the prefetch. This theory can be used, with a
little modification, in order to branch to various subroutines, rather
than just printing out different text. One interesting application of
this is to use the prefetch area to store registers. This way, a person
debugging your code can not simply nop it out, because it will be
referred to later on. In fact, you can even put the stack on the
prefetch. Try to debug through the following fragment, and watch what
happens:
nee: mov ax, 4Ch
mov dx, offset text
mov sp, offset fin_rot
push ax
mov ah, 9
fin_rot:int 21h
pop ax
int 21h
text: db 'Duck is proud of her feet. They can catch things.$'
If you run it through debug, the entire program will be corrupted
as soon as you move the stack pointer. This is because the debug code
uses the stack and expects it to be in a safe location. If you run it
through soft ice, the code will be corrupted as soon as you push ax.
The stack area will be overwritten when int21 is executed, because the
interrupt uses the stack. However, in this example, the instruction
pointer will already be beyond this area, so the program will execute
normally.
Remember not to place the stack past any calls, because then the
prefetch would have to be reloaded after the main program was returned
to, and the instructions that were there before will be gone.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
That about wraps it up for this installment. I will probably have
some new methods for you the next issue, unless I get bored and decide
to drop the whole idea. Keep in mind that the best ideas are your own.
% % % % % % % % % % % % % % % % % % % % % %
Remember: Unprotected code is public domain!
% % % % % % % % % % % % % % % % % % % % % %
[] If anyone has any questions or comments about my series, []
[] or some more suggestions for methods that can be added to []
[] it, feel free to drop me a note on Landfill BBS []
+++++
40Hex Number 7 Volume 2 Issue 3 File 003
+++++++++++++++++++++++++++++++++++++++
An Introduction to Nonoverwriting Virii
By Dark Angel
+++++++++++++++++++++++++++++++++++++++
It seems that there are quite a few virus writers out there who just sit at
home and churn out hacks of virii. Yay. Anybody with a disassembler and
some free time can churn out dozens of undetectable (unscannable) variants
of any given virus in an hour. Others have not progressed beyond the
overwriting virus, the type of virus with the most limited potential for
spreading. Still others have never written a virus before and would like
to learn. This article is designed as a simple introduction to all
interested to the world of nonoverwriting virii. All that is assumed is a
working knowledge of 80x86 assembly language.
Only the infection of COM files will be treated in this article, since the
infection routine is, I think, easier to understand and certainly easier to
code than that of EXE files. But do not dispair! EXE infections will be
covered in the next issue of 40Hex.
COM files are described by IBM and Microsoft as "memory image files."
Basically, when a COM file is run, the file is loaded as is into memory.
No translation or interpretation of any sort takes place. The following
steps occur when a COM file is run:
1) A PSP is built.
2) The file is loaded directly above the PSP.
3) The program is run starting from the beginning.
The PSP is a 256 byte header storing such vital data as the command line
parametres used to call the program. The file is located starting at
offset 100h of the segment where the program is loaded. Due to the 64K
limit on segment length, COM files may only be a maximum of 64K-100h bytes
long, or 65280 bytes. If you infect a COM file, make sure the final size
is below this amount or the PSP will get corrupted.
Since the beginning of the file is at offset 100h in the segment (this is
the reason for the org 100h at the start of assembly source for com files),
the initial IP is set to 100h. The key to understanding nonoverwriting COM
virii is to remember that once the program is loaded into memory, it can be
changed at will without affecting the actual file on disk.
The strategy of an overwriting virus is to write the virus to the beginning
of the COM file. This, of course, utterly annihilates the original program.
This, of course, is lame. The nonoverwriting virus changes only the first
few bytes and tacks the virus onto the end of the executable. The new
bytes at the beginning of the file cause the program, once loaded, to jump
to the virus code. After the virus is done executing, the original first
few bytes are rewritten to the area starting at 100h and a jmp instruction
is executed to that location (100h). The infected program is none the
worse for the wear and will run without error.
The trick is to find the correct bytes to add to the beginning of the file.
The most common method is to use a JMP instruction followed by a two byte
displacement. Since these three bytes replace three bytes of the original
program, it is important to save these bytes upon infection. The JMP is
encoded with a byte of 0e9h and the displacement is simply the old file
length minus three.
To replace the old bytes, simply use code similar to the following:
mov di, 100h
mov si, offset saved_bytes
movsw
movsb
And to return control to the original program, use the following:
mov di, 100h
jmp di
or any equivalent statements.
When writing nonoverwriting virii, it is important to understand that the
variables used in the code will not be in their original locations. Since
virii are added to the end of the file, you must take the filesize into
account when calculating offsets. The standard procedure is to use the
short combination of statements:
call oldtrick
oldtrick:
pop bp ;bp = current IP
sub bp, offset oldtrick ;subtract from original offset
After these statements have been executed, bp will hold the difference in
the new offsets of the variables from the original. To account for the
difference, make the following substitutions in the viral code:
lea dx, [bp+offset variable]
instead of
mov dx, offset variable
and
mov dx, word ptr [bp+offset variable]
instead of
mov dx, word ptr variable
Alternatively, if you want to save a few bytes and are willing to suffer
some headaches, leave out the sub bp, offset oldtrick and calculate all
offsets as per the procedure above EXCEPT you must now also subtract offset
oldtrick from each of the offsets.
The following is a short nonoverwriting virus which will hopefully help in
your understanding of the techniques explained above. It's sort of cheesy,
since I designed it to be small and easily understandable. In addition to
being inefficient (in terms of size), it fails to preserve file date/time
and will not infect read-only files. However, it serves its purpose well
as a teaching aid.
------------------------------
End of Chaos Digest #1.59
************************************
