Ground Control to Major Tom

Major.1644 is a memory-resident EXE file infector. When an infected file is executed on a PC, the virus decryptor receives control, and enters a convoluted loop which decrypts the rest of the virus.

Viruses use encryption to prevent scanners finding a fixed sequence of bytes to use for searching. This procedure does work as intended with Major.1644, but its decryption routine is quite lengthy and fixed, and can therefore be used as a search-string.

The Major Moves In

Once the virus code is decrypted, further examination screams out 'Virus': the first instruction after decryption is an 'Are you there?' call via Int 21h, AX=ABCDh.

The expected result of 1234h in the AX register will be returned only if a copy of the virus is already loaded. If so, the virus need do nothing further. The starting point of the host program is retrieved from the virus body, and control passes to that address, allowing the host to run as normal.

If the return value is other than 1234h, the virus must place itself in memory. Major.1644 does this by taking one of the segment pointers as initialized by DOS when loading the host program, and decrementing it. This allows the virus to examine the MCB associated with this segment.

The MCBs, or memory control blocks, are linked by a set of chained pointers in memory. The first byte of any MCB indicates whether or not this particular MCB is the last in the chain. The virus walks the chain until it reaches the last MCB: if it reaches the video memory segment before reaching the end of the MCB chain, it aborts the attempt to go resident. Once the end of the MCB chain has been found, the MCB is directly modified.

Major.1644 reduces the amount of memory which is associated with the last MCB by just over 29KB. When I first worked that figure out I had to check it - I cannot see any reason for reducing memory by this vast amount unless the programmer did not realise that the values stored in the MCBs are in paragraphs (multiples of 16 bytes).

Once the MCB is modified, the virus has made a fairly large hole in memory in which to reside. It then copies 1643 bytes (not 1644) of its own image to the new location in memory. The next task is to prepare to become resident and to hook the virus code into the system interrupts, which will allow the virus to gain control at appropriate times.

The virus first uses the undocumented but well-loved function to obtain what TSR programmers call the INDOS flag. This is a pointer which TSR programs can use to see at a later time whether or not it is safe to interrupt DOS. DOS maintains this flag and sets it to 1 when it is in an unstable state and does not want to be interrupted. Major.1644 calls Int 21h, AH=34h, which returns a pointer to the flag.

Interrupts 21h (DOS services) and 08h (System Timer) are then hooked by the virus. The original contents of both of these vectors are used to build far calls to the original routines for later use. The vectors are then amended to point to the virus handlers, at offsets 24Ah and 407h in the virus body respectively.

From that point on, the virus interrupt handlers are active, so all that is left for this transient copy of the virus to do is to allow the host to run, which it does. All other processing for the virus is controlled by the two interrupt handlers mentioned above.

Interrupt 21h (DOS Services)

When this handler is invoked, the virus checks the AX register. If it is set to ABCDh, Major recognises the call and simply sets AX to 1234h to indicate that it is in memory, and then returns. The only other function of interest to the virus is 4B00h (Load and Execute Program).

If the function is not of interest, the virus passes control via the far call it constructed at installation to the original DOS handler. There are therefore no stealth capabilities, and all increases in file size and changes in file content will be visible in the directory listing.

In the case of the 4B00h function, the handler will set about infecting the target file before allowing it to run as normal. Major.1644 next obtains and saves the file's attributes, then clears them, which allows read-only files to be infected. Following this, a critical error handler is installed, in an attempt to prevent those nasty DOS error messages which occur when DOS detects a hardware error (for example, write-protected disks).

Due to programmer error, this does not work as expected. Therefore, the tell-tale sign of a 'Write Protect' error occurs when using write-protected floppies on a PC which is infected with Major.1644.

Before this, however, the virus reads in the first 18h bytes from the target file. The virus is only interested in EXE files, and at this stage the file under examination is checked to ensure that the first two bytes are the EXE signature (4D5Ah).

If this test is passed, the virus checks to see if the file is already infected, examining an unused entry in the EXE header called the CHECKSUM field. If the file is infected, this field will contain the hexadecimal value DEADh.

If the file is uninfected, the file pointer is then moved to the end of the file and an encrypted copy of the virus, complete with decryption routine, is written out. The amended EXE header, containing the DEADh signature, is written back. The file's date, time and attributes are then restored. Finally, the critical error handler is unhooked and the new host - which is now infected - is allowed to run.

Interrupt 08h (Timer Tick)

The Int 08h handler will receive control eighteen times per second: this is a hardware interrupt which is used by the timer chip routines.

The virus handler begins, as do all good TSRs, by using a far call to service the original timer routine. Then Major.1644 retrieves a word from low memory - this again is part of the timer functionality. This word is incremented approximately once an hour by the real time clock.

The virus checks the current value: if it is not 2, the virus does nothing, and the handler processing is complete. This word will actually have a value of 2 so infrequently that I believe it is intended to allow the programmer to switch this routine on and off manually.

If the value 2 is found, the virus then checks its own internal flags, which would indicate if either of the virus handlers were already active. If any of these or the system INDOS flag are set, the virus cannot continue, and the handler will end its processing. Assuming all these flags are clear, the virus immediately sets its own internal flag to indicate that the Int 08h handler is now active and therefore prevents recursive entry to this part of the handler.

Before continuing, a new stack is allocated, and the critical error handler is installed as described above under the Int 21h handler.

The virus now enters program logic that can have no use or purpose for any PC other than the virus author's own. The virus looks for the presence of two files in the current drive, BBSV6\BBSAUDIT.DAT and BBSV6\BBSUSR.DAT. These file names correspond to the following text, visible in the virus after decryption:

The Major BBS Virus created by Major tom

If the relevant files do not exist, the interrupt handler's work is complete, and control of the PC is returned to the user. If the files are found, they appear to have a strict format, as the virus reads in a record count first and then processes the records in the file one at a time. For each record, Major.1644 attempts to match against the user names which are hard-coded in the virus. These names are Puppet, Image, Gnat, Minion, Cindy, and F'nor.

When the virus finds a record for a user with a username matching one of these strings, it makes a small modification to that record - it writes a '1' over the first byte.

Unfortunately, it has not been possible to figure out what effect this has - without access to the file format specifications of these particular files, which are part of any Major BBS version 6 setup, it's impossible.

[In spite of this, some educated guesses may be made. It is, for example, reasonable to assume that the virus is attempting to increase the access privileges of matching users in some way. Perhaps a '1' in that particular location in the record indicates that this user is a SysOp?

The theory would then be that the author, or any of his friends, could create a user on a BBS, and then upload an infected file to it. If the real SysOp tests the uploaded file on the same machine, it will (sometimes) change the access rights of the author's account to grant him full access to the whole board. Ed.]

Summary

This virus contains little which would set it aside from most others. It should be easily detected, even despite its inbuilt encryption, and infects easily and rapidly; therefore, in tandem with the fact that Major.1644 is loose in the wild, it must be considered a threat.

Major.1644

Aliases:

None known.

Type:

Resident EXE file infector.

Infection:

EXE type files.

Self-recognition:

Value DEADh in the EXE header checksum field.

Hex Pattern:

This pattern will locate the virus in files and in memory.
1E33 DB0E 8BC3 03C1 1F8B
D18B F38A 8730 008B D080

Intercepts:

Interrupt 21h DOS handler; Interrupt 08h Timer Tick.

Trigger:

None.

Removal:

Delete infected files and recover from a backup.

Virus Bulletin: Major.1644 / webmaster@virusbtn.com

© 1998 Virus Bulletin Ltd.