======================================= T H E N E W F O N E E X P R E S S ======================================= The newsletter of the Society for the Freedom of Information (SFI) Electronic Edition Central distribution site is Secret Society BBS (314) 831-9039, WWIVNet 3460, 24hrs ----------------------------------------------------------------------------- The publisher, SFI, distribution site(s), and authors contributing to the NFX are protected by the Bill of Rights in the U.S. Constitution, which specifically protects freedom of speech and freedom of the press. The information provided in this magazine is for informational purposes only, and the publisher, SFI, distribution site(s) and authors are not responsible for any problems resulting from the use of this information. Nor is SFI responsible for consequences resulting from authors' actions. This disclaimer is retroactive to all previous issues of the NFX. We accept article submissions of nearly any sort, about hack/phreak/anarchy/gov't/nets/etc. Send mail to the publisher (The Cavalier) at any of these addresses: WWIVnet [15@3460] WWIVlink [442@13468] VMB (301) 771-1151. hit #, then 140. Ripco [send mail to Silicon Avalanche] Daydream Nation [send mail to Silicon Avalanche] Internet [1098i9@gmuvax2.gmu.edu or 2275a6@gmuvax.gmu.edu] The printed edition of the newsletter is available for $14 (U.S.) per year on paper or $2 (U.S.) for a single copy. Send mail to the New Fone Express, Jackson House Rm 206, President's Park, 10309 Senatorial Lane, Fairfax, VA 22030. Don't forget your name and address. To download the New Fone Express, call Secret Society at (314) 831-9039 and log on as NFX, password NFX, phone# 0000, or see the distribution list elsewhere in this magazine. ----------------------------------------------------------------------------- Highlights for Issue #5/October 1991 ==================================== * SFI's Reason for Existence ... typed by the Cavalier (see article #1) * AT&T NY Phone Crash ... typed by the Cavalier (see article #2) * Using Novell Netware 2.2 ... by the Cavalier (see article #3) * Beginners' ED ... by the Cavalier (see article #4) * "The Law Comes to Cyberspace" ... typed by the Cavalier (see article #5) * Newsletter Policy ... by the NFX 'staff' (see article #6) * Distribution Site List ... edited (see article #7) * Editorial ... by the Cavalier (see article #8) ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- SFI's Reason for Existence This feature is our 'mission statement,' if you will - the reasons for the existence of the Society for the Freedom of Information. Thanks to Olorin the White and Silicon Avalanche for helping us to more precisely define our purpose. We (the founders of SFI) have noticed a growing trend in the attempt to conceal or in other words protect information that, if revealed, would promote personal and group understanding of technology that might otherwise go un-documented. Although we very much acknowledge the right to privacy, we submit that this right only extends to a certain point: The moment a piece of information has the capability of benefitting the general public in their understanding of the world around them, the piece of information should be free to all who would care to inspect it. Attempts to reach this goal should be initially reached by a general exchange of information via the establishment of a newsletter and eventually through the establishment of a BBS, or other such means of electronic discussion and exchange. Also, attempts to provide equal access to information through a network gateway or a public network should be promoted and actively searched for. We are not terrorists; nor law-scoffing individuals by nature. We simply believe in the fundamental international right to equal and free access to information that can have a bearing on or can enrich people's lives, and will try to bring about the implementation of this right by any means available to us. >< ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- AT&T NY Phone Crash Phone failure stalls air traffic Disruption in N.Y. felt nationwide By Kimberly Hayes Taylor and Steve Marshall - USA TODAY Air traffic in and out of New York City resumed late Tuesday after a phone-service failure virtually shut down three airports for almost four hours. Hundreds of flights coast to coast were delayed or canceled when controllers at John F. Kennedy, La Guardia and Newark (New Jersey) airports lost the link that allows communication among themselves or with other U.S. airports. Communications between pilots and air-traffic controllers travel over telephone lines to ground-based radio equipment. AT&T spokesman Herb Linnen blamed an internal power failure in a long-distance switching office in Manhattan. Hours after the 4:50 PM EDT failure, 40 planes loaded with passengers were sitting on the runway at Kennedy, 35 at Newark, 30 at La Guardia. "During the height of the thing, at least 300 aircraft were delayed at metropolitan airports," said Bob Fulton, a spokesperson for the Federal Aviation Administration. Included: flights taking off "from California to Florida" and headed for New York, said FAA's Fred Farrar. Farrar said planes had to be grounded for safety. Without telephone communication, they would "fly willy-nilly." Among diverted flights: a British Airways supersonic Concorde from London, which landed at Bradley airport outside Hartford, Conn. Passenger reaction: at Washington's National Airport, Dominique Becoeur of Paris was "reading, drinking, and thinking" while waiting for a flight to New York. At La Guardia, Ernie Baugh, of Chattanooga, Tenn., said, "I think I will go and have another beer." Flights were reported resuming by 9 p.m. EDT. Linnen said AT&T was busy Tuesday night restoring long-distance service in and out of New York City, which had been interrupted. Some international service also had been affected. (end of article one, 9/18/91) THE BIG HANG-UP Phone crash grounds airplanes, raises anger Phone snag likely won't ground fliers after Oct. By John Schneidawind - USA TODAY The Federal Administration Aviation has some good news for travelers who were stranded at airports, or delayed for hours, the past two days by the New York City telephone outage. If a similar phone disaster strikes next month, hardly any fliers will know the difference. That's because AT&T is close to completing installation of a network of microwave dishes that will supplement, if not replace, the phone lines AT&T uses to relay calls between air-traffic controllers in different cities. Tuesday evening, flights in and out of some of the nation's busiest airports - Kennedy, La Guardia, and Newark, N.J. - were grounded because FAA controllers couldn't communicate with one another. For much of the 1980's, land-based fiber optic lines have been slowly replacing microwave phone dishes phone companies long have used to transmit telephone calls. That's because fiber-optic wires were thought to provide clearer calls than microwave technology. Now, it's becoming apparent that sending some or most telephone calls via wireless microwave might ease the burden handled by fiber-optic cables. In addition, a microwave call could be transmitted point-to-point, bypassing an inoperative switching center when a breakdown or catastrophe occurs. (end of article two, 9/19/91) Customers demand an explanation Experts say outages could continue if systems aren't upgraded By John Schneidawind and Mark Land - USA TODAY The telephone network crashed again Tuesday, this time crippling New York, the world's financial capital. The culprit, a power shortage at an AT&T switching center, left more than 1 million residents without telephone service for up to seven hours. Now the victims, including hundred of people stranded at New York airports, are demanding to know: What's going on? The USA is supposed to have the world's most reliable telephone network. Yet this summer alone, outages have struck Pittsburgh, Los Angeles, Washington, and other cities, disrupting service for more than 11 million people. Why, suddenly, is our telephone network so vulnerable? To answer those questions, USA TODAY has pieced together what happened Tuesday and why. We also look ahead: Experts say the problems could reoccur unless major changes are made in the way the nation's phone networks operate. Why did the network melt down in New York? Blame the heat, at least in part. Like anything else, the phone networks run on electricity. Tuesday's 93-degree heat meant lots of power was needed to air-condition the skyscrapers in lower Manhattan. So at 10 a.m., a worried Con Edison - New York's public utility - asked AT&T to draw electricity for its call-switching computers at 33 Thomas St. from AT&T's own diesel-fueled generators. That was a routine request, but then disaster struck. During the attempted changeover, a sudden surge of electricity knocked out several key devices known as power rectifiers, which failed to switch AT&T's computers from Con Ed's power to AT&T's diesel power. Instead, AT&T's computers began to draw electricity from a battery-operated backup system. Negligence also played a major role. AT&T admitted Wednesday that when the attempted power shift took place, no one physically checked to see that the system was operating on diesel turbines - a routine procedure. Had they checked, they probably would have noticed the system was running on a battery reserve that lasts only about six hours. Also, audio and visual alarms at the switching center apparently went unnoticed. Still, the crash never would have happened had AT&T been able to switch back to Con Edison's power grid at 4:30 p.m., as planned. For some reason, it couldn't. The system then automatically reverted to the battery reserve, which ran out of juice about 20 minutes later, causing the computers to crash. Why did that relatively isolated failure disrupt airline traffic throughout the USA? The Federal Aviation Administration uses AT&T lines to relay air-traffic information from its control center on Long Island to airports from Boston to Washington, D.C. - including New York's three metro airports. With those phone lines down, air-traffic controllers couldn't be sure where planes were, and neither could the planes' pilots. That meant planes at the three airports couldn't take off. Connecting flights at other U.S. airports had to be delayed, and dozens of flights were canceled hour by hour. How many of these switching centers are there? Could this happen somewhere else? There used to be thousands of AT&T switching centers throughout the country. But advances in computer technology let AT&T handle even more calls with fewer switching centers. Today, there are about 100 such computerized switches - including three in lower Manhattan - which AT&T uses to route calls throughout the country. Just one of AT&T's switches can handle 700,000 calls an hour. Switches five years ago handled just 180,000 calls per hour. The more powerful systems complete calls much more quickly and provide much clearer connections. But with greater call-handling power concentrated in fewer places, there's a greater potential for major phone-service outages. What caused the other recent phone outages? Were those power failures, too? No, the culprit in almost every instance was a computer-programming error, commonly known as a bug. Such errors are buried in the millions of lines of computer code used to create a call-switching program. Eliminating every software bug in AT&T's signaling network would be almost impossible because each program contains up to 5 million typed lines of code. As a comparison, a program that runs on a personal computer contains just 1,000 lines of code. One mistake, even a misplaced punctuation mark, can wreak havoc on any computer system, including a telephone network. (end of article three, 9/18/91) >< ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Using Novell NetWare 2.2 This article covers the fundamentals of the use and administration of Novell's NetWare v2.2. Note that while most of the procedures outlined in this document are also applicable to NetWare v3.xx (for the 386 only), there may be some slight differences in structure, etc. Also, if you are working with an ELS-I, ELS-II, Adv. NetWare 2.15, or an SFT NetWare network, you will find minor discrepancies in command operation. ELS-I is the least similar, but the general principles and menu-drive system utilities should be the same. Overview -------- NetWare v2.2 (hereafter referred to as 'NetWare') is part of the most common PC local-area network product line in use today. It has earned the reputation of being the fastest and most reliable LAN server software available today, with a workstation shell that is among the smallest in the industry. Capable of using any computer from 4.77-mHz 8088s to 40-mHz 80486s running DOS versions 3 through 5, it has gained wide favor among the business world -- indeed, many companies consider support for NetWare a must. Requirements ------------ NetWare requires a 286- or 386-based computer with at least 2 MB of memory to run as a file server. It can be run in either dedicated or non- dedicated mode. This file server should be backed up with an uninterruptible power supply, and if dedicated, it should ideally be physically protected. NetWare also needs two special memory-resident utilities to boot up on every workstation; the protocol handler (e.g. IPX, SPX, etc) and DOS3, DOS4, or DOS5, depending on the DOS version used. The underlying network topology can be configured in many ways; NetWare does not mind if you have an Ethernet star configuration, a ArcNet bus topology, or a Token Ring network to operate with. NetWare comes with a large set of manuals in small three-ring binders to read, although not too many people do. NetWare is considered sufficiently hard to install and administer that many people simply hire an outside consultant. Note also that Netware servers have the advantage (from many points of view) of acting like an advanced disk subsystem to the workstations: All programs on a network are executed by the workstation's processor, not the file server's. Installed Defaults ------------------ The account defaults for a NetWare system are SUPERVISOR and GUEST. SUPERVISOR has administrative access, or all rights in every directory. GUEST has a security equivalence to the group EVERYONE, which has a set of easily modifiable default rights. Upon installation, the system will set up four default directories: SYSTEM, LOGIN, PUBLIC, and DOS (this may also be MSDOS, DOS33, DOS5, etc.) Since the network shell operates over DOS, using NetWare is the same thing as using DOS, with the exception of extended file attributes. Both of these accounts are initially left unpassworded. DEFAULT DIRECTORY STRUCTURE: \ ------SYSTEM (PAUDIT, mail dirs, bindery files, etc.) ! !--PUBLIC (FILER, SESSION, SYSCON, NSNIPES, other pub. utils) ! !--LOGIN (LOGIN.EXE, SLIST.EXE, CONSOLE.COM, misc. login) ! !--MSDOS (DOS commands) The file server's hard drives are usually F: through Z:. An exception to this rule is when using non-standard LASTDRIVE settings in the workstation CONFIG.SYS file; however, the vast majority of NetWare setups use F: as the NetWare drive. Other drive letters may be mapped to subdirectories (like the DOS SUBST command) or search drives (like the DOS PATH statement). For example, the drive letter G: can be assigned to the F:\PUBLIC directory. Generally, the search drives are at the end of the alphabet. X:, for example, could be a search drive for the F:\SYSTEM subdirectory. The user might never actually switch to the X: drive, but by its presence as a search drive it is automatically looked-through for commands. Novell Utility Overview ----------------------- Most of the Novell utilities that come with the file server are menu- driven and easy to use. They are all written using the same C menuing library, the name of which slips my mind. The menu structures are simple: when presented with a list (say, of users) hitting ENTER on a user name will edit it. Hitting Insert will insert a user in the list. Hitting Delete will erase the user that the cursor is on. Online help is available by pressing F1. The most prominent utility is SYSCON, or System Configuration. This program controls user access to the server. With SYSCON, the administrator or system entry specialist (SES) can set the times a person can log in, their password, their login script, how much they are billed per K used of disk space, etc. The second-most important utility to the administrator/SES is FCONSOLE, or File Server Console. This program allows you to control file server functions from a workstation, allowing the remote administrator to monitor server statistics, broadcast console messages, knock users off the network, shutdown the file server, etc. PAUDIT and SECURITY, although not menu-based utilities, are extremely important. PAUDIT displays a network log of sorts, describing logins/outs at all workstations, intruder lockouts, important network actions, etc. SECURITY attempts to analyze the network for security holes, checking various aspects of the system configuration and reporting to the administrator any security holes it finds. Two others, SESSION and FILER, allow the user to easily send messages in-between users, perform maintenance on their account, and list other users on the server (SESSION), while FILER allows the user to easily examine the subdirectories and files they have access to. One last important addition: MENU. This program is a menu interpreter for the network that uses menu script files. These files can be named almost anything, and they are accessed by MENU filename.ext. The script files generally have an appearance as follows: %Main Menu,10,10 WordPerfect 5.1 f: cd\wp51 wp cd\ Use SESSION session Logout logout The % sign indicates a new window with a title of Main Menu starting at the X,Y position 10,10. Occasionally a color attribute will follow the screen position. The left-justified items are the menu selections that appear to the user. The tab-justified commands are put into a temporary batch file by the menu processor and executed when the selection is chosen. Quite a simple and easy-to-understand language. Accessing the Network --------------------- To access a Novell network from a workstation, the workstation must either have a "Remote Reset" boot-up PROM in the network adapter, or it must have the two sets of Novell drivers, mentioned earlier (IPX, NET5, etc.). If the workstation is diskless, it will have a Remote Reset PROM to boot up with. This ROM allows the workstation to access the F:\LOGIN subdirectory on the server, which will have a standard AUTOEXEC file for the workstations to boot up with. A sure sign of a Remote Reset PROM is the computer startup message, which will generally give a message saying that it has a boot-up ROM in it. In most cases, the ROM itself is located on the network adapter and is removable. If the workstation boots up from a hard drive, it has the option of not connecting to the network at all: the Novell workstation drivers are TSRs, not CONFIG.SYS-style drivers, so the Novell drivers could be contained in a batch file. A floppy-based workstation will almost always have the traditional set of Novell drivers on the disk, and most floppy workstation users leave the network bootup disk in the drive. The most vulnerable types of workstations are the hard/floppy disk-based ones. But the arguably safest point of access into a Novell network is through a dial- in phone line. With a hard drive system on the workstation, the SES can generally comb through the local directories looking for helpful hints and utilities. A proficiency in MS-DOS is extremely helpful for accessing a Novell network. Often, a user might leave his account and password in a so-called 'hidden' area of the hard drive, in case he forgets. Or perhaps he might have saved some mail there from another user, containing information he would want to keep handy. Hard drives are naturally conducive to having the traditional 'shell monitor' interrupt hack installed on them. And of course, there is the occasional rebellious employee, who keeps NETCRACK on his own system so he can spy on the big boys! Whatever the case, a hard drive-containing workstation is very serviceable. Next down the line is the floppy-based workstation. Although this type of workstation is far less likely to contain anything of interest on the disk, floppy-drive workstations are also far less likely to contain any sort of boot-up local password protection. Not to mention, the user may have a collection of floppies somewhere in the room, with potentially useful information. However, it takes a lot of time and some personally-supplied utilities to make much sense of them. With a few modifications, the shell monitor interrupt TSR can be made to work via a floppy system, but the risk of detection is somewhat higher. This type of workstation lends itself to the NETCRACK approach as well, assuming the SES has it on a compatible floppy. The diskless workstation is quite the irritant of the three, forcing a SES to meticulously hand-hack the accounts in question. Diskless workstations are by their very nature impervious to any sort of viral invasion, and system administrators like them for their entry-resistant qualities. However, this does not mean they are impossible to attack by any means. If the SES has the time, the expertise, and the tools, he can open the case of the workstation, pop the Remote Reset PROM, install a floppy controller card (which in some cases could already be there), and install a floppy drive. For several reasons, this approach is limited to the creative. Another utility freely available on the network F:\LOGIN directory is SLIST. SLIST will list other servers accessible from the workstation, giving the SES a second network to attempt entry on. The LOGIN command is obviously the key to the whole operation. You know it's Netware when it asks you: Enter your login name: Enter your password: Hitting ENTER at both prompts will generally return you to the DOS prompt, unless an incredibly security-aware administrator has encased the LOGIN command in a specially-treated batch file. (I'm not going to go into the process for doing so here, considering once in it, there is no way to break out.) To find all the parameters for the LOGIN command, type LOGIN /?. The most useful parameter for LOGIN is the Noscript parameter, which will put you directly at the Novell prompt when access is gained to the server - aborting the script files that normally execute after you log on, in case the user/administrator has inserted something uncouth, like a non-exitable menu. All this would be well and good if it weren't for some of Netware's intrusion-resistant features. The administrator (through SYSCON) can define limits for incorrect logins, at which point that workstation will be locked out for an amount of time determined by the administrator. He can also set minimum periods of time in which a user must change his/her password. These features make life hard for the non-technologically advanced hand-hacker, so creativity is a must. Life After LOGIN ---------------- After a successful LOGIN, the system login script is executed. Defined by the administrator through SYSCON, this file written in Novell's script language generally bades the user good morning/afternoon/evening, MAPs subdirectories to drive letters and sets up search drives, and terminates. Then the user login script kicks in, setting up personal MAPped drives, firing phasers a few times, and either exiting to a menu or to the DOS prompt. Simple login scripts run along these lines: DOS VERIFY ON MAP G: = F:\WP51 MAP H: = F:\PUBLIC (end of system login script) FIRE PHASERS 3 TIMES MAP I: = F:\MYDIR DRIVE I: EXIT "MENU" (end of user login script) Login scripts are more complicated than that; but those two are general guidelines on what to expect to see. Well, maybe not the FIRE PHASERS, but it DOES exist, and is often abbreviated to FIRE. The first login script would be the system login script, which turns the DOS verify flag on and MAPs the logical G: drive to the F:\WP51 directory and the H: drive to the F:\PUBLIC directory. (Sidenote: Although the G and H logical drives are mapped to those two directories, they are not limited to those two directories.) The second login script would be the user login script, making three phaser noises, MAPping the I: drive to the directory F:\MYDIR, switching to drive I:, and exiting and executing the file MENU.*. Note here that pathnames may NOT be included in an EXIT. If exited to a DOS prompt, the user may then come and go as he pleases through the directories he has rights in. To determine one's rights in a directory, type RIGHTS (assuming there is a search drive MAPped to the F:\PUBLIC directory). To logoff, type LOGOUT. To use Nsnipes, a very important Novell game (er..utility), type NSNIPES. Physical Access to the File Server ---------------------------------- No doubt the serious SES will be wondering by now what the file server is doing at this time. Assuming the file server is running as a dedicated server (Netware 2.2, ELS-x), you will be at the : prompt. This prompt is more or less worthless, with the exception of three commands: MONITOR, DOWN, and CLEAR STATION. The command MONITOR will display the first six workstations in windows on the screen and display a list of the five most recent file accesses they have made. If the network has more than six workstations, the next group of six can be displayed with MONITOR 7, and the next with MONITOR 18, etc. The other command is DOWN, which does exactly what it looks like it's supposed to do - shutdown the file server. If users are currently using the server with active files open, the system will display the warning "ACTIVE FILES OPEN, HALT NETWORK?" at which point you are free to decide the fate of the server. Note that shutting the server down while files are active runs the risk of severely damaging the active files. The command CLEAR STATION will in effect knock a particular workstation off the network, in case it has crashed or has been possessed by evil spirits. The syntax is CLEAR STATION x, where x is the number of the workstation that corresponds to the window on the MONITOR screen. This command is also executable through FCONSOLE. Dialing into Netware -------------------- There are several products, both hardware and software, that allow remote connections to a Netware LAN. I'm not going to go through them, because I haven't had any experience with them, but I can point in the right direction: the July 1991 Byte magazine has a review of six products. They range in speed and LAN-external security, but it is interesting to note that none of them support callbacks and some even dump you into a DOS prompt at the F:\LOGIN prompt. I hope you've been able to make some sense out of this rudimentary guide. As I hope you've inferred, there are various software products out there designed to make an SES's task easier. If there's anyone out there with suggestions, or people who know if I've screwed up somewhere, feel free to drop me a line. And remember, there is no substitute for experience. >< [TC: The Cavalier can be reached at any of the addresses in the header.] ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Beginners' ED This article will cover some of the basic functions of Unix's simple text editor, ED. The Unix system this example was used on is a straight BSD 4.2 using the C shell. By the way, I don't claim to be at all an expert on Unix, but since I've had a little bit of experience with ED, I figured it was worth putting out an overview of this common editor. ED is a Unix-based text editor that comes standard with virtually every version of Unix sold. It has been superseded by VI, a full-screen editor, but ED is a lot easier to use with a glass TTY terminal. In some ways, ED is similar to EDLIN -- the text editor that comes with MS-DOS. Like EDLIN, most commands in ED can be preceded with 'addresses,' or line numbers to perform the specified operation on. For example, the command 2,4d would delete lines 2 through 4. ED also has special metacharacters, most notably the $ and the .. The dollar sign substitutes in to the command the last line number in the file, so typing 2,$d would delete lines 2 through the end of the file, leaving you with line 1. The period indicates the current line that the editor is on. So, in other words, if you just made a change to line 4, and typed .,6d, ED would delete lines 4 through 6. There are other metacharacters, but the $ is arguably of the most importance to the beginner at ED. Another convention in ED is to use a lone period on a blank line to terminate input. For example, when inserting lines, let's say you are inserting before line 6. (So your command would be 6i.) You would type: 6i Blah, blah. This text is inserted before line 6. SFI iz grate. . And then you would be returned to ED's command mode. You, unfortunately, wouldn't be able to tell you were returned to command mode, because ED does not prompt you. You have to know what you just did to use ED effectively. Also, commands in lowercase must be entered in lowercase -- ED distinguishes between lowercase and uppercase commands. To start up ED, one usually invokes ED with the name of the text file to be edited, i.e. ed .login This brings up ED with the .login file. ED will then report the number of characters loaded in, i.e. ed .login 1604 means that the file is 1604 bytes long. At this point, ED is ready for you to enter commands. The basic ED commands are as follows; Cmd ! Description ---------!------------------------------------------------------------------- n ! Lists the specified lines with line numbers. ! Example: 2,4n - List w/ line numbers lines 2 thru 4. ! l ! Lists the specified lines without line numbers. ! Example: 3,7l - List w/o line numbers lines 3 thru 7. ! i ! Inserts text before the specified line number. ! Example: 6i text . - inserts text before line 6. ! d ! Deletes the specified lines. ! Example: 4,$d - Deletes lines 4 through the end of the file. ! c ! Changes the existing lines to lines you specify. ! Example: 4,5c blah. Damnit! . - changes ! the contents of line 4 to blah. and line 5 to Damnit! ! m ! Moves the specified group of lines to a new location. ! Example: 3,7m10 - Moves lines 3 through 7 to lines 11 through 16. ! In other words, make lines 3 -> 7 start after line 10. ! t ! Copies the specified group of lines to a new location. ! Example: 3,7t10 - Copies lines 3 through 7 to lines 11 through 16. ! In other words, put a copy of lines 3 -> 7 after line 10. ! w ! Writes the file back to disk. ! Example: w - Writes the file loaded in at the command line back out. ! w filename - Writes the file back as filename. ! q ! Quits out of ED. ! Example: q - Quits. ! ! ! Allows the ED user to execute a Unix shell command. ! Example: !ksh - Executes the Korn shell, allowing the user to ! execute multiple commands. ---------!------------------------------------------------------------------- There are other commands, but these are the ones that are used the most often. On the print edition, commands entered by the user are underlined. A sample transcript of an ED session appears below: # ed hello 50 1,4l Hello. Is anybody in there? Can anybody hear me? 1,3n 1: Hello. 2: Is anybody 3: in there? Can 2c Is there anybody . 1,3n 1: Hello. 2: Is there anybody 3: in there? Can 3d 1,3n 1: Hello. 2: Is there anybody 3: anybody hear me? 3i in there? Just not if you . 1,4l Hello. Is there anybody in there? Just not if you anybody hear me? !whoami root w pftw 67 q # >< [TC: The Cavalier can be reached at any of the addresses in the header.] ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- "The Law Comes to Cyberspace" The following is a reprint of the essay written by John Perry Barlow and published in the Stop Bit op-ed section of Byte magazine, October 1991. This should help people have a better grasp of the function of the EFF, and even though his essay looks like it was edited by a butcher, the salient points still come through. On May Day of 1990, I received a visit from the FBI in my Wyoming home. Special Agent Richard Baxter of the Rock Springs Field Office was looking for information about something he kept calling the "New Prosthesis" League, a band of computer terrorists apparently bent on giving away the recipe for Macintosh computers. Or something. Like most BYTE readers, I was aware that someone calling himself NuPrometheus had shipped around some Mac ROM source code, but I had dismissed it as a practical joke aimed at irritating the humorless folks at Apple. Which, of course, it did. Agent Baxter's specialty was livestock theft, and the only chips he knew much about were the kind that cows make. So before I could convince him that I was not the perpetrator, I had to spend 3 hours educating him on the nature of the crime. It was a pretty surreal experience for both of us. I realized over the course of this interview that I was looking at the general condition of law-enforcement preparedness in the area of computer crime. And I never like what happens when slightly insecure and well-armed men feel in over their heads. I posted an account of Agent Baxter's visit on The WELL. There it was read by Mitch Kapor, in whom it struck a resonant chord. Mitch had also been questioned in connection with NuPrometheus - he'd been sent one of the disks - and had found the encounter as disorientating as I had. Several days later, Mitch called me from his bizjet. He wanted to know if he could literally drop in and discuss Agent Baxter and whatever else I might know about federal efforts to nab cyberpunks. By then I knew enough to think that the government was charging into the computer underground without much sense of how the Constitution might apply there. We talked about an electronic publisher named Craig Neidorf, who was looking at a possible 31 years in jail for the interstate transport of stolen goods as a result of what strongly appeared to be the exercise of his First Amendment rights. We talked about a massive 14-city raid called Operation Sundevil, in which Secret Service agents had seized 28 computers (including 10 BBSes) and 23,000 disks under sealed warrants. And I knew that none of this equipment and data had ever been returned, even though no arrests had resulted. We talked about Steve Jackson Games, a role-playing-game publisher in Austin, Texas, which had almost been driven out of business after the Secret Service confiscated all its equipment, including the hard disks upon which its next product (a game called GURPS Cyberpunk) resided. Over the course of the afternoon, and without knowing it at the time, Mitch and I started what is now called the Electronic Frontier Foundation (EFF). At first, we thought we might be able to sort things out with a few trips to court. But we hadn't been at this very long before we realized that we had taken on something a lot bigger than a few random police excesses. As we wrote in the mission statement we issued upon announcing the EFF in July 1990: "While well-established legal principles and cultural norms give structure and coherence to uses of conventional media like newspapers, books, and telephones, the new digital media do not so easily fit into existing frameworks. Conflicts come about as the law struggles to define its application in a context where fundamental notions of speech, property, and place take profoundly new forms." We've had a very busy year since those words were written. We intervened on behalf of Craig Neidorf (an embarrassed federal prosecutor withdrew the charges after four days in court), filed suit on behalf of Steve Jackson Games, lobbied at the state and national levels for sane laws relating to computers, fostered a number of conferences and roundtables, addressed numerous gatherings, established several on-line conferences, worked with the press to reduce "hacker hysteria," met with many computer security and law-enforcement officials, and worked for policies that would lead to a National Public Network. A lot remains undone. The electronic frontier remains wild and sparsely populated. But, with Internet growing at a rate of 25 percent per month, it is likely to be flooded soon with newcomers who are not bound by its unwritten customs and etiquette - the electronic equivalent of The Code of the West - which have prevailed since its inception at MIT in the early 1970s. But we have opened the frontier, and they will come, whether we're ready for them or not. >< ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Distribution Sites As of 09/91, the distribution sites with the New Fone Express include: * Secret Society * Solsbury Hill (314) 831-9039 (301) 428-3268 3/1200 bps 3/12/24/9600HST WWIVNet 3460 Usenet feed Central Distribution Site 1500+ text files Blitzkrieg The Logic Board (502) 499-8933 (518) 356-5711 3/12/24/9600? 3/12/2400 bps WWIVNet 5211 WWIVnet 5852 TAP Headquarters A * indicates a system with a 'captive account,' or an account specifically for downloading the NFX. Solsbury Hill may be supporting one in the near future. Many thanks to the sysops supporting the NFX. >< ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Newsletter Policy Recently, I (The Cavalier) have received a letter questioning the inclusion of articles such as "Cracking Confidentials." It is a valid letter, and it gives me the opportunity to lay down how we run the newsletter and the group in general. Note: Despite rules and regulations, we do try to keep an open mind. Complaints and admiration are, believe it or not, taken on equal footing - we're not doing this solely for our health. 1. As this newsletter is the "journal," if you will, of the Society for the Freedom of Information, we publish whatever we have at presstime that is somewhat related to the scope of this newsletter, being primarily "free- speech"-type articles, then hack/phreak info, then 'anarchy,' and then any other topic that does not have a sufficient outlet elsewhere. 2. Articles written by others take precedence over the ones I write. If a newsletter only has my articles in it, I had received no other articles at presstime. 3. I have never edited and never will willingly edit the actual content of an article, beyond checking for spelling and attempting to correct a little bit of grammar. 4. If this newsletter is to survive, we need submissions from other people than myself. I can only stretch my own limited knowledge so far. Those four rules basically make up our ethos for this newsletter. If you like 'em, that's great. If you don't, hey, nobody's forcing you to read this. Not only that, but if you want to see changes, send me suggestions or articles or something. This entire article was in response to a single letter, although I had been meaning to do this for a while now. I hope I'm actually doing something meaningful out there, and thanks for reading. >< [TC: The Cavalier can be reached at any of the addresses in the header.] ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Editorial "A Matter of Honor" Well, for the first time since our first issue, I've been the only author re ORIGINAL articles. While I'm proud of most of what I write, I don't personally know all THAT much. God knows I've spent overmuch time plugging for articles, so I'm not going to do it now, but... just to let you know. I *DO* have to admit that I'm not totally proud of having to type in articles from USA TODAY - the "snack food" of American journalism - but I felt that news-wise, since we don't have a 'New York bureau,' (YET!! heh...) it was worth publishing. I also place great faith in the readers of this magazine - you're all quite intelligent, I hope, and USA TODAY places quite a "Mom-America-Apple Pie" spin on it, as well as some questionable facts (personal computer programs are only around 1,000 lines of code??? what the hell?)... but I'm confident that you can filter that out. The reprints in this issue, incidentally, are all unauthorized and reprinted as close to word-for-word as I could manage. Credit was given where credit was due, I believe. I am considerably happier at the notion of reprinting John Perry Barlow's essay that appeared in Byte. The "Code of the West" that Barlow talks about is definitely worth reading, at the very least. The book that perhaps was the first to define the "Hacker Ethic" in print was Hackers, by Steven Levy, another book worth reading. In a utopian society, all the beings that traverse the electronic networks of our age would conform to that Ethic. However, there are the few who do not. For the non-hackers reading this editorial, please do NOT judge the actions of the many by the deeds of the few. Hence a problem is presented: How does one protect against the 'evil' few, while allowing access by the benign many? System administrators have responded in different ways. Perhaps what is necessary is to have the 'benign' hackers protect against the 'evil' ones. Again, this has been done for quite a while now, with true hackers forming tightly-knit groups to attempt to keep information among those who will not abuse it. However, it is getting harder to tell what intention an individual has in mind when attempting to enter a system. This, I think, will prove to be one of the major dilemmas that SFI and indeed the entire hacker community will have to deal with in the upcoming years. One other note: a single printed issue is now available for a flat $2 per issue from us, allowing you to receive one copy. If you like it, get a subscription. If not, you're only down $2. Until next time. ><