3.1 Windows Technologies | Malicious Mobile Code: Virus Protection for Windows (OReilly Computer Security)


Team-Fly

	Malicious Mobile Code: Virus Protection for Windows By Roger A. Grimes
	Table of Contents

	Chapter 3. Windows Technologies

3.1 Windows Technologies

Microsoft Windows started out strictly as a shell menu to hide the roughness of DOS, but it is slowly lessening its reliance . Microsoft has two core Windows platforms: 9x and NT. Although they look alike, they are significantly different under the hood. For the purposes of this book, unless specifically separated, the 9x platform includes Windows ME, and NT includes Windows 2000. The next section explains the evolution of Windows and the different programming and security constructs each version uses.

Since 1996, it has been Microsoft's stated development path to converge the 9x platform's ease of use with the stability and security of NT's operating kernel. Every 9x release is supposed to be Microsoft's last, but the two OS platforms are different enough that migrating users was tougher than Microsoft originally bargained for. Although the 9x and NT platforms may look alike (the 9x interface was given to NT in version 4.0), underneath they are completely different animals. Programming for any of the Windows platforms is significantly harder than programming for the DOS world. For that reason, and the greater hardware requirements, the first Windows viruses didn't appear for years after the popular acceptance of Microsoft's new operating systems. Initially, some believed Windows had defeated computer viruses, but that wasn't the case.

Much of what Microsoft introduced in Windows 3.x is still used in the today's versions. During this next section, we will discuss the technologies and terms relevant to our discussion of malicious mobile code (for example, we won't talk about Plug and Play or the significance of the Start button). There will a bit of jumping around from topic to topic, but everything will fall into place when we see each Windows platform's booting process and its exploits in Chapter 4.

3.1.1 Windows APIs

Application Programming Interface (API) is the way a high-level language (e.g., C++, Visual Basic) interacts with a lower-level language or operating system. The Windows API is a core set of routines that contain the basic system calls needed to manipulate the Windows operating system and file subsystem. For instance, the WriteFile API function writes data to an open file and can be used by virus writers to infect host files. Windows APIs are stored inside of dynamic linking libraries (. DLL ) files installed with Windows. For instance, the WriteFile function is stored in the KERNEL32.DLL file.

3.1.1.1 Win32 API

The Windows 32-bit APIs used in Windows 9x and NT are called Win32 API . Windows 3.x was eventually given a partial set of emulated 32-bit APIs called Win32s , to allow application programmers to take advantage of some of the newer types of technologies. Although the Win32 API was created to allow an application to work across all 32-bit Windows versions, it is not identical between platforms. As examples, the API functions that allow a program to become a service and modify NTFS security permissions are only available under NT and 2000. In some cases, the API functions are named the same thing, but return different values or are called something different. Accordingly, depending on what a virus is trying to accomplish, and how it accomplishes it, it may or may not work on both 9x and NT environments. Virus names will be prepended with Win95, WinNT, or Win32 according to the types of calls and methods it employs. While a virus might use Windows 95 API calls (and thus be called Win95), it doesn't mean it can't function under another Windows platform. For example, the Win95.CIH virus can infect the NT platform, but its payload routine designed to corrupt the BIOS firmware does not work. A virus with Win32 functionality uses calls and routines available in two or more 32-bit Windows platforms.

3.1.1.2 32-bit access

Windows 3.x and 9x file and disk operations can be operated in 16-bit (real mode) or 32-bit modes (NT and 2000 can only run 32-bit drivers). Windows 9x will try to use 32-bit access whenever it can for performance and security reasons. Sixteen-bit access uses DOS and BIOS calls to read and write files. Because the newer versions of Windows run mostly 32-bit code, this means Windows has to switch the CPU in and out of Protected mode whenever a 16-bit access is needed. If Windows is prevented from running in 32-bit mode for file or disk access, a file called IOS.LOG will be created showing what device driver prevented the better access. Often the name of a virus infected file trying to interfere with disk operations can be found in this file.

3.1.2 Windows Booting

All Windows platforms go through a complex booting routine, different among platforms, but with some commonalities. First, every Windows boot begins with a text or non-GUI boot portion before Windows really begins to boot up. It is during this process that low-level hardware details are worked out, and enough system files are piled into memory to allow the larger Windows kernel to load. As Windows starts up, dozens of files are loaded into memory, device-drivers are loaded, the registry is checked, and information learned there used to continue the boot process (see Figure 3-1). Finally, Windows starts running programs, processes, and services defined in the different autostart areas of Windows. Chapter 3 will cover each boot routine in detail.

Figure 3-1. Generic Windows boot process

3.1.3 Windows Technologies Introduced with Windows 3.x

Some readers may be surprised to see how much Windows technology had its beginnings in Windows 3.x.

3.1.3.1 Text mode to GUI mode booting

All versions of Windows go through a transition from a text-based screen to GUI portion during the boot process. It's important to recognize the transition as it indicates where Windows is in the bootup process, and it will help troubleshooting later on. If you receive an error message during the booting process, recognizing what files are loading at that particular time will isolate the possible causes.

In Windows 3.x and Windows 9x, the text-to-GUI transition is pretty distinct and indicates the same place in the bootup process is occurring, loading real mode drivers. During the text portion, the background is black, the text is white, and displayed in 25 x 80 video mode. When Windows 9x loads the AUTOEXEC.BAT and CONFIG.SYS files, a Windows logo file is displayed. Don't be fooled, you can easily Alt Esc around the logo and see what is really going on.

In all versions of Windows, when you see the graphical screen load (not the logo screen), the Windows kernel files are loading and beginning to take control. NT has no real mode device drivers, so when you see the text portion of the boot process, NT is choosing the appropriate boot operating system to run, detecting hardware configurations, and beginning to load its kernel (in Windows 2000 a logo screen is displayed during the startup, just like Windows 9x). When you finally see the Windows desktop, but you don't yet have full use of your cursor, Windows is loading startup programs or services.

3.1.3.2 Virtual machines

The DOS operating system was created to let one user have one program running at once (referred to as real mode in the Windows world). Since Windows can run two or more DOS programs at once, a trick was needed. That trick is named the DOS Virtual Machine ( VM or DVM, or VDM in NT). Intel's 386 chip provided a way (called protected mode ) for separate memory areas (called virtual memory ) to emulate individual DOS machines (called virtual machines ). A DOS program running in a DVM thinks it's the only one and writes to memory as it normally would.

In Windows 3.x, each DVM shares the same startup settings (i.e., AUTOEXEC.BAT and CONFIG.SYS ), but can be modified by a Program Information file . Later versions of Windows allow each DVM to have unique real-mode settings. Virtual DOS Machines (VDM) use the same concept to achieve backward compatibility for DOS and 16-bit Windows' programs under NT. In Windows 9x, all 16-bit Windows applications share the same virtual machine. In NT 4.0 and beyond, each is given its own VDM (shown as a process called NTVDM in NT's Task Manager ). Each VDM can have its own copies of CONFIG.SYS and AUTOEXEC.BAT stored as CONFIG.NT and AUTOEXEC.NT .

