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