The anti-trojan tests found on this page and the Informal Trojan Detection Test # 1 page are now a year old. All of the applications that were tested have been updated since these tests were performed -- some several times. In many cases, new functionality has been added to those applications. Consequently, the relevance and meaningfulness of these tests is much less than it was a year ago when these tests were first posted. Please keep that in mind as you look over these tests.

Also, due to space limitations on the UIUC server which hosts these pages, the screenshots for each test result have been removed. Thus, clicking on the numbered links to view screenshots will give you a "page not found" error. If you are interested in obtaining a complete copy of the tests with the screenshots as originally posted, please contact me at eburger68@myrealbox.com . I am more than happy to supply interested parties with complete copies of the tests (probably burned onto a CD-R and delivered via snail mail).

If you read the web page detailing my previous series of Informal Trojan Detection Tests, then you'll recall that popular anti-virus and anti-trojan applications can encounter difficulties when confronted with trojan servers that have been packed with the many executable compression programs available on the Internet. 

In response to a number of questions about how well other applications would perform under the same conditions, I've run a new round of tests. As before, I used the Sub7 2.13 MUIE server, packed several different ways (and even left completely unpacked in one case). Once again, I selected seven programs to test: four dedicated anti-trojan programs and three standard anti-virus programs. I also ran the same types of tests as before, mixing on-demand scans file scans with tests designed to check the performance of real time memory and process monitoring components. 

In essence, this is the same series of tests as performed in the original Informal Trojan Detection Tests, but with a different set of applications.

The results of these tests are detailed below. Before you jump to any hasty conclusions based on what you see here, please take the time to read the Disclaimers & Limitations section at the end of this document. 

I would also urge you read the Note On Re-testing for an explanation of the updates to this page made since its initial release.

I hope you find these tests interesting and useful.

Seven anti-virus or dedicated anti-trojan programs were tested. Every attempt was made to get recent engine and database updates for each program. Configuration options of note are detailed for each application.

Note: All programs' options were left at their defaults unless noted above or in specific tests below..

For links to all of these applications on the web, see the Links section at the end of this document.

Tests were performed with six files, each a version of Sub7 2.13 MUIE server, a common RAT (Remote Administration Trojan). Only the third file (THAT-PACKED.EXE)  was left un-manipulated. All other server files were compressed or edited as described below.

To compress servers, servers were first packed with one of the compression programs listed above with the programs' default options. In the case of THAT-ASPROT.EXE, the server was compressed w/ ASProtect with the following options: Max compression & Preserve extra data. 

The packed servers were then edited with the Sub7 2.13 MUIE EditServer.exe to append server configuration options.  Server configuration options were the defaults (startup method: WIN.INI, installation: use random name, automatically start server on 27374). In the case of THAT.EXE (the unpacked server), the configuration options were: startup method: WIN.INI & registry-Run, installation: THAT-EDIT.COM, automatically start server on 20000.

This set of trojan files is the same set that was used in Informal Trojan Detection Test # 1.

For links to all the compression programs used, see the Links section at the end of this document.

Each application was run through a set of three tests. In each test, all six of the server test files detailed above were either scanned or launched. Thus, each application (w/ the exception of two) was tested a total of 18 times (3 main tests x 6 test files = 18 total tests). F-Prot and TDS-3 were excluded from Test # 2-B (see below for more details about the reasons). 

Note: No cleaning/disinfecting of any type was performed by the programs being tested (unless noted below). The programs were configured  to "report only" and/or prevent program load. Any trojan servers launched were killed from memory with PrcView and changes to auto-start locations (the Registry, WIN.INI) were reversed with MSCONFIG.EXE or System Mechanic. Finally, any trojan servers copied to C:\WINDOWS were deleted.

This set of tests is the same set that was run in Informal Trojan Detection Test # 1.