DOS Virtual Machines can be started by running COMMAND.COM in Windows 9x and CMD.EXE in Windows NT. Windows NT also contains COMMAND.COM for backwards compatibility.

3.1.3.3 Program information files

Program Information files (PIFs) control the environmental parameters doled out to DOS applications running in each DVM. Using PIFEDIT.EXE , PIF files can be customized for the particular needs of each DOS application (amount and type of memory, task slice settings, window size , etc.) to make them behave better. If a customized .PIF file is not declared for a particular DOS program, then Windows uses the settings in _DEFAULT.PIF . Native Windows applications do not need PIF files. Some Trojans and worms use .PIF files to help hide their illicit activity.

3.1.3.4 Virtual memory and swap files

Windows will create temporary or permanent (in the case of 9x and NT) swap files on the hard disk to use as temporary memory and is called virtual memory. This has the effect of allowing Windows to use more runtime memory than is physically installed in a system, and it can improve performance. Often when a computer virus attempts to control file I/O operations it will interfere with swap file mechanics. This can cause bootup errors or overall system slowness.

3.1.3.5 NE executable

Under DOS, file executables were either COMs or EXEs. Windows executables did away with the small COM file, and extended the EXE structure with the new 16-bit NE (New Executable) format. The NE file header is significantly more complex than its DOS counterpart (although it does contain a DOS header section). NE files will run under Windows 9x and NT systems. Some early Windows viruses, like WinVir, simply wrote to the DOS header portion of NE files and really didn't spread well.

In order for a virus to cleanly infect a Windows 3.x .EXE file, it must be able to recognize and manipulate the more intricate structure of the NE file. It is this new file type, which early on had very little publicly available documentation, that kept virus writers at bay for two years. DOS viruses, which do not recognize NE files, often corrupt them and leave them unable to run. For years, if a Windows system got infected, the number one symptom was Windows would not load, or the infected program would crash on startup. DOS file viruses do not spread well in Windows. Boot viruses, which run in the real mode before the Windows GUI portion begins to load, have a better chance of replicating.

Code Bits

Different central processing units (CPUs) have different size data paths (bus) and instruction sets. For instance, Intel's 386DX chip has a 32-bit structure while the Pentium family has a 64-bit data and memory bus. Intel's 80286 chip introduced an instruction set and memory features that allowed multitasking to occur. In order for software to take advantage of a particular chip instruction set and the faster data buses, the program must be developed with programming tools that take advantage of a particular chip's feature set. Hence, whenever the Windows world talks about 16-bit applications, they are referring to applications developed to run on Windows 3.x platforms. Windows 9x and NT can run 16-bit applications, but they are treated differently than their native 32-bit counterparts. Windows 9x is a mixture of 16-bit and 32-bit code, whereas, NT is pure 32-bit programming.

3.1.3.6 Core Windows files

Core Windows 3.x files are KERNEL.EXE , USER.EXE , and GDI.EXE . They are loaded each time Windows starts. KERNEL.EXE provides real-mode memory management, and is assisted by WINOLDAP.MOD to run DOS applications. KRNL286.EXE is used in Standard mode, and KRNL386.EXE is used in the default Enhanced mode . USER.EXE is the Windows executable that handles all the software routines interfacing with the user, including windows placement, icons, and input from the keyboard and mouse. GDI.EXE stands for Graphic Device Interface , and is responsible for displaying graphics on the screen. These files are also in later versions of Windows (with updated counterparts), and as such, are frequent targets of virus attacks. Most Windows antivirus programs automatically scan these core files during boot up.

3.1.3.7 Dynamic linking libraries

Dynamic linking libraries (DLLs) are Windows executable files meant to be shared by one or more Windows programs. Microsoft includes dozens of these files in each installation of Windows and application programmers can use the functionality of the default DLLs within their products. Dynamic linking libraries usually have a .DLL extension, but can have .EXE or some other predefined extension. GDI.EXE and USER.EXE are examples of .DLLs with .EXE extensions. When you hear .DLL, just think Windows executable. Windows viruses can infect .DLL files and use them to spread.

3.1.3.8 Processes and services

A process is a single running program with all the .DLL and support files it uses. Each process has a unique Process ID (PID) that uniquely identifies it (for the current session only) to Windows. In NT, you can see a list of processes and their related PIDs in the Task Manager. Many NT utilities, which allow you to manipulate processes, require that you use the process's PID instead of its name.

Any Windows program can register itself as a service and receive special treatment, such as being automatically loaded each time Windows is started. Windows uses dozens of them just to maintain its own functionality (for example, DHCP, EventLog, and Print Spooler). Unlike programs started after a user logs on (called Interactive ), a service runs under a special context with the full rights of the operating system. Services are not stopped when a user logs off the system, unless a complete system shutdown is initiated. In Windows 9x, processes registered as a service remain hidden from the task list. Computer viruses and other forms of rogue code want to be registered as a service, and can do so by using an API in KERNEL32.DLL called RegisterServiceProcess . This registers the program as a service and sets it to automatically start under the HKLM\System\CurrentControlSet\Services key. In Windows NT, any program listed in HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\System is trusted to run in the SYSTEM context.

Any application, including rogue code, can find out what other programs and processes are running on the local system at a particular point in time. This process, called enumeration , must be called through APIs ( EnumProcesses( ) in NT). Viruses often use it to detect if a particular antivirus program is running, or to hide runtime error messages that pop up. Some malicious program files can prevent themselves from appearing as a process by attaching themselves to an already running process. The Back Orifice 2000 Trojan uses this technique when going stealth.

3.1.3.9 Initialization files

Windows 3.x introduced the SYSTEM.INI and WIN.INI files, which can be edited by using any DOS ASCII editor. My personal favorite editor, SYSEDIT.EXE , is excellent for bringing up startup files. Initialization files, or INI (pronounced "any" or "eye and eye") files, contain commands that affect the startup and operation of Windows or applications. Most of the command statements located in SYSTEM.INI refer to software interactions with hardware.

After the core Windows files are loaded, the PC reads the SYSTEM.INI file to find out which device drivers to load. Windows 3.x and 9x device drivers are called virtual device drivers (VxDs) . Most hardware devices on a 9x Windows PC have a corresponding VxD file, including the motherboard, programmable interrupt controller, keyboard, serial ports, and monitor. VxDs contain the coding to interface Windows to the particular hardware device. VxDs are loaded with DEVICE= statements (just like CONFIG.SYS ) under the [386Enh] section of the SYSTEM.INI file. Viruses often install themselves as drivers in 32-bit versions of Windows.

