A Few More Facts About LockDown
Friday, 11 December 1998
After my testing and review of Lockdown 2000, I thought I'd covered all the bases. But on reflection I realized I should revisit this issue again and clear up a few points.
So I've spent what I hope is the last few hours I'll ever spend on this rather unworthy program. Here are the facts I discovered, including a couple of my own errors.
First I should clear up my errors.
In my review, I said: "I searched the LD2000 menus. I hit "refresh." I tried everything. There was no provision to check again for trojans!" Well, I've no wish to be inaccurate, and in fact that's not true:
It isn't much of a check! (I'll tell you more about that below) But I was incorrect when I said there was no provision to run that check again after startup. As you can see above, there's a way to manually re-check for the BO trojan (but not trojanS) while Lockdown runs.
I simply never expected to find it in the pulldown menu under Help; and so never looked there.
I made another error that's a bit more complex to explain. In my review, (please see the relevant section) I described how Lockdown failed to control the connection from another machine on my LAN. My description of its behavior was fully accurate, but my conclusions were not all fully correct.
After examining Lockdown's executable file today, I began to suspect it may actually be capable of disconnecting the LAN-connected machine as it accessed a shared resouce. So I ran a new test.
I found that while in fact I could do practically anything I wanted with the shared drive, something Lockdown did prevent was the transfer of a very large file. So what's going on?
Well, it's essentially this: Lockdown is slow! Very, very slow in computer terms. It requires a large fraction of a second for Lockdown to respond to a share access and to break the connection. Oh, it breaks the connection all right. But not before a large file can be transferred in full and it's too late! The job is done and the other machine doesn't even notice the disconnect! Windows basically ignores the disconnect; it just reconnects on demand. So from the viewpoint of the other machine, Lockdown does nothing.
From a second machine, I transferred a series of files of increasing size to and from the Lockdown machine; and I found the transfers began to be interrupted when they reached around a half megabyte in size. My LAN runs, ostensibly, at 10MBits per second; which means it's taking Lockdown about half a second to act. Imagine if my data rate were 100MBits, as it is on many LANs! A file of 5 megabytes would presumably get by Lockdown before it could respond.
So -- Lockdown DOES disconnect users! After they have almost any file they're likely to want. Then it lets them connect again long enough to do it again. And again. And again...
Because the dialup connection is typically very slow, Lockdown can successfully interrupt most data transfers by that avenue.
For this reason, I assumed it may be adequate to protect open shares on a dialup link.
Wait a second. How long does it take to delete a file? Might Lockdown be slow enough to respond, that an intruder might manage that?
I created a dummy file. Over the dialup link, I sent a simple
And Lockdown responded with a
siren! And the file... was gone. It takes no longer to delete a
huge file. Or a directory for that matter. Or nbtstat. Or what if I tried this command:
It just doesn't get any more pathetic than that, does it?
Incidentally, Lockdown does a very poor job of tracing users. It almost always fails to get an IP address when I attempt to access shares over the dialup connection.
The Secretive Program
After I found Lockdown so gravely ineffective against Back Orifice, and totally oblivious of NetBus, and finally so horribly ineffective at protecting shares, I became more interested in the contents of the Lockdown executable; the program itself. To a significant degree, it is often possible to read the contents of a program file and find out what it's doing.
My programming skills don't run very deep, but I've done this many times with good success. A great deal of information can be gleaned from the ASCII text contained in most programs. I've found Netninja's BinaryTextScan a very handy utility for the purpose.
Ah, but I found Lockdown unreadable!
After a little checking, I determined they had used Shrinker v3.3 to encode Lockdown2000.exe. This made the file a total hash. It's not just shrunk but encrypted. The creators of Lockdown clearly don't want their work examined.
I'm sure they expected this tactic to keep out prying eyes. No such luck.
I think I will refrain from commenting on the method I used to decrypt the Lockdown executable. I may as well keep a little something under my hat, eh? But decrypt it I did, and I have had an interesting time browsing thru its contents. It's 716K in size, and runs just fine in decrypted/expanded form.
The trojan check especially is a complete joke. It is completely obvious that it does one thing, and one thing only. Precisely as I deduced in my review, I found that it simply checks the RunServices key in the Registry, and examines the files that are named in that key, in an effort to find Back Orifice -- and only Back Orifice. It's clearly evident that no other Registry key is checked, and no other trojan is looked for!
It's also clear that the progress bar Lockdown displays while doing its "System Check" runs far more slowly than does the check itself! The progress bar is there for show. The actual check is very rapid, because there isn't much to it.
All the window texts displayed by the program throughout all its functions are in clear text in the program file. There are no warnings that apply to any other trojan, nothing whatsoever but the messages I reproduced as images in my review. The "System Check" isn't a "System Check." It's a check for BO, nothing more, and a sadly inadequate one at that.
A few more tidbits of interest:
I created a textfile containing essentially all of the readable text contained in the Lockdown 2000 executable. It's decidedly not interesting reading. But it does reveal a lot. It shows a great deal about Lockdown's activities, what Windows DLLs it uses, and so forth. There are dozens of names of Windows APIs (Application Programming Interfaces) which speak volumes to a programmer -- especially to one more savvy than I. I welcome the comments of any programmers who might happen to browse this text.