Chapter 4-3
Hacker Crackdown

Go to Table of Contents

It has been my practice throughout this book to refer to hackers
only by their "handles."  There is little to gain by giving
the real names of these people, many of whom are juveniles,
many of whom have never been convicted of any crime, and many
of whom had unsuspecting parents who have already suffered enough.

But the trial of Knight Lightning on July 24-27, 1990,
made this particular "hacker" a nationally known public figure.
It can do no particular harm to himself or his family if I repeat
the long-established fact that his name is Craig Neidorf (pronounced NYE-dorf).

Neidorf's jury trial took place in the United States District Court,
Northern District of Illinois, Eastern Division, with the
Honorable Nicholas J. Bua presiding.  The United States of America
was the plaintiff, the defendant Mr. Neidorf.  The defendant's attorney
was Sheldon T. Zenner of the Chicago firm of Katten, Muchin and Zavis.

The prosecution was led by the stalwarts of the Chicago Computer Fraud
and Abuse Task Force:  William J. Cook, Colleen D. Coughlin, and
David A. Glockner, all Assistant United States Attorneys.
The Secret Service Case Agent was Timothy M. Foley.

It will be recalled that Neidorf was the co-editor of an underground hacker
"magazine" called Phrack.  Phrack was an entirely electronic publication,
distributed through bulletin boards and over electronic networks.
It was amateur publication given away for free.  Neidorf had never made
any money for his work in Phrack.  Neither had his unindicted co-editor
"Taran King" or any of the numerous Phrack contributors.

The Chicago Computer Fraud and Abuse Task Force, however,
had decided to prosecute Neidorf as a fraudster.
To formally admit that Phrack was a "magazine"
and Neidorf a "publisher" was to open a prosecutorial
Pandora's Box of First Amendment issues.  To do this
was to play into the hands of Zenner and his EFF advisers,
which now included a phalanx of prominent New York civil rights
lawyers as well as the formidable legal staff of Katten, Muchin and Zavis.
Instead, the prosecution relied heavily on the issue of access device fraud:
Section 1029 of Title 18, the section from which the Secret Service drew
its most direct jurisdiction over computer crime.

Neidorf's alleged crimes centered around the E911 Document.
He was accused of having entered into a fraudulent scheme with the Prophet,
who, it will be recalled, was the Atlanta LoD member who had illicitly
copied the E911 Document from the BellSouth AIMSX system.

The Prophet himself was also a co-defendant in the Neidorf case,
part-and-parcel of the alleged "fraud scheme" to "steal" BellSouth's
E911 Document (and to pass the Document across state lines,
which helped establish the Neidorf trial as a federal case).
The Prophet, in the spirit of full co-operation, had agreed
to testify against Neidorf.

In fact, all three of the Atlanta crew stood ready to testify against Neidorf.
Their own federal prosecutors in Atlanta had charged the Atlanta Three with:
(a) conspiracy, (b) computer fraud, (c) wire fraud, (d) access device fraud,
and (e) interstate transportation of stolen property (Title 18, Sections 371,
1030, 1343, 1029, and 2314).

Faced with this blizzard of trouble, Prophet and Leftist had ducked
any public trial and had pled guilty to reduced charges--one conspiracy
count apiece.  Urvile had pled guilty to that odd bit of Section 1029
which makes it illegal to possess "fifteen or more" illegal access devices
(in his case, computer passwords).  And their sentences were scheduled
for September 14, 1990--well after the Neidorf trial.  As witnesses,
they could presumably be relied upon to behave.

Neidorf, however, was pleading innocent.  Most everyone else caught up
in the crackdown had "cooperated fully" and pled guilty in hope
of reduced sentences.  (Steve Jackson was a notable exception,
of course, and had strongly protested his innocence from the
very beginning.  But Steve Jackson could not get a day in court--
Steve Jackson had never been charged with any crime in the first place.)

Neidorf had been urged to plead guilty.  But Neidorf was a political science
major and was disinclined to go to jail for "fraud" when he had not made
any money, had not broken into any computer, and had been publishing
a magazine that he considered protected under the First Amendment.

Neidorf's trial was the ONLY legal action of the entire Crackdown
that actually involved bringing the issues at hand out for a public test
in front of a jury of American citizens.

Neidorf, too, had cooperated with investigators.  He had voluntarily
handed over much of the evidence that had led to his own indictment.
He had already admitted in writing that he knew that the E911 Document
had been stolen before he had "published" it in Phrack--or, from the
prosecution's point of view, illegally transported stolen property by wire
in something purporting to be a "publication."

But even if the "publication" of the E911 Document was not held to be a crime,
that wouldn't let Neidorf off the hook.  Neidorf had still received
the E911 Document when Prophet had transferred it to him from Rich Andrews'
Jolnet node.  On that occasion, it certainly hadn't been "published"--
it was hacker booty, pure and simple, transported across state lines.

The Chicago Task Force led a Chicago grand jury to indict Neidorf
on a set of charges that could have put him in jail for thirty years.
When some of these charges were successfully challenged before Neidorf
actually went to trial, the Chicago Task Force rearranged his
indictment so that he faced a possible jail term of over sixty years!
As a first offender, it was very unlikely that Neidorf would in fact
receive a sentence so drastic; but the Chicago Task Force clearly
intended to see Neidorf put in prison, and his conspiratorial "magazine"
put permanently out of commission.  This was a federal case, and Neidorf
was charged with the fraudulent theft of property worth almost
eighty thousand dollars.