Every attempt was made to regularize the system on which the tests were performed as well as the conditions under which they were performed.  The tests were conducted over two days (3/14/02 - 3/15/02). No new applications were installed during that time on the test system. Neither were any major system configuration changes made.

This is essentially the same system setup as was used in Informal Trojan Detection Test # 1, with these key differences:

• system hard drives are a Quantum Firewall 2.25 GB (primary, 2 partitions) and a Seagate Medallist 540 MB (secondary); drives on the original system were a Western Digital 20 GB (primary, 9 partitions) and a Seagate Medallist 540 MB (secondary)
• system CD-ROM is a Toshiba XM-6302B; the original system used a Philips CDRW 800
• ZIP drive is a ZIP100 Internal IDE; original system used a ZIP100 Plus w/ a SCSI connection

In the "Detect?" row of the test results below:

1 indicates that a trojan was detected. You can click on the 1 to see the corresponding screenshot. 1, 2 indicates that a trojan was detected and that there are multiple corresponding screenshots (multiple numbers do not indicate multiple trojans detected). 

--- indicates that no trojan was detected. --- / --- indicates that no trojan was detected and that there are multiple corresponding screenshots.

In all cases, please read the "Comments:" that follow the "Results:" for an explanation of the "Results:" and the corresponding screenshots.

The first test involved a simple file scan of each folder in which the trojan servers were loaded. This test forced the applications to rely exclusively on "signature" scanning. Scans were conducted one folder at a time. Every main folder that was scanned was empty of all other files and folders except the trojan server files and the sub-folders in which they were stored.

Notes: The main scanning application was loaded and a series of scans performed.

Results:

Comments: ANTS 2.1 detected the Unpacked server and the default Packed server. It missed all the other packed servers. Presumably, the Unpacked and Packed servers would be the easiest to detect. This performance puts it roughly on par with two of the other applications tested..

Notes: The main scanning application was loaded and a series of scans performed. The "Complete Test" was used to perform scans, though the specified "Test Files" for the "Complete Test" were adjusted for each scan. AVG 6.0 automatically removed detected trojans ("Automatic Healing") and provided no apparent way to turn this feature off for manual file scans. After scans were run with AVG 6.0, deleted trojans were restored from backup. 

Results:

Comments: AVG 6.0 detected the Unpacked server and the default Packed server. It missed all the other packed servers. Presumably, the Unpacked and Packed servers would be the easiest to detect. This performance puts it roughly on par with two of the other applications tested..

Notes: As BOClean does not perform on demand file scans, BOClean was excluded from this test.

Results:

Comments: BOClean works primarily as a resident, real time memory/process scanner. See the BOClean home page for more information.

Notes: The main scanning application was loaded and a series of scans performed.

Results:

Comments: VirusScan 5.21 detected every trojan server, except the ASPack-ed server embedded in an .RAR file. This was the best on-demand file scanning performance of all six applications tested.

Notes: The main scanning application was loaded and a series of scans performed.

Results:

Comments: Norton AntiVirus 2000 failed to detect all but the default Packed server. Surprisingly, it even missed the completely Unpacked server. This performance makes it one of the worst performers for this on-demand file scanning test..

Notes: The main scanning application was loaded and a series of scans performed.

Results:

Comments: PestPatrol 3.0 detected the Unpacked server and the default Packed server. It missed all the other packed servers. Presumably, the Unpacked and Packed servers would be the easiest to detect. This performance puts it roughly on par with two of the other applications tested...

Notes: The main scanning application was loaded and a series of scans performed by selecting a folder to scan from the main program window and then running "Full Scan."

Results:

Comments: TrojanHunter 2.53 detected every trojan. This performance puts it at the top of all the applications tested for on-demand file scanning.

Re-test Notes: In the initial tests run with Ruleset Update 25x-2002-03-08, TrojanHunter detected none of the trojan servers. TrojanHunter does allow users to grab "signatures" from files and use those signatures to generate new custom File Rules. During re-testing it was determined that TrojanHunter would detect all six trojans if File Rules were added for each of the six trojan files. Still further, after Update 25x-2002-03-18 was applied manually (with the custom File Rules removed), TrojanHunter detected all six trojan files.