Windows NT and 2000 use 32-bit .SYS driver files, and do not use VxDs.

3.1.3.10 SYSTEM.INI

The [boot] section of SYSTEM.INI contains a SHELL= command that defines what Windows GUI interface to load. By default, in Windows 3.x, it is the Program Manager shell , or PROGMAN.EXE . In today's versions, it is EXPLORER.EXE , or Windows Explorer . Don't confused EXPLORER.EXE with Internet Explorer (IEXPLORE.EXE). Viruses (and to a larger extent, Trojans) will often load themselves into memory each time Windows starts by modifying the SHELL= statement. The current screensaver file, which can be replaced by a malicious program, can be found in SYSTEM.INI after the SCRNSAVE.EXE= statement. NT loads the operating system shell from the registry key HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell instead of from the SYSTEM.INI file.

3.1.3.11 WIN.INI

The second initialization file Windows looks for during startup is WIN.INI . The overall look and feel of the Windows environment is controlled here. For our purposes, the [windows] sections of the WIN.INI file concern us most. Programs started with the LOAD= or RUN= commands will automatically be executed when Windows starts. Programs started with the LOAD= statement will be run in a minimized state, while programs executed by RUN= commands are run in a normal window. Viruses and Trojans can modify these statements to take control whenever Windows starts. In rough terms, the SYSTEM.INI file is analogous to the DOS CONFIG.SYS file, and WIN.INI is related to the DOS AUTOEXEC.BAT .

3.1.3.12 WININIT.INI

Another INI file rarely talked about is WININIT.INI , which is used by Windows, and Windows programs, to install and uninstall programs. It can contain commands that copy or delete files. If placed in the Windows folder, the instructions in WININIT.INI will be executed upon the first reboot. Once the instructions are followed, the file is usually deleted. At least a few MMC programs, like W95.MTX, W32.Kriz, and VBS.Kidarcade, use it to install themselves on Windows machines.

3.1.3.13 Startup folder

All versions of Windows have had a folder, or folders, where programs can be placed to automatically run upon startup. In Windows 3.1, it was known as the Startup group . Programs can be placed there by users or by installing programs. Windows 9.x startup programs are typically found in the C:\Windows\Start Menu\Programs\Startup folder and in C:\Winnt\Profiles\All Users\Start Menu\Programs\Startup or C:\Winnt\All Users\Start Menu\Programs\Startup or C:\Winnt\Profiles\< userid >\Start Menu\Programs\ Startup in NT. The startup programs can be easily found from the menu Start Programs Startup in all Windows 9x and NT versions. Startup programs can be bypassed during the Windows boot process by holding down the right Shift key prior to the programs loading or booting in Safe mode. Malicious mobile code will often install itself in the startup folders.

3.1.3.14 Registration database

Although most Windows troubleshooters groan at the word Registry , it was introduced by Microsoft to make our lives easier. Or at least that is the theory. The registry is a complicated Windows database used to store configuration information for Windows operations and application functionality, instead of the separate .INI files. Just about every piece of Windows software you can install modifies the registry and adds its own values and keys. Every user who logs on to a Windows PC generates personalized registry information that can be restored whenever they logon again. Windows-aware MMC also uses the registry to automate its dirty work.

Introduced in Windows 3.x, the registry file ( REG.DAT ) initially started out as a way to store OLE information. Windows 9x stores the registry in the WINDOWS folder in two hidden files called SYSTEM.DAT and USER.DAT . NT stores the registry in \WINNT\SYSTEM32\CONFIG directory. Each time Windows successfully boots, a copy of the registry is saved to disk. Those copies can be used to restore the registry to a previous state if it becomes corrupted.

The registry can be manipulated using the REGEDIT.EXE command in all versions of Windows ( REGEDT32.EXE is also included in NT) and contains up to six hives (starting with 9x versions):

HKEY_CLASSES_ROOT (or HKCR)
HKEY_CURRENT_USER (or HKCU)
HKEY_LOCAL_MACHINE (or HKLM)
HKEY_USERS (or HKU)
HKEY_CURRENT_CONFIG (or HKCC)
HKEY_DYN_DATA (or HKDD).

Each hive contains a substructure somewhat equivalent to subdirectories. Each of these substructures eventually gets broken down to its lowest structure, called a key . Each key has a value . Because hives frequently contain shortcuts to locations in other hives, changing the value in one key will often change the value set in another.

Backing Up the Registry

Microsoft intended all registry manipulations to occur within applications or by using the Control Panel applet. However, as any serious Windows user can tell you, it is impossible to troubleshoot and investigate Windows without directly viewing and manipulating the registry using a registry editor. Before changing the registry be sure to back it up. One small mistake can make your PC unbootable. Although there are several better registry backup programs, both Registry Editors contain an Export feature (Registry Export Registry File) that works nicely . The NT Resource Kit contains a nice utility called REGBACK.EXE , which performs nicely. NT 2000 has a Backup System State Data feature and we will cover it in Section 4.8 of Chapter 4.

HKCR contains file association information, and ActiveX configuration information. Each ActiveX object (discussed in detail in Chapter 11) registers itself by name and has a unique class ID (CLSID). HKCU points to branch section of the HKU hive with personal settings for each logged in user. HKDD (or HKPD in Windows NT) contains system performance information. HKCC is a shortcut key to hardware information stored in HKLM.

The hive most malicious mobile code manipulates is HKLM. It contains information about hardware and software specific to the particular PC. Information stored here is shared by all users. Malicious mobile code loves to load into memory from the HKLM (and sometimes, HKCU) startup keys. If placed in the appropriate keys, the registry will execute the malicious mobile code each time Windows starts. The following keys, in order, will automatically load programs:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce(9x and ME only)
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices (9x and ME only)
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\Userinit (NT and 2000 only)
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell(NT and 2000 only)

Depending on the version of Windows, the keys listed above may or may not appear. And even if they appear they may have no programs listed to run. The Once keys are usually blank because they only contain values used during software installation and uninstall routines that are automatically run after a reboot. The first two registry keys load services and run first, regardless of whether a user logs on. The other keys will run every time a new user logs in. Memorizing these registry keys will help you troubleshoot possible malicious code problems quicker.

Two related keys you might see, Run- and RunServices- are created by Windows ME's MSCONFIG.EXE , when startup programs are disabled. MSCONFIG.EXE stores the disable programs in the new keys so that they can be displayed during its use as manually disabled, and to allow enabling again. MSCONFIG.EXE is great for troubleshooting startup problems.

In Windows 3.x and 9x, anyone can modify the registry. With Windows NT, system administrators can limit who and what can view and edit registry keys to a certain extent. Using REGEDT32.EXE , administrators can choose Security Permissions to lock down different parts of the registry. NT also allows the remote editing of registry databases. Malicious mobile code uses Windows APIs to modify the registry and to create new keys.

