covert operation. The hacker then uploads the program to a BBS and -here's the important part - hopes the sysop runs the program.
You will want to procure a copy of the BBS program before writing a Trojan horse, so that you know exactly what those secret instructions should be doing. Otherwise, how will you know what files to look in or where to go on the disk for information?
What kinds of things can you program a Trojan horse to do? Here are some suggestions:
Have it secretly reprogram the BBS itself to in-clude a trap door. If the BBS program is written in an interpreted language, you can have the Trojan horse add some lines which would give you sysop ccess upon entering some code word. This actu-ally has been done on a popular Commodore 64 bulletin board system that was written in BASIC.
You can program the Trojan horse to look into the password file and send data contained in it back to you somehow. Many BBSs have a text file section. You can have your program encrypt the passwords as it routs them out, then append them to the end of one of the text files. Then you simply log on, view the files, obtain
the encrypted pass-words and decode them. People reading the text files on-line will interpret the seeming random characters as line noise or harmless file corruption.
Another way to get password information back to yourself is to use the BBS's e-mail function. To avoid suspicion (because sysops love to read the e-mail users send to each other) you should, again, encode the information and imbed it within an otherwise bormg piece of e-mail.
A Trojan horse may contain a rough version of some key portion of the BBS program itself. The Trojan then extracts that piece of itself, copying over the legitimate version already on disk.
Covering Up Trojan Horse Activity
There are two things you have to worry about when you upload a program containing a Trojan horse to a system:
1 That your Trojan horse will be discovered while it is running.
2 That it will be discovered either before or after it has run.
I will talk about each of these problems in turn.
While It Is Running
The rational hacker has an easier time of this than does the malicious system crasher. You see, if junior Joe writes a program to covertly format hard drives, something has to be happening on-screen to divert the user's attention while the hard disk drive light flashes on and on and on.... It takes quite a while to format a hard drive. junior Joe has to clev-erly devise some non-interactive time-killer that will hold interest for the length of the format or file de-letions. The time-killer could be a pornographic display (perhaps accompanied by digitized sound effects: "Ohhh! Ooooh baby! Yummm-mee ... !") or a digitized musical score, or perhaps the
program could send graphics to the printer. Meanwhile, you will be using rapid-action Trojan horses (sprinters) which do their thing in short, quick bursts.
Never have your program access the hard drive (or any unauthorized peripheral) for what the sy-sop will think is no reason. When the Trojan horse is actually going about its business, there should be a note on the screen to misinform the sysop as to what the program is doing. For example, if the Trojan horse is hidden in a game, you could have it display the message, "Saving your new high score...", while the program changes around user access files (or whatever your horse is trained to do).
Don't forget, the program actually should be saving the user's high score as well, and the entire drive access time should be very short. As soon as the Trojan horse is finished operating, the program should erase the note from the screen; this will en-sure the drive access time goes unsuspected. If possible, have the note be
erased midway through the Trojan horse's activities, to deliver the illusion of very quick drive access.
Another way to access the drive unnoticed is to have the program say something like this when it is started up:
AutoCheck Virus Detection Program v1.3 (c)opyright 1992 Paul Bradley Ascs.
Scanning file FILENAME.1 for viruses
Scanning file FILENAME.2 for viruses
Meanwhile, the Trojan horse will be scanning the computer's hard disk for passwords!
For FILENAME.1, FILENAME.2, etc. in the above, substitute names of the program and data files that were uploaded with the application. A nice extra touch is to not have the ellipses ( ) writ-ten to the screen immediately. Instead, have the periods appear one at a time between disk accesses, to make it appear that the program is really scan-ning through the different files.
Trojan horse activities can also be covered up under befitting circumstances by such messages as:
Opening data file
Reading data
Saving selections before quitting
Loading text
Messages should always follow naturally from whatever's taking place on the visible program.
Trojan horses that perform BBS functions (such as changing passwords) should do so via direct disk access if possible, and not by utilizing the BBS program. That lets you bypass any security logs and printouts that are made of suspicious activity.
Before & After
Sysops, system administrators, and even regu-lar u-,ers are now wise to the hazards of bulletin board file transfers. They understand at the very least the threat of viruses, and so are more likely nowadays than ever to examine a program care-fully before using it.
This means they will use a virus scanner to check your uploads for viruses. This is almost a given, but it is nothing to be feared since the avail-able virus detection programs will not locate your Trojan horse in an otherwise valid file. What you do have to be careful of, is that the sysop or system manager will manually examine your uploads for filthy words or erratic programming.
As before, malicious crashers and system van-dals have a bigger job ahead of them than you. They have text they have to hide within their programs. For instance, who hasn't heard of a virus or logic bomb that screams "GOTCHA!!" as it overwrites the File Allocation Table? Programs are available that specifically look for this sort of thing in files. Even if the sysop doesn't have one of those pro-grams, if he or she is cautious enough, that crasher's "GOTCHM!" will certainly be discovered before the program is ever run.
Your Trojan horses won't have as much to hide. AU the text in your programs will be text that gets written sensibly to the screen anyway, text that is either part of the application program, or text that looks like it comes from the program, but is actually used to blanket your Trojan horse. Also, your program won't have any "format &' commands sticking out like sore thumbs. Thus, your job is easier than the crasher's, though it's far from being a snap.
There may be commands in your program to read or write, or to rename private BBS files. These commands, and more importantly, the filenames, must not be discovered by the sysop. It is not good enough to use a simple one-letter-higher cipher to encode commands and filenames; for there are programs which can scan a file and display read-able text it contains. If you just push everything up one letter higher (i.e., "PASS" becomes "QBTT"), those programs will still locate this encoded text -and the sysop might be smart enough to discover what it means. You're better off encoding text using numbers, symbols or foreign alphabets.
A program you upload may be an uncompiled source listing or a batch file. In this case, you will have to do some fancy fingerwork to keep your Trojan horses hidden. NEVER simply upload a batch file in its raw form. Imagine if you were the sysop who got this from a user:
cd BBS\USERS
open USERINFO.TXT
read USERINFO.TXT: User #44
set systemlevel 3 == systemlevel 99
close
exit
This isn't real code. It's meant to illustrate the kind of brazen attempt at upgrading access that would catch a sysop's attention.
One way to eliminate this problem is to have the main application program create batch files and other programs it needs. The batch commands start out as encoded gibberish in the application pro-gram. A subroutine is called, which opens a text file, decodes the commands, fills the file with them, then goes about its business. The creation and use of the file should probably be done on separate oc-casions, to keep illegal drive access time low.
Also for easily-readable sources, the Trojan horse part should not be standing right in front or at the end of the listing. Put it deep within the pro-gram. Add comments that will tend to mislead the careless reader. Remember, if your cover program is particularly clever, the sysop may want to ana-lyze it, to see how you
achieved such a wonderful thing! This means your cover program could be under some heavy scrutiny; and your Trojan horse could be discovered by accident.
Consider having your program delete the Tro-jan horse after it has been executed. That is, have the last few steps the Trojan horse takes be to erase itself from the program.
Alternatively, have the sysop delete the applica-tion prograrn (and thus the Trojan horse). This can be tricky: how can you get the sysop to delete all those files you uploaded, without letting on that something shady is going on below the surface? Ways this can come to pass are by having the ap-plication program be something
that you know the sysop already owns, or something similar yet infe-rior to the sysop's version.
Or you could just write the sysop some e-mail, saying that you found a potentially dangerous bug in the program, "so if you would delete it I will send you a corrected version." This can only be done when the application you sent is a compiled program, elsewise the sysop would be able to correct the problem himself -wouldn't he!
A particularly paranoid sysop might transfer any uploaded files to a different computer before he tries them out. Or the directories could be set up different than expected, or the BBS might be set up to upload files to a floppy instead of the hard drive. Take these things into consideration when you program, and have your
Trojan horse only work when the computer is set up as it is supposed to be. That is, it will only run when it has access to the password files, or whatever else is necessary for the Trojan horse to function. It's also necessary to do this because, if the application that hides your Tro-jan horse is good enough, the sysop will make it available for other users to download.
A Few Tips For The Do-It-Yourselfer
We talked earlier about hacker BBSs. What if you make a dedicated effort at finding a suitable BBS on which you can learn and share, but none turns up in your search? You may want to start a BBS of your own to suit your needs. Get ahold of the proper software, gather your most trustworthy friends together, and put
together your own bulle-tin board system!
Running your own system means that you won't get much use out of your home computer and the telephone line to which it is connected. This would be no problem if all you did on your computer was hack, since your hacking can be taken on the road through the use of laptops, pub-licly available computers and the like. But you most likely use your computer for other sports: game playing, word processing, programming, and legal modem usage. Consider this before you get all ex-cited about setting up a BBS.
One way to get around this problem - and to simultaneously overcome many of the problems that arise when one sets up a BBS - is to use your hacking skills to break into a mainframe far away from your house, and use it for the site of your electronic bulletin board.
Whatever home you give to your system, you should install it with a false front to make it look legit, and a back side that encompasses the private area for accepted hackers only. Invite the hackers whom you know to be wise and trustworthy into the inner sanctum, while leaving the rest of the board open for unknowns to
explore. I have seen some fantastic BBSs go up, only to fail miserably. And I've seen so-so BBSs that quickly establish themselves as the "in" place to be. As a hacker BBS, you won't experience this to such a great extent since you aren't going to advertise as much as a generalized BBS would - after all, you re trying to keep out all the riffraff.
But you will still want new users to come and enjoy them-selves, and if they turn out to be the kind of folks you'd like to invite behind the scenes to your secret hacker sub-section, all will benefit by it.
The strategy for getting users to come in and stay awhile is to set up your BBS, turn it on, then leave it on. Many first-time sysops, excited with the prospect of running their own system, continually take their BBS off-line to make improvements. Don't do that! If someone calls and finds no com-puter is there to pick up, they aren't going to call back a second time. Advertise your BBS on other BBSs whose mem-bers you would like to have on yours.
Have members of your BBS run scouting mis-sions to the above-ground hacker BBSs. You will find out what, if any, useful information is ex-changing hands over there, and you may be lucky enough to discover a hacker who is worthy of becoming a member of your club.
Before you allow an unknown hacker into the secluded realm of your hacker subboards, you should make doubly and triply sure that he or she is not a cop. Real hacker BBSs verify their members by having them go through an initiation procedure which includes recommendations from respected hackers, full disclosure
by the hacker of personal information so that it can be checked, and an autobiography detailing what he or she has done, and what he or she can contribute to the group. Don't be fooled! Verify that this self-proclaimed hacker is not an FBI agent by checking out credit ratings, telephone company data, and positions on other computer systems. You will have to use every inch of your hacking skills to ensure that the personal information that you are given matches a real human being. This isn't paranoia - it is common sense. Many, many hackers have been fooled by impostors pretending to be hackers. The safest thing is to not accept new members into your BBS; but that may not be the smartest thing because it eliminates a possible world full of information that will never expose itself to you. Exploring electronic bulletin boards can be a pleasant pastime. It can sharpen your skills and teach you much about a lot of things. There is such a startlingly large number of BBSs around that a hacker could find himself spending all hours of the day and night connected to them, never to enjoy the thrill of the hack itself. Considering the dangers of hacking, that might not be such a bad fate.
In an upcoming section we will explore more ways you the hacker can protect yourself from the law. But for now let's get back to hacking - some of the best and most useful techniques are yet to come!
