ComLog does a pretty good job at pretending to be the real command prompt, but in fact it has some limitations that can affect or not its actor performance, depending on the situations. Some limitations are gone since the pre-release version, but some still remain. First of all, since I mentionned it earlier, there is a limitation in the use of the * wildcard in directory names. In normal circumstances, under NT/2K, you can cd to a directory by supplying only the first few letters followed by a *, which can be convenient with long path names. The limitation occured when I implemented the checkdir() function (which I cannot remove, or else ComLog may be fooled into non-existing directories, and at that point you can kiss your cover goodbye). I tried doing it with the opendir() function, like I did with checkdrive(), but it doesn't support wildcards whatsoever (from my testing, anyway). So I use the same trick as when I send commands, and I use this to make a IF EXIST on the directory (this is usually used only in batch files, since there is little use to make an IF statement on a one-liner, but it works just as well when it is typed in DOS) to validate its existence. And the IF EXIST command cannot handle more than one layer of wildcarded directories. For example, in a ComLog session, let's pretend that I am in the root directory, and I want to move to \Program Files\Common Files. If I type cd pro* [ENTER], cd com* [ENTER], this will work just great. But if I type cd pro*\com*, the program will issue a "The system cannot find the path specified." error message. But under a real NT command prompt, that line should work.
Another problem is that it cannot handle interactive DOS programs, such as a regular FTP session or something as simple as date or time (you have to at least press enter to exit date and time). Since the command prompt output is captured by ComLog, and that ComLog waits for cm_.exe to terminate to continue its execution, and that cm_.exe is waiting for some sort of user input that will not come before quitting, we can see where the problem lies. Under certain circumstances, this is not so much of a problem, for example a web server that the command prompt can be abused with netcat, since netcat won't allow for interactive programs either, so the attacker behavior will already be adjusted to that limitation (or else he will face the same results). But on a local prompt, where a user might want to launch an interactive DOS program (be it a network scanner waiting for its parameters or a mere DOS game), it will be obvious that something is not working right. Launching such a program from the GUI should not pose a problem, but if you must absolutely start a program from a DOS prompt, remember that you can always do so from cm_.exe.
One other thing is that ComLog will try to hide himself from the view of the user, by modifying the output when cm_ or ComLog log files shows up. This will be the case if the user issues a dir or a pslist command to see what files or running programs are present on the system. This have the side effect of having a different file count at the end of the dir commands and the number of files displayed on the sreen (or the user's dumpfile, as he is likely to do). While this has little chance of being detected on directories containing a lot of files, in an empty directory, this might ring a bell to an attacker. Another thing that could give it is that by hiding the bigger file size for cmd.exe (695 kb once compiled with perl2exe, compared to 204 kb on NT and 231 kb on 2K), I drop any files that is the same exact size as ComLog. So, in a directory where you have cm_.exe (204 kb), cmd.exe(695 kb), and you copy cmd.exe to root.exe and produce a dir, you will see cmd.exe(204 kb), but no trace of cm_.exe (that's good) or root.exe (not so good).
Oh!, I almost forgot. If you use ComLog in its Perl format, or if you compile it and is it called comlog.exe or anything else except cmd.exe, it will work as advertised. But when you rename cmd.exe to cm_.exe, and rename ComLog.exe to cmd.exe, ComLog will go on an infinite loop when you try to execute cmd.exe. This is because the compiled program still need a shell environment to start into, and that shell is by default... cmd.exe. So the program just keep launching itself in the useless hope of ever finding a shell environment. It took me quite a while to figure this one out, tried almost everything from changing my COMSPEC variable, editing the registry, patching some Windows executables and DLLs (the later caused my system not to be able to boot anymore. Luckily I had a NT Recovery CD with NTFS4DOS on it, which let me put the original DLLs in place). It turns out that all you need to do is to patch 2 ActivePerl DLL with a hex editor to do the trick. This is where is stored the hardcoded call to cmd.exe that kept haunting me, no matter what change I was applying to my system. The files that need to be changed are p2x560.dll and perl56.dll. Make a backup of these files and open them with a hexadecimal editor. Make a string search for cmd.exe (there's only one instance in each file), and replace the 'd' character with '_'. Of course, you could chose another name, but you have to realize that you are limited to a three characters filename, and that you must change the name evrywhere in the program so that it matches accordingly. Windows 200 involve one more step (not covered with the ComLog shareware install pack, to come later), thanks to Windows File Protection, a feature added in Win2K that lets the system monitor its system files and replace them with the original version if they become corrupted or deleted. This feature, which was inexistant on Windows before, will effectively keep replacing ComLog with the real cmd.exe. This feature can be disabled with a simple registry tweak on Win2K, a DLL have to be patched in addition of the tweak on Win2K SP2. Full details on how to disable Windows File Protection can be found at http://www.jsifaq.com/SUBK/tip5300/rh5392.htm and http://www.lanovation.com/support/docs/NT_2000/WFP_2000XP.htm or by typing 'disabling Windows File Protection' on Google.
The last thing is the giveaway that is the banner displayed at the end of execution when compiled with perl2exe evaluation version. This is why you may want to download the install pack, it is compiled with a registered version of perl2exe.
3. How it works
5. To Install
Table of contents