Well, here we are again. Its the end of February and there are more things
going on than one can keep up with. Starting this month, The Scanner
will be a monthly publication. The next issue should be out about the begining
of March. This will be on a trial basis.
We have some great stuff this month. We have changed the format a bit again in an attempt to find just the right format. We have tips from the pros in The Proshop. We have information from around the World in the AV Around The World section. As promised, this issue has Mikko Hyppönen's treatise on Retorviruses (part 1). A brilliant piece of work don't skip it. We of course have the usual book reviews and virus info. So, sit back get comfortable and let us know what you think.
Editor's Note: I am pleased to introduce Ruben Mario Arias. Ruben is a
new member of The Scanner staff and I can see already he is going to be
a great asset. He caught his virus in 1989 (Ping Pong A ) and was curious
enough to pursue the virus. As it ends up Ruben now owns his own Computer
Security company called RALP Computer Security. Ruben's home is in Bueno Aries,
Argentina, where he and his wife, Alejandra, live. Ruben is 34 years old and
enjoys music and working out at the gym. Ruben also writes in a local virus and
security magazine called Diskette Magazine. Welcome aboard Ruben, we
look forward to working with you in the future and welcome the news from
Argentina.
Since end of 1993 many groups of the "underground" have been programming new threats and increasing the population of "known" virus in Argentina.
Situation is not different at all for countries limiting Argentina like Uruguay, Chile and Brasil. Each country has its very own local viruses that enter Argentins by frontier points or by companies representing these countries here.
Many local Virus Interchange BBS complement the activities listed before and this situation will increase in the future. The viruses are not complex at all but the people who program them are learning quickly. An example of this was a local virus (Avispa) that many researchers consider polimorphic.
I don't wish to make "free" publicity for the groups so I will not mention them by their "War_names".
Name : Vinchuca.
Size : 925 Bytes.
Infects : .COM files only.
Scan string : B0 B8 BF 1D 01 2E 38 05 74 13 F9 BE 1D 01 72 01.
In the wild : Yes.
Interrupts : Hooks interrupt 21h.
Load Address: ---
Polymorphic : No.
Resident : Yes.
Size in RAM : 1232 bytes.
Stealth : No.
Text : Not visible.
Type : Infects .COM files, and the virus locate itself in
the beginning of the infected host files.
Don't infect command.com.
Unusual : When some small *.com files are executed system crash
(hangs). When virus try to infect a write protected
diskette no message is shown.
Other info : This virus was submitted to Wolfgang Stiller.
Name : Patoruzu.
Size : 1024 Bytes.
Infects : .COM files only.
Scan string : 4D 59 00 F1 E5 EB 53 2D 13 3D BF 59 15 25 21 BD BF 0D BF 65 15.
In the wild : Yes.
Interrupts : Hooks interrupt 13h and 21h.
Load Address: ---
Polymorphic : No.
Resident : Yes.
Size in RAM : 1360 bytes.
Stealth : No.
Text : (In the begin of file: TOMY)
Type : Infects .COM files, and the virus locates itself
in the beginning of the infected host files.
Don't infect command.com.
Unusual : Some small should be infected but then no run.
When the virus tries to infect a write protected
diskette DOS reports a write protect error.
Other info : This virus was submitted to Wolfgang Stiller.
Editor's Note: Gerard Mannig is an Anti-Virus researcher in France.
Apparently there aren't too many in the field in France. Gerard gives us the
stats from '94 on the virus situation in France. Gerard has a degreee in
Science Technology is attending school again in pursuit of a Computer Science
Degree. We are glad he has joined the 'gang' at The Scanner and we look
froward to working with him in the future. I asked Gerard what RECIF stood for.
He is what he had to say:
It is a French acronym standing for: Recherches et Etudes sur la Criminalité Informatique Francaise, which could be translated as "French Computer Criminality Research Center."
Here is a quoted message about the 'announcing RECIF creation' I posted months ago in comp.virus newsgroup
The RECIF society (Recherches et Etudes sur la Criminaliteé Informatique Francaise) targets experiences and ideas exchange to fight computer criminality. These exchanges may be done between both RECIF members and national/international societies running in computer security Main activities of RECIF are recording, collecting, studying all informations about computer foul-play. RECIF members meet regularely and publish both documents and utilities relating to their goals for individuals, corporates and media.
RECIF has just finished gathering virus attack stats for 1994.
Virus names stated hereafter are common names. Due to varity of scanners used, it is impossible to present a Caro-naming listing in this posting. We plan to imporve this as time goes on.
percent of total cumulative Virus name attacks reported percent ---------- ---------------- ---------- Form 20.7 20.7 Jumper 19.7 40.4 Parity_Boot 9.6 51.0 AntiEXE 8.0 59.0 Stoned family 5.3 64.3 Tequila 4.8 69.1 'Generic' Boot/MBR 3.7 72.8 Cascade 2.7 75.5 Cansu 2.6 78.1 Yankee Doodle 1.9 80.0 Flip 1.7 81.7 Jack_The_Ripper 1.7 83.4 AntiTel 1.5 84.9 No_Int 1.3 86.2 Maltese Amoeba 1.2 87.4 Michaelangelo 1.2 88.6 French_Bug 1.0 89.6 miscellaneous 11.4 100.0
Apart collecting samples for AV tools improvment and/or study purposes, such reports would allow RECIF to emphasize its stats accuracy, increase its utility in providing advices to companies/individuals victims of viruses, help it to improve its stregnht mainly when RECIF collaborates with Police Departments.
Editor's Note: Gerard can be reached at mannig@world-net.sct.fr if you would like more information.
Editor's Note:Again, The Scanner thanks Mikko for his generosity
and time. The following article is taken from the F-PROT Bulletins 2.14 and
2.15. Mikko attended the Virus Bulletin Conferance in 94 and presented this
brilliant paper. Don't miss the second half in the next issue of The
Scanner!!! Mikko Hyppönen, who works in Data Fellows Ltd's
F-PROT-support, presented the following treatise in the Virus Bulletin '94
conference.
"The GoldBug virus has extensive anti-anti-virus routines. It can install itself while several resident anti-virus monitors are running. It will prohibit most popular anti-virus programs from running, and will also by-pass several integrity checking programs"
- from the original source code of the GoldBug virus.
It's not surprising that virus authors have realised that anti-virus tools are one of their creations' worst enemies. The logical step for them has been to make their viruses fight back, either directly or indirectly.
Several viruses explicitly target anti-virus programs. The attack routines may be generic or targeted against a specific program. Many virus authors obviously consider an attack to be the best defence, when the objective is to keep the virus alive in order to spread it as widely as possible.
There is a battle going on in computer systems world-wide - it's survival of the fittest, one might say. Hopefully, this paper will provide some ideas how to make anti-virus applications fitter than viruses.
Retrovirus is a computer virus that specifically tries to by-pass or hinder the operation of an anti-virus program or programs. The attack may be specific to a known product or a generic one.Retroviruses are sometimes known as anti-anti-viruses. Anti-anti-viruses should not be confused with anti-virus-viruses, which are viruses that will disable or disinfect other viruses. To avoid confusion, the term retrovirus will be used here.
The creation of a virus which incorporates retro-routines is not necessarily a difficult task. In most cases, virus writers have access to the anti-virus programs they want to by-pass. All they need to do is experiment by trial and error until they find a way to attack the anti-virus program in a way the anti-virus developer has not foreseen. [Siilasmaa]
Some virus authors have gone all the way and disassembled the offending anti-virus programs in order to find the most effective way to attack them. They often look for methods to attack a product in a way that would be most difficult to circumvent in future versions of the product.
As the virus authors are pretty efficiently connected to each other via different types of electronic networks, information on how to attack specific products spreads quickly.
It should be noted that virus writers typically have access to only those anti-virus products that are available as freeware or shareware. Some virus exchange BBS systems are known to make pirated copies of commercial products available, but the shareware products seem to be targeted most often [Fellows].
It can be expected that more retroviruses, using more advanced retro-routines, will be seen in the future.
Several approaches are possible, including:
Methods like encryption, stealth, polymorphic routines, code armouring, anti-debugging tricks and confusion code can also be considered attacks against anti-virus programs. However, they are often generic in type and therefore outside the scope of this paper.
There are several different ways a scanner can be attacked against.
A virus can replace the scanner program with a Trojan horse which could trigger a damage routine when run or just simply display an error message and abort. Such an error message would also make the scanning product look bad in the eyes of the users, especially if the error message would be something like 'only 620kB of free DOS memory, unable to run' or 'BRUN30 GW-Basic run-time library not found, aborting'.
If the virus stays resident in memory, it can do similar attacks when it sees that an anti-virus program is executed. It can also by-pass a self-check routine of an anti-virus program by patching it only after the application has finished the check on its own code.
A similar attack in which the virus modifies the configuration file of an anti-virus program might also be possible - these files are often left unencrypted and are not checked for such modifications.
A variation of the theme would be that the virus would patch the texts displayed by the product. If the text string 'Virus found!" were to be changed to 'All clear!', a typical user wouldn't probably doubt anything.
In many installations, anti-virus programs are run automatically and the alarms are set off depending on the exit codes (errorlevels) returned by a program. A successful attack on such a system might consist of a retrovirus that would always set the return-code of an anti-virus program to zero.
One way to implement this kind of an attack would be to include an encryption routine to a virus, but borrow the decryption code from some known application - the encryption would limit the traditional search strings to only strings that would cause false positives, and this in itself would cause problems for some scanning products.
A similar attack might be possible against products that actually unpack the programs and scan underneath the packing. In order to uncompress the program, the scanner fetches program info from the unpacking code. If this code contained irrational values, it could cause some scanners to crash or run out of memory.
Since a virus can control the system in any way it wants, one way to by-pass a scanner would be to change the file extensions of all infected files to non-executable ones, for example from EXE to XEX. While the virus is resident in memory, it can use stealth techniques to hide this change - but it will also make sure that all executables copied to floppies have the valid extension, to ensure that the virus gets a chance to spread. The advantage of such a method is that even if the machine is booted up from a clean diskette and all executables are scanned with a scanner that can detect the virus, it will only be found in the initial carrier file.
The Command Bomber virus is an example of this: it inserts its code in the middle of the host file and builds a complicated series of branching commands to transfer the flow of the program code to the actual code. The detection of such virus would force some scanners to scan the whole file from the beginning to the end - which would be enough to make them unusably slow.
A virus can use such back doors for its own benefit, either disabling the resident part or by using the clean path to file system provided by the TSR.
Yet another way for a virus to attack a resident scanner is to observe the display routines, and trap the alarm messages displayed by the TSR. If the user never sees the alarm messages of the TSR, the protection is not doing its job.
To be continued in the next issue of The Scanner.
With Frodo (as with many Stealth viruses), you can get the virus to disinfect itself by copying infected files to non-executable extensions (e.g. copy *.COM *.COO + COPY *.EXE *.EXX). Booting clean and then renaming the files.
> I've been infected by the B1 virus. I have no idea how to get rid of it as F-Prot will not run with the virus in memory. Here's what happens: F-Prot comes up and scans memory. 96% of the way through the scan I get a red-screened message that states that B1 is in memory (though may not be active). I have booted from many clean floppies and each time I run F-Prot, I get the same message.
The floppies don't appear "clean" from what you report.
> Running F-prot with the /nomem switch will allow me to run the program, but I can't find any sign of infection (B1 works! Go figure...).
It's stealth, and controls memory, mis-directing disk reads.
> IBM AV, which I consulted for a second opinion, does the same thing F-Prot does--reports a virus and stops.
(Henri goes on to explain more about B1)
You need to power down and reboot from an UNinfected floppy. B1, also known as NYB, is a Boot Sector Virus, which starts from an infected PC. It's in memory all the time, and writes part or all of its code to Sector #0, which all diskettes have. It makes no difference to the virus what is on the disk, or even whether the diskette is bootable or not, and infects diskettes in both A or B drives, if not they are not already infected, or write-protected.
B1/NYB moves the diskette's original Boot record code to the last sector of the area used by the Directory, and if the disk has files listed in the overwritten sector, this will cause the loss of entries of files, deleted files, and subdirectories in the root.
The files could still be located in the file storage area of the disk, and could be recovered using CHKDSK /F, or a utility program, but since they are no longer listed in the Directory, they may be overwritten, as other files are later stored on the diskette.
Once the virus is on the diskette, if that diskette is later in the A drive of another PC at power-up, or when re-booted with Ctrl-Alt-Del, the Boot sector is read, the virus takes control of memory, and infects the hard disk, moving the partition/MBR data to the last sector (#17) of Track Zero, and writing its code to the first sector.
Ordinarily, data are not lost from the hard disk, because Sector 17 which the virus thus overwrites is not used by DOS. However, disks formatted in a non-standard manner, other than with DOS, will lose data from Sector 17.
B1/NYB is loaded into memory at every boot-up after. It's considered a "stealth" virus, since besides giving no outward sign of its presence, while in memory it can keep anti-virus and disk utility programs from reading the infected Partition/MBR sector, where the virus code is. It does this by redirecting attempted reads of the infected MBR or boot sector to the sector which has a copy of the original, un-infected code.
One pecularity of the virus is that if it's in memory, DOS sometimes cannot read infected high-density diskettes. "General Failure" messages may occur, and disk utility programs can be deceived, reporting (erroneously) that the Boot Record is "invalid," that the Media Descriptor Byte is "incorrect," and that File Allocation Tables are corrupt. Unfortunately, correcting these non-existent errors will cause data loss.
Many people think that the Michelangelo computer virus was a) a hoax or b) confined to March of 1992. Neither of these assumptions are true. Many hundreds of thousands of copies of Michelangelo were found, and eradicated, in the months leading up to March 6, 1992, which was why there was no great crash on that day. Michelangelo is, however, still around, and in some countries is the most commonly reported computer virus.
Michelangelo will infect any Intel/BIOS architecture machine, although it generally will create problems, and therefore be noticed, if MS-DOS is not present. Until the computer is "booted" on March 6th of any year, the virus is symptomless (except for possible loss of files on diskettes). March 6, 1993 was a Saturday, and most business computers would not have been turned on. Therefore, Michelangelo would not have triggered, and could have infected many of those machines and had March 6th pass without notice. The same is true for Sunday, March 6, 1994. March 6th in 1995, however, will be a Monday, the first "boot time" on March 6th, for many computers, since 1992.
Almost all virus scanners can easily identify, and readily eliminate, Michelangelo. With the increase in the use of antiviral software, the level of danger is likely somewhat less than in 1992. However, the danger is still there, and this would be a good time to prompt people just to make a quick check.
A couple of further points: if people are too lazy to get antiviral software, a quick check can be made with CHKDSK. If the "Total memory" is 655,360, then you do not have Michelangelo. You may, of course, have something else, and there are other reasons than a virus infection for a lower number. Also, making a backup on diskettes is not protection against Michelangelo, as it can corrupt the non-standard disk format used by popular backup software.)
(Also, the source code for Michelangelo has been recently posted no less than three times on various computer networks.)
Part one is a general introduction to CompuServe, covering means of access, the WinCIM front end program and a general overview of CompuServe services. This last is extended to form the eight chapters of part two, giving details of operation of the features and functions. Part three gives a quick overview of the information resources available.
The book is not without flaws. Although attention is paid to both front end and command line access, the material is not always clear on which functions are handled by the local program, and which by CompuServe, itself. The question of costs, with the growth in interest of the supposedly "free" Internet, is delicate, but some of the advice in this area is questionable. Overall, however, the material is relevant, useful, and to the point.
Well worth the investment for a new CompuServe member.
The work is considerably different, in style, to the Stallings and Garfinkel efforts. Those books, while not obtuse, were still written with a technical audience in mind. Schneier's work, while definitely showing the expertise he demonstrated in Applied Encryptography, is clearly aimed at the general, non-technical reader. (Interestingly, while he does tell you where to find the RC4 algorithm posting, he doesn't mention the loophole recently pointed out in the Clipper "Skipjack" algorithm.) The straightforward style lulled me into thinking that chapter one was too long. It isn't: Schneier makes the important point that, for it to be truly effective, encryption must be used on all correspondence, even trivial items. So well crafted is his argument that it would be difficult to reduce the chapter by so much as a paragraph.
Schneier uses this argument to good effect in pointing out some of the major deficiencies in the two systems. PGP is awkward to use, and PEM may use incompatible algorithms. Surprisingly, he does not emphasize (though he does mention) what is probably the major problem with each--the inability to use the same system within and outside of the United States. The PGP fiasco is too involved to get into here (see the Garfinkel work for details) and there is not yet an "international" implementation of PEM (although there may soon be an "authentication only" version available).
This won't help you design your own algorithm, but it is definitely for any user of email, manager of communications systems, or student of privacy and confidentiality.
We are starting to get some participation from a few of you out there and it is
great stuff. Keep those alerts coming in.
The first one comes from Rob Slade. Think there is safety in shrink wrap? Guess again.
SunGuard Data Systems, as the name implies, sells security, and even antiviral, software. Recently the company shipped disaster recovery planning disks to clients -- infected with a virus. Microsoft also distributed virus infected disks to developers at a recent meeting in London, UK. Neither report (in Information Week for February 6th, and The Guardian, reported by Edupage) mention the viral programs involved. -Rob Slade
Next, Jay Cochrane sends an addition to last months Trojan report on the file SCCL100.zip.
Thanks for the heads up. Did a search of our CD's and found it also on Mega CDROM 3 so I guess we can all add that one to the list. Guess there are nice people out there... Jay
(Yeah Jay, there are some real sweethearts out there :-))
Thomas Smith got a hold of Bill Lambdin and reported this Trojan reported by Mike Schmieg.
A customer has informed us that a file called QKEY.COM, accompanied updated technote, titled "MS-DOS 6 and UPDATE for Quarterdeck Produc an abridged version of UPDATE75.TEC Q-FAX #197, was uploaded to his
It claims to be an update to QEMM 7.5 and suggests to replace KEYB a KEYBOARD.SYS with the provided QKEY.COM. This is not a genuine update. There is no technote called "UPDATE75.TEC" and Q-FAX #197 is RSH.TEC.
According to the information we have received, QKEY.COM contains code self-encryption and can potentially kill your partition-table.
Bryan Joyce reported the following Doom II Trojan to Bill. Bryan did such a good job of detailing the problem I thought we'd just do his report in The Scanner. Thanks Bryan.
Here is the full report on the Doom2 trojan that I mentioned earlier in the week. I'm afraid it's not much more than I said in earlier posting. Please spread this message as far as possable.
Last week (3/Jan/95) I visited a friend of mine. One of the files that he gave me was LKCC_WAD.ZIP which was a supposed WAD viewer for Doom one and two. Except that it wasn't.
The main file SHOWAD.EXE didn't seem to do anything other than report that it couldn't find the WAD file. The file seemed too small to be an editor. When it was ran without any parameters it showed a help table which said that the Escape key would delete the contents of the WINDOWS directory. This was followed by an emosicon of a face winking. This struck me as odd an I immediately did a virus check which showed up nothing.
I ran another file DA-CHAOS.COM. Bingo! It tried to unload VSAFE from memory. Luckily for me, it was unable to do this as I had loaded other TSR's after Vsafe. Next it tried to write to the bootsector, but was unable to do so because Vsafe was still loaded. It then displayed an ANSI screen that looked like an advert for a BBS or coding group. Finally it returned to DOS with the message THE CHAOS EFFECT.
I then used Norton to copy my FATs, CMOS values and bootblock to a floppy file and write protected it.
This done, I turned Vsafe off and re-ran the file. Something was written to the bootsector which changed the size of COMMAND.COM. After rebooting, I found that Vsafe no longer worked, but still gave a message that it was installed although it wasn't. MSAV detected no virus, but noticed a difference in file sizes. It was the same with FINDVIRU (Solomons). The files DOSKEY.COM, INK.COM and MOUSE.COM had got bigger. The few EXE's that I ran were unaffected; WP.EXE, and PRINTER.EXE.
To double check, I re-sysed the hard drive. After a reboot, the new COMMAND.COM had become bigger again along with SYS.COM. Tests having been done, I deleted all the infected files, rebooted with a clean disk, restored the bootsector etc., from the floppy I had created, sysed the hard drive from the clean floppy and finally restored the deleted files from a back up on my tape streamer.
In conclusion, the file DA-CHAOS.COM disables VSAFE, and writes a virus into the boot block of the hard drive. From there it copies itself into other files. What it will ultimately do is anybody's guess. Whether or not it was written by the same person (claiming to be Dr Lazy'94) who wrote SHOWAD.EXE is not known, but seems likely.
This has been confirmed by Bill Lambdin, Wallace Hale and Howard Wood. See Wallace's preliminary report on Taipan.666.
I viewed the contents of these archives with PKunzip 1.93 alpha version. My computer, and PKzip 2.04G do not cooperate. Just a brief disclaimer to explain the "Method" column of the archive contents.
Here is the contents of REG_AT10.ZIP
Length Method Size Ratio Date Time CRC-32 Attr Name
------ ------ ----- ----- ---- ---- -------- ---- ----
152 A-Xtra 69 55% 11-29-94 16:55 a7bb45fa --w- AUTO.CFG
1443 A-Xtra 408 72% 11-27-94 16:26 b2d136b7 --w- HEADER.PCB
0 Stored 0 0% 11-29-94 18:17 00000000 --w- AUTO.MSG
2654 A-Xtra 2297 14% 11-29-94 18:01 f6930f49 --w- AUTOEDIT.PPE
71 A-Xtra 58 19% 12-10-94 14:45 9b7bd441 --w- FILE_ID.DIZ
828 A-Xtra 677 19% 11-29-94 18:07 ffbf0429 --w- AUTO.PPE
5282 A-Xtra 1907 64% 11-29-94 18:27 f3985f6b --w- AUTO.DOC
15900 A-Xtra 15643 2% 11-29-94 18:17 03b5cf9f --w- AUTO.DAT
81 A-Xtra 51 38% 11-29-94 18:19 578d939d --w- AUTO.BAT
1467 A-Norm 457 69% 11-13-94 03:13 d6cd997e --w- WORKSHOP.BBS
------ ------ --- -------
27878 21567 23% 10
AUTO.DAT is a corrupted self extracting archive infected with Taipan.438 virus.
Taipan.438 is a resident infector of .EXE files. The infected files increase by 438 bytes. This virus is not stealthed, and is not destructive. This virus is also refered to as Whisper.
Here is an AUTO.BAT Included in the archive.
@ECHO OFF DEL AUTO.MSG REN AUTO.DAT AUTO.EXE AUTO.EXE REN AUTO.EXE AUTO.DATAs you can see, the .BAT file renames the infected file to AUTO.EXE, runs the infected file then renames the file back to the original file name.
The sole purpose of this .BAT file is to drop the virus on computers belonging to unsuspecting users. The executable files were intentionally named to non executable file extension so scanners would not detect this virus because most people only scan files with executable extensions.
Here are the contents of REG_ER10.ZIP
Length Method Size Ratio Date Time CRC-32 Attr Name
------ ------ ----- ----- ---- ---- -------- ---- ----
1952 A-Xtra 1765 10% 11-27-94 21:39 c7e812c7 --w- RUNPPE.PPE
0 Stored 0 0% 11-27-94 14:01 00000000 --w- RUNPPE.SCR
0 Stored 0 0% 11-27-94 14:01 00000000 --w- RUNPPE.TEM
5720 A-Xtra 2067 64% 11-27-94 14:08 a34d4ad8 --w- RUNPPE.DOC
260 A-Xtra 224 14% 12-10-94 14:46 5a26faff --w- FILE_ID.DIZ
214 A-Xtra 73 66% 11-27-94 14:01 6c04038d --w- RUNPPE.DAT
29397 A-Xtra 29080 2% 02-01-93 02:04 79548d46 --w- RUNPPE1.DAT
121 A-Xtra 70 43% 11-27-94 14:02 3fb6a08b --w- RUNPPE.BAT
1467 A-Norm 457 69% 11-13-94 03:13 d6cd997e --w- WORKSHOP.BBS
------ ------ --- -------
39131 33736 14% 9
RUNPPE1.DAT is PKunzip.EXE version 2.04g infected with the Taipan.438 virus.
See note above for brief description for Taipan.438.
Here is RUNPPE.BAT included in this archive.
@ECHO OFF DEL RUNPPE.SCR DEL RUNPPE.TEM REN RUNPPE1.DAT UNZIP.EXE UNZIP.EXE RUNPPE.DAT REN UNZIP.EXE RUNPPE1.DATThis virus renames RUNPPE1.DAT to UNZIP.EXE Runs the infected file with RUNPPE.DAT, then renames the executable file to RUNPPE1.DAT.
Apparently; this is a deliberate attempt to release Taipan.438 on computers belonging to unsuspecting users.
Virus...............: TaiPan.666
Alias(es)...........: Doom_II_Death, Doom_III, Doom2.666
Virus Strain........: Tai-Pan (Whisper)
Status..............: New, verified in the wild.
Detected:..when.....: 13 November 1994
where....: Toronto, Ontario, Canada
Specimen source.....: Marc Faubert, Ajax, Ontario
Classification......: Memory resident .EXE file infector
Length(s) of Virus..: 666 bytes
Disassembled........: Yes
Operating System(s).: PC-DOS/MS-DOS
Version/Release.....: 2+
Computer model(s)...: PC/XT/AT
Type of Infection...: Appending; modifies EXE header.
Infection Technique.: Infects on host execution.
Infection Trigger...: EXEC function, INT 21h, fn 4B00h
Interrupts hooked...: 21h
Stealth.............: No
Tunneling...........: No
Polymorphic.........: No
Encryption Engine...: n/a
Damage..............: None intentional
Damage Trigger......: n/a
Particularities.....: Following plain ASCII text can be found in the
: body of the virus:
:
: DOOM2.EXE
:
: Illegal DOOM II signature
:
: Your version of DOOM2.EXE matches the
: illegal RAZOR release of DOOM2
:
: Say bye-bye HD
:
: The programmer of DOOM II DEATH is in
: no way affiliated with ID software.
:
: ID software is in no way affiliated
: with DOOM II DEATH.'
Similarities........: Essentially Tai-Pan code padded to achieve
: a 666-byte length.
Countermeasures.....: F-PROT 2.15 recognizes as a Tai-Pan variant.
: TBScan 6.30 identifies as DOOM_III.
: AVP 2.1 names the virus Doom2.666
Date................: 30 November 1994
Updated.............: 14 December 1994
By..................: R. Wallace Hale
For.................: Zen Works
COMMENTS:
On initial execution, the virus calls Interrupt 21h, function 7BCFh, as a residency test, and if a copy is not found it memory, it goes resident just below TOM in the lower 640k of main memory, reserving 720 bytes for itself, and hooking Interrupt 21h. CHKDSK will detect the change in free memory and almost any memory mapping utility will show the presence of the virus.
Interrupt 21h calls are monitored for an EXEC function, fn 4B00h, and suitable hosts are infected when that function is intercepted by appending the viral code to the end of the host file. Original time and date stamps of infected hosts are preserved.
Suitable hosts are .EXE files not larger than 64,768 bytes, and .EXE files that have been renamed to .COM extensions. The EXE header is modified so the viral code is executed first, then control is passed to the host file.
The virus contains no intentionally destructive routines and the text strings detailed above are never displayed.
Name ] Page 10
Size ] 1221 bytes
Infects ] .COM & .EXE files including COMMAND.COM
Scan String ] I'm not releasing a scan string because I do not believe
] this virus can survive in the wild.
In the wild ] Unlikely. However; this virus was UUencoded and posted
] into the FIDO Virus_NFO conference.
]
A-V ] This virus has been forwarded to the following;
] Vesselin Bontchev, David M. Chess, Spencer Clark,
] Dmitry O. Gryaznov, Eugene V. Kaspersky, FRISK, Dr.
] Alan Solomon, Wolfgang Stiller, Frans Veldman, and
] Tarkan Yetiser.
Armored ] No.
Detected ] Yes. F-prot detects the first generation as possibly a
] variant of Desperado. However; F-Prot does not detect the
] second generation specimens.
Effects ] This virus deletes the following data files ANTI-VIR.DAT,
] CHKLIST.CPS, CHKLIST.MS, and MSAV.CHK
Encrypted ] Yes
Interrupts ] 21h
Marker ] On all infected host files except for COMMAND.COM, the
] seconds field of the time stamp, was updated to 24
] seconds.
Polymorphic ] No
Resident ] Yes
Size in RAM ] 2560 bytes (according to CHKDSK)
Stealthed ] Partially Stealthed. Page 10 does not temporarily
] disinfect infected host files when they are opened. The
] time and date stamps remain the same except for the
] seconds field mentioned earlier.
Text ] No text visible in the second generation of this virus.
Type ] Resident .COM and .EXE infector. The virus appends to the
] end of the infected host files.
Unusual ] This virus will repeatedly try to access write protected
] diskettes, but this virus does intercept the errors. The
] second generation of this virus refused to replicate on
] my test machine. I'm posting this because this virus may
] properly re-infect other systems.
This is only a "Preliminary" analysis, and may be incomplete.
Junkie virus originated in Sweden, and is classified as "Multipartite" since it
can infect the hard disk Master Boot Record, diskette boot sectors, and *.COM
files.
It can spread to an uninfected PC when a diskette, infected in another PC, is in the A: drive at boot-up, or when a *.COM file which was infected in another PC, is run.
Junkie writes its code to the first sector of the hard disk, where the Master Boot/Partition data are stored. Unlike most such viruses, it does not save or relocate the original data. It also writes the rest of its code to (cylinder&head 0, sectors 4 and 5).
Ordinarily, data are not lost from the hard disk, because the sectors which virus uses are not used by DOS. Some disks formatted in a non-standard manner may lose data, however. Junkie will be in memory after that whenever the PC is on, and infects floppy diskettes (not 360KB) by writing its code to the Boot sector (sector #0) of them.
It also writes its code to the last track of infected diskettes, and unlike some viruses which do so, does not protect its code by arbitrarily marking the sectors as if they were "bad."
Junkie can spread quickly, because it will infect diskettes on any access, even when just read, such as if the DIR command is used. In addition, it infects *.COM files as they are run or even if they're merely opened, such as during an anti-virus scanning process. It adds just over 1,000 bytes to infected *.COM files.
I spent some time recently getting rid of the JUNKIE.BOOT virus off my cousin's PC. I think if I had V214 of McAfee scan at the time it would have helped a lot. The only problem I had with scan was that I had to reboot the machine each time scan found and tried to remove the JUNKIE.BOOT virus from a diskette. Scan would find and remove the first detected virus and any following viruses found would be reported as "JUNKIE.BOOT+emr" and could not remove the virus. The virus would also be loaded into memory when first detected and hence needed to be rebooted.
I located the source where I got the virus from. It came from a game called "Quarter Pole" by Microleague. Each of the four (write protected) disks were infected.
I'm sure it must have been said many times before but please be sure to scan ANY new disks purchased before making use of them.
Well, as you can see, The Scanner is growing by leaps and bounds. Thanks to the wonderful folks that have contributed and taken time out of their busy scheduals to participate. To be honest with you, I had to stop here before this issue got too far out of hand. As this is being posted and distributed, I am already starting April's issue. Don't miss it!
My heartfelt thanks to the following people:
And most of all thank-you, the reader, for taking the time to read The Scanner. Some of you have contacted us and let us know how we are doing. Please, if you have the time, let us know what you think of The Scanner. Any suggestions or ideas will be looked at and seriously concidered. Until April take care. Remember, keep those AV programs busy!