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 CъSAB receives a subscriber complaint (i.e.,
cannot dial 911) the ъSA 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 beyone 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 FOъTъAN 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.

                         #

     John Nagle read the E911 Document.   He drew his
own conclusions.  And he  presented Zenner and his
defense team with an overflowing box of similar material,
drawn mostly from Stanford University's engineering
libraries.   During the trial, the defense team -- Zenner,
half-a-dozen other attorneys, Nagle, Neidorf, and
computer-security expert Dorothy Denning, all pored
over the E911 Document line-by-line.

      On the afternoon of July 25, 1990, Zenner began to
cross-examine a woman named Billie Williams, a service
manager for Southern Bell in Atlanta.  Ms. Williams had
been responsible for the E911 Document.  (She was not its
author -- its original "author" was a Southern Bell staff
manager named ъichard Helms.  However, Mr. Helms
should not bear the entire blame; many telco staff people
and maintenance personnel had amended the
Document.  It had not been so much "written" by a single
author, as built by committee out of concrete-blocks of
jargon.)

     Ms. Williams had been called as a witness for the
prosecution, and had gamely tried to explain the basic
technical structure of the E911 system, aided by charts.

     Now it was Zenner's turn.  He first established that
the "proprietary stamp" that BellSouth had used on the
E911 Document was stamped on *every single document*
that BellSouth wrote -- *thousands*  of documents.  "We
do not publish anything other than for our own company,"
Ms. Williams explained.  "Any company document of this
nature is considered proprietary."  Nobody was in charge
of singling out special high-security publications for
special high-security protection.  They were *all*  special,
no matter how trivial, no matter what their subject matter -
- the stamp was put on as soon as any document was
written, and the stamp was never removed.

     Zenner now asked whether the charts she had been
using to explain the  mechanics of E911 system were
"proprietary," too.  Were they *public information,*  these
charts, all about PSAPs, ALIs, nodes, local end switches?
Could he take the charts out in the street and show them
to anybody, "without violating some proprietary notion
that BellSouth has?"

     Ms Williams showed some confusion, but finally
agreed that the charts were, in fact, public.

     "But isn't this what you said was basically what
appeared in *Phrack?*"

     Ms. Williams denied this.

     Zenner now pointed out that the E911 Document as
published in Phrack was only half the size of the original
E911 Document (as Prophet had purloined it).  Half of it
had been deleted -- edited by Neidorf.

     Ms. Williams countered that "Most of the
information that is in the text file is redundant."

     Zenner continued to probe.  Exactly what bits of
knowledge in the Document were, in fact, unknown to the
public?  Locations of E911 computers?  Phone numbers for
telco personnel?  Ongoing maintenance subcommittees?
Hadn't Neidorf removed much of this?

     Then he pounced.  "Are you familiar with Bellcore
Technical ъeference Document Tъ-TSY-000350?"  It was,
Zenner explained, officially titled "E911 Public Safety
Answering Point Interface Between 1-1AESS Switch and
Customer Premises Equipment."  It contained highly
detailed and specific technical information about the E911
System.  It was published by Bellcore and publicly
available for about $20.

     He showed the witness a Bellcore catalog which listed
thousands of documents from Bellcore and from all the
Baby Bells, BellSouth included.   The catalog, Zenner
pointed out, was free.  Anyone with a credit card could call
the Bellcore toll-free 800 number and simply order any of
these documents, which would be shipped to any
customer without question.  Including, for instance,
"BellSouth E911 Service Interfaces to Customer Premises
Equipment at a Public Safety Answering Point."

     Zenner gave the witness a copy of "BellSouth E911
Service Interfaces," which cost, as he pointed out, $13,
straight from the catalog.  "Look at it carefully," he urged
Ms. Williams, "and tell me if it doesn't contain about twice
as much detailed information about the E911 system of
BellSouth than appeared anywhere in *Phrack.*"

     "You want me to...."  Ms. Williams trailed off.  "I
don't
understand."

     "Take a careful look," Zenner persisted.  "Take a look
at that document, and tell me when you're done looking at
it if, indeed, it doesn't contain much more detailed
information about the E911 system than appeared in
*Phrack.*"

     "*Phrack* wasn't taken from this," Ms. Williams said.

     "Excuse me?" said Zenner.

     "*Phrack* wasn't taken from this."

     "I can't hear you," Zenner said.

     "*Phrack* was not taken from this document.  I don't