William Cook was a strong believer in high-profile prosecutions
with symbolic overtones.  He often published articles on his work
in the security trade press, arguing that "a clear message had
to be sent to the public at large and the computer community
in particular that unauthorized attacks on computers and the theft
of computerized information would not be tolerated by the courts."

The issues were complex, the prosecution's tactics somewhat unorthodox,
but the Chicago Task Force had proved sure-footed to date.  "Shadowhawk"
had been bagged on the wing in 1989 by the Task Force, and sentenced
to nine months in prison, and a $10,000 fine.  The Shadowhawk case involved
charges under Section 1030, the "federal interest computer" section.

Shadowhawk had not in fact been a devotee of "federal-interest" computers
per se.  On the contrary, Shadowhawk, who owned an AT&T home computer,
seemed to cherish a special aggression toward AT&T.  He had bragged on
the underground boards "Phreak Klass 2600" and "Dr. Ripco" of his skills
at raiding AT&T, and of his intention to crash AT&T's national phone system.
Shadowhawk's brags were noticed by Henry Kluepfel of Bellcore Security,
scourge of the outlaw boards, whose relations with the Chicago Task Force
were long and intimate.

The Task Force successfully established that Section 1030 applied to
the teenage Shadowhawk, despite the objections of his defense attorney.
Shadowhawk had entered a computer "owned" by U.S. Missile Command
and merely "managed" by AT&T.  He had also entered an AT&T computer
located at Robbins Air Force Base in Georgia.  Attacking AT&T was
of "federal interest" whether Shadowhawk had intended it or not.

The Task Force also convinced the court that a piece of AT&T
software that Shadowhawk had illicitly copied from Bell Labs,
the "Artificial Intelligence C5 Expert System," was worth a cool
one million dollars.  Shadowhawk's attorney had argued that
Shadowhawk had not sold the program and had made no profit from
the illicit copying.  And in point of fact, the C5 Expert System
was experimental software, and had no established market value
because it had never been on the market in the first place.
AT&T's own assessment of a "one million dollar" figure for its
own intangible property was accepted without challenge
by the court, however.  And the court concurred with
the government prosecutors that Shadowhawk showed clear
"intent to defraud" whether he'd gotten any money or not.
Shadowhawk went to jail.

The Task Force's other best-known triumph had been the conviction
and jailing of "Kyrie."  Kyrie, a true denizen of the digital
criminal underground, was a 36-year-old Canadian woman,
convicted and jailed for telecommunications fraud in Canada.
After her release from prison, she had fled the wrath of Canada Bell
and the Royal Canadian Mounted Police, and eventually settled,
very unwisely, in Chicago.

"Kyrie," who also called herself "Long Distance Information,"
specialized in voice-mail abuse.  She assembled large numbers
of hot long-distance codes, then read them aloud into a series
of corporate voice-mail systems.  Kyrie and her friends were
electronic squatters in corporate voice-mail systems,
using them much as if they were pirate bulletin boards,
then moving on when their vocal chatter clogged the system
and the owners necessarily wised up.  Kyrie's camp followers
were a loose tribe of some hundred and fifty phone-phreaks,
who followed her trail of piracy from machine to machine,
ardently begging for her services and expertise.

Kyrie's disciples passed her stolen credit-card numbers,
in exchange for her stolen "long distance information."
Some of Kyrie's clients paid her off in cash, by scamming
credit-card cash advances from Western Union.

Kyrie travelled incessantly, mostly through airline tickets
and hotel rooms that she scammed through stolen credit cards.
Tiring of this, she found refuge with a fellow female phone
phreak in Chicago.  Kyrie's hostess, like a surprising number
of phone phreaks, was blind.  She was also physically disabled.
Kyrie allegedly made the best of her new situation by applying for,
and receiving, state welfare funds under a false identity as
a qualified caretaker for the handicapped.

Sadly, Kyrie's two children by a former marriage had also vanished
underground with her; these pre-teen digital refugees had no legal
American identity, and had never spent a day in school.

Kyrie was addicted to technical mastery and enthralled by her own
cleverness and the ardent worship of her teenage followers.
This foolishly led her to phone up Gail Thackeray in Arizona,
to boast, brag, strut, and offer to play informant.
Thackeray, however, had already learned far more
than enough about Kyrie, whom she roundly despised
as an adult criminal corrupting minors, a "female Fagin."
Thackeray passed her tapes of Kyrie's boasts to the Secret Service.

Kyrie was raided and arrested in Chicago in May 1989.
She confessed at great length and pled guilty.

In August 1990, Cook and his Task Force colleague Colleen Coughlin
sent Kyrie to jail for 27 months, for computer and telecommunications fraud.
This was a markedly severe sentence by the usual wrist-slapping standards
of "hacker" busts.  Seven of Kyrie's foremost teenage disciples were also
indicted and convicted.  The Kyrie "high-tech street gang," as Cook
described it, had been crushed.  Cook and his colleagues had been
the first ever to put someone in prison for voice-mail abuse.
Their pioneering efforts had won them attention and kudos.

