ComLog is a Perl program that sits in front of the command prompt and emulates it, capturing any data typed in and out before transmitting it to the real prompt for execution or before displaying the data on the screen. It could be considered as a wrapper. To do so, the program must be compiled with perl2exe (available from www.indigostar.com) and renamed cmd.exe (this is why it doesn't work on Win9x/Me, these OS use command.com, which allow for smaller files, and I haven't figured how to make a .com file. Besides, it is used for boot-up. If you can help on this one, send me an e-mail). The real cmd.exe has to be renamed cm_.exe (or whatever name you chose, but make sure to change the source code approprietly), because we still need it to execute the commands asked by the user.
So this way, when a user double-click on the command prompt icon, or run cmd.exe from the Start menu, or a cracker issues commands to the prompt by abusing the web server, web browser, database server, mail client, netcat session, etc., or to a renamed or relocated copy of it, it will be thru ComLog that these commands will be issued. ComLog makes a timestamp in the log file (*.clg) between each input and output, allowing the administrator to know things like at what time each event occured, how much time each command took to perform, how much time passes between the result of the last command and the when the next command is issued, etc.
Since ComLog emulates the command prompt, there are certain things we need to keep track of in order to make the session as transparent as possible to the user. Such things to keep track of is the current directory and current drive, and to keep track of this we monitor closely 'cd' command and changes of drive. 'cls' is also a command that I cannot rely on cm_.exe to implement, since it returns an empty screen as output, so we implement that as well. We also have to check if the drive or directory the user wishes to go to really exists, or else ComLog will contain erroneous environment data and will stop working properly. This causes a limitation in the use of the wildcard '*' in directory names (more on that in the next chapter).
That is about all the checking and emulating that is done, all the rest that is typep by the user and/or attacker will be sent as is to the real prompt (cm_.exe), and bad commands will simply produce the expected "The name specified is not recognized as an internal or external command, operable program or batch file." error message, as it normally would.
ComLog always start in the . (current) directory. Issuing cd commands with relative paths will create a relative path chain that will keep track of the current directory. So after browsing a couple of directories out of and back in to C:\WINNT\SYSTEM32(cd..; cd..; cd winnt; cd system32), the path should look like .\..\..\WINNT\SYSTEM32, altough the user will only perceive his current directory. Issuing a cd command with a path starting with \ will replace the whole relative path that built over the session with that absolute path, in order to avoid getting too long and confusing relative path names in memory. Further relative path browsing will be appended to this absolute path, until a new absolute path is entered. Drives and current directories for each drive are kept in a self-adjusting table. Bad directories and bad drives error messages are handled by ComLog, and will replace the user's command with something neutral so not to disturb environment variables. Once these checks are done, commands are sent in the form of cm_.exe /C currentdrive: && cd currentdir && usercommand, the && signs are letting us to issue more than one command on the same line. So this way, the new instance of cm_.exe (which has its own environment variables) is always kept fresh on where the user wants to be. cm_.exe terminates after executing the command. This is why we have to keep track of the environment variables ourselves. The output is captured, sanitized to hide ComLog's prosence, and then sent to its log file and displayed on the screen.
In the first, pre-release version of ComLog, log files were stored in a file called history.txt, that was present in the . (current directory) along with cmd.exe. I thought that this was good, because ComLog would produce a log file wherever it is copied to. But this produced two problems that are now solved with a single solution. First, if two (or more) instances of the same cmd.exe were running, they were all writing to the same log files. So issuing an intensive command like dir \ /s on one instance meant that one command typed in another instance had to wait until the intensice dir finishes before producing its output. The other thing was that having a potentially floating location for the log files, it was hard to keep an eye on it using a tool like LogAgent. This was solved by storing the log files in \WINNT\Help\Tutor, each instance having a random-generated filename associated to it, to prevent collision. ComLog log files have a .clg extension. Take note that if you install ComLog manually (not using the install pack), you have to create the \Tutor folder in \WINNT\Help.
2. Purpose of the program
4. Things you need to know
Table of contents