In this test the application's monitoring component was started, and then each trojan server was loaded into memory one at a time. This test allowed the applications to detect trojan servers not only on their signatures, but also on their changes to auto-start locations as well as their attempts to set up to listen in on ports.

When launched, each trojan server attempted to copy itself (usually w/ a randomly chosen name) to C:\WINDOWS, thus leaving two copies of itself on the hard drive: one in the original location, one in C:\WINDOWS. Each trojan server then attempted to launch the renamed copy it had made of itself from C:\WINDOWS. Finally, each trojan tried to edit the Run= line of WIN.INI to launch the renamed copy of the server in C:\WINDOWS on reboot.. In the case of the unpacked THAT-UNPACKED.EXE, the server also attempted to add the copied server to the Registry auto-start location HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

In the case of the RAR'd THAT-ASPACK.RAR, the RAR file was opened with WinRAR 2.80 and then the THAT-ASPACK.EXE contained within the archive was launched from within the RAR file. This process of launching the server from within the RAR file created an additional copy of the server in the TEMP directory (E:\TEMP) on top of the original server file and the renamed copy in C:\WINDOWS. 

Given the original and copied files, as well as the changes to the auto-start locations, there were several things that could be detected:

• the original file (launched, but closed by itself after starting a renamed copy of itself from C:\WINDOWS)
• the renamed/copied file (loaded from C:\WINDOWS and listening on one port)
• the changes to the Run= line of WIN.INI (and the changes to HKLM\...\Run for the Unpacked server)
• the un-RAR'd file in the TEMP directory from the original .RAR file  (ASPack/RAR server only)

None of the applications tested ever identified the un-RAR'd file in the TEMP directory. 

If trojan servers successfully loaded, they were killed with PrcView, copied servers deleted from C:\WINDOWS, and any changes to auto-start locations reversed between tests. 

Notes: As ANTS 2.1 does not have a real time memory/process scanning component, it was excluded from this test.

Results:

Comments: ANTS 2.1 works primarily as an on-demand file scanner. See the ANTS home page for more information. 

Notes: The Resident Shield was loaded at system startup.

Results:

Comments: AVG 6.0 detected only the Unpacked and default Packed servers as they attempted to load. When AVG 6.0 detected a trojan loading, it entirely stopped the trojan from loading and popped up a warning box, which read (no screenshot available):