In his article on Kyrie, Cook drove the message home to the readers
of Security Management magazine, a trade journal for corporate
security professionals.  The case, Cook said, and Kyrie's stiff sentence,
"reflect a new reality for hackers and computer crime victims in the
'90s. . . .  Individuals and corporations who report computer
and telecommunications crimes can now expect that their cooperation
with federal law enforcement will result in meaningful punishment.
Companies and the public at large must report computer-enhanced
crimes if they want prosecutors and the course to protect their rights
to the tangible and intangible property developed and stored on computers."

Cook had made it his business to construct this "new reality for hackers."
He'd also made it his business to police corporate property rights
to the intangible.

Had the Electronic Frontier Foundation been a "hacker defense fund"
as that term was generally understood, they presumably would have stood up
for Kyrie.  Her 1990 sentence did indeed send a "message" that federal heat
was coming down on "hackers."  But Kyrie found no defenders at EFF,
or anywhere else, for that matter.  EFF was not a bail-out fund
for electronic crooks.

The Neidorf case paralleled the Shadowhawk case in certain ways.
The victim once again was allowed to set the value of the "stolen" property.
Once again Kluepfel was both investigator and technical advisor.
Once again no money had changed hands, but the "intent to defraud" was central.

The prosecution's case showed signs of weakness early on.  The Task Force
had originally hoped to prove Neidorf the center of a nationwide
Legion of Doom criminal conspiracy.  The Phrack editors threw physical
get-togethers every summer, which attracted hackers from across the country;
generally two dozen or so of the magazine's favorite contributors and readers.
(Such conventions were common in the hacker community; 2600 Magazine,
for instance, held public meetings of hackers in New York, every month.)
LoD heavy-dudes were always a strong presence at these Phrack-sponsored
"Summercons."

In July 1988, an Arizona hacker named "Dictator" attended Summercon
in Neidorf's home town of St. Louis.  Dictator was one of Gail Thackeray's
underground informants; Dictator's underground board in Phoenix was
a sting operation for the Secret Service.  Dictator brought an undercover
crew of Secret Service agents to Summercon.  The agents bored spyholes
through the wall of Dictator's hotel room in St Louis, and videotaped
the frolicking hackers through a one-way mirror.  As it happened,
however, nothing illegal had occurred on videotape, other than the
guzzling of beer by a couple of minors.  Summercons were social events,
not sinister cabals.  The tapes showed fifteen hours of raucous laughter,
pizza-gobbling, in-jokes and back-slapping.

Neidorf's lawyer, Sheldon Zenner, saw the Secret Service tapes
before the trial.  Zenner was shocked by the complete harmlessness
of this meeting, which Cook had earlier characterized as a sinister
interstate conspiracy to commit fraud.  Zenner wanted to show the
Summercon tapes to the jury.  It took protracted maneuverings
by the Task Force to keep the tapes from the jury as "irrelevant."

The E911 Document was also proving a weak reed.  It had originally
been valued at $79,449.  Unlike Shadowhawk's arcane Artificial Intelligence
booty, the E911 Document was not software--it was written in English.
Computer-knowledgeable people found this value--for a twelve-page
bureaucratic document--frankly incredible.  In his "Crime and Puzzlement"
manifesto for EFF, Barlow commented:  "We will probably never know how
this figure was reached or by whom, though I like to imagine an appraisal
team consisting of Franz Kafka, Joseph Heller, and Thomas Pynchon."

As it happened, Barlow was unduly pessimistic.  The EFF did, in fact,
eventually discover exactly how this figure was reached, and by whom--
but only in 1991, long after the Neidorf trial was over.

Kim Megahee, a Southern Bell security manager,
had arrived at the document's value by simply adding up
the "costs associated with the production" of the E911 Document.
Those "costs" were as follows:

1.  A technical writer had been hired to research and write the E911 Document.
    200 hours of work, at $35 an hour, cost : $7,000.  A Project Manager had
    overseen the technical writer.  200 hours, at $31 an hour, made: $6,200.

2.  A week of typing had cost $721 dollars.  A week of formatting had
    cost $721.  A week of graphics formatting had cost $742.

3.  Two days of editing cost $367.

4.  A box of order labels cost five dollars.

5.  Preparing a purchase order for the Document, including typing
    and the obtaining of an authorizing signature from within the
    BellSouth bureaucracy, cost $129.

6.  Printing cost $313.  Mailing the Document to fifty people
    took fifty hours by a clerk, and cost $858.

7.  Placing the Document in an index took two clerks an hour each,
    totalling $43.

Bureaucratic overhead alone, therefore, was alleged to have cost
a whopping $17,099.  According to Mr. Megahee, the typing
of a twelve-page document had taken a full week.  Writing it
had taken five weeks, including an overseer who apparently
did nothing else but watch the author for five weeks.
Editing twelve pages had taken two days.  Printing and mailing
an electronic document (which was already available on the
Southern Bell Data Network to any telco employee who needed it),
had cost over a thousand dollars.

But this was just the beginning.  There were also the HARDWARE EXPENSES.
Eight hundred fifty dollars for a VT220 computer monitor.
THIRTY-ONE THOUSAND DOLLARS for a sophisticated VAXstation II computer.
Six thousand dollars for a computer printer.  TWENTY-TWO THOUSAND DOLLARS
for a copy of "Interleaf" software.  Two thousand five hundred dollars
for VMS software.  All this to create the twelve-page Document.

Plus ten percent of the cost of the software and the hardware, for maintenance.
(Actually, the ten percent maintenance costs, though mentioned, had been left
off the final $79,449 total, apparently through a merciful oversight).

