LOCKDOWN 2000 2.5.4 TEST PROCEDURE

(The test was performed in July 1999, this account written August 2001)

The software was installed using its own default installation on a
computer on my home LAN.  The computer system was a Pentium 166 running
Windows 95, with 64MB of RAM, and a 2GB hard drive, with a US Robotics
56K modem and a standard 10/100 Ethernet NIC.

System diagnostic utilities REGMON and FILEMON were run to monitor file
and Registry activity; and while so monitoring, the Lockdown 2000
version 2.5.4 installation program was run. The program, while identical
to the paid version, was not registered; so that its behavior was that
of the time-limited evaluation.

With the FileMon and Regmon utilities still logging activity, 	Lockdown
was run for the first time and set up in a presumably typical
configuration, with defaults unchanged and the local system specified
for monitoring of shared resources.

The FileMon report showed that the Lockdown program was continually
seeking the files MSAFD.DLL, SYSTRAY.EXE and RUNDLL32.EXE in the
nonexistent folder C:\WINDOWS\SYSTEM.  The machine on which Lockdown was
installed, somewhat atypically, had no C:\WINDOWS\SYSTEM folder.
Windows had been installed in C:\WIN95, but at some points in its
activity, the Lockdown program failed to recognize that fact.

To deal with the problem, the C:\WINDOWS AND C:\WINDOWS\SYSTEM folders
were created and the files MSAFD.DLL, SYSTRAY.EXE and RUNDLL32.EXE were
copied to the C:\WINDOWS\SYSTEM folder from the C:\WIN95\SYSTEM folder.

File Sharing functions of Lockdown were tested.  For reference to
methods of test and results, please see the review of Lockdown 2000
version 2.0 on my web site at
http://www.nwinternet.com/~pchelp/bo/LDtest.htm.  The methods of test
and the results were both substantially identical.  There was no
discernible change in the program's performance in this respect.

Port monitoring was examined.  I found, using Netstat, that the program
opened a single TCP port to outside connections:  port number 12345, a
default port used by some versions of the NetBus trojan.  No other ports
were opened and no options existed to open other ports.

Connections to port 12345 and to other ports were tested using the
Netscape web browser, a port scanner, and a utility called Netcat, as
well as a few other methods, from a separate machine, both via the LAN
and via the Internet by means of separate simultaneous modem
connections.  All connections resulted in alarms and identification of
the source IP address of the remote machine.  In each case, regardless
of the nature of the contact with port 12345, Lockdown 2000 reported,
"Received connection request from [IP Address] for NetBus."

No contact with any other port than 12345 was recognized by Lockdown.

Trojan detection was examined.  I found that the trojan "scan" of
Lockdown consisted of an examination of two Registry keys, namely:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

... and the subsequent examination of files named in string values
within those keys.

Note:  Two other similar Registry keys may be used to persistently run
trojans:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

... and also entries in AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, WINSTART.BAT,
WININIT.INI, plus files or shortcuts in the StartUp folder, can each and
all cause programs to run at Windows startup.  Lockdown 2.5.4 examined
none of these other startup methods and so was incapable of detecting
trojans that used any of these as their means of restarting.

Lockdown's trojan detection and recognition was tested, on the following
trojans:

	Back Orifice version 1.20
	NetBus version 1.53
	NetBus version 1.60
	NetBus version 1.70
	Sockets De Troie
	Master`s Paradise version 98.9.3.76
	SubSeven version 1.3
	Hack`a`Tack

I believe there were more trojans I tested but cannot currently recall
which ones.

I examined the trojan signatures.  I quickly determined that the trojan
"signatures" of Lockdown were nothing more than numbers in hexadecimal
format (base 16) which represented file sizes; accompanied by a second
number in decimal format (base 10) which represented a tolerance value,
so that any file of size [size] plus or minus [tolerance] bytes would be
recognized as a specified trojan, regardless of the actual nature or
content of the file.  The presentation of the signatures as
difficult-to-recognize hexadecimal numbers appeared only intended to
obfuscate the nature of the signatures, as it served no useful purpose
whatsoever.  A check for only file sizes is a grossly inadequate means
of identifying trojans.

Each trojan was placed in the SYSTEM folder and each was given an entry
in either  of these Registry keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

Here I observed again the peculiar failure of Lockdown to recognize the
Windows folders correctly.  Lockdown would only "see" files located in
C:\WINDOWS\SYSTEM regardless of the folder in which Windows was
installed.  In order to perform tests, I therefore placed files in that
folder to check the program's trojan recognition, even though the system
under test neither required nor used that folder for its operation. 
Note:  Files located in the Windows folder (whatever it may be named) OR
in its sub-folder SYSTEM OR anyplace else defined by the system variable
PATH will be executed by Registry entries which lack a specified path.
Tests confirmed that Lockdown 2.5.4 omits to examine any folder but
C:\WINDOWS\SYSTEM in such cases.  Thus even on a system with its Windows
folder named C:\WINDOWS, the program will necessarily fail to locate
many trojans that are being successfully executed from any other folder
than C:\WINDOWS\SYSTEM.

Lockdown alerted on the new Registry entries in each case, but it only
recognized some of the trojans.  When no trojan was recognized, Lockdown
asked the user to approve the startup entry.  It recognized Back Orifice
(provided it was within 200 bytes of the specified size of 124,928
bytes), and it recognized my copies of NetBus 1.53, 1.60 and 1.70.  It
recognized none of the other 4 trojans.  In the case of Master's
Paradise, the signatures appeared to contain an appropriate entry but
detection failed.  (Except for SubSeven 1.3, which was relatively new at
that time, all the trojans under test dated from 1998.  The date of that
Lockdown version's executable file was 4/13/99, and the signature file
was dated 5/10/99.)

Response to detection of trojans was noted.  Each time Lockdown
identified a file as a trojan, it produced an alert that a trojan had
been found and that purchase was necessary to effect removal.  The
trojan was not identified.  The registration dialog was presented, and
if a valid registration number was not entered, the program terminated,
that is, closed entirely.


SUMMARY

My review and testing revealed that, contrary to the representations on
the LockDown web site, the software still did not detect and remove all
trojans.  The software was also prone to false alarms or alerts that a
trojan had been detected when, in fact, there had been no intrusion by a
trojan.  The false alarms were significant because, if the user was
using the trial version of the software (and had not yet purchased it),
all alarms were accompanied by a message that told the user if he wanted
to remove the trojan he would have to purchase the software.  The false
alarms could also convey a false sense of security that the software was
protecting the system.  Also, because of the signal sent by the software
to someone just "probing" not actually intruding, the software actually
increased the likelihood that the prober would attempt an actual
intrusion of the system.  The new version also failed to protect shared
files. The details of my conclusions are on my web site at the page
entitled "Test and Review: Lockdown 2000 v2.5.4."  (The detailed testing
procedures were not initially published there, primarily for lack of
time.  Further, within weeks of my review, the version number, then
2.5.4, had been advanced to 4.0, though without substantial change to
the product.  Later, the system on which resided the bulk of the records
of my tests suffered a failure and loss of data.)