The registry is a pretty crucial piece of Windows. Luckily, Windows 9x and NT make a backup copy, sometimes several copies, that can be restored during a disaster recovery operation. Windows 95 makes one copy of the registry files as SYSTEM.DA0 and USER.DA0 . Windows 98 makes up to five backup copies located in the \Windows\Sysbckup folder. They are named RB000.CAB , RB001.CAB , and so on. Windows updates the backup copies of the registry each time it notes a successful full boot of Windows (Windows 98 updates the registry copies a maximum of once per day). NT stores a backup copy known as Last Known Good after every successful logon. Unfortunately, what Windows thinks is a successful boot or logon and what we do are two different things. I've seen all good copies of the registry overwritten while a user continues to reboot their machine several times in the process of troubleshooting a problem.

3.1.3.15 File type associations

All versions of Windows use the registry to keep track of which filename extensions refer to which applications. Only one application will automatically respond using Windows Explorer to manipulate a particular file extension. Which application Windows loads for a particular file type can depend on what you plan to do with it (e.g., opening, editing, printing). For example, in Windows Explorer, choosing a file with a .VBS extension will run different programs depending on the mouse action. Double-clicking the file to run it will bring up the Windows Scripting Host to execute the Visual Basic scripting commands, while right-clicking and choosing Print, will use the NotePad program to print it.

Figure 3-2. Folder associations displayed within Windows Explorer

You can view and modify which file extensions are associated with a particular program and action inside Windows Explorer. In Windows 9x, start Windows Explorer and choose View Folder Options File Types (see Figure 3-2). You can then select a particular file extension and investigate its related settings. In NT, choose View Options File Types. In Windows 2000, choose Tools Folder Options View.

Unfortunately, this method of using extensions as the only way to associate particular files with a single particular program has many weaknesses. First, it is easy for one Windows application to make itself the default startup program for every file with a particular extension, when often the user intended no change. Second, simply renaming a file extension can make Windows unable to find the corresponding application. Renaming BUDGET.XLS to BUDGET.XLS.JAN will prevent Windows Explorer from automatically loading MS Excel to manipulate the workbook. Lastly, since the extension must be unique for every application, this prevents two applications from sharing the same extension. Thus, WordPerfect must use .WPD instead of the more appropriately named .DOC .

3.1.3.16 Hidden file extensions

Windows, by default, hides many previously registered file extensions. This fact is often exploited by malicious code writers and should be disabled. For example, a file called HOTBABE.JPG could really be HOTBABE.JPG.EXE . Or README.TXT can really be README.TXT.PIF . .PIF files can be used like a DOS batch file to manipulate a system. There are even situations (scrap files, for example) where files can force Windows, using the NeverShowExt registry key, to hide their true extension even if the hiding file extension option of Windows is turned off. See the prevention section later for details on how to disable. You can always choose to look at a file's properties (Right-click Properties) and the true filename will be revealed.

3.1.3.17 File types that can hurt

DOS only had three file types that could be used by malicious code developers: .EXE , .COM , and .BAT . Of these, only .EXE is used by Windows executable file viruses. Unfortunately, in Windows not only are executables possible coding vehicles, but also any other file type that can use or direct file I/O operations. And that opens up a lot of ground.

Table 3-1 lists the file types I know that can be used by malicious programmers to attack your PC. This list is by no means complete, and more are soon to be added. A few of these file types have not been exploited, yet they can be. With the exception of pure datafiles, most other file types have the ability to be used in a malicious attack. And even pure datafiles are not always safe. Recently it was discovered that Joint Photographic Experts Group (JPEG) image compression files contain an unchecked two-byte data area that can be used to cause buffer overflows in Netscape.

Table 3-1. Common file extensions

File extension	Description/Notes
ADP, ADE	MS Access Data Project, Project Extension. Introduced in Access 2000, they are used to directly link users into an SQL database. Can be used by an MS Access macro virus.
ASX	Windows Media Player Active Stream Redirector files can initiate a buffer overflow condition.
BAS	Visual Basic Class module
BAT	DOS batch file
CAB	Microsoft Cabinet Archive file. Used for ActiveX component downloading and for installing files. CAB files can contain statements that automatically execute program files upon opening. Covered in Chapter 11.
CHM	Compiled HTML Help file. Covered in Chapter 8.
CMD	Windows NT command script. Basically a .BAT file run by CMD.EXE in NT.
CPL	Control Panel applet program. Applications can be written and executed using this extension.
CRT	Security Certificate. Invalid or corrupt security certificates can be passed with this extension.
COM, EXE, OVL	Executable program files, and overlay file.
CSC	Corel Script file. A few viruses have been written to infect Corel applications.
DOC, DOT	MS Word document, template. Covered in Chapter 5.
DUN	Microsoft Dial-up Networking file. Can be used to initiate unintended long distance or fee telephone calls.
HLP	Windows Help file. Several malicious programs, including W95.Babylonia, masquerade as help files. When opened, help file viruses and Trojans exploit a bug with the WINHELP.EXE interpreter. The Trojan file can create, delete, and modify system files.
HTA	HTML application. HTML programs meant to be run on the local system. HTA programs use WSCRIPT.EXE to do their dirty work and have full access to the system.
HTM, HTML	Hypertext Markup Language script files. A few HTML viruses have been written, but it is usually the more comprehensive scripting language commands (e.g., VBScript, JavaScript) contained inside that do the real damage. HTML files can be used to direct your browser to a malicious web site.
INF	Setup Information file. Used by Windows to install programs and hardware. The Vxer virus uses INF files to replicate, eventually overwriting any .INF file and destroying Windows installation functionality. Not a big threat so far.
LNK	Windows shortcut file. Can be used to run a malicious program or batch file.
INS, ISP	Internet Communication setting
JAV, JAVA	Java applets. Covered in detail in a Chapter 10.
JS, JSE	JavaScript file, JavaScript Encoded Script file. Active scripting language files interpreted by WSCRIPT.EXE . Covered in more detail in Chapter 9.
MCS	Microsoft Common Console document used to save settings in Microsoft Console.
MDB, MDE	MS Access database, MS Access application. Several MS Access macro viruses use these file types to spread. Covered in Chapter 5.
MSI, MSP	Microsoft Installer Package, Installer Patch. Invokes the Windows Installer service, smooths software installations. Can be exploited by a malicious code writer.
MST	Visual Test Source file
OCX	ActiveX control. Covered in Chapter 11.
PCD	Photo CD image.
PDF	Adobe Acrobat Reader document. Popular document type on the Internet. Adobe Acrobat Reader ActiveX object has been found to be susceptible to buffer overflow attacks. Covered in Chapter 11.
PIF	DOS Program Information file. Can be used as a batch file to execute malicious programs, malicious command sequences, or to hide malicious code execution.
REG	Registry Entry file. Can be used to modify the registry so that a malicious command is executed during startup, or to help install a new malicious program.
SCR	Windows Screensaver file. Several Trojan files claiming to be screensavers have been implemented.
SHS, SHB	Shell Scrap object file. Scrap objects are archive files that can contain almost anything else, including malicious programs. If opened, Windows will automatically unpack the file into its various components and execute. Several email Trojans were successful at using SHS files. They are especially popular with malicious code writers because they hide the archived file's true file extension. Covered in Chapter 11.
SYS	Windows executable file, usually used as a device driver.
URL	Internet shortcut file pointing to a resource identified by a URL. Clicking on a untrusted URL can take a user a malicious web site or begin downloading malicious content.
VCF	VCard file used between mail programs to exchange address book information. Outlook is susceptible to buffer overflows from this file type.
VXD	Windows virtual device driver.
VB, VBE, VBS	Visual Basic Script file, VBScript Encoded Script file. One of the most popular file types to launch a malicious code attack with. Usually associated with WSCRIPT.EXE in Windows Explorer or CSCRIPT.EXE in a DOS window. Covered in Chapter 9 and Chapter 12.
VSD, VST	Visio Data file, Visio Template file. A macro virus has been written that infects Visio files.
XLS, XLA, XLM	MS Excel workbook file, Excel Add-in file, Excel 4.0 Macro file. All have had macro viruses written for them. Covered in Chapter 5.
WMD, WMZ	Windows Media Download file, Windows Media Player Skin. Malicious programs can be hidden within Windows Media Player files and skins.
WSC,WCF, WSH	Windows Script Component, Windows Script file. Scripting files interpreted by Windows Scripting Host ( WSCRIPT.EXE ). Covered in Chapter 12.