Mr. Megahee's letter had been mailed directly to William Cook himself,
at the office of the Chicago federal attorneys.  The United States Government
accepted these telco figures without question.

As incredulity mounted, the value of the E911 Document was officially
revised downward.  This time, Robert Kibler of BellSouth Security
estimated the value of the twelve pages as a mere $24,639.05--based,
purportedly, on "R&D costs."  But this specific estimate,
right down to the nickel, did not move the skeptics at all;
in fact it provoked open scorn and a torrent of sarcasm.

The financial issues concerning theft of proprietary information
have always been peculiar.  It could be argued that BellSouth
had not "lost" its E911 Document at all in the first place,
and therefore had not suffered any monetary damage from this "theft."
And Sheldon Zenner did in fact argue this at Neidorf's trial--
that Prophet's raid had not been "theft," but was better understood
as illicit copying.

The money, however, was not central to anyone's true purposes in this trial.
It was not Cook's strategy to convince the jury that the E911 Document
was a major act of theft and should be punished for that reason alone.
His strategy was to argue that the E911 Document was DANGEROUS.
It was his intention to establish that the E911 Document was "a road-map"
to the Enhanced 911 System.  Neidorf had deliberately and recklessly
distributed a dangerous weapon.  Neidorf and the Prophet did not care
(or perhaps even gloated at the sinister idea) that the E911 Document
could be used by hackers to disrupt 911 service, "a life line for every
person certainly in the Southern Bell region of the United States,
and indeed, in many communities throughout the United States,"
in Cook's own words.  Neidorf had put people's lives in danger.

In pre-trial maneuverings, Cook had established that the E911 Document
was too hot to appear in the public proceedings of the Neidorf trial.
The JURY ITSELF would not be allowed to ever see this Document,
lest it slip into the official court records, and thus into the hands
of the general public, and, thus, somehow, to malicious hackers
who might lethally abuse it.

Hiding the E911 Document from the jury may have been a
clever legal maneuver, but it had a severe flaw.  There were,
in point of fact, hundreds, perhaps thousands, of people,
already in possession of the E911 Document, just as Phrack
had published it.  Its true nature was already obvious
to a wide section of the interested public (all of whom,
by the way, were, at least theoretically, party to
a gigantic wire-fraud conspiracy).  Most everyone
in the electronic community who had a modem and any
interest in the Neidorf case already had a copy of the Document.
It had already been available in Phrack for over a year.

People, even quite normal people without any particular
prurient interest in forbidden knowledge, did not shut their eyes
in terror at the thought of beholding a "dangerous" document
from a telephone company.  On the contrary, they tended to trust
their own judgement and simply read the Document for themselves.
And they were not impressed.

One such person was John Nagle.  Nagle was a  forty-one-year-old
professional programmer with a masters' degree in computer science
from Stanford.  He had worked for Ford Aerospace, where he had invented
a computer-networking technique known as the "Nagle Algorithm,"
and for the prominent Californian computer-graphics firm "Autodesk,"
where he was a major stockholder.

Nagle was also a prominent figure on the Well, much respected
for his technical knowledgeability.

Nagle had followed the civil-liberties debate closely,
for he was an ardent telecommunicator.  He was no particular friend
of computer intruders, but he believed electronic publishing
had a great deal to offer society at large, and attempts
to restrain its growth, or to censor free electronic expression,
strongly roused his ire.

The Neidorf case, and the E911 Document, were both being discussed
in detail on the Internet, in an electronic publication called Telecom Digest.
Nagle, a longtime Internet maven, was a regular reader of Telecom Digest.
Nagle had never seen a copy of Phrack, but the implications of the case
disturbed him.

While in a Stanford bookstore hunting books on robotics,
Nagle happened across a book called The Intelligent Network.
Thumbing through it at random, Nagle came across an entire chapter
meticulously detailing the workings of E911 police emergency systems.
This extensive text was being sold openly, and yet in Illinois
a young man was in danger of going to prison for publishing
a thin six-page document about 911 service.

Nagle made an ironic comment to this effect in Telecom Digest.
From there, Nagle was put in touch with Mitch Kapor,
and then with Neidorf's lawyers.

Sheldon Zenner was delighted to find a computer telecommunications expert
willing to speak up for Neidorf, one who was not a wacky teenage "hacker."
Nagle was fluent, mature, and respectable; he'd once had a federal
security clearance.

Nagle was asked to fly to Illinois to join the defense team.

Having joined the defense as an expert witness, Nagle read the entire
E911 Document for himself.  He made his own judgement about its potential
for menace.

The time has now come for you yourself, the reader, to have a look
at the E911 Document.  This six-page piece of work was the pretext
for a federal prosecution that could have sent an electronic publisher
to prison for thirty, or even sixty, years.  It was the pretext
for the search and seizure of Steve Jackson Games, a legitimate publisher
of printed books.  It was also the formal pretext for the search
and seizure of the Mentor's bulletin board, "Phoenix Project,"
and for the raid on the home of Erik Bloodaxe.  It also had much
to do with the seizure of Richard Andrews' Jolnet node
and the shutdown of Charles Boykin's AT&T node.
The E911 Document was the single most important piece
of evidence in the Hacker Crackdown.  There can be no real
and legitimate substitute for the Document itself.


==Phrack Inc.==

Volume Two, Issue 24, File 5 of 13

