From lehigh.edu!virus-l Mon Apr 26 07:13:50 1993 remote from vhc Received: by vhc.se (1.65/waf) via UUCP; Tue, 27 Apr 93 00:25:19 GMT for mikael Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2) id AA28175; Mon, 26 Apr 1993 19:11:06 +0200 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA40876 (5.67a/IDA-1.5 for ); Mon, 26 Apr 1993 11:13:50 -0400 Date: Mon, 26 Apr 1993 11:13:50 -0400 Message-Id: <9304261416.AA00514@first.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@first.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V6 #70 VIRUS-L Digest Monday, 26 Apr 1993 Volume 6 : Issue 70 Today's Topics: WARNING: New Mac Virus - INIT-M (Mac) Philosophy monitors [sigh...] Human factor in infections (Was: Scanners betting bigger and slower) Scanners getting bigger and slower Scanners getting bigger and slower Re: Unix PC systems (UNIX) COMMAND.COM Vaccination (PC) MtE anti-viruses (PC) Re: Can a virus infect NOVELL? (PC) Vshield V102 Bug? (PC) DOS v6.0 and Virus Functionality (PC) Port Writes (PC) Scanning Compressed files (PkLite) (PC) McAfee latest version (PC) Port Writes and a new Russian Virus using them (PC) viruses and compression (PC) Is Inbar Raz a Virus Writer? (PC :-) ) Port Write, and the Hardware Interrupt (PC) F-Prot 2.07 (PC) Re: BeBe Virus (PC) Re: Can a virus infect NOVELL? (PC) Re: Censoship/40-Hex (PC) Re: "DIR" infection, or "Can internal commands infect" (PC) Re: "DIR" infection, or "Can internal commands infect" (PC) Re: Help wanted with Dir-II virus (PC) 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. (The complete set of posting guidelines is available by FTP on cert.org or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk, krvw@first.org ---------------------------------------------------------------------- Date: Thu, 22 Apr 93 18:02:45 -0500 From: spaf@cs.purdue.edu Subject: WARNING: New Mac Virus - INIT-M (Mac) New Macintosh Virus Discovered (INIT-M) 22 Apr 1993 Virus: INIT-M Damage: Alters applications and other files; may severely damage file system on infected Macs. See text below. Spread: possibly limited, but has potential to spread quickly Systems affected: All Apple Macintosh computers, under only System 7 The INIT-M virus was recently discovered at Dartmouth College, in a file downloaded off the net. This is a DIFFERENT virus than the INIT-17 virus announced April 12. It is a malicious virus that may cause severe damage. INIT-M rapidly spreads to applications, system extensions, documents and preference files under System 7; it does not spread or activate on System 6 systems. The virus spreads as the application files are run, and is likely to spread extensively on an infected machine. The infection is accomplished by altering existing program code. Besides this incidental damage (that may, because of bugs in the virus code, cause more severe damage), the virus also does extensive damage to systems running on any Friday the 13th -- *not* just booted on that day. Files and folders will be renamed to random strings, creation and modification dates will be changed, and file creator and type information will be scrambled. In some very rare circumstances, a file or files may be deleted. This behavior is similar to the previously announced (March 1992) INIT-1984 virus. Recovery from this damage will be very difficult or impossible. Note that the next three Friday the 13ths are in August 1993, May 1994, and January 1995. The virus, when present on an infected system, may interfere with the proper display of some application window operations. It will also create a file named "FSV Prefs" in the Preferences folder. Recent 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 authors of all other 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: Central Point Anti-Virus Status: Commercial software Revision to be released: 2.01e Where to find: Compuserve, America Online, sumex-aim.stanford.edu, Central Point BBS, (503) 690-6650 When available: immediately Comments: The MacSig file will be dated 4/22/93 Tool: Disinfectant Status: Free software (courtesy of Northwestern University and John Norstad) Revision to be released: 3.2 When available: immediately 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 Tool: Gatekeeper Status: Free software (courtesy of Chris Johnson) Revision to be released: No new revision needed; 1.2.7 works When available: immediately Where to find: usual archive sites and bulletin boards -- microlib.cc.utexas.edu, sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac Tool: Rival Status: Commercial software Revision to be released: INIT-M Vaccine When available: Immediately. Where to find it: AppleLink, America Online, Internet, Compuserve. Tool: SAM (Virus Clinic and Intercept) Status: Commercial software Revision to be released: 3.5.6 When available: immediately Where to find: CompuServe, America Online, Applelink, Symantec's Customer Service @ 800-441-7234 Comments: Updates to various versions of SAM to detect and remove INIT-M are available from the above sources. Tool: Virex Status: Commercial software Revision to be released: 3.93 Where to find: Datawatch Corporation, (919) 490-1277 When available: Detection Strings will be available 4/27 on AOL and on the "DataGate" BBS @ (919) 419-1602. Updated version with detection, repair and prevention capabilities will be available next week. Comments: Virex 3.93 will detect the virus in any file, and repair any file that has not been permanently damaged. All Virex subscribers will automatically be sent an update on diskette. All other registered users will receive a notice by mail. Tool: VirusDetective Status: Shareware Revision to be released: 5.0.9 When available: immediately Where to find: various Mac archives Comments: VirusDetective is shareware. Search strings for the new virus will be sent only to registered users. 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. If you are otherwise unsure of who to contact, you may send e-mail to spaf@cs.purdue.edu as an initial point of contact. Also, be aware that writing and releasing computer viruses is more than a rude and damaging act of vandalism -- it is also a violation of many state and Federal laws in the US, and illegal in several other countries. If you have information concerning the author of this or any other computer virus, please contact any of the anti-virus providers listed above. Several Mac virus authors have been apprehended thanks to the efforts of the Mac user community, and some have received criminal convictions for their actions. This is yet one more way to help protect your computers. ------------------------------ Date: Thu, 22 Apr 93 09:13:26 -0400 From: padgett@tccslr.dnet.mmc.com (A. PADGETT PETERSON) Subject: Philosophy Recently I posted the byte change to COMMAND.COM that will allow screen colours to change without using ANSI.SYS. Someone responded that it was easier to use and not mess with DEBUG. To understand why I rarely mention products (and always include "plug" when I do) is that I deal with a large user community, no budget, and a very strong "no unauthorized software" mandate. Further, an attempt is made to separate what I do and what is suggested "to those who have to ask". As a consequence, when a simple answer exists that does not violate the above principles, this is what I offer. If you know of another way and care to post it, feel free to do so - I'm always eager to learn something new. Further, please understand that this is not a professional activity for me, it is a hobby (that I am finding less and less time & resources for). Also, what I post works for me (in the case of many ANSI.SYS alternatives, I have found few that work as advertised in all of my screwy setups (one PC is simultaneously supporting multiple partitions including one when it acts as a Novell server, Windows 3.1, Deskview, and an incredible number of TSRs). Additionally, since about 2/3 of my user population is still using XT and AT class equipment, I lean heavily toward solutions that use no RAM. True, multicolored prompts are interesing for a DOS power user but not that many people operate from the command line anymore. Finally, cost enters into the picture. True, I occasionally receive software "for evaluation", but for the most part my software is personally purchased. "Competitive upgrades" have helped a lot in this area but still the average upgrade price is in the $50 - $100 range and occurs more often than I would like - MS-DOS is getting more like the Apple systems in this respect. Incidently IMHO DBLSPACE is a potential time bomb. I just received a Microsoft "Q" document (forget the exact number but search on DEFRAGMENT) which makes it clear that like the DR-DOS version of SuperStor, when you defrag a compressed drive with the MS-DOS 6.0 utility it is just collapsed and the files are not made contiguous. The 7.0 upgrade to the Norton Utilities just arrived (I'll get the bill next momth 8*( and it *seems* that it will do a proper defrag of a compressed disk but haven't tried it yet). In my case, it took about three months after DR-DOS compressed my ST-251 before I noticed a performance drop but am sensitised to such things so in about six months... Hope this expains some of my views. Warmly, Padgett ps Mr. Naggs is exactly right about an explicit warm boot when disk cacheing is in use. Being conservative, I always turn write-cacheing off so this was not a concern. Again IMHO writes occur infrequently enough not to warrent cacheing. Since every cache program that I know (including Smartdrv) provides a means to flush the cache, a .BAT that first flushes the cache then invokes an explicit boot would be trivial (exercise is left to the student). If you really were paranoid, the instruction at location FFFF:0000 is always a jump into the ROM somewhere. Your WARMBOOT program could just jump there instead of FFFF:0000. This would take care of the case of a theoretical virus that might rely on writable shadow ROM (386 & above only) to trap FFFF:0000 - note, jump should be to somewhere in the F000 segment - if you are using QEMM "stealth" though (not recommended, NOEMS is a better choice for me) all bets are off. ------------------------------ Date: Thu, 22 Apr 93 11:16:23 -0400 From: hobbit@ftp.com (*Hobbit*) Subject: monitors [sigh...] Yes, this thread periodically comes around. Most monitors like to run at a particular scan rate, and the [analog!] electronics inside are optimized to run at that particular frequency. The scan rate can change slightly when the monitor sychronizes itself to the sync pulses coming from the computer's video board. If the rate of sync pulses from the video board is too "off", the monitor will still desperately try to sync itself to those pulses and sometimes wind up running at some oddball, out-of-design-spec rate. Some of the components in the monitor can't deal with this, since monitors are often designed without much "extra slop" in their component ratings. So some parts may start to run really hot, and eventually fail if the wrong sync condition persists for too long. It is possible to change the sync rate of the video board, in software. It is possible to change it radically enough that the above conditions exist, and if left that way can indeed damage the monitor. I did this to a cheezy mono monitor at one point and a nice wisp of smoke curled out of the vents in the top. I guess I yanked it quickly enough, because that monitor still works. _H* ------------------------------ Date: Sun, 18 Apr 93 11:42:04 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Human factor in infections (Was: Scanners betting bigger and slower) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: I said I considered chances of infection of big companies were small. > Why do you think so? Just the opposite, a directed attack is the most > probable thing that a disgruntled employee of a big company will do... > It is difficult to detect, almost impossible to stop, and often > impracticable to trace. In your presented case, you are right. However, this is rather an exception. I was more talking about the normal operation of the company. If you are ABLE to enforce whatever rules you find needed, and taking out exceptions such as fanatic employees, then this should grant you sufficient protection. One thing, though: if an employee wants to plant you a virus, he will do that. I believe that someone that thinks about it is knowledgable enough to do it well, regardless of any anti-virus softwares. I am sure that man knows what program is used, and where it resides, so he may NOT run it, or disable it, or God knows. > Problem is, this is very difficult to enforce... What are you going to > do - searching the people each time they enter the company? A 3.5" > floppy fits in a wallet... And, in the worst case, a virus could be > brought in as a hex dump on a sheet of paper and the attacker could > manually type it in! That it what I said. I find it weird to argue about something we agree. The human factor can not be taken out, unless you manage to produce a procedure that does not take ANY concious efforts from the human individual. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 14:40:12 +0100 From: Inbar.Raz@p42.f100.n403.z2.fidonet.org (Inbar Raz) Subject: Scanners getting bigger and slower frisk@complex.is (Fridrik Skulason) writes, in reply to me: >>But still, the more viruses there are, the more time you'll have to spend >>searching, or, to put it in other words, there are more things to search for >>in every scanned file, that is, exclusive of various 'Turbo Scanning' >>techniques...) > True, but as I said, one can significantly increase the number of viruses > that a program searches for, without affecting the speed noticably. Fine. That's probable something I DON'T do... >>disinfector. Maybe a generic scanner, but what good is a scanner without a >>disinfector? > Generic disinfectors exist... How effective are they? Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Mon, 19 Apr 93 11:26:00 +0100 From: Inbar.Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Scanners getting bigger and slower Hello Amir. IR: >> This is an interesting idea. What I do today, is this: {text deleted> AN: > Hope my idea helps, try to develop it, you might benefit from it. Well, the Anti-Virus is really only one of many projects I work on simultaneously, and, regretfully, it doesn't have the highest priority. More than that, the original program was not written by me. I received it after it had passed great changes, and I took over it. It took me some time to learn it (it IS a big program), but I can do anything with it now. If I have the time, which I don't... IR: >> Second, even today, there is not much memory needed. I >> don't think it will be short before programs have to >> use extended/expanded memory for virus database or AN: > If it's there, hay not use it? if it isn't, its the same old story... If you can use your conventional memory, because you have enough, why spend any time using/swapping XMS/EMS? IR: >> Yes, BUT, you must agree that the key point in >> disinfecting, rises when the virus encrypts, either AN: > I agree on the fact that if a virus encrypts the host program, it might > not be possible to recover it (unless you keep a backup of some sort, > and this is also the most generic method of all). But if the virus > "damaged" the file so that only a key-part of it is encrypted (like > HAIFA realy does) that poses a problem in *Specific* cleaning but non > for grneric one (suppose the signature you keep on the file containes > just the information missing). V-Analyst, for example, stores the main information of the file - beginning bytes, length, and end bytes (I think). Therefore, it has a partial reply for an encrypting virus, AS LONG AS the virus only encrypts its code (wether including the original first bytes of the file or not). If the virus encrypts the file as well, even with a mere XOR, you're lost... AN: > By definition a method that may do its task whithout knowing the > identity of the attacker should be called "generic". FDISK /MBR is the > generic method to clean most MBR viruses, SYS.COM it a generic BOOT- > SECTOR cleaner (even if MicroSoft did not intend to do it) etc... Ok. I get it. Inbar Raz Chief Data Recovery - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Thu, 22 Apr 93 08:08:15 -0400 From: "Capt Andy D. Rogers" Subject: Re: Unix PC systems (UNIX) I am new to this conference and I am wondering if there is a different one that specializes in UNIX operating system viruses? I have several DOS machines as well so I will continue to monitor these conversation, but do they discuss UNIX very often? Is anyone aware of any virus problems in Unix? I'm fairly new to PC's running Unix too, but I'm learning fast. Thanks for any info. Andy arogers@genesis.mpc.af.mil ------------------------------ Date: Tue, 20 Apr 93 21:14:04 +0100 From: Jani_Patanen@f273.n220.z2.fidonet.org (Jani Patanen) Subject: COMMAND.COM Vaccination (PC) ============================================================================= * Forwarded by Jani Patanen (9:3581/200) * Area : DIRTY_DOZEN (Pirating/Hacks/Trojan/Virus alerts) * From : Paul Maserang, 1:392/20 (12 Apr 93 12:47) * To : All * Subj : COMMAND.COM Vaccination ============================================================================= It looks like I may have found a way to "vaccinate" COMMAND.COM against infection by viruses that infect COMMAND.COM, which is exactly what many viruses do. The first step is to use PKLITE on COMMAND.COM. You won't be able to do it directly, though. PKLITE will refuse to compress it under that filename. So copy COMMAND.COM to another disk or directory and rename it to something else with a .COM extension (ie. WORK.COM), and then use PKLITE on that file. When it's done, rename it back to COMMAND.COM. Now all you have to do is delete the original version of COMMAND.COM that the system uses and replace it with the compressed version, and then reboot the system. You might also want to use ATTRIB to set this file to read-only status. Before doing this with the version used to boot from on your hard drive, I would advise you to format a floppy system disk, replace COMMAND.COM on it, and then reboot from that disk to make sure it will work on your system. I did this on mine and it works just fine. (I'm using DOS 4.01.) Executables that have been compressed with PKLITE are basically immune to infection by viruses that infect executables, including COMMAND.COM in this case. The PKLITE file can still be infected externally (as reported by McAfee's SCAN), but the actual executable cannot be infected in this form. * OLX 2.1 TD * Floppy not responding...Format HARD DISK instead (Y/n)? - -+- VFIDO 6.00.00 + Origin: Modem Junction (1:392/20) ============================================================================= Hello All! What do you think about this? Will it work against most of the command.com infecting viruses? - -Jani - --- GEcho 1.00+/RA 1.11+ * Origin: Empire BBS (9:3581/200) ------------------------------ Date: Thu, 22 Apr 93 05:18:31 -0400 From: "Michal Weis or INFI" Subject: MtE anti-viruses (PC) Hi all, does anybody know ANY MtE antiviral software that can also remove virus (not delete, remove!). I need it to compare with my anti-MtE program. (I already have TB). Any other soft in the world? tnx mike - - This is not a trick, this is -- _ -------------------------------------- , _ _ | ) , /| / )/ ) |/ /| / | / / / /---' | ' \_/ / (_/|\ \_/ - -------------------------------- |_) ---- Origin: weis@cc.elf.stuba.cs --- ------------------------------ Date: Thu, 22 Apr 93 09:42:02 -0400 From: Garry J Scobie Ext 3360 Subject: Re: Can a virus infect NOVELL? (PC) > GSCOBIE@ml0.ucs.edinburgh.ac.uk (Garry J Scobie Ext 3360) writes: > > If a virus can infect my applications volume where > > everyone has only read and filescan permission set as a trustee > > assignment then I would appreciate being told about it as soon as > > possible. > > > The thread appeared to end there as no-one could say either way. I > > suspect the answer is still no. > > The answer is still "it depends". > > First, it depends on what version of NetWare you are using. It seems > to me that you are implying 3.11 and I don't have much experience with > it. Sorry I should have stated that. Indeed I am referring Netware 3.11. > If you are using anything below, and if you have not applied the > security patch from Novell, then it is possible for a virus to use > the mechanism of the KNOCK.EXE program to obtain supervisor > privileges and do with your files whatever it wishes. Note however > that this trick doesn't work under 3.11 and no such virus has been > written yet anyway > - - it is just a possibility. Indeed below 3.11 all that is needed is to enable intruder detection and knock.exe will lockout the account straightaway. > Second, what does "everyone" mean? In the sense I used it above "everyone with read and filescan permission". As you say below obviously supervisors can do what they like. My original posting did state that you have to assume that a virus will adopt the privileges of the logged-on user. Logging in as supervisor from an infected workstation threatens the entire filestore. > A user with supervisor privileges > is obviously able to do anything with those files. In practice, this > means that if a virus succeeds to infect such a user, the virus will > be able to do anything with the protected files. So, it is important > not only what the protection settings of the protected files are, but > also can a virus infect a user with supervisor privileges? That is, > can such user execute something from a place where a regular user has > write privileges? (That is - is there a transitive information flow > from users with low security privileges to users with high security > privileges?) Under Netware (3.11 again) the (A)ccess control permission allows users to give access to other users to their directories and files and to give those users permissions upto the level of your own permissions in that area. However, I believe this was all discussed in last years digest :-) However, accepting the supervisor issue, it is possible to infect a volume where all user accounts have been set to read and filescan permission only, on a 3.11 novell server? Cheers Garry ------------------------------ Date: Sun, 18 Apr 93 11:45:05 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Vshield V102 Bug? (PC) sbarber@bach.udel.edu (Scott Allen Barber) Writes: > I am running a Pionex Goldseries 486DX Computer with AMI Bios and am > having a "problem" with VSHIELD. > It seems that if I load VSHIELD, when I go to do a warm boot > (ctrl-alt-del) it will cause my computer to access the A: drive and > restart the cold-boot memory check. > It seems that some part of memory is written over when VSHIELD becomes > resident, because SCAN's memory scan function will not cause this to > happen. > Does anyone else know about this problem??? This is not a problem. On the contrary. Normally, when you boot, you might want to boot from a floppy. If you do that, most chances are that the floppy will occupy the drive before you actually boot. SO, when you order a BOOT, VShield tries to vir-scan the Boot Sector of Drive A, assuming there is a disk there. If there's no drive, nothing happens, and the boot proceeded. > Thanx...and please reply thru e-mail if possible... I've forwarded this reply through normal channels, too, to: sbarber@brahms.udel.edu Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 11:53:06 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: DOS v6.0 and Virus Functionality (PC) Paul Ferguson writes: > curiosity. Given the impact that DOS v5.x had on many existant > viruses when it was introduced, (many existant viruses would simply > not run under DOS v5.x), I'd garner that much of the same > "non-functionality" will appear with the architectural changes to the > DOS v6.0 implementation(s). I don't think so. Not at all. For two reasons: 1. DOS 5.0 has introduced a whole new way to handle memory. This, I believe, is the main cause for many of the viruses' not working. Since I have made a few experiments myself, I can safely tell you that it's the DOS=HIGH that disabled a lot of viruses. When I used to examine viruses and re-infect files, looking for mutations, (like I do nowadays), I used a clean-boot floppy, that did NOT load anything high. Simply IO.SYS, MSDOS.SYS and the command interpreter. Aside from viruses that are BIOS-dependant (see my message about Murphy mutants and the Dark Avenger, Re: BeBe Virus (PC) ), all the viruses that I have (around 300, not including mutations), almost all ran on the Intel 386DX-33 I have next to me here. The DOS version was 5.0. 2. Based on articles in PCMagazine and PCToday, I gather that DOS 6.0 is merely 'DOS 5.0 + ToolCase'. Not many enhancements, and most of the new stuff is really handy utilities, most of them you probably already have on your harddisk, such as an Anti-Virus, rs-232 File XFer utilities, Backup and Restore programs, etc. > I'm of the opinion that keeping your toolkit of third-party products > current beats the tar out of relying on Microsoft to provide it for > you in the DOS v6.0 "upgrade". In fact, I've been hearing that several > folks have had problems while logged in under Netware 3.11, on both > 4Mb Token Ring and Ethernet LANs after thet rushed to "upgrade" to DOS > v6.0 .... Again, you almost say it yourself. DOS 6 is probably DOS 5, with minor improvements and a toolcase. Nothing to be worried about. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 12:01:07 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Port Writes (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: I talked about Port-Writes instead of conventional INT 13 calls. > [stuff deleted] >> Is there any EXISTING control program to inhibit such access? > Yes. Most modern hard disk controllers issue a hardware interrupt to STOP. Do you really think that THIS is a barrier? I mean, if someone already takes the trouble to learn and implement Port-Write disk access, what is it for him to add a Vector Change before and after? Besides, I haven't checked it yet, but I think it might be possible to tell the IDE NOT to generate this interrupt. I have right next to me here, for a VERY limited time, a book titled: 1992 DEVICES Systems Logic Imaging Storage By Western Digital. This books tells about HardDisks more than ANYTHING you could ever imagine, and all in the hardware level. I'll give it a look, and tell you wether it's possible to disable the interrupts. Remember - even if the interrupt is not triggerable, I can still re-vector it to myself and ignore it/use it for my own purposes. As far as I was told here, OS/2 (or anything like it) is the only safe protect against unauthorized port-writes. > accessed the disk in a non-natural way, so you raise an alert. At Someone, as I've seen, has already commented you about this remark. May I please remind you that the BIOS itself also uses port writes? And you CAN'T link into the BIOS and tell it to tell you when it's OUTting a port... >> If a virus were >> to use port writes, no anti-virus shield would be able to stop it. > This will also make the virus rather non-portable. Unfortunately, it > will still work on many computers and the virus writers don't seem to > care about portability anyway... (I've seen a virus that is able to > infect correctly only 17-byte files...) True, virus writers really don't care MUCH about portability. Nevertheless, the only portability problems would occur on change of interface. For example, if the author had an IDE drive, then his virus wouldn't work on SCSI's and ESDI's, but then again, most of the AT class computers use IDE... > BTW, note that many hardware anti-virus products -will- be able to > stop this kind of disk access, if they can be installed between the > computer and the disk controller or between the disk controller and > the bus... Yes. Those (I've seen one myself) seet between the CONTROLLER and the DRIVE. In IDE, ofcourse, it's between the INTERFACE and the DRIVE, since the drive has its own controller built in. Anyway, the whole point in doing that, is that the controller/interface sends the WRITE command, and it has no idea wether the DISK really did that, because the protection card may return no error, while no action was really taken. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 12:04:08 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Scanning Compressed files (PkLite) (PC) Vesselin Bontchev replied someone about PkLite being un-openable: > Almost. Read carefully the PKLite documentation. It says that the > files compressed with the extra compression option cannot be > decompressed to match the original. This is true - often such files Ofcourse... I can't figure out why people rather believe PkLite than those who have the facts... Every compressed file, has a DECOMPRESSION routine. Whatever that routine does (we have no need to know), the result is the ORIGINAL EXE MODULE, after relication. They obviously didn't change the original module, otherwise the program wouldn't have run... Anyway, you let the PKLITE shield decompress the file, you set a breakpoint on the relocation code and trap the values instead of doing the relocation, and all you have to do left, is write the header, which is easy by itself, but is the hardest part of the process. Summing up - all compression programs are openable. I have here two seperate non-connected programs, that open almost 80 different compression programs/ versions, including PkLite 1.15 Professional (the new algorithm). Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 14:20:10 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: McAfee latest version (PC) > From: lastort@access.digex.com (Mike Lastort) > I was just wondering if there was an address where McAfee's programs are > available through Internet. I used to subscribe to Compu$$erve but have > given up that habit when I got this account. Any info on how to ftp > McAfee's programs would be greatly appreciated. You may use the anonymous ftp site mcafee.com Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 14:36:11 +0100 From: Inbar_Raz@p42.f100.n403.z2.fidonet.org (Inbar Raz) Subject: Port Writes and a new Russian Virus using them (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Writes: > In short, the trick consists of intercepting the "device ready > interrupts" (differently for XT and AT class machines) to detect that When I read these first two lines, I suspected you were going to say "Used the return address from the stack to get the vector of the real INT 13h". However.. ------------------------------ Date: Sun, 18 Apr 93 12:14:09 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: viruses and compression (PC) sosc1043@wc05.writer.yorku.ca (Colin Beckmann) Writes: > Greetings > I was wondering if anybody could tell me if it is possible for a > scanner to detect a virus in a compressed file or on a stacked hard > drive > or if the virus can be detected on a file that has been backed up using > DOS or Norton backup. Some how I doubt it but I am asking to be sure. > If it can be detected could you tell me the name of the software that > can do it The entire idea in stacking the HardDisk, is that the stacking is done on-the- fly, and is totally user-transparent. Therefore, when a scanner wishes to access a file on a stacked drive, the stacking algorithm hands him the file as if it was never compressed. About Pklite-typu compressions - Yes. Some programs are able to detect viruses in compressed programs. I believe Scan does that for LZExe and maybe PkLite too, but I'm not sure. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 14:50:13 +0100 From: Inbar.Raz@p42.f100.n403.z2.fidonet.org (Inbar Raz) Subject: Is Inbar Raz a Virus Writer? (PC :-) ) Y. Radai replies after Inbar Raz talks about loyalty: Y. Radai quoting himself: >>> Btw, it should be noted that on Fidonet there appeared an article >>> describing tricks which can be used by virus writers to prevent tra- >>> cing and disassembly of their code. The reason I mention this parti- >>> cular article is that it appeared under the name of someone who has >>> been contributing to this forum recently, Inbar Raz. The article is >>> called "Anti Debugging Tricks", and one of the virus writers found it >>> useful enough to forward it to 40 Hex (Number 9). Y. Radai: > It's true that Vesselin has expressed the opinion that all tricks de- > scribed in your article are relatively trivial to circumvent. How- > ever, that's irrelevant from my point of view. It's hard for me to > imagine that anyone who wrote such an article could have had any > intention other than to help the *virus writers*, not the AV people. > Do you care to deny that? (or do I have to quote passages from it to > prove my point?) Well, I _DO_ deny that. This artile began as a bulettin in a BBS that I was a Co-SysOp at. Later on, as my role in the FidoNet 80XXX Assembly folder got bigger, I posted this file as a gesture to its readers. Most of my friends there write commercial products, and they face the cracking problem all the time. Since I myself still crack softwares ( FOR LEARNING PURPOSES ONLY ) to gain knowledge of more tricks, I update this article every now and then. This is SOLELY for the benefit of commercial products' writers. If you wish, you may ask Ed Beroset, the Moderator of the FidoNET 80XXX folder. It seems that people DO appreciate that article, and it has achived its goal. It has been included in the 80XXX Snippets, and I even got a special netmail from an Australian guy, that requested permission to publish my article in the Australian Shareware Foundation Bi-Monthly. So, since I wrote this article AFTER the appearance of the Whale virus, I really don't think I invented anything new for virus writers. I merely gathered information... And for GOOD purposes. > I have absolutely no complaints about the postings > that you have submitted so far to the present forum. Nevertheless, it > seems very strange to me that while you continue to submit articles on > other subjects, you do not (unless I've missed some posting of yours) > have a *single word of explanation* to offer on the above matter, I believe I just gave you sufficient explanations. If I weren't on both sides - cracking and aiding to avoid cracking, I would be probably outraged by these allegations, but I completely understand them, and, frankly, I think that had it not been me, I would have made them myself. Look, as an Israeli, unlike the other people around here, it will be easier for you to ask around about me. Never in my life have I written a Virus, nor will I ever. I object to that strongly. > which concerns you so personally. Isn't your silence an admission of > guilt, Inbar ...? No it is not. I have said more than once that I am not a virus writer. I don't need to justify myself to people who don't believe me, because such people have probably already both judged my and sentenced me. If someone things I write viruses, despite I said otherwise, that's a shame, but there's nothing I can do about it. Like Vesselin himself wrote to someone here, how can you know that Vesselin is not really a virus writer? Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Mon, 19 Apr 93 12:09:03 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Port Write, and the Hardware Interrupt (PC) Hello all. Vesselin mentioned a new virus, names Strange, that used the Hardware Interrupt, generated by the IDE on every completion of a command, to act. I promised I will check this out, and indeed, like I suspected, I found that the Hardware Interrupt may be turned off. Inbar Raz Chief Data Recovery - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Mon, 19 Apr 93 15:09:05 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: F-Prot 2.07 (PC) Hello Frisk. I did not like the fact that F-Prot 2.07 did not allow its extraction. I got the archive from an FTP site, as a ZOO file. I extracted the archive, and found out that F-PROT.EXE was compressed. I do not like compressed files on my harddisk, for various reasons. Some of them are execution speed, and the fact that I can't vir-scan compressed files. I happen to have an Israeli product that DOES scan through DIET compressed files, but that was not enough. After extracting F-PROT, I received: F-PROT EXE 245430 2-03-93 16:03 However, this didn't run. It sais 'Run a non-infected version'. I don't understand why you don't allow the extraction. SCAN does. The original SCAN comes PkLited. If you PkLite -X SCAN/CLEAN, they still run normally. Why can't you? With respect, Inbar Raz Chief Data Recovery - - -- Inbar Raz 5 Henegev, Yavne 70600, ISRAEL. Phone: +972-8-438660 Chief Data Recovery, 15 Habanim, Nes-Ziona 70400, ISRAEL. Phone: +972-8-400070 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the first UnTinyProg. (9:9721/210) ------------------------------ Date: Thu, 22 Apr 93 16:13:42 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: BeBe Virus (PC) Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes: > 1. One of the viruses, which I can't remember its name at the moment, tries t o > find the original vector of Interrupt 13h by searching for CMP DL,80 in th e This method was first implemented in the Dark_Avenger.1800.A virus. Later it was copied by several other virus writers. The CMP instruction is not the only thing the virus scans for - look at it carefully and you'll notice that it also looks for a couple of other things. > BIOS segment (0F000h), and therefore it didn't work on my computer - when > I ran it, I had to load it into the debugger, and actually feed it with a > vector to Interrupt 13h :-). Hm, no, then it should be a different virus... The one I mentioned uses this trick to find the original INT 13h handler (in the hard disk controller's EPROM), but if it cannot find it, it does not give up, but just uses what's available... > I later found another virus, Cemetery, which > is actually a Murphy mutant, which also tries to imply this trick, thus I > tend to believe that the first one was also a Murphy mutant. However, this > technique also appears to be used by the Dark Avenger virus, as I later > found out. Yes, Dark Avenger was the first, Murphy is heavily based on it, and Cemetery is just a Murphy variant. > 2. The BeBe virus, for some reason, did not execute well. It hung the > computer. What's more weird is that if I load it to a debugger and STEP it , > it works. Even more weird is that if I load and GO, it hangs as well. Hmm, -which- Bebe virus? There are three of them: Bebe.486, Bebe.1004.A, and Bebe.1004.B. I have reasons to assume that you mean the 1004-byte variant. The .B variant seem to be very buggy - I was not able to replicate it too. The .A variant is also buggy and is CPU-specific - I don't recall right now whether it needs a 8088 or 80286 and above. > 3. I have a virus, aliased 'Brothers in Arm'. I was very suprised to find that > only SCAN has managed to find this virus, but even that not completely > fine. Scan claimed there were both Brothes [Bro] and 1530 [1530]. TBSCAN > (by ThunderByte) found nothing, as well as PF1's UNVIRUS. When I ran the > infected program, nothing else ran afterwards - I simply returned to the > DOS prompt. Even DIR returned nothing. Probably your sample is just damaged - inspect it with a debugger. The virus is a variant of Murphy (its full CARO name is Murphy.Brothers) and it is reliably detected by F-Prot 2.07, SCAN 102, FindVirus 6.20, UTScan 27.03. You are correct that SCAN reports it as two viruses - this is a common problem in SCAN since a long time. > Any ideas as for the Bebe? The VSUM says that it won't replicate on 386's, bu t > hang - exactly what happened, but it doesn't say why. I suspect it has to do > with the virus's jmp instruction. The virus does a relocation-like operatin o n > a FAR JMP instruction within itself, to jump to the virus code. After that, I You are probably right. I think to recall that the self modification (was it ADD or what...) occurred right before the Far JMP instruction. On a '286 and above the prefetch queue effect does not allow the modified instruction to be executed, so the virus goes to the never-never land... :-) Try it on an XT (a 8088-based machine) - should work. 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Thu, 22 Apr 93 16:38:34 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Can a virus infect NOVELL? (PC) kam.bansal@symantec.com (Kam Bansal) writes: > famousee last words!). Novell is really good at stopping anything from > changing a file that is read-only or the user only has read only rights. I' No, if the file has the ReadOnly attribute set (and if the Modify right is granted to the file), a virus (and anybody else) can remove the attribute and infect the file. If no Write right is granted to the file (there's no "read only right"), then it is safe, UNLESS the user is allowed to modify the rights of the file - then a virus that has infected this user's account can use these rights to grant the Write right and to infect the file. (The virus must be NetWare-aware, in order to do this.) Also, if the user has Supervisor privileges, a virus that has infected his/her account can do almost anything it wishes. So, as you can see, "just" setting the files to read-only might not be sufficient to protect them. You must devise a sound security maintenance scheme for your LAN. > A virus waits till a user has write rights to SYS:SYSTEM, and then attaches > itself to a NLM! stream.nlm or clib would be a good start! They are the > libraries for netware, then once the virus is active, on the server now, not > the workstation, it can do ANYTHING! From a NLM, you can delete, trash > anything even if it has read only rights! NLM infectors are possible in theory. It's a bit tricky to implement them - the SYS:SYSTEM volume is normally protected, and the format of the NLM is not that well known, and it operates in '386 protected mode, but nevertheless, writing an NLM infector is by no means impossible. Note however, that in order to spread, such virus must also infect something else - an NLM-only infector won't spread far... 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Thu, 22 Apr 93 16:47:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Censoship/40-Hex (PC) phil@wearbay.demon.co.uk (Philip Coull) writes: > >...... One thing is certain - I didn't get them from virus > >exchange BBSes, because I don't call -any- BBSes. > ^ ^^^^^ ^^^^ ^^^^^ ^^^^^ > I'm puzzled - you seem to know a lot about virus exchange bbs's - how > do you get your info, if you don't call them?? I have a lot of sources, he-he... :-) 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Thu, 22 Apr 93 16:49:03 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: "DIR" infection, or "Can internal commands infect" (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: > True again. But consider the possibility that you use "DIR" from whithin a > batch file (that also executes programs) the one prior to "DIR" might be the > one that touched the TRANSIENT. Yes. So, the transient part will be reloaded right after that "one" exits. This has nothing to do with the running of DIR afterwards - it will not be DIR that is causing the reloading of COMMAND.COM, it will be the program before it. I repeat - using a DIR on a diskette cannot cause the reload of an infected command interpreter from it. Therefore, you cannot get infected by just doing a DIR on an infected diskette (ANSI tricks excluded). > Also what do you think about a program that " > shells" to DOS (running "DIR" from whithin a program), in this case the > TRANSIENT also might have been touched at program load time, and the "shell- > to-DOS" frees the memory for the operation (you see many times the instructio n > "Insert diskette with COMMAND.COM..." when running programs that exit to DOS > to do some DOS operations). Again this has nothing to do with the DIR command. If you "shell to DOS", you are executing a second copy of the command interpreter. You are not just loading its transient part - you are executing it. Of course if may be executed from a floppy - if your COMSPEC says so. Of course it can be infected - so what. I didn't say that the execution of an infected command interpreter cannot infect your PC - I am saying that the execution of the DIR command does not cause the reload of the transient part of the -current- command interpreter and that the execution of the DIR command on an infected floppy cannot load a virus from there. Of course, you can do anything weird -before- doing the DIR command. For instance, you can have a batch file that runs FORMAT on your floppy and then executes DIR on it. Does this mean that doing a DIR on floppies can cause them to be formatted? Next, suppose for a moment that you succeed to force the transient part of the command interpreter to be loaded from an infected copy of it. What will happen? There are two possibilities. Remember that only the transient part is loaded - not the whole command interpreter. The virus has either modified this transient part (unlikely, for practical reasons), or not. If it has not, then it will not be called at all, thus no virus in memory. If it has modified it, the checksum will not match, and DOS will tell you to put the -real- COMMAND.COM and will not load the transient part until you do so. Result - still no virus loaded in memory. The only danger is if a virus succeeds to infect a copy of the command interpreter in such a way, that it (the virus) gets loaded when the transient part is loaded, but the checksum of this transient part is not modified (i.e., the virus has forged it). This is only a theoretical threat - have you tried to "forge" even a simple CRC? - but it is a possible one. However, my point is that the execution of the DIR command DOES NOT cause the reload of the transient part of the command interpreter and thus CANNOT cause a virus to be executed. > As I said. It will not happened while typing "DIR" at the DOS prompt, but it > might if you run DIR from a batch file or from a program. No, it will happen -before- you run DIR from a batch file or from a program. Which still means that DIR -cannot- cause the infection of your computer. Running an external program or loading a new copy of the command interpreter can - but nobody was speaking about that. 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Thu, 22 Apr 93 17:08:36 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: "DIR" infection, or "Can internal commands infect" (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: > > During the reload, the checksum will be re-computed and DOS will keep > > insisting that you supply the real thing until the checksum matches. > Right again, do you not see the possible hole here? DOS is full of holes. > > That's why you cannot use a different version of the command interpreter, > > even if you change COMSPEC to point to it. (You CAN use a different > > -copy- of the same command interpreter, located somewhere else, > > if you change the COMSPEC variable.) > When you've booted from a floppy derive, the COMSPEC is A:\COMMAND.COM, (did > you forget the days few people had disks?) so you have to keep handy *THE* > bootable floppy. So what? Read what I wrote. I am not claiming that you cannot use a different -copy- of the command interpreter - on a different floppy, for instance - I am only claiming that you cannot use a different - -version- of the command interpreter, even if you change the COMSPEC variable to point to it. > > However, the DIR command is internal and its execution > > does NOT destroy the transient part of COMMAND.COM, therefore > > it NEVER causes its reloading. > Absolutelly, and definitely TRUE. But what about "DIR" from whithin a program ? Yes, what about it? A program that shells to DOS does execute (not just load the transient part of) another copy of the command interpreter - so what? How does this make the DIR command less internal? It's the execution of an external program (the command interpreter) that can cause infection, not the execution of the DIR command. > The only question here is only: when can you replace the command.com to cause > the reload of the TRANSIENT to load the infected one? You can replace the command interpreter almost at any moment, but you probably mean when the replacement will cause viral code to be executed? I already explained that in my previous message - when DOS wants to reload the transient part of the command interpreter, if it finds a copy that has the SAME checksum of the transient part as the original, and if this transient part nevertheless has been modified to include virus code - then it can cause the execution of the viral code. But this has nothing to do with the problem we are discussing - the DIR command does not cause the reloading of the transient part, thus it cannot cause a virus to be executed. > When you do a "DIR" from whithin a program (with "exec") you load another cop y > of command.com do to it, this might be the time when a "simple" does more the n > the user expects. And also when you format the floppy before you do a "DIR" on it, after the DIR it will be formatted. So what? It's the execution of a second copy of the command interpreter that can load a virus in memory, not the DIR command. > > I challenge you to describe me a reproducible > > situation in which executing the internal DIR command (on an > > uninfected system and no ANSI keyboard programmability) will cause > > reloading of the command interpreter from the diskette that is being > > examined. > I just did, and I leave the rest for virus writers who might pick your > challange. Nope, you didn't. You are speaking about executing external programs or loading a second copy of the command interpreter BEFORE the DIR command is executed. I am speaking only about the execution of the internal DIR command. 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Thu, 22 Apr 93 17:24:10 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Help wanted with Dir-II virus (PC) Robert_Hoerner@f2170.n492.z9.virnet.bad.se (Robert Hoerner) writes: > To remove a DIR-infection the only secure way is to copy all executables to > files with non-executable extensions with THE VIRUS ACTIVE IN MEMORY ! This > way the virus itself will "desinfect" the files, it will act as a "low-level- > cleaner" :-)) > "COPY *.COM *.MOC" > "DEL *.COM" > "COPY *.EXE *.XEX" > "DEL *.EXE" ..etc. While the procedure described by you works - and will be even effective against almost any stealth fast infector - in the particular case of Dir_II it is a rather clumsy one. There is a significantly more elegant method - I think the first one who has invented it was the Polish anti-virus researcher Andrzej Kadlof. The method has been posted here several times and consists in the following: With the Dir_II virus active in memory (this is important) just RENAME all your executable files (you'll have to do it in all of your subdirectories): ren *.com *.moc ren *.exe *.xex If you are using something smarter than the brain-dead COMMAND.COM - e.g., 4DOS, you could do something like that instead: pushd c:\ ^ global /qi ( if exist *.com then ren /q *.com *.moc ^ if exist *.exe then ren /q *.exe *.xex ) ^ popd (The above command should be entered on a single line.) Then boot from a clean diskette, rename them back and run CHKDSK/F. That gets rid of this particular virus. 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 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 70] *****************************************