A Pile of Junk?

Mike Lambert
Rochester Telephone Corporation

Well, Junkie came and went, and I guess I must have missed the boat. I took a look at the virus when I was first sent a copy and, getting bored, went on to another. Surely this was no big deal: no stealth, no special encryption (does anyone who is not 'hardcoding' polymorphic detection routines even care any more?), no trigger routine... the sort of virus which I receive by the gross every month.

All of a sudden there are warnings of Junkie on the public nets! To listen to Cyberspace, one would think Junkie was 'the mother of all viruses'! Somewhat chastened by what I was being told about Junkie, I took a look at it a second time to see if I had missed the point. I had not: Junkie is by no means a new wonder-virus. All that noise and it doesn't even infect a 360K floppy! This thing can be described in a single breath.

A Pressing Problem

The reasons for the virus' infamy are all too familiar. The story is that a Reflex Inc. representative found it in Ann Arbor, Michigan using DiskNet. It would appear that the virus was taken very seriously (by whom, I'm not too sure!). The press picked up the Reflex press release and ran with it, and the unknowing finally read about it in the newspapers and on the newswires. The rest is history.

Some may view some of the virus' techniques as new or innovative, but I see nothing revolutionary about them. If you missed this virus, it is nothing to worry about unless you are using a substandard product, rely wholly on scanners, or cannot restore a Master Boot Sector (MBS) and replace infected COM files. There is no attempt to hide the virus, and no destructive trigger routine.

In short, Junkie is a parasitic COM infector, dependent on the boot mechanism to establish residency to infect Boot Sectors and proliferate via COM files. The virus contains no stealth routines, is easy to spot, uses simple encryption, has no trigger, is incapable of advanced penetration techniques, and targets the TSR components of both CPAV (version 2.0) and MSAV (as shipped with MS-DOS 6.2).

Virus Operation

The infection routine used by the virus is simple, limping along, years later, in the footsteps of Tequila (the EXE multi-partite of days of old which 'introduced' multi-partite viruses). On COM execution, Junkie only drops the virus on drive 80h (see more below) and transfers control to the host. It does not go resident on COM execution (I use the term 'integrated' for those multi-partites which are equally infectious when loaded from files or a boot sector) so even elementary software write-protection is an absolute deterrent. Initial infection consists of dropping the virus loader in the real MBS code (16 words) and the virus body in sectors 4 and 5 (Head 0, Cylinder 0). The current Interrupt 13h vector in the interrupt vector table is used to make the call to carry out this write, which is why any software write-protection is effective. There is no check made as to whether boot sector infection has been successful.

At system startup, the virus code in the MBS loads the two additional sectors of virus code and transfers control to the virus decryptor. Once this operation is complete, the virus hooks Interrupt 13h for later floppy infections, and Interrupt 1Ch (the timer) in order to hook Interrupt 21h after DOS has loaded. The timer interrupt is flag-driven, and never unhooked from the system.

This flag allows one to enter the virus' timer tick interrupt handler easily, located at 9F40:01EA on a 640K system (on such a system, the memory-resident copy of the virus resides at 9F40:0000, and uses the 'standard' boot sector virus memory-stealing technique). When resident, the virus occupies 3K of memory. If CHKDSK is run on an infected machine, DOS returns 652,288 of base memory, infecting CHKDSK.COM in the process.

Other indicators of the virus being active in memory are that IO.SYS will use 9F40:0091 for disk services, and the Int 21h vector will point to near the top of memory, 9F40:0237.

Boot Sector Operation and Removal

The virus does not store a copy of the uninfected MBS, but opts to restore the 16 overwritten words of the loader routine with the original code just before returning control to the MBS. The original boot sector from both the fixed disk and any infected diskettes is not replaced on access, so there is no attempt at stealth. As a result, it is impossible to restore the original MBS by relocating a copy stored by the virus, or by allowing the virus' own stealth routine to restore the MBS itself.

In order to recover from the virus, one must either restore the real MBS from a backup copy or rewrite the MBS loader using the DOS command FDISK /MBR. Many anti-virus products also include a utility to restore such damage.

Memory-resident Operation