understand your question to me."

     "I guess you don't," Zenner said.

     At this point, the prosecution's case had been
gutshot.  Ms. Williams was distressed.  Her confusion was
quite genuine.  *Phrack* had not been taken from any
publicly available Bellcore document.  *Phrack*'s  E911
Document had been stolen from her own company's
computers, from her own company's text files, that her
own colleagues had written, and revised, with much labor.

     But the "value" of the Document had been blown to
smithereens.  It wasn't worth eighty grand.  According to
Bellcore it was worth thirteen bucks.  And the looming
menace that it supposedly posed had been reduced in
instants to a scarecrow.  Bellcore itself was selling
material
far more detailed and "dangerous," to anybody with a
credit card and a phone.

     Actually, Bellcore was not giving this information to
just anybody.  They gave it to *anybody who asked,* but
not many did ask.   Not many people knew that Bellcore
had a free catalog and an 800 number.  John Nagle knew,
but certainly the average teenage phreak didn't know.
"Tuc," a friend of Neidorf's and sometime *Phrack*
contributor, knew, and Tuc had been very helpful to the
defense, behind the scenes.  But the Legion of Doom
didn't know -- otherwise, they would never have wasted so
much time raiding dumpsters.  Cook didn't know.  Foley
didn't know.  Kluepfel didn't know.   The right hand of
Bellcore knew not what the left hand was doing.  The right
hand was battering hackers without mercy, while the left
hand was distributing Bellcore's intellectual property to
anybody who was interested in telephone technical trivia --
apparently, a pathetic few.

     The digital underground was so amateurish and
poorly organized that they had never discovered this heap
of unguarded riches.  The ivory tower of the telcos was so
wrapped-up in the fog of its own technical obscurity that it
had left all the windows open and flung open the doors.
No one had even noticed.

     Zenner sank another nail in the coffin.  He produced
a printed issue of *Telephone Engineer & Management,*
a prominent industry journal that comes out twice a
month and costs $27 a year.  This particular issue of
*TE&M,* called "Update on 911," featured a galaxy of
technical details on 911 service and a glossary far more
extensive than *Phrack*'s.

     The trial rumbled on, somehow, through its own
momentum.  Tim Foley testified about his interrogations
of Neidorf.  Neidorf's written admission that he had known
the E911 Document was pilfered was officially read into
the court record.

     An interesting side issue came up:  "Terminus" had
once passed Neidorf a piece of UNIX AT&T software, a
log-in sequence, that had been cunningly altered so that it
could trap passwords.   The UNIX software itself was
illegally copied AT&T property,  and the alterations
"Terminus" had made to it, had transformed it into a
device for facilitating computer break-ins.  Terminus
himself would eventually plead guilty to theft of this piece
of software, and the Chicago group would send Terminus
to prison for it.  But it was of dubious relevance in the
Neidorf case.  Neidorf hadn't written the program.  He
wasn't accused of ever having used it.  And Neidorf wasn't
being charged with  software theft or owning a password
trapper.

     On the next day, Zenner took the offensive.  The civil
libertarians now had their own arcane, untried legal
weaponry to launch into action  -- the Electronic
Communications Privacy Act of 1986, 18 US Code, Section
2701 et seq.   Section 2701 makes it a crime to
intentionally
access without authorization a facility in which an
electronic communication service is provided -- it is, at
heart, an anti-bugging and anti-tapping law, intended to
carry the traditional protections of telephones into other
electronic channels of communication.   While providing
penalties for amateur snoops, however, Section 2703 of the
ECPA also lays some formal difficulties on the bugging
and tapping activities of police.

     The Secret Service, in the person of Tim Foley, had
served ъichard Andrews with a federal grand jury
subpoena, in their pursuit of Prophet, the E911 Document,
and the Terminus software ring.  But according to the
Electronic Communications Privacy Act, a "provider of
remote computing service" was legally entitled to "prior
notice" from the government if a subpoena was used.
ъichard Andrews and his basement UNIX node, Jolnet,
had not received any "prior notice."  Tim Foley had
purportedly violated the ECPA and committed an
electronic crime!  Zenner now sought the judge's
permission to cross-examine Foley on the topic of Foley's
own electronic misdeeds.

     Cook argued that ъichard Andrews' Jolnet was a
privately owned bulletin board, and not within the purview
of ECPA.   Judge Bua granted the motion of the
government to prevent cross-examination on that point,
and Zenner's offensive fizzled.   This