************************************** ** ** ** EBURGER WINDOWS SECURITY UTILITY ** ** ** ************************************** ------------ - Contents - ------------ Introduction - Overview - Updates - Pre-Requisites & Limitations - Installation - Back Up Your Registry - General Advisory & Disclaimer Overview of Options - NetBIOS Over TCP/IP - Microsoft DCOM - Microsoft Jet - Microsoft WS (Windows Script) - BHO's (Browser Helper Objects) - HOSTS File Pre-Requisites - DCOM & DCOMCNFG.EXE - Jet 3.5/4.0 SP3 & JETCOUPD.EXE - Microsoft WS (Windows Script) - BHO's & Internet Explorer 4.0 (or above) - HOSTS File - CHOICE.COM/CHOICE.EXE - Necessary Files for EBURGER.BAT Limitations: Windows Me & Windows 2000 - Windows Me - Windows 2000 NetBIOS Over TCP/IP Options - Disable/Re-Enable: Windows 9x - Disable/Re-Enable: Windows NT/2000 - Other Methods for Disabling File & Printer Sharing DCOM Options - Disable/Re-enable - Configure w/ DCOMCNFG.EXE - Other Preventative Measures for DCOM Jet Security Options - Jet Security HIGH - Jet Security MEDIUM - Jet Security LOW WS (Windows Script) Options - Disarm/Rearm MS WS Extensions - Defuse/Restore MS WS File Types - Note: WS File Types vs. Extensions - Cripple/Uncripple MS WS Run Time Files - TEST.VBS - WS & Internet Explorer - Other Security Precautions for WS BHO (Browser Helper Objects) Options - View BHO's - Disable BHO's - Re-Enable BHO's - Completely Removing BHO's HOSTS File Options - Toggle HOSTS File On/Off - Edit HOSTS File Customizing EBURGER - EBURGER.BAT - The .REG Files More Information - NetBIOS Over TCP/IP - Microsoft DCOM - Microsoft Jet - Microsoft WS (Windows Script) - BHO's (Browser Helper Objects) - HOSTS File A Few Final Words... Problems & Questions ---------------- - End Contents - ---------------- ****************** ** Introduction ** ****************** Welcome to the "ReadMe" for the EBURGER Windows Security Utility! -------- Overview -------- The EBURGER Windows Security Utility is a batch file which enables you to configure a number of aspects of Windows in order to protect your privacy and security, especially while using the Internet. It is a menu-driven utility that can be used to modify, configure, disable, or re-enable such things as: - NetBIOS Over TCP/IP (File & Printer Sharing) NetBIOS Over TCP/IP is a networking protocol that is installed in Windows Networking. It enables File & Printer Sharing, one of the most frequently and easily exploited security "holes" on Windows PC's connected to the Internet. Home users of Windows PC's, esp. those connected to the Internet through a DSL line or cable modem, are highly advised to close this "hole." EBURGER allows home users to disable NetBIOS Over TCP/IP and do just that. - Microsoft DCOM (Distributed Component Object Model) DCOM is a programming technology that can be used by software developers. According to Microsoft: "The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner." EBURGER allows home users who have no need for DCOM to shut off DCOM to prevent their computer software from engaging in unknown and unwanted network communication over the Internet. - Microsoft Jet Security (MS database engine security) Jet is a database engine that ships with Office 97 and Office 2000. It is used by both Excel and Access (as well as several other Microsoft applications). During 1999 Microsoft released a security patch to close a security hole in the Jet database engine that could be maliciously exploited. With this patch comes a small utility, JETCOUPD.EXE, which EBURGER employs to configure the new security features of Jet. - Microsoft Windows Script (WS) Microsoft Windows Script (WS) is a set of powerful scripting tools that could be used by malicious parties to spread viruses and worms and do damage to computers. EBURGER allows users who do not use applications or web sites which require these scripting tools to disable WS to prevent both the spread of viruses and worms on their systems as well as the damage they can do. - Browser Helper Objects (BHO's) Browser Helper Objects (BHO's) are "add-ons" to Internet Explorer 4.0 (and above) that can piggyback on, interact with, and control Internet Explorer browsing sessions. These "add-ons" give developers enormous power over Internet Explorer, power which can be used in ways users may not fully recognize, even while BHO's are communicating over the Internet through Internet Explorer unbeknownst to users. EBURGER allows users to view and disable unwanted BHO's in order to secure their systems better. - HOSTS File The HOSTS file is a simple text file that can be used by Windows to match domain names (e.g., www.cnn.com) with IP addresses (207.25.71.24), thus avoiding the need to use a DNS (Domain Name Server) and speeding up Internet surfing. Recently, some users have begun using the HOSTS file to block ads and other unwanted Internet communication by matching domain names (www.cnn.com) with *incorrect* IP addresses (127.0.0.1 or 0.0.0.0). EBURGER allows those who use a HOSTS file to disable HOSTS temporarily and to edit the HOSTS file quickly to make small modifications to it. Platforms ~~~~~~~~~ The EBURGER security utility can be used on: - Windows 9x (Windows 95, 98, 98SE, and Me) - Windows NT 4.0 & Windows 2000 There are some limitations on the use of this utility on Windows Me and Windows 2000. For more information on these limitations, please see the next section, "Pre-Requisites & Limitations." Also, please see the "A Few Final Words..." section for more information on what platforms EBURGER has been tested on. Windows XP ~~~~~~~~~~ EBURGER was written before Windows XP was released and has not been tested on Windows XP. If you use it on Windows XP, EBURGER will likelly recognize and treat XP as Windows 2000. Most of the options that EBURGER configures should work fine with Windows XP. The only configuration options that would be of concern are the NetBIOS Over TCP/IP options. Assuming Windows XP uses the same two services and devices as Windows 2000... "NetBIOS Over TCP/IP Helper" Service [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LmHosts] "NetBIOS Over TCP/IP" Device [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT] EBURGER should be able to disable NetBIOS Over TCP/IP on Windows XP without any problems. You can check for the existence of the two Registry keys listed above before running EBURGER and using the NetBIOS Over TCP/IP options. See the "NetBIOS Over TCP/IP" section below for more details on how EBURGER disables and re-enables NetBIOS Over TCP/IP on Windows 2000. What Follows... ~~~~~~~~~~~~~~~ What follows are descriptions of the pre-requisites, limitations, and specific functions of the EBURGER Windows Security Utility. Towards the end there is a "More Information" section, which contains links to other sources of information about each of the technologies that are configurable with this utility. I would also urge folks to read the "A Few Final Words..." section right near the end. ------- Updates ------- What follows below is a list of changes made to EBURGER since the original version was released in January of 2001. ~~~~~~~ 5-24-02 ~~~~~~~ On April 14, 2002, EBURGER was updated for a third time. The following changes were made: -- A minor adjustment was made to the "VIEW Current BHO's" function for Windows 2000 based on a suggestion from an EBURGER user. ~~~~~~~ 4-14-02 ~~~~~~~ On April 14, 2002, EBURGER was updated for a third time. The following changes were made: -- CHOICE.EXE (from the Windows 2000 Professional Resource Kit) was added to EBURGER for Windows NT/2000/XP systems. CHOICE.EXE will be installed (instead of the older CHOICE.COM from Windows 95B) if Windows NT/2000/XP is detected. -- Most Registry configuration files were moved to sub-directories to reduce clutter in the top-level EBURGER installation directory. ~~~~~~~ 4-28-01 ~~~~~~~ On April 28, 2001, EBURGER was updated again. The following changes were made: -- EBURGER no longer "cripples" (by renaming) the following files: DISPEX.DLL JSCRIPT.DLL SCROBJ.DLL VBSCRIPT.DLL These files are used by Internet Explorer. This behavior can be changed by editing EBURGER.BAT. See the "WS (Windows Script) Options" section for more details. -- If Windows Script 5.6 has been installed on Windows NT 4.0 or Windows 2000, EBURGER will now "cripple"/"uncripple" WSHCON.DLL (which WS 5.6 installs on Windows NT 4.0 and Windows 2000). -- EBURGER no longer "resets" Internet Explorer scripting settings for any of the "un-do" Windows Script options. This behavior can be changed by editing EBURGER.BAT. See the "WS (Windows Script) Options" section for more details. ~~~~~~~ 4-21-01 ~~~~~~~ On April 21, 2001, EBURGER was updated. The following changes were made: -- EBURGER now handles the following Extensions and File Types through "WS (Windows Script) Options": REGISTERED EXTENSION FILE TYPE FILE TYPE ---------- --------- --------- HTML Application .HTA htafile Windows Script .SCT/.WSC scriptletfile Component Shortcut into .SHB DocShortcut a Document Scrap Object .SHS ShellScrap See the "WS (Windows Script) Options" section below for more details. -- extensive updates and corrections to the ReadMe.txt (this file). ---------------------------- Pre-Requisites & Limitations ---------------------------- To use all of the options available in the EBURGER Windows Security utility, you must have several things installed first: - Microsoft DCOM - DCOMCNFG.EXE - Microsoft Jet 3.5 SP3, or Jet 4.0 SP3 or above - JETCOUPD.EXE - Microsoft WS (Windows Script) - Internet Explorer 4.0 (or above) - HOSTS file - CHOICE.COM or CHOICE.EXE For more detailed information on these pre-requisites and how you can acquire them if you don't already have them, see the "Pre-Requisites" section below. There are some limitations to the use of the EBURGER Windows Security utility on Windows Me and Windows 2000. All of these limitations involve the System File Protection scheme which both these versions of Windows use to ensure the integrity of Windows system files (esp. .DLL's and .EXE's). For more specific information regarding the limitations of this utility on Windows Me and Windows 2000, please see the "Limitations: Windows Me & Windows 2000" section below. ------------ Installation ------------ Installation or the EBURGER Windows Security batch file utility is simple. After unpacking all the files from EBURGER.EXE to a unique, common directory (default is C:\EBURGER), make a shortcut on your desktop or Start menu to EBURGER.BAT (set the "Start in:" to C:\EBURGER or wherever it's installed), and run it. Environment Space (Windows 9x) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If EBURGER appears to conk out with errors (esp. syntax errors) and you are running Windows 9x (95, 98, 98SE, Me), then you can try adjusting the "command environment space" by adding something like the following line either to your CONFIG.SYS or to the custom CONFIG.SYS for your MS-DOS shortcut to EBURGER.BAT (see the "Properties" for the MS-DOS shortcut): SHELL=\COMMAND.COM /p /e:1024 ...where is the complete path to your COMMAND.COM. The /e:xxxx switch sets the environment space in bytes. You may only need /e:512. Missing Files ~~~~~~~~~~~~~ If EBURGER.BAT complains about a missing file, the most likely reason is that the EBURGER package you downloaded wasn't completely unpacked. The EBURGER installation package contains several sub- directories under the main \EBURGER install directory, and your "un-zipper" program may not have properly unpacked all the sub-directories. If you downloaded the .ZIP file, the easiest solution is to download the self-extracting .EXE install package and use that package instead. The .EXE file should extract on its own to the directory C:\EBURGER. All the sub-dirs should be properly unpacked. --------------------- Back Up Your Registry --------------------- Several of the functions of the EBURGER security utility involve making changes to the Windows Registry. Making changes to the Windows Registry is never risk-free. Although you should not encounter major problems with this utility, you are advised to have a recent backup of your Windows Registry before making any changes to your system configuration with the EBURGER batch file utility. Having a recent backup of your Windows Registry is only common sense whenever you make ANY changes to your Windows system configuration. ----------------------------- General Advisory & Disclaimer ----------------------------- Although I have labored to make this batch file utility as safe as possible, there is simply no possible means for me to anticipate every potential system configuration (software and hardware) on which this utility could be used. As such, some EBURGER options could cause problems with certain software or system configurations. Specifically: - NetBIOS Over TCP/IP Some Networking configurations may require NetBIOS Over TCP/IP to enable connectivity. Disabling NetBIOS Over TCP/IP on some systems could impede or even prevent certain types of network connectivity. - Microsoft DCOM Some applications (Microsoft as well as "third party" applications) could require the use of DCOM. Disabling DCOM could prevent these applications from functioning properly or even running at all. - Microsoft Jet Some applications or web pages might require a certain configuration for the Jet database engine in order to function properly. Setting the Jet security level to "High" may prevent these web pages or applications from functioning properly. - Microsoft Windows Script (WS) Some applications or web pages may require the WS (Windows Script) to be enabled. Disabling the Windows Script could prevent these applications applications and web pages from functioning properly. In some cases, web pages or applications might be completely inaccessible or unusable. In particular, the Microsoft "Windows Update" site may not work if WS is disabled by using the "Cripple WS Run Time Files" option, which renames several files that are necessary for "Windows Update" (jscript.dll, vbscript.dll, and dispex.dll). The other methods used by EBURGER to disable WS ("Disarm WS Extensions" & "Defuse WS File Types") will NOT prevent you from using "Windows Update," however. - Browser Helper Objects (BHO's) Some applications or web pages may require the BHO's (Browser Helper Objects) to be installed. Disabling Browser Helper Objects (BHO's) could prevent these applications and web pages from functioning properly. In some cases, certain web pages or applications might be rendered completely inaccessible or unusable. If You Encounter Problems... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you encounter problems with applications or web pages after using a particular option in this batch file utility, you can re-start EBURGER and "undo" the option you previously selected. Every function in EBURGER has an matching "undo" function which will precisely reverse the changes made. Know Your System's Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All users of the EBURGER security utility should be aware of the requirements of the web pages and applications they routinely access and employ. Users should also understand the requirements of their networking configuration. For additional information about the system configuration changes that EBURGER can be used to make, please see the specific sections devoted to each technology later in this document as well as the "More Information" section at the end. ************************* ** Overview of Options ** ************************* When EBURGER starts, you are presented with a global menu for the various technologies that EBURGER can configure: - NetBIOS Over TCP/IP - Microsoft DCOM - Microsoft Jet - Microsoft WS (Windows Script) - BHO's (Browser Helper Objects) - HOSTS File Selecting any of these global options will take you to sub-menus specific to each technology. What follows is a brief breakdown of those sub-menus and the configuration changes that you can make to your Windows system with EBURGER. For more detailed information about the changes each option makes, see the major sections devoted specifically to each technology later in this document. ------------------- NetBIOS Over TCP/IP ------------------- From the NetBIOS Over TCP/IP sub-menu you can: [1] DISABLE NetBIOS Over TCP/IP Disable NetBIOS Over TCP/IP. [2] RE-ENABLE NetBIOS Over TCP/IP Re-enable NetBIOS Over TCP/IP. Note that use of either of these functions requires a reboot in order for changes to NetBIOS Over TCP/IP to take effect. -------------- Microsoft DCOM -------------- From the MS DCOM sub-menu you can: [1] DISABLE MS DCOM Disable Microsoft DCOM. [2] ENABLE MS DCOM Re-enable Microsoft DCOM. [3] Configure MS DCOM with DCOMCNFG.EXE Open the DCOMCNFG.EXE utility to configure Microsoft DCOM. ------------- Microsoft Jet ------------- From the MS Jet sub-menu you can: [1] Set MS JET Security HIGH Set Microsoft Jet Security to High. [2] Set MS JET Security MEDIUM Set Microsoft Jet Security to Medium. [3] Set MS JET Security LOW Set Microsoft Jet Security to Low. ----------------------------- Microsoft WS (Windows Script) ----------------------------- From the MS WS (Windows Script) sub-menu you can: [1] DISARM MS WS Extensions Set the default associations for WS extensions to "Unknown." [2] REARM MS WS Extensions Restore the default associations for WS extensions. [3] DEFUSE MS WS File Types Set the default command for WS file types to "Edit." [4] RESTORE MS WS File Types Restore the default command for WS file types to "Open." [5] CRIPPLE/UNCRIPPLE MS WS Run Time Files Rename or restore all WS .exe's and .dll's. Note that options 3&4 (MS WS File Types) should not be used in conjunction with options 1&2 (MS WS Extensions), or 5 (MS WS Run Time Files). ------------------------------ BHO's (Browser Helper Objects) ------------------------------ From the BHO (Browser Helper Objects) sub-menu you can: [1] VIEW Current BHO's See what BHO's are currently loading in the Registry. [2] DISABLE All BHO's Disable all BHO's in the Registry. [3] RE-ENABLE All BHO's Re-enable all BHO's in the Registry. Please note that the "view" option is crude -- it displays only the BHO Registry key (or the most recent backup of it), not the corresponding CLSID keys for any installed BHO's. Note also that when you disable BHO's, these BHO's will first be backed up to a .REG file so that they can be re-enabled (restored) with option 3. ---------- HOSTS File ---------- From the HOSTS sub-menu you can: [1] Toggle HOSTS File On/Off Disable or re-enable the HOSTS file. [2] Edit HOSTS File Open the HOSTS file with a text editor. ******************** ** Pre-Requisites ** ******************** There are a number of pre-requisites for using many of the options in the EBURGER Windows Security Utility. What follows below is a detailed discussion of what those pre-requisites are and where you can download those pre-requisites if you don't already have them. ------------------- DCOM & DCOMCNFG.EXE ------------------- There are two requirements for the use of all of the DCOM options: 1. installation of Microsoft DCOM 2. installation of DCOMCNFG.EXE Installation of Microsoft DCOM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to use any of the DCOM options you must (obviously) have Microsoft DCOM installed on your Windows system. DCOM exists for all versions of Windows 9x and Windows NT 4.0/2000. It is installed by default only on later versions of Windows. Windows NT/2000: DCOM is installed by default on Windows NT and Windows 2000. Updates to DCOM for Windows NT 4.0 are included in any of the later service packs for Windows NT 4.0 (SP 4, 5, 6a): http://www.microsoft.com/ntworkstation/downloads/default.asp Windows 98/ME: DCOM is installed by default on Windows 98 and Me. Updates to DCOM for Windows 98 can be obtained from: http://www.microsoft.com/com/dcom/dcom98/download.asp Windows 95: DCOM is not installed by default on Windows 95. You can get the latest version of DCOM for Windows 95 from: - installation of Internet Explorer 4 or above: http://www.microsoft.com/windows/Ie/default.htm - installation of other programs (including 3rd party applications, esp. those that allow automatic updating online) - separate download from Microsoft: http://www.microsoft.com/com/dcom/dcom95/download.asp An easy way to check if you have DCOM installed is to see if you have any of the following files: Windows 9x: \WINDOWS\SYSTEM\MPREXE.EXE \WINDOWS\SYSTEM\RPCSS.EXE Windows NT 4.0: \WINNT\SYSTEM32\RPCSS.EXE If you find these files, it's a good bet that DCOM is installed. Installation of DCOMCNFG.EXE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To use DCOMCNFG.EXE to configure DCOM, you must have DCOMCNFG.EXE installed here: - For Windows 9x, good locations for DCOMCNFG.EXE are either \WINDOWS or \WINDOWS\SYSTEM. - For Windows NT 4.0 or Windows 2000, good locations are either \WINNT or \WINNT\SYSTEM32. On Windows 9x, DCOMCNFG.EXE may not be installed by default. If has been installed, it will be located in \WINDOWS\SYSTEM. DCOMCNFG.EXE for all Windows 9x versions can be downloaded in the DCM95CFG.EXE package from: http://download.microsoft.com/msdownload/dcom/98/x86/en/dcm95cfg.exe (Windows 95) http://download.microsoft.com/msdownload/dcom/95/x86/en/dcm95cfg.exe (Windows 98) * Note: these are in fact the same files. On Windows NT and Windows 2000, DCOMCNFG.EXE should be installed by default in \WINNT\SYSTEM32. If you cannot find DCOMCNFG.EXE in this location, then you can get a copy of the file from your installation CD-ROM. Updated versions of DCOMCNFG.EXE for Windows NT 4.0 are included in any of the later service packs (SP 4, 5, 6a): http://www.microsoft.com/ntworkstation/downloads/default.asp Windows 9x & "User Level Security" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have an early version of DCOM for Windows 9x, you may receive the following error when you attempt to run DCOMCNFG.EXE: Before you can use DCOM, your system needs to be configured for "User-level" security. Use the "Network" icon in the control panel to configure your system for "User-level" security before running the DCOM configuration utility. Upgrading to the latest version of DCOM for Windows 9x will usually resolve the error. ------------------------------ Jet 3.5/4.0 SP3 & JETCOUPD.EXE ------------------------------ There are two requirements for use of the Jet security options: 1. installation of: Jet 3.5 SP3 (Office 97), or Jet 4.0 SP3 or above (Office 2000) 2. installation of: JETCOUPD.EXE Installation of Jet 3.5 SP3 or Jet 4.0 SP3 (or above) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JETCOUPD.EXE, the utility used to configure Jet, is part of a security update to Jet 3.5 and Jet 4.0 (the "Office 97/2000 ODBC Driver Vulnerability Security Update"). To use JETCOUPD.EXE, you must have Jet 3.5 SP3 (Office 97), or Jet 4.0 SP3 or above (Office 2000) installed first. If you have Office 97, you can get Jet 3.5 SP3 from the following sources: - Jet 3.5 SP3: http://support.microsoft.com/support/kb/articles/q172/7/33.asp - ODBC Driver Update for Office 97 (JETCOPKG.EXE) - includes both Jet 3.5 SP3 as well as JETCOUPD.EXE: http://office.microsoft.com/downloaddetails/excel97odbc.htm If you have Office 2000, you can get Jet 4.0 SP3 (or above) from the following sources: - Jet 4.0 SP3 http://www.microsoft.com/data/download_Jet4SP3.htm - Jet 4.0 SP5: http://support.microsoft.com/support/kb/articles/q239/1/14.asp - ODBC Driver Update for Office 2000 (JETCOPKG.EXE) - includes both Jet 4.0 SP3 as well as JETCOUPD.EXE: http://office.microsoft.com/2000/downloaddetails/excel2000odbc.htm If you use Office 97, which includes Jet 3.5, you can upgrade to Jet 4.0 by downloading and installing the MDAC 2.1 SP2 or MDAC 2.5 SP1 packages: http://www.microsoft.com/data/ Users of Office 97 who upgrade to Jet 4.0 via MDAC 2.1 SP2 or MDAC 2.5 SP1 should not have to use any of the Jet 4.0 service packs (SP3 or above) as MDAC 2.1 contains MSJET40.DLL v. 4.00.2927.2. A word of warning about MDAC 2.5: reportedly many users experienced problems with the MDAC 2.5 package. Microsoft still makes available the older MDAC 2.1 SP2 package. Either one of these two versions of MDAC will upgrade a system to the required Jet 4.0 service pack level. (Although MDAC 2.6 is also available, it does not contain Jet components.) Note that according to Microsoft, users of Windows 2000 do not need to install the JETCOPKG.EXE update. Do You Have the Right Version of Jet? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's how to tell if you have either Jet 3.5 SP3 or Jet 4.0 SP3 (or above). Look in \WINDOWS\SYSTEM (for Win9x) or \WINNT\SYSTEM32 (for Windows NT 4.0 and Windows 2000) and check the properties of these files. For Jet 3.5 SP3 (Office 97), you should have: NAME DATE SIZE VERSION msjet35.dll 8/4/99 1050384 3.51.3203.0 For Jet 4.0 SP3 (Office 2000), you should have at least: NAME DATE SIZE VERSION msjet40.dll 7/14/99 1495312 4.00.2927.2 Installation of JETCOUPD.EXE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JETCOUPD.EXE, the Jet configuration utility, should be located here: - For Windows 9x, good locations for DCOMCNFG.EXE are either \WINDOWS or \WINDOWS\SYSTEM. - For Windows NT 4.0 or Windows 2000, good locations are either \WINNT or \WINNT\SYSTEM32. JETCOUPD.EXE is not included in the generic updates to Jet (Jet 3.5 SP3, or 4.0 SP3 and above, or any of the MDAC 2.x packages). JETCOUPD.EXE is included only in the JETCOPKG.EXE (the "Office 97/2000 ODBC Driver Vulnerability Security Update"): - Office 97: http://office.microsoft.com/downloaddetails/excel97odbc.htm - Office 2000: http://office.microsoft.com/2000/downloaddetails/excel2000odbc.htm This ODBC update is in included in Office 2000 SR1 or SR1a: http://officeupdate.microsoft.com/ouv3/catalog.htm Installation of the JETCOPKG.EXE ODBC Driver Update may not install JETCOUPD.EXE. If JETCOUPD.EXE is not installed in one of the locations listed above, you can extract JETCOUPD.EXE manually from the JETCOPKG.EXE package with WinZip 7.0 or above: http://www.winzip.com/ After you extract JETCOUPD.EXE from the package, don't forget to move it to one of the directories listed above. If You Only Need JETCOUPD.EXE... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have already updated your version of Jet to the required service pack level and you only need the JETCOUPD.EXE utility, the easiest thing to do is to simply extract JETCOUPD.EXE from the JETCOPKG.EXE ODBC Driver Update package without installing that update. Indeed, if you have newer versions of the main files included in JETCOPKG.EXE, then the installation of JETCOPKG.EXE will likely fail. To simply extract JETCOUPD.EXE from the ODBC Driver Update package, use the latest version of WinZip (see the section just above for a link). JETCOUPD.EXE Versions ~~~~~~~~~~~~~~~~~~~~~ Microsoft has released at least two versions of JETCOUPD.EXE. The first version came with the original August 19, 1999 ODBC Driver Update. The second came with the subsequent releases of the ODBC Driver Update dated October 6, 1999, and January 12, 2000, respectively. Here is file info for the versions of JETCOUPD.EXE released in all three JETCOPKG.EXE packages: NAME DATE SIZE VERSION jetcoupd.exe 8/19/99 53248 1.0 jetcoupd.exe 9/29/99 65536 1.0a jetcoupd.exe 1/7/00 65536 1.0a Either version (1.0 or 1.0a) is sufficient to use with EBURGER, though there is at least one minor difference in the way the two configure Jet security (at least according to the ReadMe's for each). See the "Jet Security Options" section below for more details. JETCOUPD.EXE & Windows 2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Although Microsoft advises that users of Windows 2000 do not need to install the JETCOPKG.EXE ODBC Driver Update, I do not know whether Windows 2000 ships with the JETCOUPD.EXE configuration tool or whether this tool even works on Windows 2000. The Easiest Way... ~~~~~~~~~~~~~~~~~~ Obviously, the easiest way to get both an updated version of the Jet database engine (with the ODBC Driver Update) as well as JETCOUPD.EXE is to download the JETCOPKG.EXE "Office 97/2000 ODBC Driver Vulnerability Security Update" (see immediately above for a link). ----------------------------- Microsoft WS (Windows Script) ----------------------------- To use any of the WS (Windows Script) options, you must have WS installed on your system. If WS is installed on your system, you should find the files CSCRIPT.EXE and WSCRIPT.EXE in the following locations: - Windows 9x: \WINDOWS (wscript.exe) \WINDOWS\COMMAND (cscript.exe) - Windows NT/2000: \WINNT\SYSTEM32 (cscript.exe & wscript.exe) Windows Script (WS) is a set of scripting tools that includes: - Visual Basic Script Edition (VBScript) - JScriptR - Windows Script Components - Windows Script Host - Windows Script Runtime Windows Script (WS) is installed by default only on later versions of Windows. Early versions of Windows NT 4.0 and Windows 95 may have only the Windows Script Host, but not the rest of the full Windows Script package already installed. Windows 98, Me, and 2000 ~~~~~~~~~~~~~~~~~~~~~~~~ The Microsoft WS (Windows Script) is installed by default on Windows 98 & Me, as well as Windows 2000. Windows 95 & NT 4.0 ~~~~~~~~~~~~~~~~~~~ Microsoft WS (Windows Script) can be updated on any Windows version or installed new on Windows 95 and NT 4.0 through the following means: - installation of Internet Explorer 4 or above: http://www.microsoft.com/windows/Ie/default.htm - download of the latest version of WS from: http://msdn.microsoft.com/scripting/ In order to install WS new, you must have: - Internet Explorer 4.0 or above - Microsoft DCOM The current version of WS is 5.5. There is also a beta of WS 5.6 available. ---------------------------------------- BHO's & Internet Explorer 4.0 (or above) ---------------------------------------- BHO's (Browser Helper Objects) are a component of Internet Explorer 4.0 and above. In order to make use of the BHO options in EBURGER, you must have Internet Explorer 4.0 (or above) installed. ---------- HOSTS File ---------- To use any of the HOSTS file options, you must (obviously) be using a HOSTS file. Use of a HOSTS file in Windows is one of the easiest, cheapest ways to block WWW ads and other unwanted network connections. If you are using a HOSTS file, it will be located here: - Windows 9x: \WINDOWS - Windows NT/2000: \WINNT\SYSTEM32\DRIVERS\ETC Note that the HOSTS file does not have an extension (i.e., no .TXT or .DOC, et al). --------------------- CHOICE.COM/CHOICE.EXE --------------------- EBURGER.BAT makes use of CHOICE.COM, a DOS utility which shipped with every version of MS DOS 6.0 and above as well as all versions of Win 9x, including Windows 95, Windows 98, and Windows Me. Windows NT 4.0, Windows 2000, and Windows XP do not, however, include a copy of this file. Moreover, CHOICE.COM apparently has compatibility issues with the Windows XP command shell interpreter. This distribution includes a copy of both CHOICE.COM (from Windows 95 B - OSR2) and CHOICE.EXE (from the Windows 2000 Professional Resource Kit), which has equivalent functionality to CHOICE.COM. If EBURGER.BAT detects that you're running Windows NT/2000/XP, it will automatically install CHOICE.EXE to your Windows directory (usually \WINNT). (If you're running Windows 95/98/Me and CHOICE.COM seems to be missing, EBURGER.BAT will instead install CHOICE.COM to \WINDOWS.) If you're running Windows XP and EBURGER.BAT gives you errors every time you reach one of the menus, the problem is likely that a straight DOS version of CHOICE.COM is somewhere on your path. Even when CHOICE.EXE is installed in the Windows directory (\WINNT), if EBURGER.BAT finds CHOICE.COM, it will use CHOICE.COM instead of CHOICE.EXE. We want EBURGER.BAT to use CHOICE.EXE, which is compatible with Windows XP. Check your Windows directory (usually \WINNT) as well as your System directory (\WINNT\SYSTEM32). If you find CHOICE.COM (as opposed to CHOICE.EXE), remove it. Also, if you downloaded an earlier version of this utility that included only CHOICE.COM, make sure that CHOICE.COM is not located in the top level installation directory (a copy is included in the \CHOICE sub-directory, but that's OK). In other words, make sure that there is no chance that CHOICE.COM will be used. On Windows XP, you should be using CHOICE.EXE instead. ------------------------------- Necessary Files for EBURGER.BAT ------------------------------- To perform its several functions, EBURGER.BAT requires that the files supplied with this distribution be located in the same directory as EBURGER.BAT. Those files are: 2kex-off.reg 2kex-on.reg 2kft-off.reg 2kft-on.reg bho-del.reg bhotext1.txt bhotext2.txt dcoff-9x.reg dcoff-nt.reg dcon-9x.reg dcon-nt.reg ext-off.reg ext-on.reg ft-off.reg ft-on.reg ie-wsoff.reg ie-wson.reg netoffnt.reg netonnt.reg vnet-off.reg vnet-on.reg A Word of Caution... ~~~~~~~~~~~~~~~~~~~~ Please note that most of these file are .REG files, Windows Registry files. Please do not try to use any of these files outside of EBURGER.BAT. EBURGER.BAT was written to use the appropriate files at the right time for your version of Windows. Double-clicking on any of them will instantly "merge" them into your Windows Registry. If you double-click on the wrong .REG file, you could make unpredictable or even damaging changes to your Windows Registry. ******************************************** ** Limitations: Windows Me & Windows 2000 ** ******************************************** There are several limitations on the use of EBURGER if you're running either Windows Me or Windows 2000. All of these limitations revolve around the System File Protection scheme that each OS uses to guarantee the integrity of key system files (esp. .EXE's and .DLL's). ---------- Windows Me ---------- If you're using Windows Me, you will not be able to use the following options: NetBIOS: - DISABLE NetBIOS Over TCP/IP - RE-ENABLE NetBIOS Over TCP/IP Explanation: the Disable/Re-Enable NetBIOS Over TCP/IP options on Windows 9x involve renaming two files (VNBT.386 and VNETBIOS.VXD). Windows Me's System File Protection scheme will replace these files once they're renamed, defeating the effort to disable NetBIOS Over TCP/IP in this manner. Alternatives: see the "NetBIOS Over TCP/IP Options" section below for other ways to address this security threat. WS: - CRIPPLE\UNCRIPPLE MS WS Run Time Files Explanation: the Cripple/Uncripple MS WS Run Time Files options on Windows 9x involve renaming a number of WS related files in \WINDOWS\SYSTEM. Windows Me's System File Protection scheme will replace these files once they're renamed, defeating the effort to cripple WS in this manner. Alternatives: use options 1-4 from the WS (Windows Script) Options menu to disable or safely reconfigure WS. EBURGER is written to check for the existence of Windows Me. To confirm the existence of Windows Me, EBURGER checks for the following files: %WINDIR%\SYSTEM\SFP\SFPDB.SFP %WINDIR%\SYSTEM\SFP\SFPLOG.TXT If either of these files is found, EBURGER will prevent the options detailed above from being run. ------------ Windows 2000 ------------ If you're using Windows 2000, you will not be able to use the following options: WS: - CRIPPLE\UNCRIPPLE MS WS Run Time Files Explanation: the Cripple/Uncripple MS WS Run Time Files options on Windows 2000 involve renaming a number of WS related files in \WINNT\SYSTEM32. Windows 2000's System File Protection scheme will replace these files once they're renamed, defeating the effort to cripple WS in this manner. Alternatives: use options 1-4 from the WS (Windows Script) Options menu to disable or safely reconfigure WS. EBURGER is written to check for the existence of Windows 2000. To confirm the existence of Windows 2000, EBURGER checks for the following files and folders: %WINDIR%\SYSTEM32\DLLCACHE %WINDIR%\SYSTEM32\RPCSS.DLL If either of these files or folders is found, EBURGER will prevent the options detailed above from being run. ********************************* ** NetBIOS Over TCP/IP Options ** ********************************* EBURGER allows Windows users to disable and re-enable NetBIOS Over TCP/IP in order to better secure their networking configurations. Disabling and re-enabling NetBIOS Over TCP/IP are performed through different means for Windows 9x vs. Windows NT 4.0 and Windows 2000. ----------------------------- Disable/Re-Enable: Windows 9x ----------------------------- EBURGER disables NetBIOS Over TCP/IP on Windows 9x by doing two things: 1. Renaming \WINDOWS\SYSTEM\VNBT.386 to VNBT.DIS. 2. Renaming \WINDOWS\SYSTEM\VNETBIOS.VXD to VNETBIOS.DIS. Additionally, to prevent Windows from trying to start VNETBIOS.VXD on boot up, the following Registry key is deleted: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETBIOS] A reboot is required for changes to NetBIOS Over TCP/IP to take effect. To re-enable NetBIOS Over TCP/IP, EBURGER restores the files VNBT.386 and VNETBIOS.VXD as well as the VNETBIOS Registry key (and all its values). Again, a reboot is required for changes to take effect. Please note that this method of disabling and re-enabling NetBIOS Over TCP/IP does not work on Windows Me because of the System File Protection scheme that Windows Me employs to guard critical system files. For alternatives methods of disabling NetBIOS Over TCP/IP on Windows Me, see the sub- section below titled, "Other Methods for Disabling File & Printer Sharing." Note: Windows Networking "Re-Install" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please be aware that if you use EBURGER to disable NetBIOS Over TCP/IP on Windows 9x and then later make any other changes to your networking configuration through the Networking Properties configuration box, Windows will "re-install" all networking components, thus re-enabling NetBIOS Over TCP/IP. The tell-tale sign that Windows is "re-installing" networking components is if you see Windows start what looks to be a long automatic configuration process, prompts you for your Windows installation media (CD-ROM), copies a number of files to your hard drive, and then prompts you to reboot for changes to take effect. If Windows does "re-install" networking components after you make changes to the Networking Properties, it would be a good idea to re-run EBURGER and disable NetBIOS Over TCP/IP again just to be safe. Warning: 3rd Party Registry "Cleaners" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you use EBURGER to disable NetBIOS Over TCP/IP on Windows 9x and then run one of the many Registry "cleaning" programs that are available on the Internet, that Registry "cleaner" may mistakenly delete Registry entries which contain references to either VNBT.386 or VNETBIOS.VXD because those have been renamed by EBURGER and, thus, the pointers to them in the Registry are now invalid. Any decent Registry "cleaner" should allow you to preview the Registry entries it wants to remove, giving you the chance to preserve any lines with references to either VNBT.386 or VNETBIOS.VXD. If you run a Registry "cleaner" and it mistakenly deletes Registry entries with references to either VNBT.386 or VNETBIOS.VXD, and you later decide to re-enable NetBIOS Over TCP/IP, you can prompt Windows to restore the lines by using the Networking Properties configuration box. Bring up the Networking Properties configuration box, make a small, non-critical change (say, to the "Identification" section), and then click "OK" to save your changes. Windows should now go through the whole process of "re-installing" and properly configuring Windows Networking, restoring the Registry entries that were mistakenly deleted. ---------------------------------- Disable/Re-Enable: Windows NT/2000 ---------------------------------- EBURGER disables NetBIOS Over TCP/IP on Windows NT 4.0 and Windows 2000 by doing two things: 1. Setting the "Startup" mode for the "NetBIOS Over TCP/IP Helper" Service to "Disabled." To do this, EBURGER sets the following Registry value: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LmHosts] "Start"=dword:00000004 2. Setting the "Startup" mode for the "WINS Client (TCP/IP)" (named "NetBIOS Over TCP/IP" in Windows 2000) Device to "Disabled." To do this, EBURGER sets the following Registry value: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT] "Start"=dword:00000004 A reboot is required for changes to NetBIOS Over TCP/IP to take effect. To re-enable NetBIOS Over TCP/IP, EBURGER sets the "Startup" mode for each of the above services to "Automatic" by setting their "Start" Registry values thus: "Start"=dword:00000002 Again, a reboot is required for changes to take effect. DNS Lookup & Windows 2000 ~~~~~~~~~~~~~~~~~~~~~~~~~ Disabling the "NetBIOS Over TCP/IP" Device (NetBT) in Windows 2000 may prevent DNS Lookup. If you wish to modify EBURGER so that it does not disable the NetBT Device, "comment" out the following lines in NETOFFNT.REG... [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT] "Start"=dword:00000004 ...so that they look like this: ; [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT] ; "Start"=dword:00000004 Then if DNS Lookup is disabled, simply re-run EBURGER, re-enable NetBIOS Over TCP/IP (to re-enable the NetBT Device), and then (assuming you have edited the NETOFFNT.REG file as shown above) disable NetBIOS Over TCP/IP again(which will disable only the TCP/IP Helper Service [LmHosts]). -------------------------------------------------- Other Methods for Disabling File & Printer Sharing -------------------------------------------------- There are other ways that you can disable NetBIOS Over TCP/IP and protect your system from this particular networking vulnerability. All of these, in fact, can be used in conjunction with the means that EBURGER employs to achieve the same effect. For links to additional information on NetBIOS Over TCP/IP and File and Printer Sharing, see the "More Information" section below. Disable "File & Printer Sharing" (Win9x) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you're running Windows 9x, the easiest way to disable "File and Printer Sharing" is to go through the Networking Properties: 1. Right-click on Network Neighborhood and select "Properties" from the context menu. 2. Click the "File and Printer Sharing..." button on the first tabbed page. 3. In the "File and Printer Sharing" settings box, make sure all the appropriate options are unchecked. 4. Click "OK" to save your settings. Then click "OK" again to close the Network Properties settings box. Note that Windows will now insist on going through an annoying configuration process in which it will need your Windows installation media, so have it ready. You may also have to reboot for changes to take effect. Re-Do Networking Bindings ~~~~~~~~~~~~~~~~~~~~~~~~~ Another very effective method for addressing the NetBIOS Over TCP/IP vulnerability is to re-do your networking bindings so that your TCP/IP protocol is bound only to your networking adapter (an Ethernet card or other NIC, or the DialUp Networking Adapter). This process of re-doing networking bindings can be a bit intimidating (and confusing) for beginning users, but it is highly recommended. For detailed, illustrated, step-by-step instructions for both Windows 9x and Windows NT 4.0, see Steve Gibson's "ShieldsUp" page, which also contains a few online tests that you can run against your own box to see if your NetBIOS ports are still vulnerable: https://grc.com/x/ne.dll?bh0bkyd2 Block Ports 137-139 w/ a Firewall ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have a firewall (like AtGuard, Norton Internet Security 2000, Conseal, et al), you ought to consider setting up rules to block ports 137, 138, and 138, both inbound and outbound. If you have ZoneAlarm or ZoneAlarm Pro, then your NetBIOS ports should be automatically "stealthed" for you. ****************** ** DCOM Options ** ****************** EBURGER allows users to disable/re-enable Microsoft DCOM, or configure DCOM with DCOMCNFG.EXE. ----------------- Disable/Re-Enable ----------------- Windows 9x and Windows NT/2000 set different Registry keys to disable and re-enable DCOM. Windows 9x ~~~~~~~~~~ To disable DCOM on Windows 9x, EBURGER sets the following Registry values: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole] "EnableDCOM"="N" "EnableRemoteConnect"="N" To re-enable DCOM on Windows 9x, EBURGER sets the same Registry values thus: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole] "EnableDCOM"="Y" "EnableRemoteConnect"="Y" Note: although Microsoft's documentation for DCOM claims that the "EnableRemoteConnect" value is valid only for Windows 95, that Registry value appears to be valid for Windows 98, Windows 98SE, and Windows ME as well. Warning: "EnableRemoteConnect" vs. "EnableRemoteConnections" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Several Microsoft documents claim that the correct name for the second of the two Registry values is "EnableRemoteConnections" as opposed to "EnableRemoteConnect" (see the "DCOM Options" section above). Other Microsoft documents, however, claim that "EnableRemoteConnect" is in fact the correct name. Having informally surveyed a number of Windows 95, 98, 98SE, and ME users, I have yet to find an instance in which "EnableRemoteConnections" was added by Windows itself (through the DCOMCNFG utility -- see below). In other words, when the DCOMCNFG.EXE utility is used, it will generate "EnableRemoteConnect" (not "EnableRemoteConnections"). The best evidence I have seen so far indicates that "EnableRemoteConnect" is the correct value name, and that the few documents that do specify "EnableRemoteConnections" are in error. Windows NT 4.0 & 2000 ~~~~~~~~~~~~~~~~~~~~~ To disable DCOM on Windows NT 4.0 and Windows 2000, EBURGER sets the following Registry values: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole] "EnableDCOM"="N" "EnableDCOMHTTP"="N" To re-enable DCOM on Windows NT 4.0 and Windows 2000, EBURGER sets the same Registry values thus: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole] "EnableDCOM"="Y" "EnableDCOMHTTP"="Y" ------------------------- Configure w/ DCOMCNFG.EXE ------------------------- EBURGER allows you to open up the DCOMCNFG.EXE utility ("Distributed COM Configuration Properties"). Through DCOMCNFG.EXE, you can set the same Registry values as EBURGER does -- look on the "Default Properties" page. Below is a table which matches the Registry values that EBURGER modifies and the configuration tabs and boxes that appear in DCOMCNFG.EXE. Windows Version Registry Value DCOMCNFG Tab Name >> Box Name --------------- -------------- ----------------- -------- Windows 9x EnableDCOM Default Properties >> Enable Distributed COM on this computer Windows 9x EnableRemoteConnect Default Security >> Enable remote connection Windows NT/2000 EnableDCOM Default Properties >> Enable Distributed COM on this computer Windows NT/2000 EnableDCOMHTTP Default Properties >> Enable COM Internet Services on this computer You can also set a number of other configuration options. See the DCOMCNFG Help file (DCOMCNFG.HLP) for more information. DCOMCNFG.EXE should be installed on your "Path." For information on how to get DCOMCNFG.EXE, see the "Pre-Requisites" section above. ------------------------------------ Other Preventative Measures for DCOM ------------------------------------ There are several other ways to handle DCOM. Personal Firewall: Block Port 135 & RPCSS.EXE/MPREXE.EXE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have a firewall (like AtGuard, Norton Internet Security, ZoneAlarm, Conseal, Tiny Personal Firewall, et al), you ought to consider setting up rules to block inbound and outbound communication for the following executables: Executable Name Operating System ---------- ---- ---------------- RPCSS.EXE Microsoft Distribute Windows 9x & Windows NT/2000 COM Services MPREXE.EXE WIN32 Network Interface Windows 9x only Service Process Indeed, many users first stumble upon DCOM when they start using a personal firewall (like ZoneAlarm or Norton Internet Security) and then discover that one or both of these executables have either attempted outbound communication to the Internet or has set itself up to "listen" on certain ports, esp. port 135 and ports 1025 and up. A typical warning from a personal firewall like ZoneAlarm will look something like this: "Microsoft Distribute COM Services" is attempting an outbound connection to the Internet. Do you wish to grant this program access?" You can usually answer "NO" to such requests and suffer no consequences. The surest solution to the problem of RPCSS.EXE or MPREXE.EXE listening on certain ports is to shut down DCOM while using a firewall to wall off these executables from the Internet. Disabling DCOM through EBURGER, as well as using a firewall to block inbound and outbound traffic to and from these executables (esp. on port 135), should be enough to reign in DCOM firmly. Shutdown MDM.EXE ~~~~~~~~~~~~~~~~ MDM.EXE (Machine Debug Manager) is another pesky program often associated with DCOM. As with RPCSS.EXE and MPREXE.EXE, users often find MDM.EXE in a list of running processes. This program, to my knowledge, does not usually attempt outbound network connections, but it can prove to be a "pig," chewing up valuable chunks of system resources, memory, and CPU time. Some users have also reported large volumes of .TMP junk files left over from MDM.EXE. To add to one's frustration, MDM.EXE often does not start from any of the "usual" locations (including the [HKLM\... \Run] and [HKCU\...\Run] keys in the Registry). MDM.EXE can be shut down through the DCOMCNFG.EXE utility (see the "Configure w/ DCOMCNFG.EXE" section above). 1. Start DCOMCNFG.EXE 2. On the "Applications" tab, scroll down through the list of "Applications:" until you find "Microsoft Debug Manager." Click on the entry to select or highlight it. 3. Hit the "Properties..." button. A dialog box titled "Machine Debug Manager Properties" should pop up. 4. On the "Location" tab uncheck the "Run application on this computer" box. 5. Click Apply," then "OK" to close the "Properties" box. 6. Click "OK" again to close DCOMCNFG.EXE. You will probably have to reboot for changes to take effect. MDM.EXE (Machine Debug Manager) is used by Microsoft's Internet Explorer to debug scripts. You can also disable MDM.EXE through Internet Explorer: 1. In Internet Explorer go to "Tools" (or "View") >> Internet Options... >> Advanced 2. Check the "Disable script debugging" box 3. Uncheck the "Display a notification about every script error" box 3. Click "OK" to save your changes Finally, you should check to see that MDM.EXE is not set to start through any of the usual locations (esp. the [HKLM\...\Run] and [HKCU\...\Run] keys in the Registry). If you're using Windows 9x, you can use the "System Configuration Utility": Start >> Run >> (type in) "MSCONFIG." Other Applications Which Use DCOM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Other applications (or even drivers) can cause DCOM (usually RPCSS.EXE) to attempt communication over a networking connection and hold open a port (usually 135). Such an application or driver is likely network capable and uses DCOM to communicate with other software components over a network (good examples of this are some of the newer Lexmark printer drivers). If you are not working in a networked context in which DCOM is required for certain software applications to function properly, disabling DCOM through EBURGER (or through DCOMCNFG.EXE) should put a stop to these pesky attempts at communication. If you don't need such network capable functionality from the program or driver, you can also try searching through the options for the program making use of DCOM and search for a way to turn off this network capable functionality. NOT To Be Tried... ~~~~~~~~~~~~~~~~~~ One thing that you ought NOT try to do to address the issues raised by DCOM is to rename (and thus "disable") or delete either RPCSS.EXE or MPREXE.EXE. Doing so yields very unpleasant results (believe me): Windows will likely not boot to a desktop; even if it does, Windows will have turned into a slow-motion nightmare of un-usability and endless errors. ************************** ** Jet Security Options ** ************************** To set the new security levels for Microsoft Jet, EBURGER runs JETCOUPD.EXE, a utility that comes with the JETCOPKG.EXE ODBC Driver Update. JETCOUPD.EXE, which should be installed somewhere on your "Path," configures three things: - "Open Confirmation after Download" - Jet "Sandbox" Mode - Jet "Disabled Extensions" For more information on how to get the ODBC Driver Update as well as the JETCOUPD.EXE utility, see the "Pre-Requisites" section above. What follows are detailed descriptions of each aspect of Jet security. "Open Confirmation after Download" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "Open Confirmation after Download" flag for a number of MS Office File Types is set. According to the ReadMe for JETCOPKG.EXE, the complete list of those File Types is: "MS_ClipArt_Gallery.2", "Excel.Chart.5", "Excel.Chart.8", "Excel.Sheet.5", "Excel.Sheet.8", "iqyfile", "rqyfile", "Outlook.Template", "msgfile", "vcsfile", "vcffile", "icsfile", "PowerPoint.Slide.8", "PowerPoint.Show.8", "PowerPoint.SlideShow.8", "PowerPoint.Template.8", "Word.Template.8", "Word.Wizard.8", "Word.Backup.8", "Word.Document.8", "Word.RTF.8", ---(end first 21)------------------ "Access.Application.8", "Access.BlankDatabaseTemplate.8", "Access.DatabaseWizardTemplate.8", "Access.Extension.8", "Access.MDEFile.8", "accesshtmlfile", "accessthmltemplate", "dqyfile", "Excel.Addin", "Excel.Backup", "Excel.CSV", "Excel.DIF", "Excel.Macrosheet", "Excel.SLK", "Excel.Template", "Excel.Workspace", "Excel.XLL", "Excelhtmlfile", "Excelhtmltemplate", "icsfile", "Office.Binder.8", "Office.Binder.Template", "Office.Binder.Wizard", "oqyfile", "PowerPoint.Addin.8", "PowerPoint.Wizard.8", "powerpointhtmlfile", "powerpointhtmltemplate", "wordhtmlfile", "wordhtmltemplate" The "Open Confirmation after Download" is a Registry value ("EditFlags"=hex:00,00) that is added to each File Type. For example, after the "Open Confirmation after Download" flag is set for the "Excel.Sheet.5" File Type, the top tier of the Registry key for the "Excel.Sheet.5" File Type looks like this: [HKEY_CLASSES_ROOT\Excel.Sheet.5] @="Microsoft Excel Worksheet" "EditFlags"=hex:00,00 Jet "Sandbox" Mode ~~~~~~~~~~~~~~~~~~ The "Sandbox" mode for Jet -- 0, 1, 2, or 3 -- is set. The "Sandbox" mode is stored as a Registry value. For Jet 3.5, it is: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Engines] "SandboxMode"=dword:0000000x For Jet 4.0, it is: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines] "SandboxMode"=dword:0000000x ...where x is the sandbox mode. Note that when you install the JETCOPKG.EXE ODBC Driver Update, the installer uses JETCOOUPD.EXE to set the "Sandbox" mode to 2. Jet "Disabled Extensions" ~~~~~~~~~~~~~~~~~~~~~~~~~ the list of "Disabled Extensions" for Jet. According to the ReadMe for JETCOPKG.EXE, the complete list of "Disabled Extensions" is: !txt csv tab asc htm html This list is kept as a Registry value... - for Jet 3.5 it is: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Engines\Text] "DisabledExtensions"="!txt,csv,tab,asc,htm,html" - for Jet 4.0 it is: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text] "DisabledExtensions"="!txt,csv,tab,asc,htm,html" Please understand that this list of "Disabled Extensions" determines which file types CAN be modified and excludes all others from being modified. One interesting note: Microsoft released its original version of JETCOPKG.EXE on August 19, 1999 (size 2,876,896). The version of JETCOUPD.EXE included with that first release (size 53248, v. 1.0) is different than the version included in the re-releases of the ODBC Driver Update. Of still more interest is that this original JETCOUPD.EXE sets the following "Disabled Extensions": "bat,cmd,ini,sys,inf,vbs,js" On October 6, 1999, and again on January 12, 2000, Microsoft re- released JETCOPKG.EXE (sizes 4,878,824 and 4870328). These re- releases include a newer version of JETCOUPD.EXE (size 65536 v. 1.0a). This later version of JETCOUPD.EXE sets a different list of "Disabled Extensions": "!txt,csv,tab,asc,htm,html" According to Microsoft, the original Disabled Extensions" list represents a list of file types that CANNOT be modified. The new list, however, works differently -- it represents an EXCLUSIVE list of file types that CAN be modified (in other, words only files on the new list can be modified -- all others are excluded from modification). Evidently, it's the exclamation point at the start of the newer list that determines the way the new list functions. For more information on this point, see MS KB Q239471: http://support.microsoft.com/support/kb/articles/Q239/4/71.asp If you have the newer version of JETCOPKG.EXE and are interested in getting the older version, you can readily find the older, original version on FTP sites: http://ftpsearch.lycos.com/ The smaller size of the older version (2.7 MB vs. 4.7 MB) clearly distinguishes it from the newer version. JETCOUPD.EXE /switches ~~~~~~~~~~~~~~~~~~~~~~ To set each security level, EBURGER runs JETCOUPD.EXE with a different set of switches. Here is Microsoft's command summary of the switches for JETCOUPD.EXE (from the JETCOPKG.EXE ReadMe), which is also used for installation of the ODBC Driver Update: JetCoUpd [/q | /s] [/d] [/m:0 | /m:1 | /m:2 | /m:3] [/a "path to root of Office 97 admin image"] [/i "path to INF file"] switches: /q (or /s) - Quiet or Silent mode. /d - This switch disables the "Confirm Open After Download" flag for the first 21 file types of the above list. Used for non-admin installation's patch only. /m:0, /m:1, - Set Jet sandbox mode to 0, 1, 2, or 3 respectively. Used /m:2, /m:3 for non-admin installation's patch only. /a - Specify the root of Office 97 admin image. Used for admin installation's patch only. /i - Specify the INF file path. Used for admin installation's patch only. What Follows... ~~~~~~~~~~~~~~~ What follows below is a summary of the switches for JETCOUPD.EXE as run by EBURGER and the resulting configuration settings for Jet. ----------------- Jet Security HIGH ----------------- Command: jetcoupd.exe /q /m:3 Results: - "Open Confirmation after Download" flag for MS Office File Types set (see above list). - Jet "Sandbox" mode set to 3. - Jet "Disabled Extensions" list set. ------------------- Jet Security MEDIUM ------------------- Command: jetcoupd.exe /q /m:2 Results: - "Open Confirmation after Download" flag for MS Office File Types set (see above list). - Jet "Sandbox" mode set to 2. - Jet "Disabled Extensions" list set. ---------------- Jet Security LOW ---------------- Command: jetcoupd.exe /q /d /m:0 Results: - "Open Confirmation after Download" flag for first 21 MS Office File Types cleared (see above list). - Jet "Sandbox" mode set to 0. - Jet "Disabled Extensions" list set. ********************************* ** WS (Windows Script) Options ** ********************************* EBURGER allows you to disable/re-enable Windows Script (WS) in three different ways: DISABLE RE-ENABLE OPTIONS(S) ------- --------- ---------- set WS Extensions to restore WS Extensions to 1 & 2 "Unknown" their defaults set default Command for restore default Command for 3 & 4 WS File Types to "Edit" WS File Types to "Open" rename WS Run Time files Restore WS Run Time files 5 (toggle) to *.DIS to their proper names When disabling or re-enabling WS Extensions and File Types, EBURGER merges .REG files (Windows Registry files) to change Windows File Associations. Note that EBURGER uses different .REG files for WS Extensions and File Types if you are running Windows 2000, because Windows 2000 uses different Registry value types than Windows 9x and NT 4.0. Here is a basic table of the Registry keys involved in the default WS File Association configuration: Note: all Registry keys and values are under [HKEY_CLASSES_ROOT\...] REGISTERED EXTENSION FILE TYPE DEFAULT FILE COMMAND TO BE FILE TYPE TYPE ACTION EXECUTED ---------- --------- --------- ------------ ------------- HTML Application .HTA htafile htafile\Shell JSFile\Shell\Open\Command @="Open" @="mshta.exe \"%1\" %*" JScript File .JS JSFile JSFile\Shell JSFile\Shell\Open\Command @="Open" @="WScript.exe \"%1\" %*" JScript Encoded .JSE JSEFile JSEFile\Shell JSEFile\Shell\Open\Command File @="Open" @="WScript.exe \"%1\" %*" Windows Script .SCT/.WSC scriptletfile scriptletfile\ scriptletfile\Shell\Open\ Component Shell Command @="Open" @="\"Notepad.exe\" \"%1\"" VBScript Encoded .VBE VBEFile VBEFile\Shell VBEFile\Shell\Open\Command File @="Open" @="WScript.exe \"%1\" %*" VBScript File .VBS VBSFile VBSFile\Shell VBSFile\Shell\Open\Command @="Open" @="WScript.exe \"%1\" %*" Windows Script .WSF WSFFile WSEFile\Shell WSFFile\Shell\Open\Command File @="Open" @="WScript.exe \"%1\" %*" Windows Script .WSH WSHFile WSHile\Shell WSHFile\Shell\Open\Command Host Settings @="Open" @="WScript.exe \"%1\" %*" File In addition to WS Extensions and File Types, EBURGER also handles "Scrap Object" File Associations: REGISTERED EXTENSION FILE TYPE DEFAULT FILE COMMAND TO BE FILE TYPE TYPE ACTION EXECUTED ---------- --------- --------- ------------ ------------- Shortcut into .SHB DocShortcut DocShortcut\ DocShortcut\Shell\Open\ a Document @="Open" Command @="rundll32 shscrap.dll, OpenScrap_RunDLL /r /x %1" Scrap Object .SHS ShellScrap ShellScrap\ ShellScrap\Shell\Command @="Open" @="rundll32 shscrap.dll, OpenScrap_RunDLL %1" Here's how File Associations in Windows work. When you double-click on a file to run it, Windows... 1. checks the EXTENSION for a specified FILE TYPE 2. goes to the FILE TYPE specified by the EXTENSION 3. goes to the DEFAULT ACTION specified by under \Shell 4. executes the COMMAND Some WS Extensions point not only to File Types, but to MIME Content Types as well. Here is a table of the MIME Content Types specified by WS Extensions: REGISTERED EXTENSION MIME Content Type FILE TYPE ---------- --------- ----------------- HTML Application .HTA "Content Type"="application/hta" Windows Script .SCT/.WSC "Content Type"="text/scriptlet" Component MIME Content Types are itemized under [HKEY_CLASSES_ROOT\MIME\Database\Content Type\...]. ----------------------------- Disarm/Rearm MS WS Extensions ----------------------------- When EBURGER "disarms" WS Extensions, it does so by changing the specified File Type for all WS Extensions to "Unknown." On most Windows systems the "Unknown" File Type (HKEY_CLASSES_ROOT\Unknown \...) has the following command associated with it: "%SystemRoot%\rundll32.exe shell32.dll,OpenAs_RunDLL %1" This command pops up the "Open With..." dialog box, asking the user to choose a program to open the file with. After the specified File Type for all WS Extensions have been changed to "Unknown," whenever a WS file is run, the "Open With..." dialog box should pop up, giving the user the option to either run the program with a program of the user's choice or to kill the attempt altogether. In addition to changing the specified File Type for all WS Extensions to "Unknown," EBURGER also sets the specified MIME Content Types for .HTA, .SCT, and .WSC to null (""). When EBURGER "rearms" WS Extensions, it merely resets the specified File Type for each Extension to its default (see the table above). It also restores the proper MIME Content Types specified by .HTA, .SHB, and .SHS (see the table above). .HTA & Internet Explorer 4.x ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ EBURGER does not distinguish between systems with Internet Explorer 4.x and Internet Explorer 5.x. Thus, when EBURGER "rearms" WS Extensions, IE 4.x systems will gain an .HTA Extension (but no File Type), however this Extension will be useless as neither the specified File Type ("htafile") nor the required executable (MSHTA.EXE) exist on IE 4.x systems. This unusable Extension will be ignored by Windows. Internet Explorer 4.x users can edit the .REG files which are involved (EXT-ON.REG & EXT-OFF.REG) to "comment out" the lines which handle the .HTA extension. In EXT-ON.REG the lines to look for are: [HKEY_CLASSES_ROOT\.hta] @="htafile" "Content Type"="application/hta" Change the EXT-ON.REG lines to look like this: ; [HKEY_CLASSES_ROOT\.hta] ; @="htafile" ; "Content Type"="application/hta" In EXT-OFF.REG the lines to look for are: [HKEY_CLASSES_ROOT\.hta] @="Unknown" "Content Type"="" Change the EXT-OFF.REG lines to look like this: ; [HKEY_CLASSES_ROOT\.hta] ; @="" ; "Content Type"="" If you prefer, you could delete the lines specified above instead. If you edit these two .REG files, you should do the same thing for "Section 3" of FT-ON.REG & FT- OFF.REG, as this section in both files also handles the .HTA Extension. For more information on editing EBURGER's .REG files, see the "Customizing EBURGER" section below. If you have already run EBURGER and it has added an .HTA extension to your Registry, you can use REGEDIT (Start >> Run >> "REGEDIT" >> "OK") and delete the following Registry key: [HKEY_CLASSES_ROOT\.hta] ------------------------------- Defuse/Restore MS WS File Types ------------------------------- When EBURGER "defuses" WS File Types (except for "DocShortcut," "htafile," "ScrapObject," and "scriptletfile"), it does so by setting the default File Type Action to "Edit." The "Edit" command for all WS File Types is: "Notepad.exe" "%1" ...which opens the WS file in question in Windows Notepad. Thus, whenever a WS file is run, it should automatically open in Notepad, preventing the file from being executed by the WS scripting engine. When EBURGER "restores" WS File Types, it merely resets the default File Type Action to "Open" (see the table above). Note that when you use EBURGER to "defuse" WS File Types, EBURGER also sets the following options for each File Type ("DocShortcut," "htafile," "ScrapObject," and "scriptletfile"): Option Registry Value ------ -------------- "Always show extension" "AlwaysShowExt"="" "Confirm open after download" "EditFlags"=hex:00,00,00,00 Note: both values are set individually for every File Type. Exceptions ~~~~~~~~~~ When EBURGER "defuses" WS File Types, it does NOT modify the "DocShortcut," "htafile," "ScrapObject," and "scriptletfile" File Types in any way. Instead, EBURGER changes the associated Extensions (.HTA, .SCT, .SHB, .SHS, & .WSC) so that the specified File Types are set to "Unknown" (and the MIME Content Types set to null, if applicable), as in the "Disarm/Rearm Extensions" option detailed above. EBURGER resorts to this strategy for several reasons: 1. With the exception of Windows Script Components (.SCT/.WSC), the associated files are not editable with a simple text editor like Notepad. 2. Many of the associated commands are too involved to risk modifying with a .REG file. When EBURGER "restores" WS File Types, it merely resets the specified File Type for each of these Extensions (.HTA, .SCT, .SHB, .SHS, & .WSC) to its default (see the table above). It also restores the proper MIME Content Types specified by .HTA, .SCT, and .WSC (see the table above). Manually Defusing WS File Types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Essentially, what EBURGER does to the main WS File Types is exactly what you can do yourself manually through the Windows interface. The main WS File Types that EBURGER sets to "Edit" are: REGISTERED EXTENSION FILE TYPE ---------- --------- JScript File .JS JScript Encoded File .JSE Windows Script Component .SCT/.WSC VBScript Encoded File .VBE VBScript File .VBS Windows Script .WSF Windows Script Host .WSH Settings File For example, to achieve the same results for these six main WS File Types (set the default Action to "Edit"): 1. Open Windows Explorer from the "Start" menu ("Start" >> "Programs"...) 2. Go to "Tools" >> "Folder Options" (or "Options") 3. Click on the "File Types" tab. 4. Click on each WS "Registered File Type" in succession to select or highlight it, and do the following for each: a) Click "Edit..." b) Click to select/highlight the "edit" option in the "Actions:" box. c) Click the "Set Default" button. d) Make sure the "Always show extension" and "Confirm open after download" boxes are checked. e) Click "OK" to save your changes. EBURGER does all of the above for the six main WS File Types at once. It can also reset the default "action" to "Open." ---------------------------------- Note: WS File Types vs. Extensions ---------------------------------- Please note there should be no need to both "disarm" WS Extensions and "defuse" WS File Types. Once you "disarm" WS Extensions (which sets the default specified File Type to "Unknown"), Windows should never even check any of the File Types for a Default Action to execute; the Default Action is now specified by the "Unknown" File Type. -------------------------------------- Cripple/Uncripple MS WS Run Time Files -------------------------------------- To "cripple" WS Run Time files, EBURGER renames several files associated with WS so that they cannot be found and used by Windows to execute WS files: PROPER NAME DISABLED NAME 9x Location NT/2000 Location Note ----------- ------------- ----------- ---------------- ---- cscript.exe cscript.dis \WINDOWS\COMMAND \WINNT\SYSTEM32 wscript.exe wscript.dis \WINDOWS \WINNT\SYSTEM32 mshta.exe mshta.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 IE 5 only scrrun.dll scrrun.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 wshcon.dll wshcon.dis n/a \WINNT\SYSTEM32 WS 5.6 only wshext.dll wshext.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 wshom.ocx wshom.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 To "uncripple" WS Run Time files, EBURGER restores all files to their proper names. Note that this option (Cripple/Uncripple) is a toggle -- run it once and the files are renamed; run it again and the files are restored. Note also that this option CAN be used in conjunction with either the "disarm"/"rearm" Extensions options or the "defuse"/"restore" File Types options. Indeed, "crippling" WS Run Time files nicely complements other methods of disabling WS by adding an extra layer of security. Windows Script 5.0 and above (including 5.1, 5.5, and 5.6) ship with files that EBURGER does not "cripple," because the files are used by Internet Explorer: PROPER NAME DISABLED NAME 9x Location NT/2000 Location Note ----------- ------------- ----------- ---------------- ---- dispex.dll dispex.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 jscript.dll jscript.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 scrobj.dll scrobj.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 vbscript.dll vbscript.dis \WINDOWS\SYSTEM \WINNT\SYSTEM32 Lines that will "cripple" these four files do exist in EBURGER, however, they have been "commented out" with double-colons ( :: ). Users who prefer that EBURGER "cripple" these files can edit EBURGER.BAT and remove the double-colons ( :: ) before the lines which "cripple" these files. The lines which "uncripple" are NOT "commented out." If EBURGER finds these files "crippled" (for example by a previous version of EBURGER), it will "uncripple" them by default. For more information on editing the EBURGER.BAT file, see the "Customizing EBURGER" section below. This option does not "cripple" or "uncripple" (rename or restore) any files associated with Scrap File Objects (.SHB/.SHS). "Duplicate file name or file in use" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you receive the error... "Duplicate file name or file in use" ...while attempting to "cripple" WS Run Time files, then one or more of the WS files is in use by Windows and cannot be renamed. To find out which files are in use you can immediately "uncripple" WS Run Time files. When you do so, EBURGER will be unable to find the previously "crippled" files which were in use (because they weren't properly renamed) and will give you this error: "File not found - .dis" To correct this problem you should either close down any applications which might be making use of the files, shut down and reboot Windows, or both. If EBURGER continues to report that certain files are in use, then those files are probably necessary for some application or Windows component that you are running. Other WS Run Time files will still be "crippled" and "uncrippled" as usual. MSHTA.EXE & Internet Explorer 4.x ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ EBURGER does not distinguish between systems with Internet Explorer 4.x and Internet Explorer 5.x. Since MSHTA.EXE ships only with Internet Explorer 5.0 and above, EBURGER will simply fail to find MSHTA.EXE on IE 4.x systems and not rename it (without generating any kind of error). Warning: 3rd Party Registry "Cleaners" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you use EBURGER to "cripple" WS runtime files and then run one of the many Registry "cleaning" programs that are available on the Internet, that Registry "cleaner" may mistakenly delete Registry entries which contain references to WS runtime files because those have been renamed by EBURGER and, thus, the pointers to them in the Registry are now invalid. Any decent Registry "cleaner" should allow you to preview the Registry entries it wants to remove, giving you the chance to preserve any lines with references to any of the WS runtime files listed above. If you run a Registry "cleaner" and it mistakenly deletes Registry entries with references to WS runtime files, and you later decide to "uncripple," you will have to reinstall the entire Windows Script package. You can download the latest WS package from Microsoft: http://msdn.microsoft.com/scripting/ -------- TEST.VBS -------- Included with the EBURGER package is a harmless little "test" VBS (Visual Basic Script) applet named TEST.VBS. If WS is enabled, the TEST.VBS will generate a two successive dialog boxes with the following messages: "If this were a virus, something bad might happen now." "But you can use EBURGER to short-circuit this VBScript." If WS is disabled, running TEST.VBS will either open the "Open With..." dialog box, open in Notepad, or do nothing, depending on how you chose to disable WS. ---------------------- WS & Internet Explorer ---------------------- When EBURGER "disarms" WS Extensions, "defuses" WS File Types, or "cripples" WS Run Time files, it also disables all types of scripting for Internet Explorer both in the "Internet" zone as well as the "Restricted" zone. Here are the IE scripting options that EBURGER sets to "Disabled" along with the corresponding Registry values for both the "Internet" zone and the "Restricted" zone: REGISTRY VALUE IE OPTION -------------- --------- 1400 "Active Scripting" 1402 "Scripting of Java Applets" 1405 "Script ActiveX controls marked safe for scripting" 1407 "Allow paste operations via script" Note: "Internet" zone values are under: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Internet Settings\Zones\3 "Restricted" zone settings are under: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Internet Settings\Zones\4 If you prefer EBURGER not to disable scripting in Internet Explorer, then you can edit EBURGER.BAT to prevent EBURGER from doing so. Find every instance of this line... start /w regedit.exe /s ie-wsoff.reg ...and "comment" it out so that it looks like this: REM start /w regedit.exe /s ie-wsoff.reg When EBURGER "rearms" WS Extensions, "restores" WS File Types, or "uncripples" WS Run Time files, it does not reset the IE scripting options to "Enabled." The lines to reset the IE scripting options to "enabled" (but only for the "Internet" zone. The scripting options remain "Disabled" for the "Restricted" zone) do exist in EBURGER.BAT. If you prefer EBURGER to re-enable scripting in Internet Explorer, then you can edit EBURGER.BAT to prevent EBURGER from doing so. Find every instance of this line... :: start /w regedit.exe /s ie-wson.reg ...and "comment" it out so that it looks like this: start /w regedit.exe /s ie-wson.reg For more information on editing the EBURGER.BAT file, see the "Customizing EBURGER" section below. --------------------------------- Other Security Precautions for WS --------------------------------- There are many other ways to address the issues raised by WS. For more information on alternative methods of "disabling" WS or making it more safe, see the "More Information" section below. One final note about Microsoft Windows Script: if you install or upgrade Microsoft software (esp. large applications like Internet Explorer or Microsoft Office), you may find that WS has been reinstalled and/or re-enabled. You should make it a habit to check on the status of WS regularly -- TEST. VBS has been included with EBURGER for just that purpose. ****************************************** ** BHO (Browser Helper Objects) Options ** ****************************************** EBURGER does all of its work on BHO's (Browser Helper Objects) by manipulating, in one way or another, the following Registry key (hereafter referred to as the BHO Registry key): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Explorer\Browser Helper Objects If BHO's are installed on a Windows box with Internet Explorer, then the entries in this Registry key will point to CLSID keys, which contain information about the .DLL's being used for the BHO's. CLSID keys can be found here in the Registry: HKEY_CLASSES_ROOT\CLSID EBURGER doesn't do anything with these CLSID Registry keys. What follows is a brief summary of what EBURGER does with the BHO Registry key. ---------- View BHO's ---------- To allow the user to "view" any currently installed BHO's, EBURGER exports the BHO Registry key to a .REG file, combines it with an explanatory text, and opens the result in Notepad. In effect, EBURGER allows you to view the raw BHO Registry key to check if you do in fact have BHO's installed and loading. EBURGER doesn't take you to the corresponding CLSID keys -- you can do that yourself with REGEDIT.EXE (the Windows Registry Editor). Admittedly, this is a comparatively crude method for "viewing" BHO's, but it does at least allow you to check very quickly if you do indeed have BHO's installed. ------------- Disable BHO's ------------- EBURGER "disables" BHO's by merely backing up (to a .REG file) and deleting the BHO Registry key. Even though the corresponding CLSID keys are still in place, this should be sufficient to prevent BHO's from loading. EBURGER will keep up to five backups of your BHO Registry key. Thus, if you use EBURGER to backup and then whack the BHO Registry key, and a new BHO installs at some later point, you can use EBURGER to backup and whack the new one as well without overwriting your previous backup. --------------- Re-Enable BHO's --------------- To re-enable BHO's, EBURGER merely restores your most recent backup to the Registry. After it has been merged into the Registry, this most recent backup is deleted. ------------------------- Completely Removing BHO's ------------------------- EBURGER cannot completely uninstall or remove BHO's from your system, because it does not remove the corresponding CLSID Registry keys and associated .DLL files from your system. All EBURGER does is "disable" BHO's by removing the references to them from the BHO Registry key. To completely remove BHO's from you system you would need to remove manually: - the CLSID references from the BHO Registry key (as done by EBURGER) - the corresponding CLSID keys - the corresponding files (specified in the CLSID keys) For a more powerful means of viewing, disabling, re-enabling, and uninstalling BHO's, see the "More Information" section below for a link to a free program called BHOCaptor. ************************ ** HOSTS File Options ** ************************ If you use a HOSTS file, EBURGER allows you to toggle the HOSTS file on and off, or view and edit it. If you're using Windows 9x, the HOSTS file will be located here: \WINDOWS If you're using Windows NT 4.0 or Windows 2000, the HOSTS file will be located here: \WINNT\SYSTEM32\DRIVERS\ETC Note that the HOSTS file does not have an extension (i.e., no .TXT or .DOC, etc.). For links to more information on using a HOSTS file, see the "More Information" section below. ------------------------ Toggle HOSTS File On/Off ------------------------ This option is a toggle. If HOSTS is currently enabled, EBURGER will disable it by renaming it to HOSTS.dis. If HOSTS is currently disabled (named HOSTS.dis), EBURGER will re-enable it by restoring it to its proper name (HOSTS, no extension). Note that in order for changes to take effect for your browser, you'll have to close and re-open your browser. --------------- Edit HOSTS File --------------- EBURGER allows you to open and edit the HOSTS file in Notepad. If you make any changes, be sure to save your changes before exiting Notepad. Note that if your running Windows 9x and your HOSTS file is over 32 kb in size, then Windows will be unable to load HOSTS in Notepad and will ask you if you want to open it in Wordpad instead. This size limitation is inherent to Notepad in Windows 9x. You can get around this size limitation by using one of the many "freeware" Notepad replacements out there on the web. My current favorite happens to be MetaPad, which you can download at: http://welcome.to/metapad/ ************************* ** Customizing EBURGER ** ************************* One of the nicer, more powerful aspects of the EBURGER Windows Security Utility is that it can be completely customized by the user. In fact, there may be options or configurations that you do not want EBURGER to perform or that you want EBURGER to perform in a different manner. Not to fret -- EBURGER can be customized to do exactly and only what you want it to do. Customizing EBURGER involves editing two different types of files: -- batch files (i.e., the EBURGER.BAT file) -- .REG files (Windows Registry files) The EBURGER program itself is a batch file, which is editable with a simple text editor like Windows Notepad. EBURGER.BAT not only displays all the options menus, but it does some of the configuration work itself. In many cases, however, EBURGER uses .REG files (Windows Registry files) -- also editable with a simple text editor -- to configure various aspects of Windows security. What follows are brief descriptions of how to edit and customize these files. ----------- EBURGER.BAT ----------- The EBURGER program is a batch file which is editable with any simple text editor like Windows Notepad. To open an EBURGER.BAT in Windows Notepad you can either: -- right-click on EBURGER.BAT and select "Edit" from the context menu that pops up -- open Windows Notepad, navigate through the "File - Open..." dialog box to the folder that contains EBURGER.BAT, and open it from there Once you open the EBURGER batch file, you will notice that it is divided into major sections corresponding to the choices on the main menu. Each section has its own sub-menu and is itself divided into sub-sections. All titles of sections and sub-sections are preceded by a single colon. For example, the NetBIOS Over TCP/IP section is headed by this entry: :NETBIOS You will also find may lines which are not executable -- that is, there are lines that consist of "comments" that have been "remarked" out so that Windows will ignore them when executing EBURGER. All "remarked" out "comment" lines are preceded by a double set of colons (::). For example, Windows will ignore the following lines in the EBURGER batch file: :: -------------------------- :: Give the available options :: -------------------------- These "comments" exist mainly to help someone looking at the file follow and understand all the different commands, the sequence in which they are edited, and why they are where they are. One of the most straightforward customizations you can make to EBURGER to "remark" out a line to prevent it from executing. For example, say you decide that you don't want EBURGER to disable NETBIOS.VXD when it disables NetBIOS Over TCP/IP on Windows 9x. To prevent EBURGER from disabling NETBIOS.VXD, you find the following lines (which have been truncated for readability) in the NETOFF- 9X section... ren %WINDIR%\SYSTEM\vnetbios.vxd vnetbios.dis start /w regedit.exe /s vnet-off.reg ...and insert double colons (::) so that they look like this: ::ren %WINDIR%\SYSTEM\vnetbios.vxd vnetbios.dis ::start /w regedit.exe /s vnet-off.reg With the double colons (::) at the start of these lines, Windows will ignore the lines and not disable VNETBIOS.VXD. Note that in this case we had to lines to 'remark" out: the first renames the VNETBIOS.VXD file; the second merges a .REG file (VNET-OFF.REG) in the Windows Registry in order to delete the VNETBIOS Registry key. If you were to "remark" out the above lines, you probably also want to find the similar lines in the NETON-9X section and disable those as well so that when you use EBURGER to re-enable NetBIOS Over TCP/IP on Windows 9x, EBURGER doesn't try to re-enable VNETBIOS.VXD as well. By the way, another way to "remark" out a line in a batch file like EBURGER.BAT is to use the letters REM (not case sensitive) at the start of a line instead of double colons: REM ren %WINDIR%\SYSTEM\vnetbios.vxd vnetbios.dis REM start /w regedit.exe /s vnet-off.reg There are other customizations that you can make to the EBURGER batch file, but the above is the simplest and most straightforward type. If you make any changes to the EBURGER.BAT file, don't forget to save your changes in Notepad. -------------- The .REG Files -------------- As we saw in the above example, EBURGER sometimes uses .REG files (Windows Registry files) to configure certain aspects of Windows security. .REG files are, in reality, merely text files formatted for use by REGEDIT.EXE. As such, they can be edited using any simple text editor like Windows Notepad. To open one of the .REG files in Windows Notepad you can either: -- right-click on the appropriate .REG file and select "Edit" from the context menu that pops up -- open Windows Notepad, navigate through the "File - Open..." dialog box to the folder that contains EBURGER.BAT, and open it from there If you edit one of the .REG files in a text editor like Notepad, you will not only be able to see the Registry entries that will be added or deleted if EBURGER "merges" that .REG file into the Registry, but you will be able to add or modify entries. Here's a quick introduction to the syntax of the entries in the .REG files using the NetBIOS Over TCP/IP on Windows 9x example we looked at above in the EBURGER.BAT file: To re-enable/restore the NETBIOS.VXD Registry key, EBURGER merges the VNET-ON.REG file into the Registry. VNET-ON.REG contains the following main lines: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETBIOS] "Start"=hex:00 "NetClean"=hex:01 "StaticVxD"="vnetbios.vxd" The first line [HKEY_LOCAL_MACHINE...VNETBIOS] specifies the Registry key to be added. The other three lines specify the "values" for that key as well as the "data" of those "values" ("Value"=data). Note that you will also find a few other lines in VNET-ON.REG -- these are mainly "comments" which are "remarked" out (with a semi-colon [ ; ], not double colons [::] as in batch files). To disable the above lines so that they would not be "merged" into the Registry, we would add semi- colons to the start of each line so that they looked like this: ; [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETBIOS] ; "Start"=hex:00 ; "NetClean"=hex:01 ; "StaticVxD"="vnetbios.vxd" EBURGER sometimes uses .REG files to delete or disable certain Registry keys and values. For example, to remove the VNETBIOS key from the Registry, EBURGER "merges" the VNET-OFF.REG, which contains the following line: [-HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETBIOS] The hyphen or "minus" sign ( - ) right before the name of the Registry key tells REGEDIT.EXE to delete that key (and all the values and data under it) from the Registry, instead of adding it. You could disable this line as well, thus preventing the .REG file from deleting the VNETBIOS key when EBURGER "merged" it into the Registry. One bit of advice about disabling entire .REG files: the easiest way to prevent an entire .REG file from being "merged" into the Registry by EBURGER is not to edit the .REG file; the easiest way is to simply "remark" out the line in EBURGER.BAT which "merges" the .REG file (see the section above for instructions on how to edit EBURGER.BAT). If you make any changes to .REG files, don't forget to save your changes in Notepad. Finally, please note that the file attribute of all the .REG files are set to "Read Only" by default, meaning that you won't be able to save any changes you make to these .REG files until you take off the "Read Only" attribute. To take the "Read Only" attribute off a .REG file... -- right-click (context click) on the appropriate .REG file and select "Properties" from the context menu. -- uncheck the "Read-only" box (in the "Attributes" section on the "General" tabbed page) -- Click "OK" to save your changes. With the "Read Only" attribute off, you should now be able to save your changes to the .REG file. ********************** ** More Information ** ********************** ------------------- NetBIOS Over TCP/IP ------------------- For more info on the risks of NetBIOS Over TCP/IP (File and Printer Sharing) as well as a different approach to addressing this problem, see Steve Gibson's outstanding "Shields Up!" site, which includes not only an enlightening set of online networking tests that you can run on your own system, but tons of useful documentation to boot: https://grc.com/x/ne.dll?bh0bkyd2 Before he put together his extensive instructions for re-configuring the bindings for Windows networking protocols, adapters, and services, Steve Gibson made available two lightning fast tools to enable and disable File and Printer Sharing, NOSHARE.EXE and LETSHARE.EXE, which can still be downloaded from GRC.com: http://grc.com/files/noshare.exe http://grc.com/files/letshare.exe For a contrarian's view of the risks associated with NetBIOS Over TCP/IP (and pointed criticism of the "Shields Up!" site), check out the "Navas Cable Modem/DSL Tuning Guide": http://cable-dsl.home.att.net/index.htm In particular, see the Navas "File and Printer Sharing (NetBIOS) Fact and Fiction": http://navasgrp.home.att.net/tech/netbios.htm For Microsoft's instructions for Windows 9x, consult the Knowledge Base article Q199346 - "Disable File and Printer Sharing for Additional Security": http://support.microsoft.com/support/kb/articles/q199/3/46.asp Fred Langa has extensively covered the risks of Windows networking in general, and NetBIOS Over TCP/IP in particular, in his WinMag "Explorer" column as well as his free newsletter. For a good intro to his coverage of these issues, see his "Four Myths of Online Security": http://content.techweb.com/winmag/columns/explorer/2000/04.htm For insightful info about various strategies for tackling the problem of NetBIOS Over TCP/IP on Windows, peruse the "Basic Windows 9.x Security" page at the "Secure Design - Port Scan Security Check" site: http://www.sdesign.com/securitytest/win9xsecurity.html Finally, for yet another utility to disable and re-enable File and Printer Sharing in Windows 9x, check out the Privacy Software Corporation's free ShareClean utility: http://www.nsclean.com/sclean.html -------------- Microsoft DCOM -------------- For more info on Microsoft DCOM, a good starting point is smallfish's page on DCOM & SOAP at her excellent "Privacy Power!" site: http://accs-net.com/smallfish/dcom.htm A page at the "CounterExploitation" site dicusses RPCSS.EXE and MDM.EXE more specifically: http://www.cexx.org/rpcss.htm For detailed, "official" info, see Microsoft's documentation on DCOM: - Microsoft's DCOM page: http://www.microsoft.com/com/tech/dcom.asp - Microsoft KB article Q158508 - "COM Security Frequently Asked Questions": http://support.microsoft.com/support/kb/articles/Q158/5/08.asp - MSDN Library - "Enabling and Disabling DCOM": http://msdn.microsoft.com/library/psdk/com/security_8bzh.htm - MSDN Library - "COM Security in Practice": http://msdn.microsoft.com/library/techart/msdn_practicom.htm A note about Microsoft's documentation on DCOM on Windows 9x: Several Microsoft documents claim that the correct name for the second of the two Registry values is "EnableRemoteConnections" as opposed to "EnableRemoteConnect" (see the "DCOM Options" section above). Other Microsoft documents, however, claim that "EnableRemoteConnect" is in fact the correct name. Having informally surveyed a number of Windows 95, 98, 98SE, and ME users, I have yet to find an instance in which "EnableRemoteConnections" was added by Windows itself (through the DCOMCNFG utility -- see below). In other words, when the DCOMCNFG.EXE utility is used, it will generate "EnableRemoteConnect" (not "EnableRemoteConnections"). The best evidence I have seen so far indicates that "EnableRemoteConnect" is the correct value name, and that the few documents that do prefer "EnableRemoteConnections" are in error. Finally, for a disturbing, anonymous, and unverified *allegation* about Microsoft's use of DCOM, point your browser to: http://www.infoforce.qc.ca/spyware/ms.html ------------- Microsoft Jet ------------- For more info on the JETCOUPD.EXE security tool and what it does, see the README.TXT (entitled "Microsoft Office Jet/ODBC/IISAM Update") that comes with the JETCOPKG.EXE ODBC Driver Update (the "Pre-Requisites" section above contains a link to JETCOPKG.EXE). To read about the specific vulnerability addressed by the JETCOPKG.EXE update, see the Microsoft Security Bulletin MS99-030 - "Office 97/2000 ODBC Driver Vulnerability Security Update": http://www.microsoft.com/technet/security/bulletin/ms99-030.asp The "Frequently Asked Questions" for this bulletin (which contains links to still more information) is here: http://www.microsoft.com/technet/security/bulletin/fq99-030.asp ----------------------------- Microsoft WS (Windows Script) ----------------------------- Microsoft's Windows Script (WS) has received extensive coverage in the popular tech media, esp. following the outbreak of the "Melissa" and "I Love You" viruses. For more info on WS from the "horse's mouth," consult Microsoft's documentation at the Microsoft Scripting page: http://msdn.microsoft.com/scripting/ In the wake of the devastation caused by the "I Love You" virus, Fred Langa has once again proved to be a useful source for info on Windows security threats. Check out "Four Ways to Disable Windows Scripting" from his May 11, 2000 newsletter: http://www.langa.com/newsletters/2000/2000-05-11.htm Symantec, maker of Norton Anti-Virus, provides both a free tool to disable WS as well as instructions for manually removing WS: http://www.symantec.com/avcenter/venc/data/win.script.hosting.html http://service1.symantec.com/SUPPORT/nav.nsf/docid/2000050512031906 And for yet another set of instructions to disable WS, see: http://www.us.sophos.com/support/faqs/wsh.html Evidently Microsoft hasn't taken kindly to recommendations to uninstall or disable WS. In a recent post (12/21/00) to GRC's "OptOut" newsgroup (http://grc.com/discussions.htm), Kevin McAleavey of the Privacy Software Corporation (makers of NSClean, IEClean, and BOClean), warned readers that: "Just so you know, Microsoft went *volcanic* over that recommendation as well as our own recommendation to do so a few days earlier on our site. Now, any time you install anything from Microsoft or allow "windows updates" they now replace the files and restore the registry settings. "Therefore, if you delete the files yourself or diddle the registry, make it a POINT to go look for those files on a regular basis ... they DO come back eventually in all their "glory" ... keeping those zombies dead was a critical part of our IEClean design. Microsoft *insists* upon restoring those files in preparation for ... 'Microsoft dotNET' ..." The program Kevin McAleavey plugs here, IEClean, is a highly regarded privacy tool that can be purchased at: http://www.nsclean.com You can read the Privacy Software Corporation's warnings about the security risks of WS and look at still another set of instructions for removing it at: http://www.nsclean.com/psc-vbs.html There are several other useful tools out there on the Net that address the security risks associated with WS. You can find links to a good number of these tools at my web site at the University of Illinois at Urbana-Champaign: http://www.spywarewarrior.com/uiuc/soft4.htm Of the many 3rd party tools available to "disarm" Microsoft's WS, one in particular is worthy of separate mention: ScriptSentry, a free tool from Jason Levine (formerly of WinMag.com). ScriptSentry (which is an improved version of the WatchDog utility at the old WinMag.com site) deals with the WS security threat much more subtly than my EBURGER batch file manages to do, and it has the added benefit of allowing you to keep WS installed and running, albeit in a "safe" environment. You can read about and download ScriptSentry from: http://www.jasons-toolbox.com/scriptsentry.asp Please note that if you install and enable ScriptSentry, it will insert itself into the associations for WS File Types. If you use ScriptSentry, don't also make use of the WS options in my EBURGER batch file -- they conflict. If you are interested in completely uninstalling Windows Script from your computer, you can use another batch file utility that I wrote: the Windows Script (Host) Uninstaller: http://www.spywarewarrior.com/uiuc/resource2.htm#WSH-UN As noted in the "WS (Windows Script) Options" section above, EBURGER also handles "Scrap Objects" (.SHB/.SHS). For more information on the threat represented by "Scrap Objects," see PC Help's insightful page entitled "Scrap Files Can Tear You Up": http://www.pc-help.org/security/scrap.htm ------------------------------ BHO's (Browser Helper Objects) ------------------------------ Browser Helper Objects (BHO's) represent a powerful technology that is available to developers through Internet Explorer 4.0 and above. Perhaps the best introduction to the potential privacy and security risks of BHO's is a WinMag column by Dave Methvin titled, "IE Helpers That Don't Help!": http://content.techweb.com/winmag/fixes/2000/1013.htm Microsoft itself provides a detailed intro to BHO's in a document titled, "Browser Helper Objects: The Browser the Way You Want It" (although some may wonder just who the "you" is here): http://msdn.microsoft.com/library/techart/bho.htm Microsoft also helpfully supplies an example BHO to play around with: http://support.microsoft.com/support/kb/articles/q179/2/30.asp Finally, Adam Stiles offers not only a short intro to BHO's, but a small, free utility called BHOCaptor that gives users a bit more control over BHO's than my EBURGER batch file (which is comparatively crude) manages to do: http://www.xcaptor.org/bhocaptor.php ---------- HOSTS File ---------- Use of a HOSTS file in Windows is one of the easiest, cheapest ways to blocks WWW ads and other unwanted network connections while surfing the Internet. For an introduction to and instructions for the use of a HOSTS file on all versions of Windows, see: - "Web Ad Blocking" http://www.ecst.csuchico.edu/~atman/spam/adblock.shtml - Gorilla Design Studios http://www.accs-net.com/hosts/ Stephen Martin keeps the most extensive and useful HOSTS file of anyone on the Net (9000 plus unique entries and counting). To read about and download Stephen Martin's HOSTS file, see his detailed web site at: http://www.smartin-designs.com/ Several utilities exist to aid users in constructing and managing a HOSTS file for both its originally intended use as well as its use as an ad blocking tool. Three of the more popular ones are: - FastNet http://www.geocities.com/TimesSquare/Stadium/1851/ - CIP http://radsoft.net/gallery/cip/ - Hostess http://accs-net.com/hostess/ And finally, for links to more sites with info about using a HOSTS file as well as links to small utilities to be run in conjunction with a HOSTS file, check out the following pages at my web site at the University of Illinois at Urbana-Champaign: http://www.spywarewarrior.com/uiuc/info2.htm http://www.spywarewarrior.com/uiuc/soft8a.htm ************************** ** A Few Final Words... ** ************************** So why did I make this EBURGER security batch file? The story here is really quite simple: Over the past nine months or so I had put together a number of batch files and .REG files to configure various aspects of Windows security. Many of the methods for configuring or disabling certain aspects of Windows that were incorporated into these batch files were methods that I had learned from articles on the web or in newsgroup postings. I decided I ought to consolidate these batch files into one menu-driven batch file, instead of having shortcuts to all of them littering my "Start" menu. Truth be told, I also wanted something that I could give friends and family who often ask me about how to secure their own Windows boxes, but get that "thousand-yard stare" when I attempt to explain to them just exactly what they need to do. So I came up with this batch file. Now, to be frank, I'll be the first to admit that the methods employed by EBURGER to disable or configure the various aspects of Windows that it addresses are fairly crude. In many cases, there are better, more powerful, and more subtle, programs out there that do the same things that EBURGER does. You can even do many of these things manually right through the Windows interface or by editing the Registry directly. So why would someone want to use EBURGER? There are a few good reasons that I can think of: 1. It's free. 2. It's quick. 3. It consolidates a number of configuration tasks into one menu-driven utility. 4. It's configurable. If you know how to edit batch files or .REG files (Windows Registry) files, you can tweak EBURGER so that it does only and exactly what you want it to do. Indeed, I would encourage folks to open up EBURGER, as well as all the .REG files it uses, in Notepad and take a look around. There's nothing that EBURGER does that is THAT complicated. So, please, use EBURGER to your heart's content. Take a look "under the hood." Hack it however you like for your own uses and purposes. Or, maybe, don't use it all, if you've found better methods for addressing these privacy and security issues. Lastly, I should tell you that I have personally tested EBURGER on the following systems: - Windows NT 4.0 (Workstation) w/ SP6a and Internet Explorer 5.01 w/SP1 - Windows 95C (OSR 2.5) w/ all the MS updates and Internet Explorer 4.01 w/ SP2. I have also had the opportunity to nose around a Windows 2000 box, and I even exported some .REG files for use in EBURGER. I have not had the opportunity personally to test EBURGER on the following OS's: - Windows 98 - Windows 98SE - Windows Me - Windows 2000 I have had reports from users of all these OS's, though, that EBURGER works fine on these versions of Windows. And need I say it again? BACK UP YOUR REGISTRY. Please. I would be most interested to hear from users of any version of Windows, but esp. Windows 98, 98SE, Me, and 2000, and to get reports on how EBURGER fairs on those versions of Windows. If you do reply, please be sure to specify the following: - the exact version of Windows you use; - the exact version of Internet Explorer installed on your system. And please do feel free to send me exported copies of any Registry keys on your system as .REG files, esp. if you notice crucial differences between EBURGER's .REG files and what you see in your Registry. ************************** ** Problems & Questions ** ************************** I hope you find the EBURGER batch file utility helpful in your attempts to ensure your privacy and security while using Windows. If you run into serious problems with the EBURGER batch file utility, and you have made every attempt to address the problem but remain stumped, I can be reached at: eburger68@myrealbox.com Please keep in mind that my busy schedule may not allow me to respond immediately. I will attempt to get back to you, though, and address your questions. Other helpful resources for getting answers to questions about Windows security and privacy include the GRC Privacy & Security news groups, which are generously hosted by Steve Gibson of Gibson Research (GRC): http://grc.com/discussions.htm I've found the folks who hang out in these groups to be helpful, knowledgeable, passionate, and more than wise to the wiles of the marketing droids and other unsavory entities which infest the Net. Finally, you might also check out my web site at The University of Illinois at Urbana-Champaign, a site which contains a bevy of links to information and software relevant to Privacy & Security on the Internet: http://www.spywarewarrior.com/uiuc/ ------------------------------------------------- Date: 1/8/01, 4/28/01, 3/26/02, 4/14/02, 5/24/02, 5/28/02 From: http://www.spywarewarrior.com/uiuc/ Made By: Eric L. Howes (eburger68@myrealbox.com) ------------------------------------------------- Copyright (c) 2000-2002 Eric L. Howes This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Some files distributed with this package may not be covered by the GNU GPL. Those files remain the property of their original owners and are covered by the licenses under which they were originally distributed. All trademarks are the property of their respective owners. You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.