The important thing to remember is that no untrusted file that is capable of causing malicious damage should ever be executed or opened without the appropriate precautions .

3.1.3.18 Resource sharing

All versions of Windows since Windows for Workgroup (WFW) have the ability to share files and printers. The versions differ with the level of security granularity that can be applied toward a resource or resource user. A Windows user can share their local hard drive with other users, who then can map a new drive letter (e.g., M) to the shared drive. Shares can be set up to access whole hard drives, CD-ROM drives , individual subdirectories, or even individual files. When a drive is shared, the user can choose who should access the new share, what permissions are assigned, and whether or not a password is needed to access it. Windows shares are advertised to a network using TCP/IP ports 137, 138, and 139; this is described in more detail in Chapter 6.

NT has default system shares (e.g., C$, D$, etc.) that can be accessed across a network with the appropriate logon information.

Resource sharing is largely accomplished using the Windows NetBIOS (Network Basic Input/Output System) protocol. Not developed by Microsoft, NetBIOS was created in the early 1980s for IBM's SNA network topology. The standard frame type associated with NetBIOS is called NetBeui (or NetBIOS Extended User Interface ). For that reason, people often say one when meaning the other and vice-versa. Today, NetBIOS is commonly run over TCP/IP (NBT) on most Windows networks.

NetBIOS allows Windows machines and resources to be identified by a 16-character name (actually the 16 ^th character is reserved by Microsoft for identifying different service types). NetBIOS machines constantly advertise themselves to each other and each participating node builds a database to associate names with logical or IP addresses. Because NetBIOS was never intended to be used outside of the LAN arena, Microsoft invented WINS (Windows Internet Name Service) to share NetBIOS names through routers. Hackers and worms can search for the existence of NetBIOS port numbers and then begin trying to access shares. If the shares are not password protected, the process is not all that difficult to do.

Viruses and rogue programs can easily exploit resource sharing to manipulate files not located on the local machine and use those shares as a quick way to spread. Almost always when a local program is executed (including malicious code), the program has full access to anything the logged in user has access to. If the user can delete and modify files located in a particular directory or drive, so can malicious code. Most viruses don't care whether the file host they are going to modify is located on the local C drive, or a networked drive, like M or Z. Directory services, like Microsoft's Active Directory or Novell's Netware Directory Service , can allow malicious code to spread anywhere the logged on user can access. Sometimes the malicious code has more access.

Microsoft's Server Message Block (SMB) protocol is beginning to replace NetBIOS entirely as a way to request files and services over the TCP/IP protocol and Internet on a Windows machine. MMC will probably begin to exploit SMB holes in the future.

3.1.4 Windows 3.x Startup Sequence

Each version of Windows has a different way of executing and a different set of files to execute in order to take control. Because these files are executed during each boot, they are often the first ones to get infected (or corrupted). The following list describes the bootup steps of a Windows 3.x PC running on a 386 with network services.

DOS boots normally and loads real-mode drivers and programs from CONFIG.SYS , COMMAND.COM , and AUTOEXEC.BAT .
User or AUTOEXEC.BAT runs WIN.COM , which starts WIN386.EXE , the Windows 386 Enhanced mode system loader.
Virtual Memory Manager (VMM) loads, Windows opens SYSTEM.INI file.
All VxDs are loaded, including network support files (e.g., VNETSUP.386 , VREDIR.386 , etc.).
Core Windows files are loaded: KRNL386.EXE , USER.EXE , and GDI.EXE .
KRNL386.EXE loads driver files ( .DRV ) and additional support files (e.g., fonts) listed in SYSTEM.INI . Additional Windows support files are loaded.
KRNL386.EXE executes the shell program listed by the SHELL= statement in the [boot] section of the SYSTEM.INI .
Lastly, programs defined by the LOAD= and RUN= statements of the WIN.INI file are loaded along with software listed in the Startup group.

3.1.5 New Technologies in Windows 9x

Windows 95 is a great example of going forward and backward at the same time.

3.1.5.1 Old carryovers

Windows 9x's DOS support is perhaps better than Windows 3.x's, while at the same time it supports both 16- and 32-bit code. DOS is still a requirement of Microsoft's 9x platform (MS-DOS 7.0 is installed with Windows 95 to the C:\WINDOWS\COMMAND subdirectory) and is loaded prior to the GUI portion loading. More importantly, the disk storage system is managed by the DOS component, which controls files and disk partitioning. Long filename support is supported alongside of DOS's 8.3 filenaming convention using Windows 95's Virtual File Allocation Table (VFAT).

The traditional DOS boot files, IO.SYS and MSDOS.SYS , share nothing in common with their earlier predecessors but the names. In Windows 9x, they take on a whole new functionality as device-loading programs. For example, IO.SYS will load HIMEM.SYS automatically for extended memory support. This explains why you will see HIMEM.SYS load when you single step a Windows 9x bootup when HIMEM.SYS isn't listed in the CONFIG.SYS file. MSDOS.SYS , placed in the root directory with read-only, system, and hidden attributes enabled, is a user-editable text file. It contains commands to customize the boot process and other operating characteristics of Windows 9x (see Microsoft KnowledgeBase Article Q118579 ).