Interrupt 13h processing consists of trapping A: boot sector reads in order to infect 720K, 1.2MB, and 1.4MB (but not 360K) floppies. If an uninfected system is subsequently booted from such a diskette, the fixed disk is infected.

On 720K and 1.2MB diskettes (type F9h), the extra two sectors of the virus code are stored in sectors 8 and 9 of the last track (Head 1, Cylinder 79). This leaves a little extra space on 1.2MB floppies. On 1.44MB floppies, the last two sectors are used (Head 1, Cylinder 79, Sectors 17 and 18). Original boot sectors are not saved, and infected sectors are not protected and can be overwritten.

Interrupt 21h processing consists of trapping Load and Execute, File Open, and Extended Open. During infection, the CPAV and MSAV TSRs are disabled so the virus can infect files (even this is nothing new - many virus writers know how to do this).

The virus, encrypted with a simple XOR, adds between 1027 and 1041 bytes to COM files over 4K long. COM infection continues as files are opened or executed. The only validation of a COM host is by file extension, so EXE files renamed to COM files (within required size) can host the virus dropper but are destroyed during infection. No 'Are you there?' call is necessary, as the virus only becomes memory-resident when loaded from the boot sector.

A Fast Infector

An important note, which is applicable to a number of different multi-partite viruses, is that it is sometimes necessary to use the SYS command in order to disinfect an infected disk. The reason for this is simple.

It is possible that the operating system installed on the infected machine uses system files with a COM extension (for example, IBM's IBMBIO.COM v3.30). Although these files are suitable candidates for infection, in the normal course of viral operation they will not be infected, because they are 'opened' before DOS has set up its own Int 21h vector. This is a characteristic of the technique used to set the Interrupt 21h vector and holds true for all viruses using the timer tick in order to hook Int 21h.

However, when a disk is scanned with an anti-virus product which fails to detect the virus in memory, every eligible COM file on the disk will be infected. This 'infect on open' strategy (making the virus a 'fast infector'), was one of the points highlighted for special concern in much of the coverage of Junkie. Once again, this attribute is nothing new: the elderly 4K virus (Frodo), does a much more effective job of this, infecting COM and EXE files on Close.

This makes it vital that disk scanning only takes place after a scan of memory using the search string provided, or after booting the system from a clean, write-protected system disk. A good rule of thumb is never to rely on a scanner to check memory -- whenever possible, use a cold boot.

Conclusions

The principal lesson to be learnt from this virus is that one should treat popular press virus alerts with a large pinch of salt: Junkie is a long way from being the wonder virus which the press would have had us believe.

If this virus has a purpose, it may be to illustrate that the trailing edge is very rusty. If you can 'catch' this virus, you have no protection at all. If you cannot find this virus, it is time to change your anti-virus software vendor. If you cannot recover from this virus, take action before you face something which is a real threat.

Junkie

Aliases:

None known.

Type:

Multipartite.

Infection:

COM files, MBS of the fixed disk, and the boot sector of 720K, 1.2MB, and 1.44MB diskettes.

Self-recognition in Files:

The length of the file in paragraphs is checked.

Self-recognition on Disk:

The first jump of the MBS is checked, as well as the first word of the loader.

Self-recognition in Memory:

None necessary. The virus does not become memory-resident when an infected file is executed.

Hex Pattern:

Due to the short length of these patterns, they should be used with care.

Junkie-infected files:: BE?? ??B9 F401 2681
34?? ??46 46E2 F7??
Junkie-infected MBS:: FB8E C7B8 0202 BB00 7EB9 0400 BA80 0056

Intercepts:

Int 13h for diskette infection, Int 1Ch for hooking Int 21h after DOS has loaded, and Int 21h for file infection.

Trigger:

Disables the Central Point Anti-Virus and Microsoft Anti-Virus TSRs.

Removal:

Under clean system conditions, identify and replace infected files. Note the possibility of the system files IBMDOS.COM and IBMIO.COM becoming infected. Use the DOS command FDISK /MBR to remove the virus from the MBS of the fixed disk.

Virus Bulletin: Junkie / webmaster@virusbtn.com