Control Office Administration
Of Enhanced 911 Services For
Special Services and Account Centers

by the Eavesdropper

March, 1988


Description of Service
~~~~~~~~~~~~~~~~~~~~~
The control office for Emergency 911 service is assigned in
accordance with the existing standard guidelines to one of
the following centers:

o  Special Services Center (SSC)
o  Major Accounts Center (MAC)
o  Serving Test Center (STC)
o  Toll Control Center (TCC)

The SSC/MAC designation is used in this document interchangeably
for any of these four centers.  The Special Services Centers (SSCs)
or Major Account Centers (MACs) have been designated as the trouble
reporting contact for all E911 customer (PSAP) reported troubles.
Subscribers who have trouble on an E911 call will continue
to contact local repair service (CRSAB) who will refer the
trouble to the SSC/MAC, when appropriate.

Due to the critical nature of E911 service, the control
and timely repair of troubles is demanded.  As the primary
E911 customer contact, the SSC/MAC is in the unique position
to monitor the status of the trouble and insure its resolution.

System Overview
~~~~~~~~~~~~~~
The number 911 is intended as a nationwide universal
telephone number which provides the public with direct
access to a Public Safety Answering Point (PSAP).  A PSAP
is also referred to as an Emergency Service Bureau (ESB).
A PSAP is an agency or facility which is authorized by a
municipality to receive and respond to police, fire and/or
ambulance services.  One or more attendants are located
at the PSAP facilities to receive and handle calls of an
emergency nature in accordance with the local municipal
requirements.

An important advantage of E911 emergency service is
improved (reduced) response times for emergency
services.  Also close coordination among agencies
providing various emergency services is a valuable
capability provided by E911 service.

1A ESS is used as the tandem office for the E911 network to
route all 911 calls to the correct (primary) PSAP designated
to serve the calling station.  The E911 feature was
developed primarily to provide routing to the correct PSAP
for all 911 calls.  Selective routing allows a 911 call
originated from a particular station located in a particular
district, zone, or town, to be routed to the primary PSAP
designated to serve that customer station regardless of
wire center boundaries.  Thus, selective routing eliminates
the problem of wire center boundaries not coinciding with
district or other political boundaries.

The services available with the E911 feature include:

Forced Disconnect       Default Routing
Alternative Routing     Night Service
Selective Routing       Automatic Number
Identification (ANI)
Selective Transfer      Automatic Location
Identification (ALI)


Preservice/Installation Guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a contract for an E911 system has been signed, it is
the responsibility of Network Marketing to establish an
implementation/cutover committee which should include
a representative from the SSC/MAC.  Duties of the E911
Implementation Team include coordination of all phases
of the E911 system deployment and the formation of an
on-going E911 maintenance subcommittee.

Marketing is responsible for providing the following
customer specific information to the SSC/MAC prior to
the start of call through testing:

o  All PSAP's (name, address, local contact)
o  All PSAP circuit ID's
o  1004 911 service request including PSAP details on each PSAP
   (1004 Section K, L, M)
o  Network configuration
o  Any vendor information (name, telephone number, equipment)

The SSC/MAC needs to know if the equipment and sets
at the PSAP are maintained by the BOCs, an independent
company, or an outside vendor, or any combination.
This information is then entered on the PSAP profile sheets
and reviewed quarterly for changes, additions and deletions.

Marketing will secure the Major Account Number (MAN)
and provide this number to Corporate Communications
so that the initial issue of the service orders carry
the MAN and can be tracked by the SSC/MAC via CORDNET.
PSAP circuits are official services by definition.

All service orders required for the installation of the E911
system should include the MAN assigned to the city/county
which has purchased the system.

In accordance with the basic SSC/MAC strategy for provisioning,
the SSC/MAC will be Overall Control Office (OCO) for all Node
to PSAP circuits (official services) and any other services
for this customer.  Training must be scheduled for all SSC/MAC
involved personnel during the pre-service stage of the project.

The E911 Implementation Team will form the on-going
maintenance subcommittee prior to the initial
implementation of the E911 system.  This sub-committee
will establish post implementation quality assurance
procedures to ensure that the E911 system continues to
provide quality service to the customer.
Customer/Company training, trouble reporting interfaces
for the customer, telephone company and any involved
independent telephone companies needs to be addressed
and implemented prior to E911 cutover.  These functions
can be best addressed by the formation of a sub-
committee of the E911 Implementation Team to set up
guidelines for and to secure service commitments of
interfacing organizations.  A SSC/MAC supervisor should
chair this subcommittee and include the following
organizations:

1) Switching Control Center
 - E911 translations
 - Trunking
 - End office and Tandem office hardware/software
2) Recent Change Memory Administration Center
 - Daily RC update activity for TN/ESN translations
 - Processes validity errors and rejects
3) Line and Number Administration
 - Verification of TN/ESN translations
4) Special Service Center/Major Account Center
 - Single point of contact for all PSAP and Node to host troubles
 - Logs, tracks & statusing of all trouble reports
 - Trouble referral, follow up, and escalation
 - Customer notification of status and restoration
 - Analyzation of "chronic" troubles
 - Testing, installation and maintenance of E911 circuits
5) Installation and Maintenance (SSIM/I&M)
 - Repair and maintenance of PSAP equipment and Telco owned sets
6) Minicomputer Maintenance Operations Center
 - E911 circuit maintenance (where applicable)