In so doing, AVG 6.0 effectively prevented a trojan copy from going to C:\WINDOWS and also prevented the WIN.INI and Registry auto-start locations from being edited. (The screenshots included for the Unpacked and default Packed servers show Windows error messages after AVG prevented those servers from loading, not AVG 6.0's warning as rendered above.)

Notes: BOClean was loaded at system startup.

Results:

Comments:  BOClean detected all six servers as they attempted to load. When BOClean detected a trojan loading, it did not prevent the trojan from loading but did offer to kill it. If BOClean was allowed to kill the running trojan, BOClean successfully killed the running process, removed the WIN.INI Run= edit, and removed the trojan copy from C:\WINDOWS. It left the HKLM/.../Run  entry in the Registry (now invalid) for the Unpacked server, however.

Re-test Notes: In the initial tests run with Update 03/13/2002 23:31:28, BOClean detected only two of the trojan servers (Unpacked and default Packed). Once Update 03/17/2002 23:17:00  was applied, BOClean detected all six trojan servers.

Notes: VShield (System Scan only) was loaded at system startup.

Results:

Comments: VirusScan 5.21 detected every single trojan as it attempted to load. When VirusScan 5.21 detected a trojan loading, it completely stopped the trojan from loading, thus preventing a trojan copy from going to C:\WINDOWS and also preventing the WIN.INI and Registry auto-start locations from being edited.

Notes: Auto-Protect was loaded at system startup.

Results:

Comments: In five of the six trials for this test, NAV 2001 failed to detect the trojan itself as it loaded (the default Packed server being the only exception), but did detect the trojans' attempts to write to WIN.INI. When NAV 2001 detected a write to WIN.INI, it popped up a warning and offered to stop it (no screenshot available):

It still allowed the write to HKLM\...\Run (for the Unpacked server), allowed the trojan to be copied to C:\WINDOWS, and allowed the trojan to load into memory, even after stopping the write to WIN.INI. (Note: the screenshots available for these five instances show the trojan server running in memory after Norton AntiVirus prevented a write to WIN.INI, not the warning box detailed above.)

In the one case that NAV did detect the trojan as it attempted to load (the default Packed server), it stopped the trojan from loading, giving the user a menu of potential actions. In so doing, it prevented the trojan from being copied to C:\WINDOWS and prevented a write to the WIN.INI Run= line.

Notes: As PestPatrol 3.0 does not have a real time memory/process scanning component, it was excluded from this test.

Results:

Comments: PestPatrol works primarily as an on-demand file scanner. See the PestPatrol home page for more information. 

Notes: TrojanHunter Guard was loaded at system startup. 

Results:

Comments: TrojanHunter Guard caught every trojan as it loaded. When TrojanHunter Guard detected a trojan loading, it did not prevent the trojan from loading, but would kill the process and rename the trojan file that had been copied to C: \WINDOWS.

If "Automatically remove trojans" was not selected in TrojanHunter Guard,  TrojanHunter Guard offered to kill the running trojan process (see example screenshots 1 & 2). If  "Automatically remove trojans" was selected in TrojanHunter Guard,  TrojanHunter Guard killed the running trojan process outright  without further user intervention (as shown in all the other screenshots).

In both cases, TrojanHunter Guard successfully killed the running process, removed the WIN.INI Run= edit, and renamed the trojan copy in C:\WINDOWS with the extension .TCF. It left the HKLM/.../Run  entry in the Registry (now invalid) for the Unpacked server, however.

Re-test Notes: In the initial tests run with Ruleset Update 25x-2002-03-08, TrojanHunter detected none of the loading trojan servers. TrojanHunter does allow users to grab "signatures" from running processes and use those signatures to generate new custom Process Rules. During re-testing it was determined that TrojanHunter would detect all six trojans if one Process Rule was added for the Unpacked trojan file. Still further, after Update 25x-2002-03-18 was applied manually (with the custom Process Rule removed), TrojanHunter detected all six trojans as they loaded.

During the initial tests, TrojanHunter Guard (build 581) also had issues renaming the trojan files that had been copied to C: \WINDOWS and removing the WIN.INI Run= edit. After build 588 was installed, TrojanHunter Guard successfully renamed all copied trojan files and removed references to those trojan files from WIN.INI.

In this test trojan servers were loaded into memory one at a time, and then each application's monitoring component was launched. This test allowed the applications to detect trojan servers based not only on their signatures, but also on their changes to auto-start locations and their listenening on pre-designated ports.

When launched, each trojan server copied itself (usually w/ a randomly chosen name) to C:\WINDOWS, thus leaving two copies of itself on the hard drive: one in the original location, one in C:\WINDOWS. Each trojan server then launched the renamed copy it made of itself from C:\WINDOWS. Finally, each trojan edited the Run= line of WIN.INI to launch the renamed copy of the server in C:\WINDOWS on reboot.. In the case of the unpacked THAT-UNPACKED.EXE, the server also added itself to the Registry auto-start location HKLM\SOFTWARE\Microsoft\Windows\Current Version\Run.

In the case of the RAR'd THAT-ASPACK.RAR, the RAR file was opened with WinRAR 2.80 and then the THAT-ASPACK.EXE contained within the archive launched from within the RAR file. This process of launching the server from within the RAR file created an additional copy of the server in the TEMP directory (E:\TEMP) on top of the original server file and the renamed copy in C:\WINDOWS. 

Given the original and copied files, as well as the changes to the auto-start locations, there were several things that could be detected:

• the original file (launched, but closed by itself after starting a renamed copy of itself from C:\WINDOWS)
• the renamed/copied file (loaded from C:\WINDOWS and listening on one port)
• the changes to the Run= line of WIN.INI (and the changes to HKLM\...\Run for the Unpacked server)
• the un-RAR'd file from the .RAR file in the TEMP directory (ASPack/RAR server only)

None of the applications tested ever identified the un-RAR'd file in the TEMP directory. 

Between tests, the trojan servers were killed with PrcView, copied servers deleted from C:\WINDOWS, and any changes to auto-start locations reversed. All monitoring programs were closed in between tests and then restarted after the next trojan server was loaded.

Notes: As ANTS 2.1 does not have a real time memory/process scanning component, it was excluded from this test.

Results:

Comments: ANTS 2.1 works primarily as an on-demand file scanner. See the ANTS home page for more information. 

Notes: AVG Control Center was started, but with Resident Shield disabled. After trojans were loaded, AVG Resident Shield was activated from the AVG Control Center.

Results:

Comments: Although AVG Resident Shield did eventually detect the Unpacked and default Packed servers running, it is important to recognize that the Resident Shield initially missed these trojans when Resident Shield was activated through the Control Center. Only when a trojan was directly accessed (for example, in the PrcView process list) or if a reboot was forced would AVG Resident Shield detect the trojan and pop up the warning box (no screenshot available):

If the trojan was already running (as was the case when it was accessed through the PrcView process list), Resident Shield would NOT shut down the trojan, however. In such cases, the copied trojan was left in C :\WINDOWS.  AVG always left the modifications to Windows auto-start locations (WIN.INI Run= and HKLM\...\Run) intact.

AVG 6.0's behavior in this test is similar not only to that of McAfee VirusScan and Norton AntiVirus (see below), but also to what was seen with Innoculate IT PE and Kaspersky Labs AVP on the original set of trojan detection tests. See the "Comments" for both applications on Test #2-B on the original Informal Trojan Detection Test page.

(Note: The second screenshot for the Unpacked server shows the Windows error message that resulted after Resident Shield prevented the trojan loading from WIN.INI on reboot. All other available screenshots show Resident Shield running while a trojan server is in memory.)

Notes: After trojans were loaded, BOClean was launched from the Start menu.

Results:

Comments: After BOClean was launched, it detected all six trojan servers. When BOClean detected a trojan in memory, it offered to kill it. If BOClean was allowed to kill the running trojan, BOClean successfully killed the running process, removed the WIN.INI Run= edit, and removed the trojan copy from C:\WINDOWS. It left the HKLM/.../ Run entry in the Registry (now invalid) for the Unpacked server, however.

Re-test Notes: In the initial tests run with Update 03/13/2002 23:31:28, BOClean detected only two of the trojan servers (Unpacked and default Packed). Once Update 03/17/2002 23:17:00 was applied, BOClean detected all six trojan servers.

Notes: VShield was loaded at system startup, but with System Scan disabled. After trojans were loaded, System Scan was enabled through the VShield tray icon (Properties >> System Scan)

Results:

Comments: While VShield System Scan eventually detected all six running trojans, it initially missed these running trojans when System Scan was loaded. Only when the trojan was accessed (from the process list or System Mechanic's StartUp Manager, for example) would System Scan pop up a warning that offered a range of options. The options offered by System Scan were not always effective, though, and the user was required to go through a whole series of unsuccessful attempts at deleting or quarantining the trojan files before System Scan finally removed the trojans:

• When "Delete" was selected and System Scan reported that the trojan had been successfully deleted from C:\WINDOWS, the original process was left running in memory. 
• When C:\WINDOWS was manually checked through Windows Explorer, however, it was discovered that the trojan file was STILL in C:\WINDOWS. 
• Again, System Scan popped up a warning, and multiple attempts at deletion and quarantine through System Scan failed, though System Scan still insisted it had deleted or quarantined the trojan. 
• Only when the process was killed through PrcView was System Scan finally able to remove the trojan from C:\WINDOWS. 

Even when finally deleting the trojan from C:\WINDOWS, however, System Scan left the edits to Windows auto-start locations.

As was the case with AVG 6.0 (see above) and Norton AntiVirus (see below), if the system was rebooted, System Scan would stop the trojan trying to load on reboot and offer to delete it. Again, though, all changes to Windows auto-start locations remained intact.

VirusScan's behavior in this test is similar not only to that of AVG 6.0 (see above) and Norton AntiVirus (see below), but also to what was seen with Innoculate IT PE and Kaspersky Labs AVP on the original set of trojan detection tests. See the "Comments" for both applications on Test #2-B on the original Informal Trojan Detection Test page.

(Note on screenshots: the three screenshots for the Unpacked server are examples from the series of attempts to delete the Unpacked trojan file with System Scan. The screenshots for the other trojans show only the initial popup box from System Scan when running trojan servers were accessed with PrcView, though the same series of problems deleting the trojan files were experienced with these other trojans.)

Notes: After trojans were loaded, Auto-Protect was enabled and launched from the main NAV application window (Options >> Auto-Protect).

Results:

Comments: NAV Auto-Protect detected only one of the previously loaded trojans: the default Packed server. Even in this instance, though, Auto-Protect initially missed the loaded trojan when Auto-Protect was launched, just as AVG 6.0 and McAfee VirusScan did. When the trojan process was selected from the PrcView process list, NAV popped up an alert (no screenshot available), giving the user a range of options.

 "Delete" was selected, but NAV reported that it failed to delete the trojan, giving the following warning (no screenshot available):

 Quarantine was then selected, but NAV reported that it failed to quarantine the trojan, again providing the warning (no screenshot available):

Finally, "Continue" was selected and PrcView was used to kill the process, still leaving the trojan in C:\WINDOWS. When C:\WINDOWS was manually accessed with Windows Explorer, NAV popped up yet another alert with a range of options. This time "Delete" succeeded, indicating that killing the process with PrcView first was the key. All auto-start references to the trojans were still left in WIN.INI and HKLM\...\Run, however.

As was the case with AVG 6.0 and McAfee VirusScan, if the system was rebooted, System Scan would stop the trojan trying to load on reboot and offer to delete it, resulting in a blizzard of error messages, after the trojan file was deleted from C:\WINDOWS. Again, though, all changes to Windows auto-start locations remained.

NAV's behavior in this test is similar not only to that of AVG 6.0 and McAfee VirusScan (see above), but also to what was seen with Kaspersky Labs AVP and Innoculate IT PE on the original set of trojan detection tests. See the "Comments" for both AVP and Innoculate IT PE on Test #2-B on the original Informal Trojan Detection Test page.

Notes: As PestPatrol 3.0 does not have a real time memory/process scanning component, it was excluded from this test.

Results:

Comments: PestPatrol works primarily as an on-demand file scanner. See the PestPatrol home page for more information.

Notes: After trojans were loaded, TrojanHunter Guard was started from the Start menu.

Results:

Comments: After TrojanHunter Guard was launched, it caught every previously loaded trojan. When TrojanHunter Guard detected a trojan, it would kill the process and rename the trojan file that had been copied to C: \WINDOWS.

If "Automatically remove trojans" was not selected in TrojanHunter Guard,  TrojanHunter Guard offered to kill the running trojan process (see example screenshots 1 & 2). If  "Automatically remove trojans" was selected in TrojanHunter Guard,  TrojanHunter Guard killed the running trojan process outright without further user intervention (as shown in all the other screenshots).

In both cases, TrojanHunter Guard successfully killed the running process, removed the WIN.INI Run= edit, and renamed the trojan copy in C:\WINDOWS with the extension .TCF. It left the HKLM/.../Run  entry in the Registry (now invalid) for the Unpacked server, however. 

Re-test Notes: In the initial tests run with Ruleset Update 25x-2002-03-08, TrojanHunter detected none of the loaded trojan servers. TrojanHunter does allow users to grab "signatures" from running processes and use those signatures to generate new custom Process Rules. During re-testing it was determined that TrojanHunter would detect all six trojans if one Process Rule was added for the Unpacked trojan file. Still further, after Update 25x-2002-03-18 was applied manually (with the custom Process Rule removed), TrojanHunter detected all six loaded trojans.

During the initial tests, TrojanHunter Guard (build 581) also had issues renaming the trojan files that had been copied to C: \WINDOWS and removing the WIN.INI Run= edit. After build 588 was installed, TrojanHunter Guard successfully renamed all copied trojan files and removed references to those trojan files from WIN.INI.

In this series of tests with several compressed variations of one well known trojan server, three applications turned in noteworthy performances:

• McAfee VirusScan, though it encountered severe problems when deleting trojan files while there were still 
  actively running trojan processes;
   
• BOClean, though an update had to be applied to enable BOClean to detect all six trojan servers;
   
• TrojanHunter, though a Ruleset update and an updated build of TrojanHunter had to be installed to enable it
  to detect all six trojan trojan servers and deal with them properly.

The majority of the other applications turned in "middling" performances, detecting some trojans but missing others, both in the on-demand file scan test and the two memory/process scanning tests. 

As was the case with the original series of Informal Trojan Detection Tests, these results suggest that compressed executables present detection problems that some anti-virus and anti-trojan applications have difficulty addressing. Still further, some of these applications apparently lack the ability to kill running processes, causing severe problems when they attempted to delete trojan files from the hard drive. And even the best performers in these tests missed some files, leaving potentially dangerous trojan servers lying around, just waiting to be launched accidentally or deliberately  -- all potential causes of future havoc on the user's system.

These tests also demonstrate one important point about the unavoidable responsibilities that all users have for their systems. As we've already noted, good anti-virus and anti-trojan applications often don't finish the job. While many of these applications are undoubtedly invaluable tools for combating mal-ware like the Sub7 2.13 MUIE trojan, they can't be completely relied upon to do the job by themselves. Even after an anti-virus or anti-trojan application reports that it has deleted a virus or trojan from your hard drive, it would be wise to investigate further yourself. Important aspects of your system to check are:

• all Windows auto-start locations (esp. the Registry)
• your Windows directory (\WINDOWS or \WINNT) and its key system sub-directories
• running processes

And to check these aspects of Windows effectively, you have to know your system: what processes should be running, what applications are configured to launch on Windows start-up, and what files are typically found in the WINDOWS directory and its main system sub-directories. It would also be wise to run a full file scan scan of your entire hard drive, if you haven't already

In other words, your system is your responsibility. Take the initiative and start getting familiar with it, because you can't count on an anti-virus or anti-trojan application to maintain your system for you.

In response to the initial version of this web page, Privacy Software Corp.and Mischel Internet Security contacted the author. Both requested and received copies of the trojan files used in these tests. Privacy Software Corp. then released a series of updates to BOClean on 3/16 and 3/17. Mischel Internet Security released a Ruleset update on 3/17 and a series of new builds of TrojanHunter on 3/18 and 3/19. (The latest build will be soon be released as TrojanHunter 2.54.) These updates were used in a series of re-tests for BOClean and TrojanHunter that were conducted from 3/16-3/19.

There are those who will say that because these authors and  vendors were allowed to supply updates used in re-testing, the tests have been fatally compromised. In some ways they're right. In other ways, though, the charge misses the point of the tests.