Real-mode DOS device drivers are loaded in CONFIG.SYS and AUTOEXEC.BAT files before the dynamic 32-bit VxDs loaded with Windows. This is done for 16-bit compatibility, and wherever you can, you should minimize what programs and real-mode drivers are loaded before Windows. VxDs are loaded in extended memory freeing up more conventional memory for DOS applications. Real-mode drivers and programs are loaded in every DOS VM started, although NT is a bit more customizable than Windows 9x.

Windows operating systems have started decreasing their dependency on .INI files to startup. However, on 9x systems, initialization files are still used to load device drivers, for 16-bit support, and for startup commands ( LOAD= , RUN= ,and SHELL= ) . Microsoft wants programs and devices to place configuration details in the registry.

3.1.5.2 Dynamic VxDs

Windows 3.0 introduced the concept of virtual device drivers (VxDs), but they were static entries loaded when Windows starts and they don't unload until Windows is shutdown or exited. Windows 3.1 introduced dynamic VxDs , which can be started anytime a program or device needs them and removed from memory when not needed. Windows 95 was really the first operating system to use dynamic loading VxDs as a default. VMM32.VXD is a Windows 9x archive file with many common static VxDs inside. During Windows startup, dynamic VxDs found in the C:\WINDOWS\SYSTEM\VMM32 folder are compared against VxDs found inside VMM32.VXD . Matches result in the newer dynamic files being loaded instead. Virus and Trojan writers often install their creations as VxD files, but they don't work on Windows NT and 2000 because VxDs are not supported.

3.1.5.3 WINSTART.BAT and DOSSTART.BAT

WINSTART.BAT is a batch file that can be located in \WINDOWS (versions 9x and 3.x). The DOSMGR.VxD will run this batch file, if present, during the Windows start routine. In it, Windows program files can be loaded. Some malicious programs will hide themselves in this batch file. Alternately, if a file called DOSSTART.BAT is present, it will be analyzed and its program instructions will be executed if you exit the Windows GUI to a DVM (not in Windows 3.x versions). Often during installation, Windows 9x will move real-mode drivers, such as CD-ROM executables, to the DOSSTART.BAT file. Exiting from MS-DOS mode, back into the GUI, gives WINSTART.BAT another opportunity to run.

There is a batch file virus called WINSTART that places itself in the WINSTART.BAT file in order to spread. Although it was never widespread, it was successfully dropping another virus file called Q.COM and executing it.

3.1.5.4 Portable executables

Starting with Windows NT, Microsoft introduced the 32-bit Portable Executable (PE) file format. It can be used as executable binaries, .DLL s, .VxD s, and program files. One of the notable features of the PE format was a header indicator that specifies what type of CPU (386, 486, 586, Mips, Alpha, IA64, etc.) needs to be present in order to run. PE files, like any Windows executable program file, begins with the letters MZ or ZM. They can also include many different code segments, with visible text names, like .data , .text , and .rdata . Windows viruses will often add a .reloc section to an infected host to manipulate the contents, and its presence in a file might indicate an infection. Again, just as the NE executable file format had frustrated virus writers, so too did the PE format. Sixteen-bit NE files and 32-bit PE files will both run under Windows 9x, NT, and in some cases, Windows 3.x machines with Win32s installed.

3.1.5.5 Password files

In Windows 9x, logon passwords are stored in files (in the \WINDOWS directory) with the name of the logon name and with the extension of .PWL . Thus, my password file could be called RGRIMES.PWL . Although the password is encrypted, albeit with a basic encryption routine, deleting the associated .PWL file allows the user's password to be deleted. I mention it here because the appearance of unknown .PWL files is often a sign of malicious mischief. NT uses a much more secure method of storing security information and it will be covered shortly.

3.1.5.6 Integration of browser and web-based content

With Windows 9x, Microsoft began to integrate the functionality of the browser into the operating system. The browser can manipulate local and remote files, and sometimes it is hard to tell whether the file you are working on is located in China, or on your C drive. Microsoft's email client, Outlook , is so tightly integrated with the browser that security for one controls the other. Executing Internet content, now called Active Content by Microsoft, is often as simple as double-clicking the file. More and more, you don't even have to click. Even the desktop can be viewed as a web page (Active Desktop) , and it is quite the resource hog. Just about every Microsoft application is written to accept and create Internet-based content. If not for Microsoft's historic antitrust case, the already seemingly thin line between the end-user GUI and the Internet would have been completely erased.

3.1.5.7 Safe mode

If Windows 9x detects a problem during bootup, it will reboot in a diminished state. Safe mode , which can be manually initiated in Windows 9x or 2000 by holding down the F5 or F8 keys during bootup, loads a bare-bones system configuration to aid in troubleshooting. Safe mode will bypass the CONFIG.SYS and AUTOEXEC.BAT files, and load minimal device drivers (such as standard VGA display). Loading in a minimized state increases the odds that Windows will boot, and allows troubleshooters to fix the problem with a minimal amount of interference from the operating system or applications.

3.1.5.8 Hard drive file storage schemes

The file allocation table (FAT) is placed on the beginning of DOS and Windows 3.x hard drives. It is an address book that keeps track of what files are placed where. Often if a virus or Trojan wants to trash a hard drive, all they really do is corrupt the FAT area. The FAT disk system is still used on today's floppy disks, including the floppy diskettes formatted by NT. A virtual FAT disk system was created with Windows for Workgroups, and was also used with early versions of Windows NT and 95. FAT32 , an upgraded version of FAT, was released with Windows 95 (OSR2) and Windows 98.

Each version of the newer FAT structure allowed larger disk sizes and partitions. With Windows 9x, you can choose whether to use a FAT or FAT32 hard disk structure. If you've used FDISK lately, you were probably asked whether or not to enable large disk support. If you answered yes, any partition over 512MB is formatted as a FAT32 partition. It also means that you need a FAT32 boot diskette for recovery measures. Windows 3.x and NT do not recognize FAT32 partitions (although Windows 2000 does), which is usually only a problem for dual-boot systems.

DOS boot viruses often corrupt Windows 9x boot sectors because the infection code was written to read and write regular FAT (now called FAT16 ) areas. For example, interrupts 25h and 26h (read and write disk sectors) will not work under FAT32 and beyond. And with FAT32, the root directory can now be located anywhere on the disk (instead of near the beginning). DOS boot viruses can accidentally overwrite the root directory when they are storing the original boot sector.

3.1.5.9 Memory rings