7) Area Maintenance Engineer
 - Technical assistance on voice (CO-PSAP) network related E911 troubles


Maintenance Guidelines
~~~~~~~~~~~~~~~~~~~~~
The CCNC will test the Node circuit from the 202T at the
Host site to the 202T at the Node site.  Since Host to Node
(CCNC to MMOC) circuits are official company services,
the CCNC will refer all Node circuit troubles to the
SSC/MAC. The SSC/MAC is responsible for the testing
and follow up to restoration of these circuit troubles.

Although Node to PSAP circuit are official services, the
MMOC will refer PSAP circuit troubles to the appropriate
SSC/MAC.  The SSC/MAC is responsible for testing and
follow up to restoration of PSAP circuit troubles.

The SSC/MAC will also receive reports from
CRSAB/IMC(s) on subscriber 911 troubles when they are
not line troubles.  The SSC/MAC is responsible for testing
and restoration of these troubles.

Maintenance responsibilities are as follows:

SCC@           Voice Network (ANI to PSAP)
@SCC responsible for tandem switch

SSIM/I&M        PSAP Equipment (Modems, CIU's, sets)
Vendor          PSAP Equipment (when CPE)
SSC/MAC         PSAP to Node circuits, and tandem to
                PSAP voice circuits (EMNT)
MMOC            Node site (Modems, cables, etc)

Note:  All above work groups are required to resolve troubles
by interfacing with appropriate work groups for resolution.

The Switching Control Center (SCC) is responsible for
E911/1AESS translations in tandem central offices.
These translations route E911 calls, selective transfer,
default routing, speed calling, etc., for each PSAP.
The SCC is also responsible for troubleshooting on
the voice network (call originating to end office tandem equipment).

For example, ANI failures in the originating offices would
be a responsibility of the SCC.

Recent Change Memory Administration Center (RCMAC) performs
the daily tandem translation updates (recent change)
for routing of individual telephone numbers.

Recent changes are generated from service order activity
(new service, address changes, etc.) and compiled into
a daily file by the E911 Center (ALI/DMS E911 Computer).

SSIM/I&M is responsible for the installation and repair of
PSAP equipment. PSAP equipment includes ANI Controller,
ALI Controller, data sets, cables, sets, and other peripheral
equipment that is not vendor owned. SSIM/I&M is responsible
for establishing maintenance test kits, complete with spare parts
for PSAP maintenance. This includes test gear, data sets,
and ANI/ALI Controller parts.

Special Services Center (SSC) or Major Account Center
(MAC) serves as the trouble reporting contact for all
(PSAP) troubles reported by customer.  The SSC/MAC
refers troubles to proper organizations for handling and
tracks status of troubles, escalating when necessary.
The SSC/MAC will close out troubles with customer.
The SSC/MAC will analyze all troubles and tracks "chronic"
PSAP troubles.

Corporate Communications Network Center (CCNC) will
test and refer troubles on all node to host circuits.
All E911 circuits are classified as official company property.

The Minicomputer Maintenance Operations Center
(MMOC) maintains the E911 (ALI/DMS) computer
hardware at the Host site.  This MMOC is also responsible
for monitoring the system and reporting certain PSAP
and system problems to the local MMOC's, SCC's or
SSC/MAC's.  The MMOC personnel also operate software
programs that maintain the TN data base under the
direction of the E911 Center. The maintenance of the
NODE computer (the interface between the PSAP and the
ALI/DMS computer) is a function of the MMOC at the
NODE site.  The MMOC's at the NODE sites may also be
involved in the testing of NODE to Host circuits.
The MMOC will also assist on Host to PSAP and data network
related troubles not resolved through standard trouble
clearing procedures.

Installation And Maintenance Center (IMC) is responsible
for referral of E911 subscriber troubles that are not subscriber
line problems.

E911 Center - Performs the role of System Administration
and is responsible for overall operation of the E911
computer software.  The E911 Center does A-Z trouble
analysis and provides statistical information on the
performance of the system.

This analysis includes processing PSAP inquiries (trouble
reports) and referral of network troubles.  The E911 Center
also performs daily processing of tandem recent change
and provides information to the RCMAC for tandem input.
The E911 Center is responsible for daily processing
of the ALI/DMS computer data base and provides error files,
etc. to the Customer Services department for investigation and correction.
The E911 Center participates in all system implementations and on-going
maintenance effort and assists in the development of procedures,
training and education of information to all groups.

Any group receiving a 911 trouble from the SSC/MAC should
close out the trouble with the SSC/MAC or provide a status
if the trouble has been referred to another group.
This will allow the SSC/MAC to provide a status back
to the customer or escalate as appropriate.

Any group receiving a trouble from the Host site (MMOC
or CCNC) should close the trouble back to that group.

The MMOC should notify the appropriate SSC/MAC
when the Host, Node, or all Node circuits are down so that
the SSC/MAC can reply to customer reports that may be
called in by the PSAPs.  This will eliminate duplicate
reporting of troubles. On complete outages the MMOC
will follow escalation procedures for a Node after two (2)
hours and for a PSAP after four (4) hours.  Additionally the
MMOC will notify the appropriate SSC/MAC when the
Host, Node, or all Node circuits are down.

The PSAP will call the SSC/MAC to report E911 troubles.
The person reporting the E911 trouble may not have a
circuit I.D. and will therefore report the PSAP name and
address.  Many PSAP troubles are not circuit specific.  In
those instances where the caller cannot provide a circuit
I.D., the SSC/MAC will be required to determine the
circuit I.D. using the PSAP profile.  Under no circumstances
will the SSC/MAC Center refuse to take the trouble.
The E911 trouble should be handled as quickly as possible,
with the SSC/MAC providing as much assistance as
possible while taking the trouble report from the caller.

The SSC/MAC will screen/test the trouble to determine the
appropriate handoff organization based on the following criteria:

PSAP equipment problem:  SSIM/I&M
Circuit problem:  SSC/MAC
Voice network problem:  SCC (report trunk group number)
Problem affecting multiple PSAPs (No ALI report from
all PSAPs):  Contact the MMOC to check for NODE or
Host computer problems before further testing.

The SSC/MAC will track the status of reported troubles
and escalate as appropriate.  The SSC/MAC will close out
customer/company reports with the initiating contact.
Groups with specific maintenance responsibilities,
defined above, will investigate "chronic" troubles upon
request from the SSC/MAC and the ongoing maintenance subcommittee.

All "out of service" E911 troubles are priority one type reports.
One link down to a PSAP is considered a priority one trouble
and should be handled as if the PSAP was isolated.

The PSAP will report troubles with the ANI controller, ALI
controller or set equipment to the SSC/MAC.

NO ANI:  Where the PSAP reports NO ANI (digital
display screen is blank) ask if this condition exists on all
screens and on all calls.  It is important to differentiate
between blank screens and screens displaying 911-00XX,
or all zeroes.

When the PSAP reports all screens on all calls, ask if there
is any voice contact with callers.  If there is no voice
contact the trouble should be referred to the SCC
immediately since 911 calls are not getting through which
may require alternate routing of calls to another PSAP.

When the PSAP reports this condition on all screens
but not all calls and has voice contact with callers,
the report should be referred to SSIM/I&M for dispatch.
The SSC/MAC should verify with the SCC that ANI
is pulsing before dispatching SSIM.

When the PSAP reports this condition on one screen for
all calls (others work fine) the trouble should be referred
to SSIM/I&M for dispatch, because the trouble is isolated to
one piece of equipment at the customer premise.

An ANI failure (i.e. all zeroes) indicates that the ANI has
not been received by the PSAP from the tandem office or
was lost by the PSAP ANI controller.  The PSAP may
receive "02" alarms which can be caused by the ANI
controller logging more than three all zero failures on the
same trunk.  The PSAP has been instructed to report this
condition to the SSC/MAC since it could indicate an
equipment trouble at the PSAP which might be affecting
all subscribers calling into the PSAP.  When all zeroes are
being received on all calls or "02" alarms continue, a tester
should analyze the condition to determine the appropriate
action to be taken.  The tester must perform cooperative
testing with the SCC when there appears to be a problem
on the Tandem-PSAP trunks before requesting dispatch.

When an occasional all zero condition is reported,
the SSC/MAC should dispatch SSIM/I&M to routine
equipment on a "chronic" troublesweep.

The PSAPs are instructed to report incidental ANI failures
to the BOC on a PSAP inquiry trouble ticket (paper) that
is sent to the Customer Services E911 group and forwarded
to E911 center when required.  This usually involves only a
particular telephone number and is not a condition that
would require a report to the SSC/MAC.  Multiple ANI
failures which our from the same end office (XX denotes
end office), indicate a hard trouble condition may exist
in the end office or end office tandem trunks.  The PSAP will
report this type of condition to the SSC/MAC and the
SSC/MAC should refer the report to the SCC responsible
for the tandem office.  NOTE: XX is the ESCO (Emergency
Service Number) associated with the incoming 911 trunks
into the tandem.  It is important that the C/MAC tell the
SCC what is displayed at the PSAP (i.e. 911-0011) which
indicates to the SCC which end office is in trouble.

Note:  It is essential that the PSAP fill out inquiry form
on every ANI failure.

The PSAP will report a trouble any time an address is not
received on an address display (screen blank) E911 call.
(If a record is not in the 911 data base or an ANI failure
is encountered, the screen will provide a display noticing
such condition).  The SSC/MAC should verify with the PSAP
whether the NO ALI condition is on one screen or all screens.

When the condition is on one screen (other screens
receive ALI information) the SSC/MAC will request
SSIM/I&M to dispatch.

If no screens are receiving ALI information, there is usually
a circuit trouble between the PSAP and the Host computer.
The SSC/MAC should test the trouble and refer for restoral.

Note:  If the SSC/MAC receives calls from multiple
PSAP's, all of which are receiving NO ALI, there is a
problem with the Node or Node to Host circuits or the
Host computer itself.  Before referring the trouble the
SSC/MAC should call the MMOC to inquire if the Node
or Host is in trouble.

Alarm conditions on the ANI controller digital display at
the PSAP are to be reported by the PSAP's.  These alarms
can indicate various trouble conditions so the SSC/MAC
should ask the PSAP if any portion of the E911 system
is not functioning properly.

The SSC/MAC should verify with the PSAP attendant that
the equipment's primary function is answering E911 calls.
If it is, the SSC/MAC should request a dispatch SSIM/I&M.
If the equipment is not primarily used for E911,
then the SSC/MAC should advise PSAP to contact their CPE vendor.

Note:  These troubles can be quite confusing when the
PSAP has vendor equipment mixed in with equipment
that the BOC maintains.  The Marketing representative
should provide the SSC/MAC information concerning any
unusual or exception items where the PSAP should
contact their vendor.  This information should be included
in the PSAP profile sheets.

ANI or ALI controller down:  When the host computer sees
the PSAP equipment down and it does not come back up,
the MMOC will report the trouble to the SSC/MAC;
the equipment is down at the PSAP, a dispatch will be required.

PSAP link (circuit) down:  The MMOC will provide the
SSC/MAC with the circuit ID that the Host computer
indicates in trouble.  Although each PSAP has two circuits,
when either circuit is down the condition must be treated
as an emergency since failure of the second circuit will
cause the PSAP to be isolated.

Any problems that the MMOC identifies from the Node
location to the Host computer will be handled directly
with the appropriate MMOC(s)/CCNC.

Note:  The customer will call only when a problem is
apparent to the PSAP. When only one circuit is down to
the PSAP, the customer may not be aware there is a
trouble, even though there is one link down,
notification should appear on the PSAP screen.
Troubles called into the SSC/MAC from the MMOC
or other company employee should not be closed out
by calling the PSAP since it may result in the
customer responding that they do not have a trouble.
These reports can only be closed out by receiving
information that the trouble was fixed and by checking
with the company employee that reported the trouble.
The MMOC personnel will be able to verify that the
trouble has cleared by reviewing a printout from the host.

When the CRSAB receives a subscriber complaint
(i.e., cannot dial 911) the RSA should obtain as much
information as possible while the customer is on the line.

For example, what happened when the subscriber dialed 911?
The report is automatically directed to the IMC for subscriber line testing.
When no line trouble is found, the IMC will refer the trouble condition
to the SSC/MAC.  The SSC/MAC will contact Customer Services E911 Group
and verify that the subscriber should be able to call 911 and obtain the ESN.
The SSC/MAC will verify the ESN via 2SCCS.  When both verifications match,
the SSC/MAC will refer the report to the SCC responsible for the 911 tandem
office for investigation and resolution.  The MAC is responsible for tracking
the trouble and informing the IMC when it is resolved.


For more information, please refer to E911 Glossary of Terms.
End of Phrack File
_____________________________________


The reader is forgiven if he or she was entirely unable to read
this document.  John Perry Barlow had a great deal of fun at its expense,
in "Crime and Puzzlement:"  "Bureaucrat-ese of surpassing opacity. . . .
To read the whole thing straight through without entering coma requires
either a machine or a human who has too much practice thinking like one.
Anyone who can understand it fully and fluidly had altered his consciousness
beyond the ability to ever again read Blake, Whitman, or Tolstoy. . . .
the document contains little of interest to anyone who is not a student
of advanced organizational sclerosis."

With the Document itself to hand, however, exactly as it was published
(in its six-page edited form) in Phrack, the reader may be able to verify
a few statements of fact about its nature.  First, there is no software,
no computer code, in the Document.  It is not computer-programming language
like FORTRAN or C++, it is English; all the sentences have nouns and verbs
and punctuation.  It does not explain how to break into the E911 system.
It does not suggest ways to destroy or damage the E911 system.

There are no access codes in the Document.  There are no computer passwords.
It does not explain how to steal long distance service.  It does not explain
how to break in to telco switching stations.  There is nothing in it about
using a personal computer or a modem for any purpose at all, good or bad.

Close study will reveal that this document is not about machinery.
The E911 Document is about ADMINISTRATION. It describes how one creates
and administers certain units of telco bureaucracy:
Special Service Centers and Major Account Centers (SSC/MAC).
It describes how these centers should distribute responsibility
for the E911 service, to other units of telco bureaucracy,
in a chain of command, a formal hierarchy.  It describes
who answers customer complaints, who screens calls,
who reports equipment failures, who answers those reports,
who handles maintenance, who chairs subcommittees,
who gives orders, who follows orders, WHO tells WHOM what to do.
The Document is not a "roadmap" to computers.
The Document is a roadmap to PEOPLE.

As an aid to breaking into computer systems, the Document is USELESS.
As an aid to harassing and deceiving telco people, however, the Document
might prove handy (especially with its Glossary, which I have not included).
An intense and protracted study of this Document and its Glossary,
combined with many other such documents, might teach one to speak like
a telco employee.  And telco people live by SPEECH--they live by phone
communication.  If you can mimic their language over the phone,
you can "social-engineer" them.  If you can con telco people, you can
wreak havoc among them.  You can force them to no longer trust one another;
you can break the telephonic ties that bind their community; you can make
them paranoid.  And people will fight harder to defend their community
than they will fight to defend their individual selves.

This was the genuine, gut-level threat posed by Phrack magazine.
The real struggle was over the control of telco language,
the control of telco knowledge.  It was a struggle to defend the social
"membrane of differentiation" that forms the walls of the telco
community's ivory tower --the special jargon that allows telco
professionals to recognize one another, and to exclude charlatans,
thieves, and upstarts.  And the prosecution brought out this fact.
They repeatedly made reference to the threat posed to telco professionals
by hackers using "social engineering."

However, Craig Neidorf was not on trial for learning to speak like
a professional telecommunications expert.  Craig Neidorf was on trial
for access device fraud and transportation of stolen property.
He was on trial for stealing a document that was purportedly
highly sensitive and purportedly worth tens of thousands of dollars.