--part1_9608e1e1.24533f78_boundary Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have checked this out on my virus alert on AOL and this is TRUE - it is not a hoax. --part1_9608e1e1.24533f78_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-path: VaughnGP@aol.com From: VaughnGP@aol.com Full-name: VaughnGP Message-ID: <9608e1e1.245327fc@aol.com> Date: Sat, 24 Apr 1999 09:58:20 EDT Subject: Fwd: virus on monday stay off AOL and web To: LIONBCOACH@aol.com, TRENDYG1@aol.com, Toepickl@aol.com, Whiteflam6@aol.com, Cberry109@aol.com, ChIcKaXoX@aol.com, TROUSIE@aol.com, JnCoOSpAz@aol.com, Beachgrl8k@aol.com, Creedgrl79@aol.com, KitKat5356@aol.com, ME2kRaZy4u@aol.com, JillsJazzy@aol.com, JDambinska@aol.com, Sugarxy02@aol.com, Crazy2910@aol.com, KeeMO411@aol.com, Cro8nSns8n@aol.com, Moopsie@aol.com, DeFFenD4@aol.com, Jolteon29@aol.com, VSEAGLE69@aol.com, SMR6959@aol.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part2_9608e1e1.245327fc_boundary" X-Mailer: AOL 4.0 for Windows 95 sub 10 Reply-To: VaughnGP@aol.com --part2_9608e1e1.245327fc_boundary Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit --part2_9608e1e1.245327fc_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-path: Cberry109@aol.com From: Cberry109@aol.com Full-name: Cberry109 Message-ID: <9608e1e1.245324e0@aol.com> Date: Sat, 24 Apr 1999 09:45:04 EDT Subject: Fwd: virus on monday stay off AOL and web To: Wolf122181@aol.com, Chrisgrl4E@aol.com, DAMAN666@aol.com, Rolinroc69@aol.com, MSalem6487@aol.com, Smil82@aol.com, Snugles423@aol.com, XNickWall1@aol.com, VaughnGP@aol.com, HckYBoY15@aol.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part3_9608e1e1.245324e0_boundary" X-Mailer: AOL 4.0 for Windows 95 sub 4 Reply-To: Cberry109@aol.com --part3_9608e1e1.245324e0_boundary Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In a message dated 4/24/99 1:20:53 AM Eastern Daylight Time, Stroise256 writes: << Heard this virus suppose to trigger on the 26th. Harm to windows 95 & 98. >Anyone have info on this. How do you get it in system? They say it's not e- >mail. How to use AntiViral Toolkit Pro to detect and remove the Win95.CIH virus. First here is a complete description of the virus. -------------------------------------------------- Win95.CIH This is a Windows95 specific parasitic PE files (Portable Executable) infector about 1Kbyte of length. This virus was found "in-the-wild" in Taiwan in June 1998 - it was posted by the virus author to a local Internet conference as a some utility. Within a week the virus was found in Austria, Australia, Israel, United Kingdom, and was also reported from several other countries (Switzerland, Sweden, USA, Russia, Chile and the list keeps growing). The virus installs itself into the Windows memory, hooks file access calls and infects EXE files that are opened. Depending on the system date (see below) the virus runs its trigger routine. The virus has bugs and in some cases halts the computer when an infected application is run. The virus' trigger routine operates with Flash BIOS ports and tries to overwrite Flash memory with "garbage". This is possible only if motherboard and chipset allow to write to Flash memory. Usually writing to Flash memory can be disabled by a DIP switch, however this depends on the motherboard design. Unfortunately, there are modern motherboards that cannot be protected by a DIP switch - also, some of them do not pay attention for switch position and this protection has no effect at all. Some other motherboard designs provide write protection that can be disabled/overriden by software. During tests in our lab the virus did not overwrite the Flash BIOS and just halted the computer. We do however have reports from other sources telling that the virus really is able to mess it up. The trigger routine then overwrites data on all installed hard drives. The virus uses direct disk write calls to achieve this and bypasses standard BIOS virus protection while overwriting the MBR and boot sectors. There are three virus versions known, which are very closely related and only differ in few parts of their code. They have different lengths, texts inside the virus code and trigger date: Length Text Trigger date Found In-The-Wild 1003 CCIH 1.2 TTIT on April 26th YES 1010 CCIH 1.3 TTIT on April 26th NO 1019 CCIH 1.4 TATUNG on 26th of any month YES - many reports Technical details While infecting a file the virus looks for "caves" in the file body. These caves are a result of the PE file structure: all file sections are aligned by a value that is defined in PE file header, and there are not used blocks of file data between the end of previous section and next one. The virus looks for these caves and writes its code into them. The virus then increases the size of sections by the necessary values. As a result the file length is not increased while infecting. If there is a cave of enough size, the virus saves its code in one section. Otherwise it splits its code into several parts and saves them to the end of several sections. As a result the virus code may be found as set of pieces, not as a single block in infected files. The virus also looks for a cave in the PE header. If there is a not used block not less than 184 bytes of length, the virus writes its startup routine to there. The virus then patches the entry address in the PE header with a value that points to the startup routine placed in the header. This is the same trick that was used in the "Win95.Murkry" virus: address of program entry points not to some file section, but to file header - out of loadable file data. Despite this, infected programs are run with no problems - Windows does not pay attention for such "strange" files, loads the file header into the memory, then file sections, and then passes control to the virus startup routine in PE header. When the virus startup routine takes control, it allocates a block of memory by using the PageAllocate VMM call, copies itself to there, locates other blocks of virus code and also copies them to allocated block of memory. The virus then hooks system IFS API and returns control to the host program. The most interesting thing in this part of the virus code is that the virus uses quite complex tricks to jump from Ring3 to Ring0: when the virus jumps to newly allocated memory its code is then executed as Ring0 routine, and the virus is able to hook the file system calls (it is not possible in Ring3, where all users applications are run). The IFS API virus handler intercepts only one function - file opening. When PE .EXE files are opened, the virus infects them, provided there are caves of enough size. After infection, the virus checks the file date and calls trigger routine (see above). While running its trigger routine the virus uses direct access to Flash BIOS ports and VxD direct disk access calls (IOS_SendCommand). >> --part3_9608e1e1.245324e0_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-path: Stroise256@aol.com From: Stroise256@aol.com Full-name: Stroise256 Message-ID: <9608e1e1.2452aeb5@aol.com> Date: Sat, 24 Apr 1999 01:20:53 EDT Subject: virus on monday stay off line or web To: Cberry109@aol.com, SKINNYD718@aol.com, NUBYNKING@aol.com, Rip4647@aol.com, sshulder@suffolk.lib.ny.us, jaspivak@scj.com, SpmSpiff@aol.com, URONE@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 4 Reply-To: Stroise256@aol.com i say dont go online for a few days Heard this virus suppose to trigger on the 26th. Harm to windows 95 & 98. >Anyone have info on this. How do you get it in system? They say it's not e- >mail. How to use AntiViral Toolkit Pro to detect and remove the Win95.CIH virus. First here is a complete description of the virus. -------------------------------------------------- Win95.CIH This is a Windows95 specific parasitic PE files (Portable Executable) infector about 1Kbyte of length. This virus was found "in-the-wild" in Taiwan in June 1998 - it was posted by the virus author to a local Internet conference as a some utility. Within a week the virus was found in Austria, Australia, Israel, United Kingdom, and was also reported from several other countries (Switzerland, Sweden, USA, Russia, Chile and the list keeps growing). The virus installs itself into the Windows memory, hooks file access calls and infects EXE files that are opened. Depending on the system date (see below) the virus runs its trigger routine. The virus has bugs and in some cases halts the computer when an infected application is run. The virus' trigger routine operates with Flash BIOS ports and tries to overwrite Flash memory with "garbage". This is possible only if motherboard and chipset allow to write to Flash memory. Usually writing to Flash memory can be disabled by a DIP switch, however this depends on the motherboard design. Unfortunately, there are modern motherboards that cannot be protected by a DIP switch - also, some of them do not pay attention for switch position and this protection has no effect at all. Some other motherboard designs provide write protection that can be disabled/overriden by software. During tests in our lab the virus did not overwrite the Flash BIOS and just halted the computer. We do however have reports from other sources telling that the virus really is able to mess it up. The trigger routine then overwrites data on all installed hard drives. The virus uses direct disk write calls to achieve this and bypasses standard BIOS virus protection while overwriting the MBR and boot sectors. There are three virus versions known, which are very closely related and only differ in few parts of their code. They have different lengths, texts inside the virus code and trigger date: Length Text Trigger date Found In-The-Wild 1003 CCIH 1.2 TTIT on April 26th YES 1010 CCIH 1.3 TTIT on April 26th NO 1019 CCIH 1.4 TATUNG on 26th of any month YES - many reports Technical details While infecting a file the virus looks for "caves" in the file body. These caves are a result of the PE file structure: all file sections are aligned by a value that is defined in PE file header, and there are not used blocks of file data between the end of previous section and next one. The virus looks for these caves and writes its code into them. The virus then increases the size of sections by the necessary values. As a result the file length is not increased while infecting. If there is a cave of enough size, the virus saves its code in one section. Otherwise it splits its code into several parts and saves them to the end of several sections. As a result the virus code may be found as set of pieces, not as a single block in infected files. The virus also looks for a cave in the PE header. If there is a not used block not less than 184 bytes of length, the virus writes its startup routine to there. The virus then patches the entry address in the PE header with a value that points to the startup routine placed in the header. This is the same trick that was used in the "Win95.Murkry" virus: address of program entry points not to some file section, but to file header - out of loadable file data. Despite this, infected programs are run with no problems - Windows does not pay attention for such "strange" files, loads the file header into the memory, then file sections, and then passes control to the virus startup routine in PE header. When the virus startup routine takes control, it allocates a block of memory by using the PageAllocate VMM call, copies itself to there, locates other blocks of virus code and also copies them to allocated block of memory. The virus then hooks system IFS API and returns control to the host program. The most interesting thing in this part of the virus code is that the virus uses quite complex tricks to jump from Ring3 to Ring0: when the virus jumps to newly allocated memory its code is then executed as Ring0 routine, and the virus is able to hook the file system calls (it is not possible in Ring3, where all users applications are run). The IFS API virus handler intercepts only one function - file opening. When PE .EXE files are opened, the virus infects them, provided there are caves of enough size. After infection, the virus checks the file date and calls trigger routine (see above). While running its trigger routine the virus uses direct access to Flash BIOS ports and VxD direct disk access calls (IOS_SendCommand). --part3_9608e1e1.245324e0_boundary-- --part2_9608e1e1.245327fc_boundary-- --part1_9608e1e1.24533f78_boundary--