Windows 95 implemented memory protection areas called rings . Rings are actually a function of Intel's 386 and later microprocessors and are numbered 0 to 3. In Windows, most applications run at ring 3 (or user mode) . Ring 3 programs can only manipulate their own memory area and cannot directly address any hardware or resources in ring 0. Programs running at ring 3 must call Windows APIs to request services, and are given limited DOS compatibility. Ring 0 programs have complete access to Windows and can directly manipulate the hardware. In 32-bit Windows platforms, operating system kernel, support, system support, and VxD files, run at ring 0 (also called kernel, supervisor, or Protected mode).

For a while, this separation prevented Windows viruses from becoming memory-resident and infecting other programs. Eventually, virus writers learned how to make their viruses run as VxD and driver files, and pulled a few other tricks, to plop their creations into the desirable ring 0 privilege level. When malicious code programmers learned how to grab ring 0 status, they grabbed the whole grail of 32-bit Windows security. At ring 0, programmers can completely manipulate Windows system code and applications. Antivirus scanners running on 95, and especially NT, should be written as device drivers so they can access and protect both user mode and kernel mode resources.

3.1.6 Windows 9x Startup Sequence

The startup sequence for Windows 9x is as follows :

During bootup, the boot sector locates root directory and loads IO.SYS .
IO.SYS , hidden in the boot sector of the boot partition, contains the initial instructions Windows 9x needs in order to interact with the hardware. A minimal file allocation table (FAT) is loaded.
IO.SYS then reads MSDOS.SYS , and processes its customized startup commands. DRVSPACE.BIN or DBLSPACE.BIN may load. LOGO.SYS (logo graphic) is displayed.
Windows checks to see if BIOS is Plug and Play compatible and determines which hardware profile to use.
IO.SYS then loads the registry database files ( USER.DAT and SYSTEM.DAT ) and creates a backup copy of each ( USER.DA0 and SYSTEM.DA0 ) after a successful load. DBLBUFF.SYS may be loaded.
IO.SYS checks for the presence of the CONFIG.SYS file in the root directory, and if found, executes statements found there. Next, any default settings stored in IO.SYS that were not overridden by the CONFIG.SYS file are processed . The following files and settings can be loaded by IO.SYS : HIMEM.SYS , IFSHLP.SYS , SETVER.EXE , DBLSPACE.BIN or DRVSPACE.BIN , DOS=HIGH , FILES=60 , LASTDRIVE=Z , BUFFERS=30 , STACKS=9,256 , SHELL=C:\COMMAND.COM /p , and FCBS=4 . The default values in IO.SYS cannot be edited, but they can be overrode by settings or commands placed in the CONFIG.SYS .
IO.SYS passes control back to COMMAND.COM , which then processes the AUTOEXEC.BAT file from the root directory.
WIN.COM is automatically started and it looks to see if WINSTART.BAT is present. If so, WINSTART.BAT commands are processed. Real-mode device drivers listed in the [386 Enh] section of the SYSTEM.INI file are loaded.
Registry ( SYSTEM.DAT ) is read for device drivers to load. VMM32.VXD is loaded. Other critical VxDs, support files are loaded.
KERNEL32.DLL , KRNL386.EXE , GDI.EXE , GDI32.EXE , USER.EXE , and USER32.EXE are loaded.
VMM32.VXD switches computer's processor from real mode into protected mode.
Local and network logon processes started. User may be asked to logon now. USER.DAT and WIN.INI file are loaded and Windows environment is customized.
After a successful logon, registry startup programs, SHELL= statements, and Startup group programs are executed.

3.1.7 Windows NT

David Cutler, a VAX architect originally with the Digital Equipment Corporation, began work on NT in 1987. Culter's background in multiuser, multiprocessor, secure environments was just what Microsoft was looking for. NT's stated goals were a more stable Windows platform, strong security, 32-bit performance, and CPU scalability. NT delivered. NT's 32-bit programming and security model proved to be a large obstacle to virus writers. The first native NT virus didn't come for four years after NT's release.

3.1.7.1 SAM and NT security

Without a doubt, NT's security model (see Figure 3-3) is the biggest improvement over the other versions of Windows (although default settings open it to attack). Central to NT's security is the Security Account Manager (SAM) database. The SAM maintains a user account database in the registry and controls user security. It contains all user and group permissions and access permissions for a particular Windows NT domain. The SAM database is stored in a separate, undocumented hive for security reasons. A cached copy is located in HKLM\SECURITY\SAM, and a backup copy can be stored at %SYSTEMROOT\repair in case recovery is ever needed. The information stored in the SAM database is encrypted so it can't be directly accessed or modified.

Each user and group is identified with a unique Security Identifier (SID). Deleting and re-creating a user or group results in a new SID. The SID is assigned the security rights so that simply creating a new account with the same name will not result in similar rights. NT has other security checks, implemented through policies and profiles, to allow administrators to limit the access a user or group has to a particular object.

Windows NT has a Local Security Authority (LSA) subsystem whose duty it is to enforce local security policies, generate security access tokens, and log on users. When you log on to an NT box, the LSA authenticates you against security policies and the SAM. The Security Reference Monitor (SRM) ensures the user or process has security rights (permissions) to access an object, and builds and sends an access token back.

Figure 3-3. NT 4.0 logon security processes

3.1.7.2 Administrators and domains

In the Windows NT world, the Administrator user account is king and has full access to the local system (known as root access in the Unix world). All malicious hackers want Administrator access to NT boxes. NT 4.0 file servers and workstations are managed in security zones called domains . Super users called Domain Administrators have full access to all NT file servers within the domain. Again, hackers and malicious programs love to get this type of special access.

In today's Novell networks, the super user account is called Administrator or Admin. Older Novell networks used the login, Supervisor, for full access.

Can viruses travel across domains? Yes, domain trusts are much like a drive share. If a machine or user has security rights to different domains, then malicious code can modify files on the remote network as if the user was doing the manipulation. Some advanced viruses, like WNT.Remote Explorer, wait for someone with Administrator privileges to log on, and then use those security credentials to invade other trusted domains. Most Windows viruses just infect the local Windows NT machine they are on, but they can infect unprotected programs executed remotely. A few Windows NT viruses and worms are venturing out on their own and infecting remote networks. Some look for already existing drive shares, others can search for and create their own network links.

3.1.7.3 System accounts

The Windows NT operating system uses dozens of programs, processes, and services to maintain and monitor itself. NT comes with several predefined user accounts (often hidden from the casual NT user) that run those processes and programs in a high-access security context. These accounts, like SYSTEM , can have even greater access than the Administrator account. Many Windows NT viruses will use these accounts to do things they would otherwise be prevented from doing. So, in NT, a well-written malicious program can have higher access than the security rights given to the logged on user.

Hackers have used Windows NT's task scheduling program, AT.EXE , to start programs with a higher access than the user or Administrator has access to. Programs started with the AT command in the interactive mode, use the SYSTEM account's security context.

