I'm going to list a few things to be careful of when you implement a program of this kind. My remarks will be directed toward this program in particular, but they are far-ranging enough to be applicable to just about any program like this that you hide on a system.
First, make sure EDLIN is there, as well as DE-BUG, TREE and other external DOS commands. They may not be available on the computer you are using, and you can end up with a mess on your hands, and discovery of your intentions. When you attempt to copy these files you may find that the DOS directory has been write protected. In that case you may have to put the necessary commands in an alternative directory. This might expose them to the ravages of the clean-up program. If the cleaner does delete these external commands you will have to figure out some solution to get them onto the disk and protect them from the
cleaner. This batch only works on text files - EDLIN will mess up binary files. Second, you will have to make sure beforehand that the DOS directory is in the PATH. What that means is, for a particular file to be executable, it must either be located in the current directory, or in a directory that has been predefined (usually
by AUTOEXEC.BAT) as a place for the operating sys-tem to look for files to execute.
This is no problem of course - just add a PATH or CD statement be-fore the first EDLIN - but it is something you could easily overlook, especially if you had to add the special commands yourself to an unusual or unfamiliar directory.
Also notice before installing any programs: will there be enough space on the disk? Enough mem-ory? Does the program try to create the temp file in a locked directory? (If so, open temp in a USERS di-rectory, or some other writable one.) Does a file named "temp" already exist? How about "Corrunandl," "Command2" and "Command3"? There are alternate ways to use this program. In-stead of having the date-changer execute before the clean-up program, it could be run every time the password file gets updated. Though it takes a few seconds to run and that time might be enough to noticeably slow down the user's application pro-gram. Recall
that this program is meant to be used in conjunction with some sort of Trojan horse you've installed; the horse itself will slow down the computer somewhat already, the combination of the two programs might be too much to go unnoticed. The clean-up program might use some other criteria which helps it decide which files to save and which to throw away. You will have to use similar programming techniques to thwart its ad-vances accordingly.
If there is no special clean-up program, the hard drive will be cleaned by an actual human being. That human being might not be clever enough to look outside the designated USERS directory for files, but you have to act as if that person is as clever as you. Anyhow, you never know who else is using a public computer, so
you will have to take measures to hide your precious password files from view.
Here are a few suggestions:
Change the hidden-file attribute so that it is not listed in the directory. Place it in an obscure directory or in an unreach-able one. Try this experiment. Put the following commands into a batch file:
:Start
mkdir dir
cd dir
goto Start
and then execute it from the root directory. After sixteen nestled directories named "dir" are created you will get an error message. Press Control-C and look at what has been created. You will find that within the innermost directory it is impossible to make any more directories - there's a limit to what the computer has been programmed to handle. However, you can use a disk management utility or your own system calls to prune and graft many more directories inside the deepest one.
Those grafted directories will be impossible to see or ac-cess from the DOS shell. If the clean-up program uses the DOS command TREE to scan all the direc-tories, it will crash or freeze once it gets to those il-legally nestled directories you put there. You don't want that to happen: that would lead to discovery of your secret files hidden within that directory. Accordingly, this trick requires that you have the programming prowess to write prune-and-graft programs on your own. Your Trojan horse would have to be able to move the data file from its pro-tected position, then back again afterward.
One thing you are certainly DOS-sophisticated enough to handle is to camouflage the files you want to protect within their directories. DON'T use filenames like SECRET.PSW or HACKER.HA! Use a bit of creativity when naming them. Go into one of the applications directories and see if there are any patterns to file namings. If you see for example, that a spreadsheet has files named AFGRABL.OVL, AFGRAB2.OVL, AFGRAB3.OVL, then name your files AFGRAB4.OVL, AFGRAB5.OVL, etc. Do you think anyone will bother to look at them then? You might want to split up the files, putting each in a separate directory; don't forget to specify the proper drive paths in the batch file that uses these files.
Trojan horses on public access computers can be an excellent way to slowly-butsurely collect passwords for your enjoyment. However, all will be for naught if, when you come back the next day to see what you've reaped, all of your files are gone. Protect yourself, and your handiwork.
Keep in mind as you read about these special programming tricks, that I'm not implying you should actually sit out in the open and edit menus or sift through files looking for passwords. Never do that! You must always first make a preliminary examination of the computer as I described earlier. You will have already copied
over the important and unusual files - in this initial exploration of the computer - and you should have the entire menu program at your disposal. At home and at your Iei-sure, you can write the programs necessary for this kind of hacker attack. Then, once you've finished the programming and editing required, you can go back
for a second session at the public computer, this time secretly installing your mutated versions of their programs onto the system. This reduces the amount of time you will have to spend in a public place doing questionable things to somebody else's computer. It also reduces the chance of error in the things you do.
You must be especially careful with computers that are meant to be used only for short periods of time. Guest registers, as described earlier, are used for the few moments it takes for a person to enter his or her name and identification number. You will look extremely suspicious fiddling around there for forty minutes, taking
notes and inserting disks.
It is not the other users you have to be wary of: they couldn't care less about you, and if anything, will probably mistake you for someone who works in the building. Depending on where you are, you might not even have to worry about being caught by the office or lab managers, computer aides, or whatever the official designation is for the people in charge. If it's a college computer lab being moni-tored by one or two students, they might be curi-ous, but won't pry as long as you don't stay longer than you're supposed to at the computers. It is al-most never a good idea to come right out and admit you are snooping around for the express purpose of gathering data to be used in hacking. A comment such as, "Oh, I just wanted to see how they did this batch file," or some other appropriate explanation, is a good enough excuse for most such people. Some computers are public; many more are private. That is the topic of the next chapter.
