WinVir 14 -- Shattered Glass

James Beckett

Well, we've been waiting for it to happen for some time, and no-one in the trade is very surprised: we have now encountered the first Windows-aware virus. Why do I get all the easy jobs?

Proclaiming itself, rather prosaically, 'Virus For Windows v1.4', it is only barely describable as Windows-aware, but that may well be to its advantage. Hiding no destructive payload bar its own existence, WinVir14 (a convenient name for a lazy typist like me) spreads rapidly within the Microsoft Windows environment. When run by any method such as double-clicking on an EXE or PIF file in a File Manager window, an icon in the Program Manager, or issuing a 'Run' command, a whole directory of programs may be infected at once. However, it produces no output on the display, creates no windows of its own and does not interfere with any other windows operations. Thus it remains hidden with no obvious clues to its existence.

Who Needs Windows?

The new virus specifically infects Windows executables, rearranging the original host code to have itself executed first, as many normal DOS viruses do. However, it uses no Windows calls, only knowledge of the New Executable file format. The virus code relies only on standard MS-DOS services being provided.

The operation of Windows is itself built upon MS-DOS. Windows is not a complete operating system in itself, just an operating environment that takes over the user interface and multi-tasks user programs. Depending on your system capabilities it can give programs protection against disrupting each other (on a good day!), and programs written specially for Windows are designed to take account of the added Windows facilities (and constraints). Regardless of this, many of the features of DOS are still available to a running program. DOS continues to manage the file system, and Windows does just about everything else. Therefore all the virus actually needs to know in order to spread is the format of a Windows executable file.

Executable programs under standard DOS come in two forms, COM and EXE files. COM files are an old type maintained originally for backwards compatibility (the bane of the computer industry) with the CP/M operating system, and contain just 80n86 code and data, to a limit of 64KBytes. EXE files were introduced to add flexibility and to increase the maximum program size; they contain a special header section with about 40 bytes of system information, plus any amount of relocation information (typically a few bytes for a small program).

With the advent of Windows, running as it can in 386 Protected-mode, this is no longer enough, and a much larger header is defined, containing copious amounts of information to control how the program is loaded. Under Windows, several instances of a program (say, two copies of WRITE editing different files) may share the same program code in memory, and the header must give Windows instructions on how to attempt this without disastrous corruption.

This 'Segmented Executable' or 'New Executable' header is in addition to the normal DOS EXE header, and largely independent. If a Windows program is run from DOS, which does not recognise the new header, a stub program is run, which usually prints a message such as 'This program requires Microsoft Windows'. Only when run from within Windows is the new header examined, and the full application (or, as in this case, the virus) executed.

This header is not well documented -- even the Windows 3.0 Software Developers' Kit, with a chapter dedicated to Windows file formats, was strangely mute on the matter. Fortunately, it is described in the 3.1 SDK, and The DOS Encyclopedia (Microsoft Press) also has most of the details.

It was with misgiving that I finally placed a call to Microsoft Technical Support, but for once I actually managed to navigate the automated 'phone system and reached someone competent who sent me a faxful of useful information -- within the hour!

With over ten pages of 8-point printout of just the infected program's header information, analysis was then carried out using standard debugging tools, and the virus action pieced together.

Pure And Simple

The author of the virus is certainly a purist -- the DOS stub program does not get infected. If an infected program is run from the DOS prompt (even one started from within Windows) the virus will not get control and no files will be infected. Only when run directly from Windows will anything happen.

The virus uses direct infection -- going resident under Windows would require familiarity with Windows' memory management and clearly the virus authors haven't progressed that far yet. When an infected file is run, every Windows EXE file in the current directory will be infected.

An initial section of host code is copied beyond the end of the file, followed by a section of its data. (In protected mode these should be maintained separately). The virus code and data is then written over these two areas.

After infecting all en prise files in the current directory, it disinfects the program from which it was activated. This has the (presumably intended) effect that the average user will simply imagine that they mis-clicked on the filename or icon -- a very common thing to do -- and the next double-click will correctly execute the freshly cleaned program.

This has however another interesting (and useful) side-effect: if the virus-infected executable is run in a directory which contains no other EXE files, it will disinfect itself without infecting anything. As it is non-resident, removal is therefore trivial, as long as the virus can be trusted to disinfect itself perfectly under all circumstances.

The date and time of infected files are maintained, but the Read-Only flag is not masked off before accessing a file.

There are certain complications in Windows as regards which files are likely to be infected. Within DOS, the concept of the current directory is a very simple one, and 'CD' determines the directory upon which commands will act. Clicking on an icon in the Program Manager or on a name in the File Manager could result in a PIF file changing the current directory, or a program running from its own directory, or with the directory set to the default \WINDOWS. In the latter case, every Windows-supplied program has the chance to become infected (On my test machine, 10 of the 26 Windows 3.1 executables were infected).

Yet again, it seems that this has been written 'just to show it can be done'; there is no payload or trigger date, the virus exists only to spread.

Origins And Clues

The virus is short and fairly carefully written, making checks on necessary parts of the executable to ascertain infectibility. The routines in it are neatly laid out (certainly making analysis easier) unlike much other virus code which frequently looks very amateurish.

The string 'MK92' is to be found within the data part of the virus, not used as actual data -- perhaps initials and the date of writing?

Windows Detection Tools

Cries of vindication are likely to be heard from those who are against scanning under Windows, and Joe User may well take them at face value. It is arguable that converting a DOS program into a pretty Windows interface has no positive impact on virus detection, and a clean boot and scan from DOS is still sensibly recommended by those developing Windows based scanners as being the only secure way to check.

In Windows there is going to be much more potential for viruses to hide themselves and subvert the system -- this very simple virus is bound to be followed by more sophisticated ones, and anyone creating software to run from Windows had better be sure that it cannot be 'stealthed'.

Summary

We were expecting something rather more inspiring from the first Windows' virus to hit the streets, but we find that it is simply rolling out the old standard DOS infection methods. However, VB has been recieving reports for some time now that pirated copies of the Windows SDK are easy to obtain in Bulgaria, and it seems inevitable that Bulgarian virus writers will be exploring this new playground with glee. It is therefore likely that within the next twelve months we will see Windows viruses which are capable of taking full advantage of the multitude of new features offered by Windows.

The danger is that with several things now happening at once in a user's desktop environment, the extra activity of a virus is even more likely to go unnoticed as it writhes its way through the system.

WinVir 14

Alias:: None Known.
Type:: Non resident, Parasitic.
Infection:: EXE files in the new executable format.
Hex Pattern in Files:: A140 01E8 7201 BAA8 01B9 AE02 90E8 2F01 E852 01BA A801 B9AE
Removal:: Isolate infected file in a directory with no other files in it and execute.

Virus Bulletin: WinVir 14 / webmaster@virusbtn.com