3.1.7.4 NTFS

The New Technology File System (NTFS) was introduced with NT 3.1. Besides the greatly increase disk geometries, NTFS has significant file and directory security (something lacking in all previous Windows versions). NTFS allows file manipulation and I/O to be limited by the security rights of the user logged in (usually). NTFS also allows file compression and transaction logging, but still relies on a FAT-like address book called the Master File Table (MFT). The MFT is a relational database and bares little resemblance to its earlier ancestor , FAT. In Windows 2000, NTFS was updated to optimize file read and write speed, to allow file encryption, and to allow disk space rationing (disk quotas). DOS boot viruses do not understand NTFS boot sectors and will corrupt them in most cases. Luckily, after NT is booted up, all DOS boot virus operations are halted due to the security built in to NT. Even NT's basic file structure is different and complex.

3.1.7.5 NT file streams

With DOS and earlier versions of Windows, a file was simply a file. NTFS allows one file to have multiple data streams associated with it. This means that one file can really have several (related) files in it. This feature has been available in NTFS since the days of NT 3.1. It can be useful for many reasons. For instance, the icon associated with Windows executable can be stored as separate stream within the same file. A smaller, thumbnail- sized version of a graphic can be stored as a stream within the same file. Other pieces of coding and data can be stored in their entirety within a single file. The syntax of a filename and data stream is FILENAME.EXT:Stream. A file with multiple streams might look something like this FILENAME.EXT:Stream1, FILENAME.EXT:Stream2, etc. Unfortunately, very few programs, including antivirus scanners, worked with or searched for file streams, a fact malicious code writers have exploited in the last year.

NT viruses and worms on an NTFS partition can hide in an alternate stream and patch the original file to point to the alternate stream (now saved as a separate file) after it has run. In this way, Windows NT viruses can mimic the DOS companion virus mechanisms. Some antivirus scanners search the main file, but don't bother to interrogate the alternate data stream. Because of the way an NT virus must use file streams in order to be effective, many older antivirus scanners could detect the virus, but could not repair the original infected file. Fortunately, more and more scanners will recognize an NTFS partition and start looking for alternative streams now that a few viruses have exploited it. Malicious code writers have just started to scratch the surface of Windows NT programming tricks.

3.1.7.6 Multiboot

Windows NT and Windows 9x installation routines have the ability to automatically detect and save the partitions and boot sectors of previous operating systems (e.g., DOS, Windows 9x, OS/2, etc.), and later prompt the user at boot up to choose which operating system to load. Thus, if you install Windows NT on a machine with an existing Windows 9x operating system, Windows NT will back up the 9x boot sector to a file called BOOTSECT.DOS . Conversely, Windows 9x will save DOS or some other operating system if it was previously installed on the hard disk. If you choose the non-NT operating system option on a Windows NT dual-boot machine, Windows NT will execute the boot sector code located in BOOTSECT.DOS . If your PC contained a boot sector virus prior to installing Windows NT, Windows NT will store the infected boot sector and restore it faithfully every time the non-NT operating system is started. Virus files, which would otherwise be made harmless in Windows NT, can have a chance to thrive and cause damage if the PC is booted to a non-NT version of Windows or DOS. For instance, a multipartite file virus will try to write itself to a hard drive boot sector when its host program is executed. It will be unable to while Windows NT is running, but it will be able to under Windows 95 even though both operating systems may share the same disk space. Accordingly, it is important that Windows NT antivirus scanners scan BOOTSECT.DOS for boot sector viruses when searching for MMC.

3.1.7.7 Logging and auditing

One of Windows NT's best features is logging and auditing . The Event log (in NT 4.0 choose Start Programs Administrative Tools Event Viewer) tracks operating and application-level messages and events. The Event log has three separate logs: System , Application , and Security . You can choose which one you wish to view by selecting from the Event log File menu option. The System log tracks Windows NT operating system messages and events. The Application log tracks messages specifically generated by the application, and applications must be written specifically to send messages to it. Luckily, most Windows NT-aware utilities and programs utilize the Event log. The Security log, which most users do not use, tracks security events (successes and failures) that the administrator asked it to audit. In Windows NT, auditing is turned on in User Manager (or User Manager for Domains ) under Administrative Tools. To turn on or off particular audited events, choose Policies Audit. An Audit Policy can be used to track malicious mobile code or hackers. You can audit file and object accesses and even changes to the registry.

Windows 2000 Server has three new log files (Directory, DNS, and File Replication), but they have little to do with monitoring malicious mobile code, so far.

3.1.8 NT 4.0 Boot Process

This is the boot sequence for a Windows NT 4.0 Intel (i386) machine with IDE hard drives, and without a dual boot setup:

During bootup, the BIOS locates the boot drive and loads the master boot record (MBR). The MBR reads the partition table, which locates the NT boot sector. The boot sector loads the bootstrap code and loads NTLDR. During this portion of the boot process, NT is very susceptible to boot viruses.
NTLDR switches the processor from real mode to 32-bit flat memory mode. NTLDR then loads a mini-file system corresponding with the file system (FAT or NTFS) installed on the boot partition.
NTLDR reads the BOOT.INI file and displays the operating system startup choices, and by default, starts loading NT (if NT isn't chosen , DOS is loaded using boot code stored in BOOTSECT.DOS , and the alternative operating system is started). BOOT.INI tells NTLDR where on the disk to look for the NT boot partition.
NTDETECT.COM is run to detect any hardware changes since the last good start and to make a list of current hardware.
NTLDR then loads NTOSKRNL.EXE (NT OS Kernel), but does not start it. Next, HAL.DLL (Hardware Abstraction Layer) loads hardware-specific information into memory. This is where you will see the dots run out across the screen.
System hive is loaded next and scanned for drivers and services to load. Kernel is initialized and drivers and services (usually stored in C:\WINNT\SYSTEM32\CONFIG ) are started.
Registry's CurrentControlSet is saved. Registry hardware list created by NTDETECT.COM is placed in the registry under HKEY_LOCAL_MACHINE\HARDWARE.
The Session Manager ( SMSS.EXE ) runs instructions stored in the registry including: AUTOCHECK.EXE (to check logical structure of boot partition), sets up memory paging file(s), and loads Win32 subsystem.
Win32 subsystem starts and executes WINLOGON.EXE . Next, Local Security Authority ( LSASS.EXE ) displays Ctrl+Alt+Del logon dialog box.
Service Controller ( SCREG.EXE ) loads services designated for automatic startup.
User can log on to system.
Programs and services in startup areas (registry, startup group, etc.) are run.

Windows 2000 also loads another file called HYBERFIL.SYS during the bootup process that is responsible for holding memory data when an Energy Friendly PC goes into hibernation mode.


Team-Fly

Top