The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / n_z / pirate2.008 < prev next >

Wrap

Text File | 2003-06-11 | 60.6 KB | 1,308 lines

******************************************************* * PHILE 8: VIRUSES * ******************************************************* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ There has been a lot of concern about viruses, even though they still seem to be relatively rare. Forewarned is forearmed, as they say, and we've come across a pretty useful anti-virus newsletter called VIRUS-L that gives info on all the latest bugs, vaccines, and general gossip. It's called VIRUS-L, and we've found it helpful, so we've extracted some of the best of the stuff and passed it along. Thanks to FLINT (of the UNDERGROUND) and CHRIS ROBIN for pulling some of the stuff together. * * * VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU. Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: Wed, 06 Sep 89 11:54:00 -0400 From: Peter W. Day <OSPWD%EMUVM1.BITNET@IBM1.CC.Lehigh.Edu> Subject: Re: Appleshare and viruses >Date: 04 Sep 89 01:18:53 +0000 >From: gilbertd@silver.bacs.indiana.edu (Don Gilbert) >Subject: Appleshare and viruses ? > >What are the conditions under which current Mac viruses can >infect files on Appleshare volumes? I have not attempted to infect any files with a virus, whether on an AppleShare volume or otherwise, but based on what I know about Macintosh, AppleShare and viruses, here is what I think is true. A Mac virus can infect a file only if it can write to the file, no matter where the file is located. A micro cannot access an AppleShare volume directly: it must ask the server to access the AppleShare volume on its behalf. As a result, the server can enforce access privileges. Access privileges apply only to FOLDERS. For the benefit of other readers, the privileges are See Files, See folders and Make Changes. They apply individually to the owner, a group, and everyone. I experimented writing directly to files and folders on an AppleShare volume using Microsoft Word, typing the explicit file path in a Save As... dialog box. For a file to be changeable, the volume and folders in the file path must have See Folders privilege, and the final folder must have See Files and Make Changes privilege. The virus would probably need to search for files to infect, and would only find files along paths with See Folders privs for the volume and folders in the path, and See Files in the final folder. Macintoshes used with shared files are subject to trojans, and the trojan could be infected with a virus. Consider the following scenario: A user has a private folder on a volume shared with others using (say) AppleShare. The volume has a folder containing a shared application named, say, Prog1, and the folder has everyone See Files and See Folders but not Make Changes (i.e. it is read-only). The user makes a private copy of Prog1, and later runs a virus-infected program locally while the shared volume is mounted, and the copy of Prog1 becomes infected. The user now makes his AppleShare folder sharable (See Files, See Folders) to everyone (so that someone can copy a file he has, say). Another user double-clicks on a document created by Prog1, and the Mac Finder happens to find the infected copy of Prog1 before finding the other copy. As a result, the second user's files become infected. Thus I recommend that private folders be readable only by the owner as a matter of policy. Allowing everyone Make Changes creates drop folders so that users can exchange files. Drop Folders are safe enough in that AppleShare does not allow you to overwrite a file when you only have Make Changes priv. However, users should be told to run a virus check on any files that others drop in their folders. ------------------------------ --------------------------------------------------------------------------- Date: 04 Sep 89 16:41:39 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: New Amiga virus ? This was recently posted to comp.sys.amiga... In article <716@mathrt0.math.chalmers.se> d8forma@dtek.chalmers.se (Martin Fors sen) writes: | | Last night a friend called me, since he suspected he had a virus. | I gladly grabbed my copy of VirusX (3.20) and drove over, but VirusX | reported no virus. However I saw the text from the virus myself, and | a closer look at the diskette showed that the file c/addbuffers had grown, | furthermore a file with a blank name had appeared in devs. | | The main symptom of this virus is that every fourth time you reboots the tex | | A Computer virus is a disease | | Terrorism is a transgession | | Software piracy is a crime | | this is the cure | | BGS9 Bundesgrensschutz sektion 9 | sonderkommando "EDV" | | On this disk the virus had replaced the file c/addbuffers, the size of this | new file was 2608 bytes. The above text is encoded in the program, but the | graphics.library :-) The orginal addbuffers command was stored in a "blank" | file in the devs directory. | The addbuffers command was the second in the startup sequence on this disk. | I think the virus looks in the startup-sequence for somthing (probably | files to infect), since I found the string sys:s/startup-sequence coded | in the virus. | I don't know if this virus does any damage, but the person first infected | hasn't noticed anything. | | The questions I now ask me is: | | Is this a known virus? | | and if the answer is no, | | What is Steve Tibbets mail adress? | | | MaF | | Chalmers |USENET:d8forma@dtek.chalmers.se | " Of course I'm not lost, | University |SNAIL: Martin Forssen | I just haven't pinpointed | of | Marielundsgatan 9 | exactly where we are at the | Technology |SWEDEN 431 67 Molndal | moment " (David Eddings) - -- Jim Wright jwright@atanasoff.cs.iastate.edu ------------------------------ Date: Fri, 01 Sep 00 11:51:00 -0400 From: Bob Babcock <PEPRBV%CFAAMP.BITNET@IBM1.CC.Lehigh.Edu> Subject: Re: Is this a virus? (PC) >When I copy some >files to a floppy but I misput a write protected diskette, I find the >error massage "retry, ...". At this time, if I answer "r" to the >massage and puting a non-protected diskette, then the FAT and >DIRECTORY of the protected diskette is transfered to the second non >protected diskette(and the files that I copied to). Is this a DOS's >bug or a virus? This is a known behavior of MS-DOS. The directory and FAT have already been read before the write protect error is sensed, and when you say retry, DOS doesn't know that you have changed disks, so it doesn't reread the directory info. ------------------------------ Date: Fri, 01 Sep 89 16:55:59 -0500 From: Joe Simpson <JS05STAF@MIAMIU.BITNET> Subject: Re: is this a virus? (PC) In response to the question about the FAT from a locked disk being written to another disk this is a feature of MS-DOS, not a virus. Another chilling scenario conserns running an application such as a word processor, opening a document, exchangeing data diskettes, and saving a "backup" of the file. This often hoses the "backup" disk and sometines affects the origional file. ------------------------------ Date: 01 Sep 89 15:41:00 -0400 From: "Damon Kelley; (RJE)" <damon@umbc2.umbc.edu> Subject: Kim's question concerning FATs (PC) In response to Kim: I'm no expert at MS-DOS or software-stuff, but I've been poking around in my computer's memory long enough to believe that what you are describing may be normal with MS-DOS. Often I see that within memory, data stays in its assigned spot until something moves or writes over it. I notice this effect with a certain software word-processing/graphing/spreadsheet package I have. Sometimes when I am retreiving data with my package, I place a data disk first before putting in the main program disk. The program needs to do something with the disk with the main program first, so the package asks for the main program disk. Whe the directory pops up for the main program disk, it shows a conglomeration of the files on the curent disk PLUS the files that were on the removed data disk and some random garbage. Nothing grave has happened to my files with this package (It came with my computer. It wasn't PD/Shareware, either.), so I feel that this may be either a DOS bug (not writing over completely the FAT) or something normal. Of course, I've never really had an opportunity to look at the directory track on any disks, so I can't confirm that this is absolutely true. I can find out. Has anyone out there found mixed FATs affecting the performance of their disks? ------------------------------ Date: Wed, 30 Aug 89 14:41:53 -0000 From: LBA002%PRIME-A.TEES-POLY.AC.UK@IBM1.CC.Lehigh.Edu Subject: nVIR A and nVIR B explained (Mac) I spotted this in the August issue of Apple2000 (a UK Mac user group magazine.) It first appeared on the Infomac network and the author is John Norstad of Academic Computing & Network Services, Northwestern University (hope it's OK with you to reproduce this John?) It may be old-hast to all the virus experts but I found it interesting & informative. nVIR A & B There has been some confusion over exactly what the nVIR A & nVIRB viruses actually do. In fact, I don't believe the details have ever been published. I just finished spending a few days researching the two nVIR viruses. This report presents my findings. As with all viruses, nVIR A & B replicate. When you run an infected application on a clean system the infection spreads from the application to the system file. After rebooting the infection in turn spreads from the system to other applications, as they are run. At first nVIR A & B only replicate. When the system file is first infected a counter is initialized to 1000. The counter is decremented by 1 each time the system is booted, and it is decremented by 2 each time an infected application is run. When the counter reaches 0 nVIR A will sometimes either say "Don't Panic" (if MacinTalk is installed in the system folder) or beep (if MacinTalk is not installed in the system folder.) This will happen on a system boot with a probability of 1/16. It will also happen when an infected application is launched with a probability of 31/256. In addition when an infected application is launched nVIR A may say "Don't Panic" twice or beep twice with a probability of 1/256. When the counter reaches 0 nVIR B will sometimes beep. nVIR B does not call MacinTalk. The beep will happen on a system boot with a probability of 1/8. A single beep will happen when an infected application is launched with a probability of 15/64. A double beep will happen when an application is launched with a probability of 1/64. I've discovered that it is possible for nVIRA and nVIRB to mate and sexually reproduce, resulting in new viruses combining parts of their parents. For example if a system is infected with nVIRA and if an application infected with nVIRB is tun on that system, part of the nVIRB infection is replaced by part of the nVIRA infection from the system. The resulting offspring contains parts from each of its parents, and behaves like nVIRA. Similarly if a system is infected with nVIRB and if an application infected with nVIRA is run on that system, part of the nVIRA infection in the application is replaced by part of the nVIRB infection from the system. The resulting offspring is very similar to its sibling described in the previous paragraph except that it has the opposite "sex" - each part is from the opposite parent. it behaves like nVIRB. These offspring are new viruses. if they are taken to a clean system they will infect that system, which will in turn infect other applications. The descendents are identical to the original offspring. I've also investigated some of the possibly incestual matings of these two kinds of children with each other and with their parents. Again the result is infections that contain various combinations of parts from their parents. (Hot stuff!) Rgds, Iain Noble ------------------------------ Date: Tue, 29 Aug 89 16:05:44 +0300 From: Y. Radai <RADAI1@HBUNOS.BITNET> Subject: PC virus list; Swap virus; Israeli virus; Disassemblies For several reasons, one of which is very irregular receipt of VIRUS-L, I've been out of touch with it for several weeks now. So please forgive me if some of the postings referred to below are a few weeks old. PC Virus List ------------- Lan Nguyen asks whether a list of PC viruses, incl. date first dis- covered and source(s), exists. I will soon be submitting to VIRUS-L a considerably updated version of the list I first posted on May 16. Meanwhile, Lan, I'm sending you my list as it currently stands (29 viruses, 70 strains). The Swap Virus -------------- Yuval Tal writes: >I don't think that it is so important how we call the virus. I've >decided to call it the swap virus becuase the message "The Swapping- >Virus...' appears in it! ....... I think that calling it "The >Dropping Letter Virus" will be just fine. Well, "The Dropping Letter Virus" would be a poor choice since (as I mentioned in an earlier posting) this also describes the Cascade and Traceback viruses. Yuval has explained that he originally called it the Swap virus because it writes the following string into bytes B7-E4 of track 39, sector 7 (if sectors 6 and 7 are empty): The Swapping-Virus. (C) June, 1989 by the CIA However, he has not publicly explained how the words SWAP VIRUS FAT12 got into the boot sector of some of the diskettes infected by this virus, so let me fill in the details. As David Chess and John McAfee both pointed out quite correctly, these words are not part of the virus. What happened was that Yuval wrote a volume label SWAP VIRUS onto each infected diskette for identification. Had his system been DOS 3 the label would have been written only into the root directory. But since he was apparently using DOS 4, it was also written into bytes 2Bh-35h of the boot sector. (That still leaves the string FAT12 in bytes 36h-3Ah to be explained. Under DOS4, the field 36h-3Dh is supposed to be "reserved". Anyone got any comments on that?) So although I didn't know at the time that the words SWAP VIRUS came from Yuval, it seems that my (and his original) suggestion to call it the Swap virus is still the best choice. The Israeli/Friday-13/Jerusalem Virus ------------------------------------- In response to a query from Andrew Berman, David Rehbein gave a quite accurate description of the virus, except for one small point: >(It will infect and replicate itself in ANY executible, no matter >the extension..check especially .OVL and .SYS) To the best of my knowledge, no strain of this virus (or, for that matter, of any other virus that I know of) infects overlay or SYS files. Andrew Berman writes concerning this virus: > She think's >she's cleaned it out by copying only the source codes to new disks, >zapping the hard drives, and recompiling everything on the clean hard >disks. It's a pity that so many people try to eradicate the virus by such difficult means when (as has been mentioned on this list and else- where) there is a file named UNVIR6.ARC on SIMTEL20 (in <MSDOS.TROJAN- PRO>) containing a program called UNVIRUS which will easily eradicate this virus and 5-6 others as well, plus a program IMMUNE to prevent further infection. Disassembling of Viruses ------------------------ In response to a posting by Alan Roberts, David Chess replied: >I think it's probably a Good Thing if at least two or three people do >independant disassemblies of each virus, just to make it less likely >that something subtle will be missed. I know my disassemblies (except >the ones I've spent lots of time on) always contain sections marked >with vaguenesses like "Does something subtle with the EXE file header >here". .... I probably tend to lean towards "the more the merrier"! I can appreciate David's point. However, I would like to point out that the quality of (commented) disassemblies differs greatly from one person to another. As Joe Hirst of the British Computer Virus Re- search Centre writes (V2 #174): >Our aim will be to produce disassemblies which cannot be improved upon. And this isn't merely an aim. In my opinion, his disassemblies are an order of magnitude better than any others I've seen. He figures out and comments on the purpose of *every* instruction, and vagueness or doubt in his comments is extremely rare. What I'm suggesting is this: If you have the desire, ability, time and patience to disassemble a virus yourself, then have fun. But unless you're sure it's a brand new virus, you may be wasting your time from the point of view of practical value to the virus-busting community. And even if you are sure that it's a new virus, take into account that there are pros like Joe who can probably do the job much better than you. So what about David's point that any given disassembler may miss something subtle? Well, I'm not saying that Joe Hirst should be the *only* person to disassemble viruses. Even he is only human, so there should be one or two other good disassemblers to do the job indepen- dently. But no more than 1 or 2; I can't accept David's position of "the more the merrier". Btw, disassemblers don't always get the full picture. Take, for example, the Merritt-Alameda-Yale virus, of which I have seen three disassemblies. They all mentioned that the POP CS instruction is invalid on 286 machines, yet none of them mentioned the important fact that when such a machine hangs the virus has already installed itself in high RAM and hooked the keyboard interrupt, so that the infection can spread if a warm boot is then performed! That fact seems to have been noticed only by ordinary humans. Y. Radai Hebrew Univ. of Jerusalem Date: Thu, 24 Aug 89 08:36:01 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: V-REMOVE (PC) The HomeBase group is releasing a new disinfector program that is able to remove all known viruses, repair all infected COM files, repair most infected EXE files, replace infected partition tables and boot sectors, and generally make life easier for people with infected IBM PCs. Our previous practice of releasing one disinfector program per virus has given us a terrific maintenance headache, and so V-REMOVE (which does them all) is our next step on the path. What we need now are beta testers with Large virus libraries. Interested parties please contact John McAfee or Colin Haynes at 408 727 4559. Alan ------------------------------ Date: 25 Aug 89 22:42:33 +0000 From: trebor@biar.UUCP (Robert J Woodhead) Subject: Re: Locking Macintosh disks DANIEL%NCSUVM.BITNET@IBM1.CC.Lehigh.Edu (Daniel Carr) writes: >i bet this question has been asked before, so please excuse me, but >is it possible for a virus to infect a locked macintosh disk? If the diskette is hardware locked (ie: the little slide is slid so that you can see a hole) then the hardware won't write onto that disk, so if you stick it into an infected machine it won't get infected. If, on the other hand, files on an unlocked disk are locked in _software_, they may be fair game to a persnickety virus. Date: Fri, 25 Aug 89 07:45:00 -0400 From: WHMurray@DOCKMASTER.ARPA Subject: (Hardware) Destructive Virus (Story) >Does anyone on the list have some information about an alleged virus >that caused monitors on either older PCs, Ataris, or Amigas (I forgot which >platform.... The story is apocryphal. Roots are as follows: 1. Anything a computer can be programmed to do, a virus can do. Thus, if a computer can be programmed for behavior that will damage the hardware, then it can be destroyed by a virus. 2. Early IBM PC Monochrome Adapter had a flaw under which a certain set of instructions could interfere with the normal sweep circuit operation, causing camage to the monitor. 3. Based upon this combination of facts, there has been speculation about the possibility of a virus exploiting this, or similar, flaws. Much of it has been in this list. To my knowledge, no such virus has ever been detected. The number of such PCs is vanishingly small but larger than the ones that such a virus might find. Those that exist are so old that a monitor failure would be attributed to old age. A virus would likely go unnoticed. Of course, it is a little silly to build a computer such that it can be programmed to perform hardware damaging behavior. Such damage is likely to occur by error. That is how the flaw in the IBM's was discovered. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Fri, 25 Aug 89 08:19:02 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Infecting applications on locked Mac disks... No. If the write-protect mechanism is working properly, any software operation will be unable to change the contents of the disk. If the write-protect mechanism is somehow faulty, all bets are off. Note: The write-protect mechanism on Mac disks is done in hardware. David Gursky Member of the Technical Staff, W-143 Special Projects Department The MITRE Corporation ------------------------------ Date: Thu, 24 Aug 89 17:05:47 -0700 From: Steve Clancy <SLCLANCY@UCI.BITNET> Subject: vaccine source (PC) I would like to offer our bulletin board system once again to the readers of Virus-L as a source of VIRUSCAN and other "vaccine/scanner" programs that are occasionally mentioned here. I attempt to keep up with the most recent versions I can locate of the various programs, and usually also have the current version of the Dirty Dozen trojan horse/list. The Wellspring RBBS is located in the Biomedical Library of the University of California, Irvine (U.S.A). Numbers and settings are as follows: Line # 1 - (714) 856-7996 300-9600 (HST) N81 - 24 hours Line # 2 - (714) 856-5087 300-1200 baud N81 - Evenings & Weekends Callers from Virus-L should use the following passwords to allow immediate access to downloading of files: First name Last name Password ---------- --------- -------- VL1 BITNET BIT1 VL2 BITNET BIT2 All files are located in the VIR files directory. The system uses standard RBBS commands. I attempt to get my files from the original source whenever possible. % Steve Clancy, Biomedical Library % WELLSPRING RBBS % % University of California, Irvine % 714-856-7996 300-9600 24hrs% % P.O. Box 19556 % 714-856-5087 300-1200 % % Irvine, CA 92713 U.S.A. % % % SLCLANCY@UCI % "Are we having fun yet?" % ------------------------------ Date: Mon, 28 Aug 89 13:45:10 -0700 From: fu@unix.sri.com (Christina Fu) Subject: Antidotes for the DATACRIME family (PC) Recently, I have had a chance to investigate the 1280, 1168 and DATACRIME II viruses, and found some interesting differences between the first two versions and DATACRIME II. As a result, I have developed an antidote for both 1280 and 1168, and an antidote for the DATACRIME II. Among the differences between these viruses, the most significant one for developing antidotes is that the DATACRIME II virus generates a mutually exclusive signature set than the other two. Because of the said difference, the antidote for the 1280 and 1168 becomes a de-antidote for the DATACRIME II, and vice versa. Which means, if a file is infected with either 1280 or 1168, it is still vulnerable of contracting DATACRIME II, and vice versa (this situation does not exist between 1280 and 1168, however). If we view these viruses as two different strains, then these antidotes make more sense, otherwise, they can be useless. Another interesting thing is that the DATACRIME II purposely avoids infecting files with a "b" as the second character in the name (such as IBMBIO.COM and IBMDOS.COM), while the other two avoids to infect files with a "d" as the seventh character in the name (such as COMMAND.COM), and aside from that, the DATACRIME II virus can also infect EXE files, unlike the other two. I am looking into providing them to the public free of charge (I do not claim responsibility or ask for donation). Any interested archive sites please let me know. By the way, I need a sample disclaimer for programs distributed in this manner. ------------------------------ Date: Mon, 21 Aug 89 13:36:00 -0400 From: WHMurray@DOCKMASTER.ARPA Subject: Hygeine Questions >1) Is the possibility of virus infection limited to executable > programs (.com or .exe extensions)? Or can an operating system be > infected from reading a document file or graphic image? While a virus must succeed in getting itself executed, there are a number of solutions to this problem besides infecting .exe and .com. While it will always be sufficient for a virus to dupe the user, the most successful ones are relying upon bootstrap programs and loaders to get control. >2) Are there generic "symptoms" to watch for which would indicate a virus? Any unusual behavior may signal the presence of a virus. Of course most such unusual behavior is simply an indication of user error. Since there is not much satisfaction to writing a virus if no one notices, most are not very subtle. However, the mandatory behavior for a successful virus is to write to shared media, e.g., floppy, diskette, network, or server. (While it may be useful to the virus or disruptive to the victim to write to a dedicated hard disk, this is not sufficient for the success of the virus.) >3) Any suggestions on guidelines for handling system archiving > procedures so that an infected system can be "cleaned up"? WRITE PROTECT all media. Preserve vendor media indefinitely. Never use the backup taken on one system on any other. Be patient when recovering; be careful not to reinfect. (Computer viruses are persistent on media.) Quarantine systems manifesting strange behavior. Never try to reproduce symptoms on a second machine. Never share media gratuitously. (Note that most PC viruses are traveling on shared MEDIA rather than on shared PROGRAMS.) ____________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) ARPA: WHMurray@DOCKMASTER Ernst & Young MCI-Mail: 315-8580 2000 National City Center TELEX: 6503158580 Cleveland, Ohio 44114 FAX: 203-966-8612 Compu-Serve: 75126,1722 INET: WH.MURRAY/EWINET.USA 21 Locust Avenue, Suite 2D DASnet: [DCM1WM]WMURRAY New Canaan, Connecticut 06840 PRODIGY: DXBM57A - -------------------------------------------------------------------- ------------------------------ Date: Fri, 18 Aug 89 19:07:11 -0500 From: Christoph Fischer <RY15%DKAUNI11.BITNET@IBM1.CC.Lehigh.Edu> Subject: NEW VIRUS DICOVERED AND DISASSEMBLED We just finished to disassemble a new virus, it was sent to us by the university of Cologne. We haven't found any clue that this virus showed up before. Here are the facts we found: 0. It works on PC/MS-DOS ver. 2.0 or higher 1. It infects COM files increasing them by 1206 to 1221 bytes (placing the viruscode on a pragraph start) 2. It infects EXE files in two passes: After the first pass the EXE file is 132 bytes longer; after the second pass its size increased by an aditional 1206 to 1221 bytes (see 1.) 3. The virus installs a TSR in memory wich will infect executable files upon loading them (INT 21 subfunction 4B00) using 8208 bytes of memory 4. The only "function" we found, was an audible alarm(BELL character) whenever another file was successfully infected. 5. It infects COM files that are bigger than 04B6h bytes and smaller than F593h bytes and start with a JMP (E9h) 6. It infects EXE files if they are smaller than FDB3 bytes (no lower limit) 7. It opens a file named "VACSINA. " without checking the return value. At the end it closes this file without ever touching it. The facts 4 and 7 make us belive it is a "Beta-Test" virus that might have escaped prematurely by accident. The word VACSINA is really odd beause of its spelling. All languages I checked (12) spell it VACC... only Norwegians write VAKSINE. Has anybod an idea? We produced an desinfectant and a guardian. The PC room at Cologne (28 PCs) was also infected by DOS62 (Vienna)| We call the virus VACSINA because of the unique filename it uses| Chris & Tobi & Rainer ***************************************************************** * TORSTEN BOERSTLER AND CHRISTOPH FISCHER AND RAINER STOBER * * Micro-BIT Virus Team / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ***************************************************************** ------------------------------ Date: Wed, 16 Aug 89 11:46:06 -0400 From: "Computer Emergency Response Team" <cert@SEI.CMU.EDU> Subject: CERT Internet Security Advisory Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users should change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following: o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". In general, we suggest that site administrators be attentive to configuration management issues. These include the following: o Test authenticity of critical programs - Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. o Privileged programs - Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) should always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. o Apply fixes - Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes. If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT). Date: Tue, 15 Aug 89 20:36:50 +0300 From: "Yuval Tal (972)-8-474592" <NYYUVAL@WEIZMANN.BITNET> Subject: Swapping Virus (PC) +------------------------------------------------------+ | The "Swapping" virus | +------------------------------------------------------+ | | | Disassembled on: August, 1989 | | | | Disassembled by: Yuval Tal | | | | Disassembled using: ASMGEN and DEBUG | | | +------------------------------------------------------+ Important note: If you find *ANYTHING* that you think I wrote incorrectly or is-understood something, please let me know ASAP. You can reach me: Bitnet: NYYUVAL@WEIZMANN InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU This text is divided into theree parts: 1) A report about the Swap Virus. 2) A disassembly of the Swap Virus. 3) How to install this virus? - ------------------------------------------------------------------------------ - R E P O R T - ------------------------------------------------------------------------------ - Virus Name..............: The Swap Virus Attacks.................: Floppy-disks only Virus Detection when....: June, 1989 at......: Israel Length of virus.........: 1. The virus itself is 740 bytes. 2. 2048 bytes in RAM. Operating system(s).....: PC/MS DOS version 2.0 or later Identifications.........: A) Boot-sector: 1) Bytes from $16A in the boot sector are: 31 C0 CD 13 B8 02 02 B9 06 27 BA 00 01 CD 13 9A 00 01 00 20 E9 XX XX 2) The first three bytes in the boot sector are: JMP 0196 (This is, if the boot sector was loaded to CS:0). B) FAT: Track 39 sectors 6-7 are marked as bad. C) The message: "The Swapping-Virus. (C) June, by the CIA" is located in bytes 02B5-02E4 on track 39, sector 7. Type of infection.......: Stays in RAM, hooks int $8 and int $13. A diskette is infected when it is inserted into the drive and ANY command that reads or writes from/to the diskette is executed. Hard disks are NOT infected ! Infection trigger.......: The virus starts to work after 10 minutes. Interrupt hooked........: $8 (Timer-Tick - Responsible for the letter dropping) $13 (Disk Drive - Infects!) Damage..................: Track 39 sectors 6-7 will be marked as bad in the FAT. Damage trigger..........: The damage is done whenever a diskette is infected. Particularities.........: A diskette will be infected only if track 39 sectors 6-7 are empty. +-----------------------------------------------------------------------+ | BitNet: NYYUVL@WEIZMANN CSNet: NYYUVAL@WEIZMANN.BITNET | | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU | | | | Yuval Tal | | The Weizmann Institute Of Science "To be of not to be" -- Hamlet | | Rehovot, Israel "Oo-bee-oo-bee-oo" -- Sinatra | +-----------------------------------------------------------------------+ ------------------------------ Date: Mon, 14 Aug 89 10:18:16 +0100 From: J.Holley@MASSEY.AC.NZ Subject: Marijuana Virus wreaks havoc in Australian Defence Department (PC) [Ed. This is from RISKS...] Quoted from The Dominion, Monday August 14 : A computer virus call marijuana has wreaked havoc in the Australian Defence Department and New Zealand is getting the blame. Data in a sensitive security area in Canberra was destroyed and when officers tried to use their terminals a message appeared : "Your PC is stoned - Legalise marijuana". Viruses are [guff on viruses] The New Zealand spawned marijunana has managed to spread itself widely throughout the region. Its presence in Australia has been known for the past two months. The problem was highlighted two weeks ago when a Mellbourne man was charged with computer trespass and attempted criminal damage for allegedly loading it into a computer at the Swinbourne Institute of Technology. The virus invaded the Defence Department earlier this month - hitting a security division repsonsible for the prevention of computer viruses. A director in the information systems division, Geoff Walker said an investigation was under way and the infection was possibly an embarrassing accident arising from virus prevention activities. New personal computers installed in the section gobbled data from their hard disk, then disabled them. Initially it was believed the virus was intoduced by a subcontractor installing the new computer system but that possibility has been ruled out. One more outlandish theory suggested New Zealnd, piqued at its exclusion from Kangaroo 89 military exercises under way in northern Australia, was showing its ability to infiltrate the Canberra citadel. New Zealand was not invited to take part in Kangaroo because of United States' policy of not taking part in exercises with New Zealand forces since Labour's antinuclear legislation. However, New Zealand observers were invited. New Zealand Defence Department spokesmand Lieutenant Colonel Peter Fry categorically denied the claim. "It would be totally irresponsible to do this kind of thing." In fact, New Zealand's Defence Department already had problems with the virus, he said. ------------------------------ Date: Mon, 14 Aug 89 18:12:37 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: Posting VIRUSCAN (PC) In yesterday's Virus-L, Jim Wright stated: >(Posting VIRUSCAN to comp.binaries)... is not a good idea. Since it is >frequently updated it would be long out of date by the time it got through >c.b.i.p. I'd like to point out that, while ViruScan is indeed updated as soon as a new virus is discovered, even the first version of ViruScan is still statistically current. We need to differentiate between the NUMBER of viruse out there and the statistical PROBABILITY of infection from any given virus. Viruses are not created on one day and the next become major infection problems. It take many months, and in some cases - years, before a given virus becomes a statistically valid threat to the average computer user. A case in point is the Jerusalem virus. It's nearly 2 years old and was first reported in the States (other than by a researcher) in February of 1988. In August of '88 the reported infection rate was 3 infections per week. In July of '89, the rate was over 30 reports per day. Today the Jerusalem virus is a valid threat. Another more current case is the Icelandic virus. It's over 2 months old and we've had no reported infections in the U.S. Given even the limited information we have about virus epidemiology, any product that can identify 99% of the infection ocurrences today, will be able to identify close to the same percentage 5 to 6 months from now, irrespective of the number of new viruses created in the interim. For those that insist on the 100% figure, I suggest you bite the bullet and download the current version of ViruScan from HomeBase every month. P.S. Some people have suggested that the CVIA statistics are inaccurate or incomplete. The numbers come from a reporting network composed of member companies. These companies include such multinationals as Fujitsu, Phillips N.A., Amdahl, Arthur Anderson and Co., the Japan Trade Center, Weyerhauser, Amex Assurance and others whose combined PC base, either internal or through client responsibility, totals over 2 million computers. It is highly unlikely that a major virus problem could exist and not be reported by one or another of these agencies. ------------------------------ Date: Sun, 13 Aug 89 09:48:20 -0700 From: portal!cup.portal.com!Charles_M_Preston@Sun.COM Subject: Viruscan test (PC) For the past couple weeks I have been testing the latest versions of John McAfee's virus scanning program, Viruscan, downloaded as SCANV29.ARC, SCANV33.ARC, etc., and very briefly the resident version archived as SCANRES4.ARC. While I have not completed the testing protocol with each virus, perhaps an interim report will be of interest. The testing protocol is: 1. Scan a disk containing a copy of a virus in some form; 2. Have the virus infect at least one other program (for .COM and .EXE infectors) or disk (for boot infectors) so Viruscan must locate the virus signature as it would normally be found in an infected machine; 3. Modify the virus in the most common ways people change them (cosmetic changes to ASCII text messages or small modifications to the code and try Viruscan again. Step 2 arises from testing another PC anti-virus product which was supposed to scan for viruses. When I found that it would not detect a particular boot virus on an infected floppy, I asked the software vendor about it. I was told that it would detect a .COM program which would produce an infected disk - not useful to most people with infected disks, the common way this virus is seen Even though the viruses tested are not technically self-mutating, my intent is to test Viruscan against later generation infections, as they would be found in a normal computing environment. Naturally, there is a problem knowing which virus is actually being found, since they go under different names and are frequently modified. The viruses are currently identified by their length, method of infection, symptoms of activity or trigger, and any imbedded text strings, based on virus descriptions from a variety of sources. These include Computers & Security journal, and articles which have been on Virus-L, such as Jim Goodwin's descriptions modified by Dave Ferbrache, and reports by Joe Hirst from the British Computer Virus Research Centre. There is a proposal for checksumming of viruses in the June Computers & Security, which would allow confirmation that a found virus is the identical one already disassembled and described by someone. In the meantime, identification has been made as mentioned. So far, Viruscan has detected the following viruses: Boot infectors - Brain, Alameda/Yale, Ping-Pong, Den Zuk, Stoned, Israeli virus that causes characters to fall down the screen; .COM or .EXE infectors - Jerusalem -several versions including sURIV variants, 1701-1704-several versions, Lehigh, 1168, 1280, DOS62-Vienna, Saratoga, Icelandic, Icelandic 2, April First, and Fu Manchu. SCANV33 has a byte string to check for the 405.com virus, but does not detect it. SCANV34 has been modified to allow proper detection. SCANRES 0.7V34, the resident version of Viruscan, correctly detects the 405 virus when an infected program is run. I have not had any false positives on other commercial or shareware programs that have been scanned. Viruscan appears to check for viruses only in reasonable locations for those particular strains. If there is a virus that infects only .COM files, and an infected file has a .VOM or other extension, it will not be reported. Of course, it is not immediately executable, either. On the other side of the coin, if a disk has been infected by a boot infector, and still has a modified boot record, it will be reported by Viruscan. This is true even if the rest of the virus code normally hidden in other sectors has been destroyed, thus making the disk non-bootable and non infectious. This is a desirable warning, however, since the boot record is not original, and since other disks may be still infected. Disclaimer: I am a computer security consultant and have been working with PC and Macintosh microcomputer viruses and anti- virus products for about 18 months. I have no obligation to John McAfee except to report the outcome of the tests. I am a member of the Computer Virus Industry Association, which is operated by John McAfee. Charles M. Preston 907-344-5164 Information Integrity MCI Mail 214-1369 Box 240027 BIX cpreston Anchorage, AK 99524 cpreston@cup.portal.com ------------------------------ Date: 01 Aug 89 21:18:49 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: "Computer Condom" (from Risks digest)... hahahahahahahahah!!!!!!! right chief just like swamp land in them thar everglades... seriously though things will not improve until vendors start going for protected mode and other tricks...I am talking about 386's and 68030's here... maybe something could be done in this area with charge cars on a 286 but I doubt it... your need that virtual 8086 partition on the 386 to have any real safety and have to be operating protected mode to take advantage of it(DESQVIEW 386, THD386.sys etc) after that then there are still so many ways to get in!! cheers kelly ------------------------------ Date: Thu, 03 Aug 89 12:15:52 -0500 From: kichler@ksuvax1.cis.ksu.edu (Charles Kichler) Subject: New FTP source for anti-virals (PC) - Internet access required The following files dealing with computer viruses are now available by anonymous ftp (file transfer protocol) from 'hotel.cis.ksu.edu' [Ed. IP number is 129.130.10.12] located in Computer Science Dept. at Kansas State University, Manhattan, KS. The files have been and will be collected in the future from reliable sources, although no warranty is implied or stated. I will attempt to update the files as often as possible. If anyone becomes aware of new updates or new anti-viral programs, let me know. All files are in the /ftp/pub/Virus-L sub-directory. / DETECT2.ARC.1 GREENBRG.ARC.1 VACCINE.ARC.1 ./ DIRTYDZ9.ARC.1 IBMPAPER.ARC.1 VACCINEA.ARC.1 00-Index.doc DPROT102.ARC.1 IBMPROT.DOC.1 VACI13.ARC.1 ALERT13U.ARC.1 DPROTECT.ARC.1 INOCULAT.ARC.1 VCHECK11.ARC.1 BOMBCHEK.ARC.1 DPROTECT.CRC.1 MD40.ARC.1 VDETECT.ARC.1 BOMBSQAD.ARC.1 DVIR1701.EXE.1 NOVIRUS.ARC.1 VIRUS.ARC.1 CAWARE.ARC.1 EARLY.ARC.1 PROVECRC.ARC.1 VIRUSCK.ARC.1 CHECK-OS.ARC.1 EPW.ARC.1 READ.ME.FIRST VIRUSGRD.ARC.1 CHK4BOMB.ARC.1 F-PROT.ARC.1 SCANV30.ARC.1 pk36.exe CHKLHARC.ARC.1 FILE-CRC.ARC.2 SENTRY02.ARC.1 pk361.exe CHKSUM.ARC.1 FILECRC.ARC.2 SYSCHK1.ARC.1 uu213.arc CHKUP36.ARC.1 FILETEST.ARC.1 TRAPDISK.ARC.1 CONDOM.ARC.1 FIND1701.ARC.1 TROJ2.ARC.1 DELOUSE1.ARC.1 FSP_16.ARC.1 UNVIR6.ARC.1 The current list only includes programs for MS/PC-DOS computers. I will continue to expand the collection to include some worthwhile textual documents and possible programs for other machines and operating systems. The procedure is to first ftp to the hotel.cis.ksu.edu. [Ed. type: ftp hotel.cis.ksu.edu (or ftp 129.130.10.12). Enter "anonymous" (without the quotes) as a username and "your id" as a password.] Then use 'cd pub/Virus-L'. Next get the files you would like. You will need the 'pk361.exe' to expand the ARChived programs. Be sure to place ftp in a binary or tenex mode [Ed. type "bin" at ftp> prompt]. Please note that the highly recommended VirusScan program (SCANV30.ARC.1) is available. If there are any questions, send mail to me and I will make every effort to help you as soon as time allows. ------------------------------ Date: Tue, 01 Aug 89 12:33:15 -0400 From: Barry D. Hassler <hassler@nap1.arpa> Subject: Re: "Computer Condom" (from Risks digest)... In article <0003.8907311200.AA25265@ge.sei.cmu.edu> dmg@lid.mitre.org (David Gu rsky) writes: >[From the Seattle Weekly, 5/3/89] > >PUT A CONDOM ON YOUR COMPUTER > >... >Cummings, the company's president, says the system "stops all viruses" by >monitoring the user network, the keyboard, and the program in use. He notes >that the system is programmable to alter the parameters of its control on >any given machine, but he guarantees that, "when programmed to your >requirements, it will not allow viruses to enter." Pardon me for my opinions (and lack of expertise in viral control), but I think these types of products are dangerous to the purchaser, while most likely being especially profitable for the seller. I just saw a copy of this floating around to some senior management-types after being forwarded several times, and dug up this copy to bounce my two cents off. First of all, I don't see any method which can be guaranteed to protect against all viruses (of course the "when programmed to your requirements" pretty well covers all bases, doesn't it?). Naturally, specific viruses or methods of attach can be covered with various types of watchdog software/hardware, but I don't think it is possible to cover all the avenues in any way. - ----- Barry D. Hassler hassler@asd.wpafb.af.mil System Software Analyst (513) 427-6369 Control Data Corporation ------------------------------ Date: Tue, 01 Aug 89 16:37:00 -0400 From: IA96000 <IA96@PACE.BITNET> Subject: axe by sea (PC) we have been testing various ways to help prevent a file from becoming infected and have stunbled on an interesting fact. system enhancement associates (the people who wrote arc) have also released axe, a program compression utility. basically axe reads a .exe or .com file, compresses it as much as possible, tacks a dos loader on the front of the file and then saves the new file. in many instances, the resulting file is from 15% to 50% smaller than the original file and loads and runs just like a regular dos file. what is interesting is when a virus attacks an axe'd file. the virus writes itself into the file as many viruses do. however, when you next attempt to load and run the file, it will not load and locks up the system. this is not because the viruys has taken control! this happens because when an axed file is loaded, it is decompressed and the checksum is compared to the original one generated when the file was axed. I know axe was never designed to be anti-viral, but it sure works well in this regard. since the file is actually in encrypted form on the disk, it screws up the virus! ------------------------------ Date: 01 Aug 89 00:00:00 +0000 From: David M. Chess <CHESS@YKTVMV.BITNET> Subject: Fixed-disk infectors (PC) Does anyone know of, or has anyone even heard credible rumors of, any boot-sector virus that will infect the boot sector (master or partition) of IBM-PC-type hard disks, besides the Bouncing Ball and the Stoned? Those are the only two I seem to see that do that; am I missing any? DC ------------------------------ Date: 01 Aug 89 21:23:30 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: message virus (was: Computer Virus Research) we call those ansi 3.64 control sequences.... vt100 and other terminals have similar if not exactly the same features... ansi.sys implements a subset of ansi 3.64 without any protection the problem has been known at various unix sites for years only now its starting to show up on pc's because of the usage of ansi.sys and other programs that recognize these sequences.... cheers kelly ------------------------------ Date: 30 Jul 89 17:17:17 +0000 From: hutto@attctc.Dallas.TX.US (Jon Hutto) Subject: message virus (was: Computer Virus Research) redevined keys so as to when the sysop is in dos and hits a key, it starts deleting files and directories. The worst thing about this is that people have been able to do this for a long time. they are explained in the DOS Technical Reference manual. There are also rumors of a ZMODEM virus that spreads visa ZMODEM transfers, a rumor. ------------------------------ Date: Sat, 29 Jul 89 15:59:43 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: Jerusalem Disinfector Mark Zinzow asked if there were a public domain program that would restore programs infected with the Jerusalem virus to their original, uninfected condition. John McAfee's M-series programs have just been made shareware (M-1 removes the Jerusalem from COM and EXE files and restores them), and the programs are available on HomeBase - 408 988 4004. Alan ------------------------------ Date: Fri, 28 Jul 89 23:18:17 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: "Computer Condom" (from Risks digest)... [From the Seattle Weekly, 5/3/89] PUT A CONDOM ON YOUR COMPUTER Every worry that your computer might be hanging out in a network where it will pick up some disgusting virus? Empirical Research Systems of Tacoma suggests you supply it with one of their "computer condoms". This high-tech prophylactic is a combination of hardware and software embodied in a controller card that simply replaces the one already in the machine. Rick Cummings, the company's president, says the system "stops all viruses" by monitoring the user network, the keyboard, and the program in use. He notes that the system is programmable to alter the parameters of its control on any given machine, but he guarantees that, "when programmed to your requirements, it will not allow viruses to enter." The technology was developed through successful efforts to protect a group of European banks from the massive virus that penetrated European computer networks last autumn. "Naturally these became our first orders," Cummings says. He has since picked up an additional 2500 firm orders in Europe, with 5000 more contingent on inspection of the product. In the United States, the product has been reviewed by Boeing Computer Services and computer technicians at the UW. It will be on the domestic market "early next autumn at a cost of under $1000," Cummings says. DG -- Pardon me while I laugh uncontrollably. ------------------------------ In our computerviruslab we have been working on the problem of mutants of several viruses. Initially we intended to make antiviruspackages more secure. Since a single byte added or removed from the virus code will cause most antiviruspackages to do erroneous repair attempts which might result in even bigger harm than the virus itself will do. Furthermore watertight identification leads to a better 'Epidemiology' of the different virusstrains. Thanks to the kind help of fellow virus researchers all over the world we were able to obtain and tryout quite a few viruses and their mutants. PROPOSAL VIRUS IDENTIFICATION ALGORITHM PURPOSE: Positive and secure identification of *known* viruses to prevent repair attempts on files infected by unknown mutants of a virus. REPLACES: Identification by a unique string of code. (Which might still be unaltered at the same offset in the code of a new variant of the virus) METHOD: 1. Identification of the *known* virusstrain by a unique string or other feature (sUMsDos, (C)Brain, or the 1Fh in the seconds of the filetime) 2. Relocation to segmentoffset 0 and possible decryption of the viruscode. (This might be necessary for mutiple parts of the virus) 3. Writing zero over sections that contain variant parts like garbage from the last infection attempt or a time- bomb counter. 4. Finally a CRC-sum is generated (maybe using more than one polynominal) If this signature matches the one calculated on the virus code for which the removalalgorithm was designed it is safe to apply this antivirusprogram. IMPLEMENTATION: We have done a testimplementation in C and for 2 virusstrains (6 viruses yet). Our goal is to prepare a toolset for quick addition of new variants to the set identifyable viruses. ADVANTAGE: Antivirus tools can identify exactly a specific virus without encorporating full or partial viruscode in the antivirusprogram. (This would be a security risk if done in comercial or PD software) Any comments sugestions welcome respond to VIRUS-L or directly we will summarize to the list| Currently we are also working on virus behavior in networks. For this we have setup a 4 machine Novell network. (PS2/80, PS2/60, Atari386, and a good old PC-XT). Here also any sugestions and help are welcome| ******************************************************************* * Christoph Fischer and Torsten Boerstler * * Micro-BIT Virus Center / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ******************************************************************* >--------=====END=====--------< ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++