==Phrack Inc.==

                Volume 0x0e, Issue 0x43, Phile #0x0e of 0x10

|=-----------------------------------------------------------------------=|
|=-----=[ Notes Concerning the Security, Design and Administration ]=----=|
|=-----------=[ of Siemens DCO-CS Digital Switching Systems ]=-----------=|
|=-----------------------------------------------------------------------=|
|=------------------------=[ By The Philosopher ]=-----------------------=|
|=--------------------=[ philosopher2600@gmail.com ]=--------------------=|
|=-----------------------------------------------------------------------=|


Relevance/Context-

The Siemens DCO-CS (Digital Central Office Carrier Switch), the premier 
Class 5 digital local office switching system to be introduced onto the 
American PSTN, (by Stromberg-Carlson-Siemens had not yet purchased the 
product line) was originally installed in 1977 in Richmond Hill, Virginia. 
Designed as a robust switch rich in features primarily to be used for 
smaller LECs, the DCO was produced for over a decade until Siemens, which 
acquired the product line in 1990, halted production to focus upon 
marketing the EWSD. Nonetheless the DCO-CS remains in relatively widespread
use throughout the PSTN, often in the possession of smaller CLECs (usually
servicing rural areas). For those who wish to explore PSTN switches as well
as those with the objective of securing them, the DCO-CS is worthy of 
examination as security of any substance is largely nonexistent. 

In light of the above historical information, evidently attributable 
becomes the extremely poor security of the DCO-CS to the context of the 
time period in which it was initially designed, within nearly a decade 
prior to the wide proliferation of the hacker culture potentially 
interested in unauthorized entry into telco switches; in addition, the 
mentioned relative inclusiveness of features especially as were developed 
and added to the existing MMI over a lengthy period of time serves to 
establish the potential to defeat the security precautions built into the 
switch with its own valid MMI commands. One example: although this is not 
directly related to security, many commands in the debug utilities (GBUG, 
FPBUG, DEBUG, etc.) in certain versions of the DCO-CS operating system are 
redundant in that they are identical yet named differently, so that when 
"HELP COMMAND" is entered at the prompt, identical help data will be 
displayed for both command names, one of which is usually abbreviated. 
Demonstrative this example is of the layered and almost modular evolution 
of the DCO MMI. Software updates/upgrades are seemingly uploaded in a 
modular fashion without regard for the previous state of the software in 
question. The modularity of the interface is further reflected in the 
incompatibility of particular utilities with the standard menu 
characteristics. It may be observed, for example, that certain utilities 
do not contain a "HELP" option as is typical, and that certain utilities 
use a linear parameter input system rather than a menu-driven system. It 
was likely anticipated upon the design of such programs/commands that the 
user would be experienced in and knowledgeable of their usage, rendering an
extensive help file unnecessary.
					
A Distinction of DCO Terminology-

The words "program", "utility", and "command" will be used somewhat 
interchangeably throughout this document, in reference to the commands 
prefixed with a "$" at the main MMGR prompt (DCO>) that serve to invoke 
interactive menu/parameter systems with specific functions. Also, "DCO" 
actually refers to older software revisions prior to the Siemens 
acquisition of the line, which was henceforth known as "DCO-CS", but here 
it will simply be used as an abbreviation of sorts for the latter, since 
the material in this article applies to most software revisions unless 
stated otherwise. Also, DCO can refer to the entire DCO family of switches,
including DCO-E, DCO-SE, and DCO-RLS.

 Objectives-

In formulating the structure of this paper I encountered minor difficulty 
in the establishment of a consistent method of organization and concept 
presentation. Initially I intended it to concern solely vulnerabilities 
inherent in the design of the DCO-CS and commensurate methods of exploiting
them in order to maximize the concealment of one's presence in such a 
system. Quickly I realized, however, that a great deal of explanation of 
switch operation was necessary to provide a context in which to discuss 
techniques of intrusion and anti-detection, and that documentation/articles
currently available to the underground are inadequate and quite lacking in 
this regard; however, they are recommended reference material, for at 
minimum they contain the text of the help files of the DCO and a small 
amount of basic access suggestions. Consequently this writing exhibits both
modularity and general information, encompassing sections concerning 
specific points of interest in conjunction with occasionally redundant 
material regarding the switch itself. This facilitates rapid look-up and 
browsing through specific techniques, while providing beginning readers 
with a satisfactory base of navigational knowledge. It will be assumed, 
though, that the reader has access to the help file text, available in 
"Guide to navigating and using DCO", written by DemonBytez of CyBrids CSE, 
and Mr. Nobody's "The DCO-CS Operating System", both available in various 
locations on the Internet. One should also possess at least the background 
knowledge covered in both of these articles in order to enhance one's 
comprehension of much of the following material. In addition to technical
information surrounding the DCO-CS with an obvious emphasis upon security,
the following also contains the observations of the author as to the 
administration of such switches and specifically common practices related 
thereto. As the title suggests, these writings, while they present a 
coherent article that one may fruitfully follow from introduction to 
conclusion, exhibit the general form of notes. Specific techniques are 
presented in a sort of "Problem/Solution" format. Also, for evident reasons
 of which I am confident the reader is aware, the location data, dates, and
 times have been altered or omitted from the captures included herein. 
Specific node/site identification information is replaced with 
"DCO_CITYDATA" in the following captures, and all dates and times are 
either fictitious examples or zeroes simply designed to demonstrate the 
general format of the messages. Also, another important note of which to be
 mindful is that, while to the extent of the author's knowledge all of the 
material contained within this article is correct, the observations made 
will not necessarily apply to every DCO switch installation everywhere. 
They are generalizations derived from a small sample size and should be 
considered as such.



Speculative and Factual Observations as to the Nature of DCO Access 
-------------------------------------------------------------------

                                                 and General Administration
                                                 --------------------------

DCO-CS Topology-

Note: "TTY" herein is used in accordance with its definition, "A generic 
term for any computer terminal or associated serial interface" and 
"terminal" is used in accordance with the definition, "a device 
communicating over a line". (Source: Wikipedia @ http://www.wikipedia.org)
No references to teletypes or TDDs (Telecommunication Devices for the Deaf)
are intended.

Like the Lucent 5ESS, the Siemens DCO-CS is administered through different 
TTYs (although, unlike the 5ESS, access to the DCO is not divided into as
many specialized "channels"), with different attributes and functions. The
four types of terminals on the switch, as listed in the help file of the 
SETTYP option of the SECTTY utility, are UNEQ (unequipped), CRT (video 
display-the I/O terminals from which the switch is directly administered), 
TTP (paper printer), and MODEM. The identifying format of these terminals 
is TTXX, where XX represents two digits. TT00 is the default system master
console, the terminal from which the MMI as well as various automatic 
utilities are consistently run and at which all information, error and 
alarm messages terminate (unless they are directed elsewhere-see later in 
the document for further information). Dialups connect to other CRT 
terminals for remote access.

MMI Idiosyncrasies-

A few notes on the use of the MMI: first, a semicolon ";" serves the same 
function as a <CR> (carriage return). Backspaces are displayed as "u". 
Within a few utilities, "EXIT" will take effect immediately after being 
typed (without a <CR> or ;). If one is idle for a while at a prompt or 
menu, "^U" will appear and the prompt will be re-displayed. 


 Account/User Hierarchy and Structure- 

While the hierarchical filesystem arrangement of the DCO-CS bears a 
striking fundamental resemblance to that of UNIX, organized a similar 
hierarchy of directories and subdirectories with predefined permissions, 
the user administration system exhibits numerous significant differences in
its structure. For example, there exists no "root" superuser with 
unbridled access to everything, and no user account may interfere directly 
in the affairs of another ("directly" here defined as "from the (same) 
shell/session") as might be accomplished through successful execution of 
the UNIX "su" command. User accounts are instead divided and categorized 
into certain groups with certain "purposes" on the switch in anticipation 
of differing necessities. The default groups are ADMIN, TMRS, STATUS, 
MAINT, SECURE, NAC, ESPF, and SCAT respectively; by default their access is
assigned according to the necessary tasks of each type. The access rights 
of accounts are not quantitatively equivalent, either-certain, more 
generally used accounts are able to access far more by default than more 
specialized accounts, the access of which is restricted to only those 
utilities relevant to their intended functions. All of the usernames and 
passwords to the various accounts within these groups are contained in the 
file printed and modified using the utility $PASSWM. These may or may not 
be set to the default, but it is rather likely that they will be, and even 
if this is not the case the passwords are unlikely to be very complex due 
to the limitations imposed by the MMI (passwords on a DCO may be at maximum
eight characters in length, and only alphanumeric) and simple human apathy;
 in many instances it would seem as if extremely simplistic and 
easily-guessable/crackable passwords are used on switches due to a 
disbelief in the plausibility of unauthorized access. Regardless, the 
default passwords for all pre-programmed usernames are simply the usernames
themselves-for instance, the SCAT/SCAT username/password combination. A 
concise table of DCO default accounts is as follows:

DCO Defaults
____________
Username Password  Group
======== ========  ===== 
ADMIN    ADMIN	   ADMIN
SECURE   SECURE    SECURE
TMRS	 TMRS	   TMRS
SCAT     SCAT	   SCAT
MAINT    MAINT     MAINT
STATUS   STATUS    STATUS
NAC      NAC       NAC
ESPF     ESPF      ESPF


It is significant to the attainment and preservation of one's access on a 
DCO-CS switch to understand the previously mentioned expected "uses" of 
each group of accounts, as one ought to align explorations of the switch 
with the anticipated functions for reasons of stealth-an unauthorized user 
is far less likely to be detected when using certain accounts for certain 
functions that they are intended to be "legitimately" used for. The 
execution of certain utilities while logged in under certain accounts might
be viewed as either suspicious or routine by a watchful administrator, 
depending upon the account and context in which the activity occurs. 
Although a few techniques exist that serve to provide such a user with a 
greater degree of "freedom" in this regard by concealing from those 
monitoring the switch evidence of non-routine activity as is covered 
elsewhere in this article, it is still useful and certainly prudent to 
coincide one's activity with appropriate accounts in a limited number of 
instances. Plus, it is important to consider that the efficient and 
stealthy employment of the techniques that follow may not always be 
practical or possible, so this general method of remaining proverbially 
"under the radar" is fundamentally beneficial. An explanation of the 
various groups/default accounts follows:

ADMIN - This is an administrative group/account, used primarily for the 
purposes of administering the various tables and databases on the switch, 
especially those that pertain to network/routing functions. What the 
authors of the previously mentioned DCO articles obviously failed to 
realize, in their insinuations to the effect that ADMIN is an all-powerful 
account with extremely extensive access rights, is that ADMIN is merely 
another account with access rights defined according to the necessary tasks
of its group. It lacks access to a great deal by default, actually, 
especially files and utilities concerning switch security. The access 
rights of ADMIN often overlap with those of MAINT; therefore, it is 
necessary to understand the differentiations between them, revealed 
through a closer examination of the areas in which the two accounts/groups 
do not overlap. MAINT, as explained in greater detail later, is an account 
intended to be used for the performance of routine maintenance 
functions-the administration of such tables is not routine maintenance, as 
is reflected in the access rights of the MAINT group/account. The default 
access of the admin account may also be conceptualized as the bridge of 
sorts between "intra-switch" and "extra-switch" functions-that is, 
functions (and corresponding utilities/files) that are related only to the 
switch itself (intra-switch), and those with a broader sphere of influence 
on the network (extra-switch). See the "Utility Diagram" for more 
information on and examples of this concept. Examples of strictly 
intra-switch functions include disk operations, processor operations, 
debugging, etc.-similarly, examples of extra-switch functions include call 
tracing, routing, trunk operations, WATS number functions, etc. ADMIN by 
default also has access to intra-switch administrative utilities such as 
ABNUTL (PERFORM AUTOMATIC BALANCE NETWORK FUNCTIONS), AUDIT (VERIFY S/W 
RECORD OF H/W STATES MATCH ACTUAL H/W), COPY (COPY DATABASES FROM MEMORY TO
DISK), etc. where it overlaps with MAINT. 

SECURE - The access of SECURE largely overlaps with all other account 
groups on the utilities to which all or nearly all other account groups 
have default access ($ABORT, $AMPUTL, $CONFIG, $DUMPER, $HEY, etc.). Its 
specialization is revealed, though, in the utilities accessible only by it 
and SCAT, or it, SCAT, and MAINT. These include various alarm utilities, 
$PASSWM, $BLDINH, and $SECTTY-all utilities regarding switch security, as 
the name of the group implies. In a limited number of cases SECURE may be 
less conspicuous than SCAT if only these sorts of utilities must be 
accessed. 

TMRS - This group/account is primarily intended for uses related to the 
Traffic Measurement and Recording System (TMRS), a system that gauges 
network traffic through the switch and generates reports with pertinent 
information. On a side note, TMRS may often be an active task on the master
console. It is able to access many intra-switch functions necessary to the
expedient operation of TMRS, as might be assumed-debug utilities, 
configuration control, etc. Its access rights frequently overlap with those
of ADMIN and STATUS.

SCAT - The closest group/account present on the DCO-CS to a "superuser". 
SCAT is an acronym for "Stromberg-Carlson Assistance Team", the DCO-CS 
equivalent of ETAS on a DMS-100. The function of SCAT, while the DCO-CS 
product line was supported by Stromberg-Carlson/Siemens, was to provide 
technical support for the install base in the instance of technical 
problems/failures, especially during emergencies (critical equipment 
failure, software issues, etc.). As a result, SCAT is authorized by default
to access nearly everything on the switch within the filesystem, usually 
with the highest access rights possible (typically RWX), as, in the event 
of an emergency, such omnipotent access would be vitally necessary. The RWX
permission is a significant distinction of the SCAT group as most other 
account groups only have read/execute permission on most files. However, 
there are a few files on the switch that SCAT is not permitted to access 
(by default, naturally)-for instance, the utility $AMCDMP (that which 
administers AMA message thresholds). By default, SCAT is often the only 
account/group authorized to log in through the dial-up ports, as only SCAT 
would usually require remote access to the switch. Logging in as SCAT is 
extremely conspicuous, though, particularly at odd hours, as the 
account/group is NOT supposed to be used for routine/ordinary tasks. It 
would be advisable from an unauthorized user's standpoint to perhaps log in
as SCAT once in order to authorize other account groups to log in through 
the dialup(s), until the attentiveness of those overseeing the switch's 
operation is gauged. 

MAINT - MAINT is the general maintenance group/account on the DCO-CS; as 
stated previously, it is used primarily for the performance/execution of 
routine (and non-routine) tasks related to switch maintenance. As such, it 
is authorized to access a great deal, often exclusively, where SCAT is the 
only other account group with access rights on certain files. MAINT is the
 only default account group/account, in fact, that is "exclusively" 
authorized to access certain utilities in this manner. AMA is an example of
 a such a utility to which only MAINT and SCAT have access rights in the 
default/typical configuration. As might be expected, MAINT is mainly able 
to access intra-switch functions. One preferred, recommended account for 
preliminary exploration is MAINT, for it, as a maintenance account, is by 
default enabled to access quite a few significant files and programs, and 
suspicions may be less aroused should it be seen logging in at odd hours 
and/or constantly. 

STATUS - The STATUS group/account is, as its name implies, used for 
checking and occasionally modifying the status of the system. Its access 
overlaps frequently with ADMIN, MAINT, TMRS and, of course, SCAT; the 
default access of STATUS is confined to "intra-switch" utilities and the 
occasional utility not easily classified as either "intra-" or "extra-" 
switch. Most of the utilities to which STATUS is assigned default access 
are used for such functions as alarm management, various types of 
verification, disk functions, conversion of equipment numbers, etc. 

NAC - NAC is an acronym for "Network Access Control"-the administration 
charged with overseeing the various pieces of equipment connected to the 
network and general network interactions. Expectedly, its default access 
mainly lies with "extra-switch" network utilities and the those used to 
modify the aforementioned tables, also accessible with ADMIN. The NAC 
terminal and thus group may not be equipped on a particular switch (see 
"$SECTTY"), so it may not be possible to log in under the NAC default 
account. 

ESPF - ESP denotes, "Essential Service Protection". Along with ADMIN, NAC 
and SCAT, ESPF is typically able to access "extra-switch" utilities such as
those related to routing, the hotline database, INWATS, class of service, 
etc., all "essential services". As with NAC, the "ESPF option" may not be 
equipped on a particular switch, and thus the account/group associated with
it may be unused. The $STATUS utility may be used to determine if it is 
equipped:

STA> AREA TO DISPLAY (AREA=HELP) > ESPF

   DCO_CITYDATA
   09-00-00 00:00:00 MONDAY   ESPF STATUS REPORT:

   STATUS: ESPF OPTION NOT EQUIPPED


   STATUS COMPLETE                                                              


Attainment of Access
--------------------

Upon connecting to a TTY via a dialup or another method, the LOGIN utility 
is invoked automatically, which will prompt the user for the username and 
password necessary to log in. By default ten attempts at login (entries of 
a username and password pair) are permitted before the following message is
displayed, indicating an excess of unsuccessful attempts:

DCO_CITYDATA 09-00-00 00:00:00 LOGIN  TT01 
   MP .0676:TTY=TT1 EXCESSIVE LOGIN ATTEMPTS

Subsequently the user will be "locked out" of the terminal for a period of 
approximately five minutes in which the system remains unresponsive to 
input. The amount of login attempts made is not "reset" if one disconnects 
from the dialup/terminal and reconnects; instead, the tracking of login 
attempts is based upon time-one must wait a few minutes prior to attempting
ten more login attempts.


Unauthorized Execution- 

Prior to logging on to the switching station, the user is required within 
approximately 15 seconds following successful connection to send a hard 
break or a <CR> in order to display the prompt. Within this 15 second 
period a vulnerability exists whereby a valid MMI (man-machine interface) 
command typed and sent will be dutifully executed by the DCO, allowing 
temporary control of the MMI command flow to anyone calling the dialup! 
Potential for great compromise of the system exists if the attacker runs a 
command such as $PASSWM, which prints a complete list of user accounts and
passwords on the switch in clear-text! Note: on the latest software 
release, that released in 2003, the maintenance processor (MP) must be 
experiencing a malfunction or otherwise be bogged down with an influx of 
tasks for this technique to work properly. Of all of the vulnerabilities 
presented here the execution of this is the most variable-it has been known
to occur, though, in instances of an MP malfunction, specifically on the 
DCO-SE (see "An Additional Note:" for more information).

Absence of Automatic Logout- 

Like several older versions of UNIX, the DCO-CS does not automatically log 
out of a session in the instance of user disconnection from the 
dialup/terminal. Anyone calling the switch will be thus enabled to 
"drop in" on the other user's session in all aspects, in addition to being 
able to execute commands if a user left the session open while hanging up 
the connection/modem. This is task-specific-that is, if a task is not 
aborted and the user who executed it hangs up, the sub-prompt for that task
will be displayed to anyone calling the switch thereafter as that task will
be active. This state may include tasks only supposed to be executable by 
user accounts with higher levels of access. The sole measure necessary to 
ensure success in gaining control of a session and hence potentially the 
entire switch (as access may be modified- privileges escalated, depending 
upon the account temporarily "hijacked" in this fashion, etc.) is to 
consider the time zone in which the object switch is located, in order to 
determine prime hours of operation and of account access and usage. In the 
instance that the would-be intruder is physically unable to monitor the 
dialup/port for dropped sessions and exploit them, a simple script written 
in a language compatible with the terminal client of choice is all that is 
required. Thus, this single characteristic of the switch-among others, it 
is certain, seen previously and henceforth in this admittedly alinear 
document-ensures that one who accrues the knowledge of a dialup is very
nearly guaranteed successful infiltration/ penetration of it, even in the 
face of other, also ineffective barriers erected presumably for purposes of
security. However, one may experience a limited degree of difficulty with 
this method of intrusion in the instance that one has logged in via the 
dialup port and properly logged out, in which case another one of the 
aforementioned loopholes may be traversed in order to gain eventual 
unfettered access. Also, an option does exist within the $SECTTY utility 
(discussed forthwith) to activate an idle logout on a particular TTY, but 
even this will not log a user out until an extended period of complete 
inactivity has passed-it is still possible to connect to a terminal and 
resume a session with this option activated, if one connects within this 
said window of time. It is a trivial matter indeed to automatically and 
repeatedly call a dialup in order to connect just after a user's activity 
has ceased (indicating a departure from the terminal) and prior to the 
auto-logout due to inactivity. Regardless, this is not a default setting, 
and it is perhaps quite rare that one will encounter it. 


Passive Observation-

A rather simple means through which to learn various information pertaining
to a DCO, that which may prove ultimately useful in the attainment of 
access thereto, is merely that of passive observation of the information 
messages that are displayed even prior to a login-i.e., monitoring the 
dialup. This tendency to display status and other messages to anyone who 
calls a dialup is quite unique to the DCO, although other switches such as 
the EWSD exhibit this characteristic as well. Only messages ordinarily 
broadcast to all ports (or the dial-in TTYs, at least) are displayed prior 
to login, with the most common utility to which these messages pertain the 
$SNCUTL (Synchronous Network Clock Utility). One explanation for this 
idiosycrasy lies in the fact that, when one calls a DCO dialup, one is 
automatically connected to the corresponding TTY-the login prompt/program 
is simply another utility executed like any other (notably, the prompt 
itself reveals this-the "LOG>" portion is of the similar format to all 
other utility menu prompts-the first three letters of the utility + ">") 
except that it is executed automatically upon connection if LOGOFF has been
during the last session from that TTY, as opposed to a front-end program 
that must be satisfied with proper credentials in order to connect to the 
switch at all. In other words, LOGIN technically serves to restrict access
to the remainder of the utilities and files on the switch through the MMI 
rather than access to the MMI itself.


Concealment of Presence
-----------------------

Although the DCO, as has been previously demonstrated, does not exhibit 
PREVENTIVE security measures implemented with any degree of rigor, there 
does exist a simple yet potentially effective means of detection of 
potentially suspicious activity of those with access to the switch: 
extensive logging. The majority of actions performed within the MMI are 
relentlessly logged and broadcast, in messages of the following format:

   DCO_CITYDATA 09-00-00 00:00:00 LOGIN  TT01 
   MP .0354:TTY=TT1,USERNAME=MAINT LOGGED IN

The date, time, program executed or file accessed (if applicable), port of 
origination, sortkey, terminal, and message in ASCII text comprise, in that
order from left to right, top to bottom, the message, the likes of which is
output by default to the local terminal in addition to the console (TT00), 
where the attentive administrator or technician will undoubtedly notice odd
or unexpected activity, such as logins during strange hours, execution of 
programs outside of the aforementioned sphere of tasks of a particular 
account, activity on a particular port that may differ from that upon which
the account/user logged in is ordinarily present, etc. The potential 
negative impact of this upon the maintenance of one's (presumably 
unauthorized) access should be evident; fortunately for the unauthorized 
user, there exist a small variety of methods using a few key utilities to 
mitigate the effect of these messages. 


Defeating the Printing and Logging of Status Messages-

Although it is not directly preventive and thus not a strictly classified 
"security" measure, the constant deluge of status messages pertaining to 
the execution and exit of utilities, etc., especially that of the LOGIN and
LOGOFF utilities, presents a challenge to potential intruders as they are 
by default broadcast to the console (TT00). These messages are identified 
by "sortkeys" of the format XXX.0000 or XX.000, where XX(X) are two or 
three letters signifying the classification/type of the message and the 
zeroes the number of the exact message, which is either three or four 
digits in length. Sortkey numbers of three digits in length may be typed 
with a preceding zero (MP.0354 or MP.354) as well. A list of sortkey 
prefixes (or "groups") follows, provided by $AMPUTL, which is discussed 
elsewhere in this document:


AMP> SORTKEY (SORTKEY=HELP) > 

   VALID RESPONSES ARE GROUP TYPES FOLLOWED BY A GROUP NUMBER YYY.XXXX
   YYY IS THE ALPHA QUALIFIER FOR THE GROUP TYPE
   XXXX IS THE NUMERIC QUALIFIER FOR THE GROUP NUMBER
   * , YYY.* CAN BE USED FOR ALARMS WITHIN A GROUP
   'DONE' CAN BE USED TO TERMINATE THE PROMPT IF THE TASK IS IN A REPEAT 
   MODE
    
   ACI.XXXX - ALARM COMMUNICATION INTERFACE
   ADM.XXXX - ADMINISTRATIVE
   ALT.XXXX - AUTOMATIC LINE TESTING
   AMA.XXXX - AUTOMATED MESSAGE ACCOUNTING
   CBC.XXXX - COMMUNICATION BUS CONTROLLER
   CLC.XXXX - COMMUNICATION LINK CONTROLLER
   CLK.XXXX - SNC, ANI, CLOCKS
   CP.XXXX  - CALL PROCESSOR ALARMS
   CPE.XXXX - CALL PROCESSOR ERROR ALARMS
   CUS.XXXX - CUSTOMER GENERATED ALARMS
   DLI.XXXX - DATA LINK INTERFACE
   DS1.XXXX - DIGITAL T-1 SPAN MODULE ALARMS
   ENV.XXXX - ENVIORNMENTAL ALARMS
   FP.XXXX  - FEATURE PROCESSOR
   LGC.XXXX - LINE GROUP CONTROLLER

AMP> ADDITIONAL HELP (MORE=YES) > 

   LIN.XXXX - LINE
   LSC.XXXX - LINE SWITCH CONTROLLER
   LTC.XXXX - LINE TEST CONTROLLER
   MAH.XXXX - HOST MESSAGE ASSEMBLER
   MAR.XXXX - REMOTE MESSAGE ASSEMBLER
   MCC.XXXX - MCC ALARMS
   MCI.XXXX - MAINTENANCE COMMUNICATION INTERFACE
   MDC.XXXX - MAINTENANCE AND DIAGNOSTIC CONTROLLER 1
   MD2.XXXX - MAINTENANCE AND DIAGNOSTIC CONTROLLER 2
   MIC.XXXX - MESSAGE INTERFACE CONTROLLER
   MP.XXXX  - MAINTENANCE AND ADMINISTRATION PROCESSOR
   PWR.XXXX - POWER ALARMS
   RLG.XXXX - REMOTE LINE GROUP
   RNG.XXXX - RINGING
   RPL.XXXX - REMOTE POLLED LAMA
   SLC.XXXX - SLC-96
   SS7.XXXX - SS7 ALARMS
   SSC.XXXX - SIGNALLING SYSTEM CONTROLLER
   SVC.XXXX - SERVICE CIRCUITS
   TMP.XXXX = TMP ALARMS
   TON.XXXX - TONE

AMP> ADDITIONAL HELP (MORE=YES) > 

   TPP.XXXX - TELEPHONY PRE-PROCESSOR
   TRK.XXXX - TRUNK
   TST.XXXX - TEST ALARMS


The knowledge of the sortkey of a particular message is necessary to alter 
or display data associated with that message within the following 
utilities. Sortkeys may be identified in messages as seen above, or looked 
up in the $AMPUTL utility. The messages are quite inherently extensive in 
their reporting of the conditions in which the task reported upon was 
executed; thus, they provide an extremely incriminating record of 
unauthorized or "odd" activity on the switch. The author is personally 
aware of at least one specific instance in which an individual's access to 
a DCO was permanently terminated due to precisely this-the astute viewing 
of messages printed to the console and elsewhere culminating in a 
realization of unauthorized activity. It is therefore extremely important 
for the unauthorized user to control when, how, and where these messages 
are printed. There exist to this end a few effective methods by which to 
thwart the tracking of one's activity on the switch using the utilities and
access available as a segment of the MMI. It is recommended that all of 
these be used in combination, in order to ensure maximum possible stealth.
All are generally individually limited by the existence of the logging 
measures defeated by the others; for instance, the use of the command 
parameter /NODIAL is assistive in concealing one's presence, but the 
storage and direction of information messages generated by 
utilities/programs will require the use of $AMPUTL to protect most fully 
the secrecy of usage. 

The /NODIAL Parameter-

Within the DCO MMI there are certain parameters that may be affixed to 
command strings in order to handle the input and output of commands. 
/NODIAL is one such parameter. It is an abbreviation for "NO DIALOGUE", 
indicating that the execution of a command/menu option to which it is 
affixed will not be itself reported to the defined termination points (the 
ports/TTYs to which the message is sent/printed). Alternately conveyed, one
through the use of /NODIAL avoids the printing of this sort of 
"BEGIN/END DIALOGUE" message:


DCO_CITYDATA 09-00-00 00:00:00 ADMIN TT01
M  ADM.0000: ADMIN BEGIN DIALOGUE


The begin/end dialogue messages may not be manipulated through $AMPUTL or 
the other following utilities, since the sortkey ADM.0000 is not recognized
by them as valid. ADM.0000 is a universal sortkey of sorts, used to signify
all "begin dialogue" messages for all utilities/programs; it is thus 
unassigned to any particular message. Likewise, sortkey ADM.0001 
universally signifies all "end dialogue messages", and is unassigned 
therefore as well. An attempt to alter or display a message with sortkey 
ADM.0000 through $AMPUTL will prompt the following output:


AMP> SORTKEY (SORTKEY=HELP) > ADM.0000
   AMPUTL: SORTKEY IS UNASSIGNED  


/NODIAL will offer one a degree of anonymity, then, but it does not prevent
certain messages from being printed/displayed.
 
Thwarting Information Messages With $AMPUTL- 

A method exists to defeat the broadcast of messages using the $AMPUTL 
command, the likes of which entails the use of the Alarm Message Processing
Utility, a program accessible to all default groups. The AMPUTL menu system
is as follows:


$AMPUTL

AMP> FUNCTION (FUNCTION=HELP) > 

   CHANGE - CHANGE MESSAGE
   DISPLAY - DISPLAY MESSAGE
   EXIT


The "DISPLAY" option will display the text of the message itself in 
addition to other information pertaining to it, such as the termination 
points, alarm level (if applicable), etc. Here is an example of the output 
of "DISPLAY" for sortkey MP.0354, which identifies the message that a user 
has logged into the switch:


AMP> FUNCTION (FUNCTION=HELP) > DISPLAY

AMP> SORTKEY (SORTKEY=HELP) > MP.0354

   SORTKEY ENTRY MP .354
   <TTY><DT1=USERNAME.A8>LOGGED IN
   ALARM LEVEL NONE
   INFORMATION MESSAGE 
   NO ACI INTERFACE, TERMINAL LIMIT 0
   TERMINATION POINTS ARE CONSOLE, TI:, 


The first field obviously contains the sortkey used to identify the
message, the second line/field the ASCII text of the message, the third 
field the alarm level, (which is here "NONE" since the logging in and out 
of users does not activate an alarm), the fourth the type of message, the 
fifth the type of interface and terminal limit associated with the message,
and the final field the termination points. Using the "CHANGE" option to 
alter the properties of any particular message, a multitude of options may 
be set, but most importantly the text and termination points of the message
may be altered, presenting two possible venues to negate the revealing 
effect of such messages. The termination point may be set thus to the 
initiating terminal only, or the text of the message may be altered to suit
the needs of an intruder. A list of attributes that may be altered through
CHANGE follows:


AMP> FUNCTION (FUNCTION=DISPLAY) > CHANGE

AMP> FIELD (FIELD=HELP) > 

   ADMINISTERABLE FIELDS ARE:
    
   EXIT - EXIT AMPUTL
   ^ - QUIT CHANGE WITHOUT UPDATING
   DONE - UPDATE DATABASE ON DISK
   ACI - ALARM CONTROL INTERFACE
   DELAY - DELAY ALARM SENDING
   E2A - E2A ADDRESS
   FEI - FAULT, ERROR, OR INFORMATION
   GROUP - GROUPING NUMBER
   LEVEL - ALARM LEVEL
   LIMIT - TERMINAL LIMIT
   MASKABLE - MASKABILITY FLAG
   REPEAT - REPEAT FLAG
   TERMPT - TERMINATION POINTS
   TEXT - ASCII TEXT (OUTPUT MESSAGE)
   RLS - RLS ALARM MESSAGE
   BMP - BMP LED ASSIGNMENT

To alter the termination points of the message, thereby instructing the 
switch to print it only to certain specified terminals/TTYs, TERMPT is 
entered at the FIELD prompt:


AMP> FIELD (FIELD=HELP) > TERMPT
   TERMPTS ARE CONSOLE, TI:, 


The current termination points of this message were, as displayed, the 
console and TI (initiating terminal). Numerous devices are then presented 
which may be set as termination points for the message:


AMP> DEVICE (DEVICE=HELP) > 

   EXIT - EXIT FROM MASKING UTILITIES
   ^ - BACKUP TO PREVIOUS PROMPT
   DONE
   ALL       - ALL PORTS
   CONSOLE   - SYSTEM CONSOLE
   NAC       - NAC TERMINAL
   RLS       - RLS TERMINAL
   AMATPS    - AMATPS MESSAGE FILE
   TT00-TT31 - ANY PARTICULAR TTY
   TI        - INITIATING TERMINAL


For maximum stealth it would be advisable to set the termination points of 
a message to the initiating terminal only, so that it will be displayed 
only on the remote user's terminal, here TT01, when it is invoked by said 
user:


AMP> DEVICE (DEVICE=HELP) > CONSOLE

AMP> STATUS (STATUS=HELP) > 

   REMOVE
   ADD
   ^
   EXIT

AMP> STATUS (STATUS=HELP) > REMOVE

AMP> DEVICE (DEVICE=DONE) > 

AMP> FIELD (FIELD=HELP) > TERMPT
   TERMPTS ARE TI:, 

AMP> DEVICE (DEVICE=HELP) > DONE

AMP> FIELD (FIELD=DONE) > 

AMP> FUNCTION (FUNCTION=CHANGE) >


Following this procedure, the termination point of the message MP.0354 is 
set only to the initiating terminal; when a user logs in from TT01, the 
information message announcing it will only be displayed on his/her 
terminal and will not be printed to the console. It would be most useful 
for an unauthorized user to set the termination points of the following few
messages to TI only: MP.0354 (<TTY><DT1=USERNAME.A8>LOGGED IN), MP.0343 
(<TTY>LOGGED OFF), MP.0676 (<TTY>EXCESSIVE LOGIN ATTEMPTS), MP.0002 (FILE 
NOT FOUND ON DISK), MP.0461 (<TASK><FILE>INVALID NAME) and MP.0733 (INVALID
TASK NAME) as these will commonly and naturally, as a matter of course, be 
displayed through navigation into and around the switch and reveal 
glaringly more than any other information or error messages an unauthorized
presence.


Monitoring Other TTYs and Redirecting Messages With $UTL-

Occasionally during the course of switch use it may prove useful to monitor
and manage tasks active on other terminals and to redirect I/O. The Utility
Program ($UTL) may be employed to accomplish these and other functions 
related to task management. Unlike other utilities discussed throughout, 
the "function codes" of $UTL must be entered in a single string on the 
command line:


$UTL /NODIAL
   DCO_CITYDATA
   09-00-00 00:00:00 TUESDAY  UTILITY PROGRAM

   UTL:INVALID FUNCTION CODE

DCO>
$UTL HELP /NODIAL
   DCO_CITYDATA
   09-00-00 00:00:00 TUESDAY  UTILITY PROGRAM
   FUNC  DESCRIPTION              FORMAT EXAMPLES  
   ====  =======================  ===============  
   ACT   ACTIVE TASK LIST         ACT              
             OR                   ACT ALL          
             OR                   ACT TERM         
             OR                   ACT TERM:TT06    
             OR                   ACT ALL TERM     
             OR                   ACT ALL TERM:TT06
   ATB   AUTO TRUNK MAKE BUSY     ATB 122.:ON=50.  
             OR                   ATB 37.:OFF      
   BRO   BROADCAST MESSAGE        BRO TT02 HELLO   
             OR                   BRO ALL REBOOT   
   DMO   DISMOUNT DEVICE/FEATURE  DMO I1:          
             OR                   DMO CNTRL        
             OR                   DMO REQUIRED     
             OR                   DMO LSXWRI 430   
   MOU   MOUNT DEVICE/FEATURE     (SEE DMO EXAMPLES)
   PRI   STATIC PRIORITY          PRI              
             OR                   PRI STATUS       
             OR                   PRI STATUS=100   
   RED   REDIRECT TASK I/O        RED STATUS:TT01  
   RPR   RUN PRIORITY             (SEE PRI EXAMPLES)
   SCED  SCHEDULED TASKS          SCED             
   TID   TERMINAL ID QUERY        TID              


ACT will display a list of active tasks based upon the parameter entered. 
As seen in the capture, to display tasks active on a particular terminal, 
one would enter: 


$UTL ACT TERM:TTXX


ATB will busy out a specified trunk, BRO will broadcast a message to 
another terminal, PRI sets priority of tasks, and DMO/MOU will mount or 
dismount devices/features. Possibly the most useful function of UTL is RED,
which may be entered to redirect the I/O of a task to another terminal as 
seen in the format example in the capture. Reports generated with numerous
other utilities might be printed elsewhere, etc. TID or "TERMINAL ID QUERY"
will simply display the terminal that one is currently using, similar to 
the "tty" command in DMERT/UNIX-RTR/5ESS UNIX on a Lucent 5ESS. 


$UTL TID /NODIAL
   DCO_CITYDATA
   09-00-00 00:00:00 TUESDAY  UTILITY PROGRAM

   TERMINAL ID => TT01


Rerouting Messages with $RRTUTL-

The $RRTUTL utility may be used to reroute messages destined for a 
particular TTY and to display message routing to terminals. 


RRT> FUNCTION  (FUNC=HELP) > 

   VALID FUNCTIONS ARE:
   LIST - LIST ALL LOCAL OR REMOTE TERMINAL ROUTING
   DISPLAY - DISPLAY ONE LOCAL OR REMOTE TERMINAL ROUTING
   CHANGE - CHANGE ONE LOCAL OR REMOTE TERMINAL ROUTING
   EXIT - EXIT OUT OF THIS OVERLAY

RRT> FUNCTION  (FUNC=HELP) > DISPLAY

RRT> DATABASE  (DATABASE=HELP) > 

   ENTER ROUTING DATABASE TYPE - LOCAL OR REMOTE
   LOCAL - ROUTING OF MESSAGES VIA THE TERMINAL NUMBER OR BY SORTKEYS
   REMOTE - ROUTING OF RNS/RLS-4000 MESSAGES VIA THE NODE NUMBER

RRT> DATABASE  (DATABASE=HELP) > LOCAL

RRT> TYPE OF TERMINAL  (TYPE=HELP) > 

   ENTER TERMINAL #, OUTPUT DEVICE PSEUDO NAME OR SORT KEY
   THAT IS TO HAVE ITS MESSAGES REROUTED

RRT> TYPE OF TERMINAL  (TYPE=HELP) > TT01

   RRTUTL: INVALID TYPE ENTERED - TT01, PLEASE RE-ENTER

RRT> TYPE OF TERMINAL  (TYPE=HELP) > 01

   PORT 1 HAS NO FAILOVER PORT
   PORT 1 HAS NO REROUTING

RRT> FUNCTION  (FUNC=DISPLAY) > 

RRT> DATABASE  (DATABASE=LOCAL) > 

RRT> TYPE OF TERMINAL  (TYPE=01) > 00

   PORT 0 HAS FAILOVER PORT = 1
   PORT 0 REROUTE TO PORT 1
   PORT 0 REROUTE TO PORT 2

RRT> FUNCTION  (FUNC=DISPLAY) > 

RRT> DATABASE  (DATABASE=LOCAL) > 
RRT> TYPE OF TERMINAL  (TYPE=00) > 02

   PORT 2 HAS NO FAILOVER PORT
   PORT 2 HAS NO REROUTING

RRT> FUNCTION  (FUNC=DISPLAY) > 

RRT> DATABASE  (DATABASE=LOCAL) > 
RRT> TYPE OF TERMINAL  (TYPE=02) > 03

   PORT 3 HAS NO FAILOVER PORT
   PORT 3 HAS NO REROUTING

RRT> FUNCTION  (FUNC=DISPLAY) > 

RRT> DATABASE  (DATABASE=LOCAL) > 

RRT> TYPE OF TERMINAL  (TYPE=03) > 04

   PORT 4 HAS NO FAILOVER PORT
   PORT 4 HAS NO REROUTING

RRT> FUNCTION  (FUNC=DISPLAY) > EXIT /NODIAL


As seen in the captures, messages destined to port 0 (the system master 
console, TT00) will reroute to ports 1 and 2 (TT01 and TT02). 		

Defeating Alarm Logging with $HSTUTL-

As may be discovered through interactive use of the $AMPUTL utility, 
information messages (such as notification of user login/off) and alarm 
messages are distinctly categorized, although the broadcast method used for
both is identical. With the use of any hacker/inexperienced user of the 
switch lies the possibility that mistakes will be made and alarms 
activated. Alarms, in certain situations, may reveal an unauthorized 
presence on the switch, and as such must be for purposes of stealth 
silenced. Such an occurrence is highly unlikely, however, and one exploring
a DCO without authorization would be well advised to refrain from tampering
with the alarms stored on the switch as they are often diagnostically 
essential to switch maintenance; the deletion of crucial alarms not yet 
reviewed by maintenance would be potentially perilous indeed. In any case, 
alarm messages are logged in history files stored on the disk and 
accessible through $HSTUTL. These history files are classified into 
numbered "controllers" based upon the type of alarms with which they are 
concerned, and the "data files" of the alarm messages themselves. 
Operations on controllers provide a general overview of the alarm logs 
without the need to view specific, dated messages. The menu system of 
HSTUTL:


$HSTUTL /NODIAL           

HST> FUNCTION (FUNC=HELP) >                           

   EXIT - EXITS HSTUTL                      
   DISPLAY - DISPLAYS SINGLE HISTORY FILE                                         
   LIST - LISTS ALL HISTORY FILES                                 
   ADD - ADD A NEW HISTORY FILE ENTRY                                     
   DELETE - DELETE A HISTORY FILE ENTRY                                       
   CHANGE - CHANGE AN EXISTING HISTORY FILE ENTRY                                                 
   BRIEF - GENERATE BRIEF HISTORY REPORT     


With "DISPLAY", one may display either a controller or a data file; as per 
usual, the "LIST" option will either list all controllers in output 
complete with references and occurrences, or all data files associated with
a particular controller.


HST> FUNCTION (FUNC=HELP) > LIST

HST> CONTROLLER OR LOGGING (TYPE=HELP) > 

   EXIT - EXITS HSTUTL
   CONTROLLER - HISTORICAL LOGGING CONTROLLER FILE
   LOGGING - HISTORICAL LOGGING DATA FILE

HST> CONTROLLER OR LOGGING (TYPE=HELP) > CONTROLLER

   CONTROL NAME                                      REF  OCCUR. MATCH TYPE
   ------- ---------------------------------------- ----- ------ ----------
       0   SGD ALARMS                                109    10      NONE
       3   SYNC ALARMS                                42    10      NONE
       5   SWC ALARMS                                 74    10      NONE
       6   TPP MISMATCH ALARMS                         1    10      NONE
       7   STATE 1                                     1    10      NONE
       8   STATE 2                                     1    10      NONE
       9   STATE 4                                     1    10      NONE
      10   CBC RESTARTED/STARTUP COMPLETE              2    10      NONE
      11   LSC STARTUP COMPLETE                        1    10      NONE
      12   FP RESTORE/STARTUP COMPLETE                 3    10      NONE
      13   EXTENDED NON-SYNCHRONOUS OPERATION          1     1      NONE
      14   MP STARTUP COMPLETE                         1    10      NONE

HST> FUNCTION (FUNC=LIST) > 

HST> CONTROLLER OR LOGGING (TYPE=CONTROLLER) > LOGGING

HST> CONTROLLER NUMBER (CONT=HELP) > 0

   CONTROL NAME                                      REF  OCCUR. MATCH TYPE
   ------- ---------------------------------------- ----- ------ ----------
       0   SGD ALARMS                                109    10      NONE

   DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00 
   ** PWR.0001: BATTERY CHARGER FAILURE (SGD)

   DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00 
   ** PWR.0001: BATTERY CHARGER FAILURE (SGD)

   DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00 
   ** PWR.0001: BATTERY CHARGER FAILURE (SGD)

   DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00 
   ** PWR.0001: BATTERY CHARGER FAILURE (SGD)

   DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00 
      MP .0098:CMF=000,SIDE=X REFERENCE TIMING DEVIATION

   DCO_CITYDATA 09-00-00 00:00:00 SWITCH TT01 
      CLK.0009:CMF=000,SIDE=Y MASTER CLOCK SWITCHED TO ONLINE (SGD)

With "CHANGE" one may alter a history file entry, and one may delete an 
existing one with, naturally, "DELETE". 


Escalation of Privileges
------------------------

In many cases it may be necessary for the unauthorized user to escalate the
privileges of a particular account to which access has been attained, or to
obtain access to the switch through another account entirely with alternate
privileges. The purposes or motives behind such an attempt at privilege 
escalation may be directed at expansion of one's ability to ability to 
explore the switch, or perhaps to the end of stealth itself; as has been 
demonstrated previously and heretofore, the specialization of accounts may 
restrict one's access to utilities necessary for concealment. Both 
superficial methods and those requiring one to delve more deeply into the 
heart of the switch, as it were, exist naturally to this end.


$SECTTY- 

As an attempted security measure to counter the general problem of nearly 
universally used defaults, it may be impossible to login with any account 
other than SCAT from the dial-in ports; however, SCAT is authorized to 
execute the command $SECTTY, which sets attributes such as terminal logins.
It is therefore possible to individually add users to the list of those 
authorized to log in from, as an example, TT01, or to create a new user 
group, assign all of the desired users/accounts to it, and authorize said 
group to log in from TT01. Restricted access to the file system as well as 
to certain ports and utilities is one of the primary security measures 
employed by the DCO-CS to limit user access based upon necessity.


DCO>

$SECTTY

   DCO_CITYDATA 08-00-00 00:00:00 SECTTY TT01
M  ADM.0000: SECTTY BEGIN DIALOGUE

SEC> FUNCTION (FUNC=HELP) > 

   THE FOLLOWING IS A LIST OF VALID FUNCTIONS :
   SETCON         - SET SYSTEM CONSOLE
   SETNAC         - SET NAC TERMINAL
   ADD            - GROUP TO TERMINAL ACCESS
   DELETE         - GROUP FROM TERMINAL ACCESS
   DISPLAY        - EQUIPPED TERMINAL ACCESS RIGHTS
   DEFINE         - NEW GROUP NAME
   REMOVE         - EXISTING GROUP NAME
   RESTRICTION    - SET UP FUNCTION LEVEL RESTRICTION FOR GROUP
   LIST           - VALID GROUP NAMES
   SETTYP         - SET TERMINAL TYPE
   SETATT         - SET TERMINAL ATTRIBUTES
   EXIT           - EXITS SECTTY

SEC> FUNCTION (FUNC=HELP) > DISPLAY

SEC> TTY NUMBER (TTY=HELP) > 

   VALID TTY NUMBERS ARE:
   0-31

SEC> TTY NUMBER (TTY=HELP) > 00
 
   SECTTY - TERMINAL ACCESS RIGHTS
  
   TTY       GROUP
   -------------------
    0        SCAT  


SEC> FUNCTION (FUNC=DISPLAY) > 

SEC> TTY NUMBER (TTY=00) > 01
 
   SECTTY - TERMINAL ACCESS RIGHTS
  
   TTY       GROUP
   -------------------
    1        SCAT  

SEC> TTY NUMBER (TTY=4) > 3 
   SECTTY - TERMINAL ACCESS RIGHTS
  
   TTY       GROUP
   -------------------
    3        SCAT  

SEC> FUNCTION (FUNC=DISPLAY) > LIST
 
   SECTTY - VALID GROUP NAMES
 
   GRP#  GRP NAME             RESTRICTION WORD 
                     15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC 
   -------------------------------------------------------------
     1    ADMIN       0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     2    TMRS        0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     3    STATUS      0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     4    MAINT       0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     5    SECURE      0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     6    NAC         0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   1
     7    ESPF        0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0
     8    UNDEFINED
     9    UNDEFINED
    10    UNDEFINED
    11    UNDEFINED
    12    UNDEFINED
    13    UNDEFINED
    14    UNDEFINED
    15    UNDEFINED
    16    SCAT        0  0  0  0  0  0 0 0 0 0 0 0 0  0   0   0

SEC> FUNCTION (FUNC=DISPLAY) > ADD

SEC> GROUP NAME (NAME=HELP) > MAINT

SEC> TTY NUMBER (TTY=00) > 01

   SECTTY: GROUP ADDED FOR TTY 1

SEC> FUNCTION (FUNC=ADD) > EXIT


Terminal access rights/privileges are defined, as seen in the captures, 
through the bit configuration of a "restriction word" for each group. Group
access may also be manipulated through the modification of this word.


SEC> FUNCTION (FUNC=HELP) > RESTRICTION

SEC> GROUP NUMBER (GROUP=HELP) > 1
   CURRENT RESTRICTION WORD:
 
   GRP#  GRP NAME             RESTRICTION WORD 
                     15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC 
   -------------------------------------------------------------
     1    ADMIN       0  0  0  0  0  0 0 0 0 0 0 0 0  1   0   0

SEC> RESTRICTION WORD (VALUE=HELP) > 

   0 - 65535  ANY BIT CONFIGURATION OF WORD


SETATT allows a user to set numerous terminal options, one of which is 
particularly significant as pertains to the concealment and hence 
preservation of one's access.  


SEC> FUNCTION (FUNC=HELP) > SETATT 

SEC> TTY NUMBER (TTY=HELP) > 01

SEC> OUTPUT NULLS (NULL=YES) > 

SEC> OUTPUT PRIORITY (PRIORITY=NO) > 

SEC> VT RESTRICTED (VTREST=NO) > 

SEC> ECHO I/O TO SCC (SCC_ECHO=NO) > 

SEC> INTER CHARACTER TIMING (INTCHAR TIME=YES) > 

SEC> IDLE TERMINAL LOGOFF (IDLE TIME=NO) > 

SEC> PAGINATED OUTPUT (PAGOUT =NO) > 

SEC> SEND EOM TO TERMINAL (EOM=YES) > 

SEC> TERMINAL LIMIT (LIMIT =0) >


SCC_ECHO may be set to "YES" or "NO" depending upon the individual 
configurations of different TTYs, but it should certainly be set to "NO" 
during unauthorized usage-otherwise, input and output through the terminal 
will be echoed to the SCC, and, due to the heavy monitoring thereof, one's 
access will be likely detected quickly and terminated, at best, rather 
quickly! If this was set for a particular TTY, though, an alteration of it 
might be noticed soon thereafter and thought suspicious; it is therefore 
advisable, if SCC_ECHO was set to "YES", to turn it off during one's 
session of system use and set it back to its original state prior to 
logging off. Then again, if this option was set for a single TTY, it might 
be wise simply to login from another if possible, for at least a minimal 
amount of preliminary I/O would be echoed to the SCC prior to deactivation 
of that feature.


Exploration of the File System with $FILSYS-

The filesystem of the DCO-CS is accessible through the $FILSYS utility, 
from which directories may be traversed, various forms of the disk 
directory printed, access rights displayed and modified, etc. The 
functions/options of FILSYS are as follows:


FIL> ENTER FUNCTION (FUNC=HELP) > 

   ACCESS      - CHANGE ACCESS RIGHTS
   ATTRIB      - LIST ALL FILES W/ THE SPECIFIED ATTRIBUTE
   BACKUP      - BACKUP DISK
   BADBLK      - GET A BAD BLOCK REPORT
   BLKEDT      - EDIT DISK BLOCKS
   COMPARE     - COMPARE TWO FILES
   COMPRESS    - COMPRESS A DISK
   COPY        - COPY FILES
   CP_COMPRESS - COMPRESS CP PROGRAM FILE
   CWD         - CHANGE WORKING DIRECTORY
   DB_COMPRESS - COMPRESS CP DATABASE FILE
   DELETE      - DELETE FILE
   DIR         - DISK DIRECTORY
   DSKCMP      - DISK COMPARE
   FDIR        - FULL DISK DIRECTORY
   FORMAT      - FORMAT A DISK
   FREE        - GET FREESPACE INFORMATION FOR A DISK
   HDEDIT      - EDIT PROGRAM HEADER
   MKDIR       - MAKE A SUB-DIRECTORY
   MKFS        - MAKE A FILESYSTEM
   MKTAPE      - MAKE A DCO TAPE FILESYSTEM

FIL> ADDITIONAL HELP (MORE=YES) > 

   MOVE        - MOVE A FILE FROM ONE DIRECTORY TO ANOTHER
   RENAME      - RENAME FILES
   SCHEDULE    - SCHEDULE DSKMGR TO RUN
   SDIR        - SHORT DISK DIRECTORY
   SFDIR       - SHORT FULL DISK DIRECTORY
   TYPE        - PRINT TEXT FILE CONTENTS
   VOLCHG      - CHANGE A VOLUME LABEL


As stated previously, the DCO-CS filesystem is divided into many 
directories and sub-directories beginning with the /ROOT/ directory. The 
file attributes that may be input at ATTRIB are:


FIL> ENTER ATTRIB (ATTRIB=HELP) >

   ABCPSU -  ABORT TASK ON CPSU
   ABSWO  -  ABORT TASK ON A/B SWITCHOVER
   CCHOFF -  TASK RUNS WITH CACHE OFF
   CP1SYS -  SINGLE COPY ALLOWED PER SYSTEM
   CP1TTY -  SINGLE COPY PER TERMINAL ALLOWED
   DBFILE -  DATA BASE FILE
   DCCNTL -  UNDER DIAGNOSTIC CONTROL
   INCSWO -  INHIBITS MP CONTROLLED SWITCHOVER
   INDSPA -  TASK HAS SEPARATE I AND D SPACE
   INSTLL -  TASK MAY BE INSTALLED
   INTACT -  TASK IS INTERACTIVE
   KTASK  -  KERNAL TASK
   MEMSEG -  TASK IS MEMORY RESIDENT SEGMENTED
   MRDATA -  MEMORY RESIDENT DATA BASE
   NOABRT -  DO NOT ALLOW ABORT OF TASK
   NOINTS -  TASK RUNS WITH INTERRUPTS OFF
   NONMAN -  NO MANUAL INITIATION OR ABORT ALLOWED
   NOSTAT -  NO PRINT IN ACT STAT LIST IF BLOCKED
   QUEREQ -  QUEUE REQUEST IF TASK ACTIVE
   RBOABR -  RE-BOOT ON ABORT
   RESCED -  RESCHEDULE TASK IF ABORTED

FIL> ADDITIONAL HELP (MORE=YES) >

   SEGMNT -  SEGMENTED TASK
   SGUMAP -  UNMAP UNUSED MEMORY AFTER SEGMENT LOAD
   SHRMEM -  SHARE MEMORY IF TASK ACTIVE
   STKCON -  ALLOCATE STACK CONTIGUOUS TO PROGRAM
   STKHI  -  ALLOCATE STACK FROM UPPER PAR AVAILABLE                            


Blocks of memory on the disk may be manually edited with BLKEDT (the 
$MEMMAP utility displays block numbers, types, sizes, and names):


FIL> ENTER DEVICE (DEVICE=HELP) > SY

FIL> ENTER BLOCK (BLOCK=HELP) >

   VALID BLOCKS ARE OCTAL NUMBERS FROM
   0 TO THE MAXIMUM FOR THIS DEVICE.

FIL> ENTER BLOCK (BLOCK=HELP) > 0

   LOCATION: 000000  000002  000004  000006  000010  000012  000014  000016
      VALUE: 000240  000402  000042  000340  106427  000340  010167  000602
FIL> NEW VALUE: HELP

   ADV    - ADVANCE TO NEXT 8 WORDS OF BLOCK
   BCK    - BACKUP TO PREVIOUS 8 WORDS OF BLOCK
   EXIT   - EXIT BLKEDT WITHOUT DISK UPDATE
   DONE   - DONE, UPDATE BLOCK TO DISK
   OCTAL NUMBERS RANGING FROM 0 TO 177777

                                       
DIR, FDIR, SDIR, and SFDIR all display in some fashion the disk directory. 
DIR displays the components of the directory in the following format:


FIL> ENTER FUNCTION (FUNC=HELP) > DIR

FIL> ENTER FILENAME (FILE=HELP) >

   ANY FILENAME

FIL> ENTER FILENAME (FILE=HELP) > /

  FILENAME  TYPE  CREATION DATE     LAST CHANGE    FILE SIZE PRIO A HDRADDR

/ROOT/
   BITMAP     FRSP
AMPPAT    DIR 03-00-00 00:00:00 03-00-00 00:00:00 000000220 0000 0 00XXXXXX

/ROOT/AMPPAT/
T0000_RES P/D 03-00-00 00:00:00 03-00-00 00:00:00 000000002 0000 0 00XXXXXX
P0054_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000367 0000 0 00XXXXXX
P0068_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000306 0000 0 00XXXXXX
P0070_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000764 0000 0 00XXXXXX
P0119_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000002501 0000 0 00XXXXXX


The filename, file type, creation date, date of last change, file size, 
priority, and address on the hard disk are displayed. The two file types 
are DIR (directory) and P/D (program, .txt file, .dat file, etc.). FDIR 
(Full Disk Directory) displays a few more aspects of files examined:


FIL> ENTER FUNCTION (FUNC=DIR) > FDIR

FIL> ENTER FILENAME (FILE=ROOT/) >

  FILENAME  TYPE  CREATION DATE     LAST CHANGE    FILE SIZE PRIO A HDRADDR

/ROOT/
BITMAP    FRSP
AMPPAT    DIR 03-00-00 00:00:00 03-00-00 00:00:00 000000220 0000 0 00XXXXXX
          ACCESS  - (MAINT ,RWX)
          EXTENTS - 71(1.)

/ROOT/AMPPAT/
T0000_RES P/D 03-00-00 00:00:00 03-00-00 00:00:00 000000001 0000 0 00XXXXXX
          ACCESS  - (MAINT ,RWX)
          EXTENTS - 14304(1.)
P0054_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000376 0000 0 00XXXXXX
          ACCESS  - (ADMIN ,RW),(TMRS  ,RW),(STATUS,RW),(MAINT ,RW)
                    (SECURE,RW),(NAC   ,RW),(ESPF,RW)
          EXTENTS - 212753(5.)                                                  


In addition to the attributes displayed with DIR, with FDIR the access 
rights and extents of the files are displayed. Access rights are displayed 
in the format (GROUP, ABC) where ABC is populated with R (read), W (write),
and/or X (execute). SDIR will only display subdirectories within the 
directory initially given (if a directory is initially provided) in the 
minimal DIR format. If a subdirectory containing P/D files is entered, the 
attributes of those files will be printed in the single-line minimal format
as well. SFDIR will display the directories in the "full format" (with 
access and extents) before the P/D files, as does SDIR. Access rights are 
modified through ACCESS:


FIL> ENTER FUNCTION (FUNC=HELP) > ACCESS

FIL> ENTER FILENAME (FILE=HELP) > FILENAME

FIL> ENTER FUNCTION (FUNCTION=HELP) >

   ADD    - ADD ACCESS RIGHTS
   DELETE - DELETE ACCESS RIGHTS
   LIST   - LIST ACCESS RIGHTS

FIL> ENTER FUNCTION (FUNCTION=HELP) > LIST

   GROUP    RIGHTS
   -----    ------
   ADMIN     R
   TMRS      R
   STATUS    R
   MAINT     R
   SECURE    R
   NAC       R
   ESPF      R
   SCAT      RW

FIL> ENTER FUNCTION (FUNCTION=LIST) > ADD

FIL> GROUP (GROUP=HELP) >

   ENTER ANY OF THE FOLLOWING GROUP NAMES

   ADMIN
   TMRS
   STATUS
   MAINT
   SECURE
   NAC
   ESPF
   SPARE1
   SPARE2
   SPARE3
   SPARE4
   SPARE5
   SPARE6
   SPARE7
   SPARE8
   SCAT
   DONE - UPDATE FILE ACCESS RIGHTS ON DISK                                     


The setting of access rights through FILSYS will alter the access rights 
stored in the file PTL.TXT, which may also be modified alternately and 
directly as discussed in the next section.
 
PTL Modification-

To comprehend this concealment technique it is necessary to possess an 
understanding of the derivation of access rights in the file system. 
Occasionally (or often, depending upon the utilities used and the account 
logged on) the curious hacker/phreak will find that the "INSUFFICENT ACCESS
RIGHTS" message will be displayed at attempts to invoke particular 
programs/utilities or to view certain files. Even using the disk directory 
options/functions of the $FILSYS utility it will be observed that 
information for certain files is irretrievable due to insufficient access. 
The inevitable question then arises as to where all of these access rights 
are defined. Rewarded is the hacker who considers this sort of question-the
context of DCO exploration is no exception. Access rights and many other 
attributes are defined and stored in an ASCII text file named PTL.TXT, 
(access rights are merely a tertiary option) in the /ROOT/ directory, 
appropriately entitled the Prioritized Task List-the PTL is the very heart 
of the filesystem on a DCO-CS. At the beginning of the PTL all options and 
the format of entries are explained:


***************************************************************************
!***** RELEASE OCC150 DEVELOPMENT PRIORITIZED TASK LIST *******************
!**************************************************************************
!	
!
!
!
! The PRIORITIZED TASK LIST is free format ASCII text file. Any line that
! begins with an exclamation point(!) is assumed to be a comment, all other
! lines are assumed to be data lines. If a data line ends with a dash(-)the
! next line is used to continue the line. A data line may be no more than
! 1000 characters in length. Since this file is free format multiple blanks
! or tabs are treated as a single space. 
!
! The PTL defines the list of tasks contained in a given release and the
! desired order in which to place the tasks on the disk. The PTL also 
! defines the options, the processor type, and the values of the CP 
! switches, e.g.: file type, access rights.
!
! A data line consists of the DCO file specification followed by optional 
! switch modifiers.
!
!---------------------  BEGIN SWITCH DEFINITIONS  -------------------------
!
! -proc <type>        the processor type. This is used to determine the
!                     search rules for the file.
! 
! -input <file>       the input file name. If this switch is NOT given the
!                     input file name is derived from the output file
!                     specification. If the output file specification does
!                     NOT have an extension, an extension of .DTC is used.
!                     [EG: -INPUT STD.H]
!
! -for <option>       the file is required FOR this option(feature). If the
!                     site has this option, the file will be copied to the
!                     DCO disk. If this switch is NOT given, the file is 
!                     assumed to be part of the GENERIC and is always
!                     copied to the DCO disk. Options may be OR'ed together
!                     by separating the options by a vertical bar(|).
!                     [EG: -FOR LAB|ANI]
! 
! -disk <nbr>         forces the file to be copied to the given disk, if a
!                     a multi-disk set is required to hold all the files. 
!                     If this switch is NOT given and a multi-disk set is
!                     required, the file will be placed on the first disk
!                     with enough available free space.
!                     [EG: -DISK 0]
!
! -size <bytes>       make sure that at least X number of bytes are
!                     reserved. If this switch is NOT given the number of 
!                     bytes reserved is determined by the size of the file.
!                     [EG: -SIZE 1792]
!
! -access  <#,#,#>    give the access rights to a file. These are used to
!                     define the first three words of the rights section
!                     in the DCO file header. If this switch is NOT given
!                     a value of 177777 is used for the three values. The
!                     values must be in OCTAL representation.
!                     [EG:  -ACCESS 1000,1000,1000     -ACCESS ,100000,1]	
!                     The order is: READ,WRITE,EXECUTE
!
! -load               the file is to be used for the load/boot block
!                     on the DCO disk. Although the load block is NOT
!                     referenced by a DCO file specification, one is
!                     required in the PTL for completeness. The -INPUT
!                     switch is normally used in conjunction with this
!                     switch to specify the input file. Only one file may 
!                     be marked with the -LOAD switch. That file is treated
!                     as task created by TKB and is loaded from byte offset
!                     1024(02000).
!                     [EG: /boot_block -proc mp -load -input inildr.tsk]
!
! -offset             the offset into the input file at which to start
!                     reading the data.  Used only with the -LOAD switch
!                     [eg:  please see the Appendix PTL file.]
!
! -ama_store          designate as a special AMA storage file. This switch
!                     should be used with the -DISK switch to inform KUT
!                     on which disk the file should be placed.
!                     [EG: please see the Appendix PTL file.]
!
! -dir                the DCO file specification is a DIRECTORY, valid
!                     switch modifiers are -FOR -ENTRIES & -RIGHTS
!
! -entries <nbr>      reserve the given number of DIRECTORY entries
!
! -boot               the file is designated a BOOT file. If this switch is
!                     NOT given the file is designated a PROGRAM/DATA file.
!
! -data               the file is copied as a binary data file. A DCO
!                     file header is created.
! 
! -text               the file is copied as ASCII text file. A DCO file
!                     header is created.
!
!                     NOTE: if neither the -DATA or -TEXT switch is given
!                     the file is copied as an IMAGE file. In this
!                     case a DCO file header is NOT created, but
!                     assumed to exist in the input file.
!
! -name  <name>       used to specify the internal name of a file.
!                     [eg: -name RPLDAT]
!
!------------------------  END SWITCH DEFINITIONS  ------------------------
!
!
!-------------------------  BEGIN "FOR" OPTIONS  --------------------------
!                  
!    This section defines the valid options (features) that may be used
!    with this release's ptl files. These options are to be used in 
!    conjuction with the "-for" and "-ifnot" switches. Those ptl entries 
!    that do not have a "-for" switch are defined as generic tasks/files 
!    and will be put on all disks kut for this release.
!
!	alt		Automatic Line Insulation Test
!	ama		Automatic Message Accounting
!	big_ama		AMA 10mb Emergency Storage on 2d IOmega disk
!       codc		Remote Polled LAMA
!	dialup		Dial-up Terminal Secure Access
!	dli		Data Link Interface (OCC3)
!       dntrans         DN transperancey         
!       esp             Essential Service Protection Feature 
!	ess		Emergency Switching Service
!	fp		Feature Processor
!	gen	     	The Base Line Generic
!	hard_disk	MSS Winchester (not iomega)
!	lab		Switch to allow all options for lab systems
!	lab_test	Tasks for testing in S-C lab only - not for fld use
!	rcc		Radio Common Carrier
!      	res		Reseller (OCC4)
!	rls1000		Remote Line Switch 1000, 360
!	rls4000		Remote Line Switch 4000
!	rpl3 - rpl7	Protocol selection for RPL (rplc03,rphp03,dlip03)
!	simul		Simulator Options for specific Simulator Tasks
!	small_ama	AMA  3mb Emergency Storage on 1st IOmega disk
!       synopsis        site synopsis text file for dbgen databases
!	trafsep		Traffic Separation (Source Destination)
!       trktst          Trunk Testing
!	win	   	Winchester Hard Disk Drive
!	wkup		Wake-up Service
!
!  The following options were made generic per customer service on 9/19/91
!
!     * abn             Automatic Balance Network
!     *	aci		Alarm Control Interface
!     *	bbt		Board to Board Test
!     *	boc_tmrs	Traffic Measure't Reptg. Sys w/BOC Config (LSSGR)
!     * bx25            Bell x25 Interface - Operations Sys Netwrk Protocol
!     * cba             coin box accounting
!     *	dmp		Duplex Maintenance Processor
!     *	e2a		Switch Cntl Ctr Sys (SCCS) w/E2A Telemetry
!     *	eadas		Bell Eng. and Admin. Data Acquisition System
!     *	pora		Point of Origin Recorded Announcement
!     *	rlg		Remote Line Group
!     *	rmas		Bell Remote Memory Administration System
!     *	rns		Remote Network Switch
!     *	rotl		Remote Office Test Line
!     *	slc96		SLC-96 Interface
!     *	smp		Simplex Maintenance Processor
!     *	tsitpp		High-Density TSI/TPP Subsystem
!     * veac		Virtual Equal Access
!
!  The following options were made codc per customer service on 9/19/91
!
!     #	amatps		Protocol selection for AMATPS option
!     #	bisync		Protocol selection for IBM BISYNC application
!     #	hdlc		Protocol selection for pollstar application
!
!--------------------------  END "FOR" OPTIONS  ---------------------------
!
!---------------------  BEGIN PROCESSOR DEFINITIONS  ----------------------
!
!    The following is the list of valid processor ids for this release to 
!    be used with the -proc switch. Each processor id is usually associated
!    with an unique SCM software set.
!
!    ac             = aci
!    al             = alit
!    amp            = amp message database
!    bxc            = bx25
!    cbc            =
!    cp             = call processor
!    dct            = database software (dbver, dbview, dbchek, ...)
!    dli            =
!    fc             =
!    fp             = feature processor
!    inet           = To add intelligent network MP files to KUT medium.
!    lg             = lgc (line group controller)
!    lt             = ltc
!    ma             = mah/mar (rls1000)
!    mci            = 
!    md             = mdc
!    mp             = maint/admin processor
!    mp_text        = command files (com directory)
!    ptl            = to add ptl file to disk
!    rg             = rlg (remote line group controller)
!    rlr            =
!    rph            =
!    rls4           = rls4000 tasks
!    rls68          = 68000 processor tasks for RLS4000, created 9/30/90.
!    rt             = rtc (slc96)
!    ss7            =      
!    up             =
!    tmp            =
!
!----------------------  END PROCESSOR DEFINITIONS  -----------------------
!
!-------------------------  BEGIN PTL FILE LIST  --------------------------
!
/boot_block -proc mp -load -offset 01000 -input inildr.dtc
/smosld -proc mp -boot  -disk 0
!       
/com/a -proc mp_text -text -input a.txt -dynamic -
	-access ,100000,0
/a15shu -proc mp  -
       	-access 100000,100000,100000
/abnutl -proc mp -
        -access 100000,100000,100011
/abort -proc mp  -
	-access 100000,100000,
/segment/diag2/type5/abotcp -proc mp  -
	-access ,100000,0
/segment/diag2/type5/abotst -proc mp  -
	-access ,100000,0
/required/abrt -proc mp -disk 0 -
	-access 100000,100000,
/driver/acidrv -proc mp -
	-access 100000,100000,100000
/download/acipgm -proc ac -
	-access ,100000,0
/acisu -proc mp -
	-access 100000,100000,100010
/acitst -proc mp -
	-access 100000,100000,100010
-------List truncated for brevity-----------

!--------------------------  END PTL FILE LIST  ---------------------------


Access rights in the PTL are denoted with a "-access" switch under file 
options, in the following syntactical order: READ, WRITE, EXECUTE; in other
words, the octal values which represent account access permissions for a 
file denote consecutively, from left to right, which accounts are permitted
to read (or view) the file in question, write to it, or execute it if it is
executable. The following table of octal values may prove useful:

Octal Value     Group(s) with Permission
===========     ========================
0               NONE
1               ADMIN
2               TMRS
10              MAINT
100000          SCAT
100001          ADMIN, SCAT
100002          TMRS, SCAT         
100005          ADMIN, STATUS, SCAT
100010          MAINT, SCAT
100011          ADMIN, MAINT, SCAT
100012          TMRS, MAINT, SCAT
100013          ADMIN, TMRS, MAINT, SCAT
100014          STATUS, MAINT, SCAT
100020          SECURE, SCAT
100024          STATUS, SECURE, SCAT
100030          MAINT, SECURE, SCAT
100035          ADMIN, STATUS, MAINT, SECURE, SCAT
100036          TMRS, STATUS, MAINT, SECURE, SCAT
100037          ADMIN, TMRS, STATUS, MAINT, SECURE, SCAT
100042          TMRS, NAC, SCAT
100050          MAINT, NAC, SCAT
100071          ADMIN, MAINT, SECURE, NAC
100075          ADMIN, STATUS, MAINT, SECURE, NAC
100077          ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, SCAT
100140          NAC, ESPF, SCAT
100141          ADMIN, NAC, ESPF, SCAT
100150          MAINT, NAC, ESPF, SCAT
100154          STATUS, MAINT, NAC, ESPF, SCAT
100155          ADMIN, STATUS, MAINT, NAC, ESPF, SCAT
100160          SECURE, NAC, ESPF, SCAT
100164          STATUS, SECURE, ESPF, SCAT
100175          ADMIN, STATUS, MAINT, SECURE, NAC, ESPF, SCAT
100177          ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, ESPF, SCAT
177777          ALL DEFINED GROUPS

Any octal value in this table indicates the groups with the permission that
it occupies under "-access" in the PTL. For instance, if a file had -access
10, 100000, 100001, the MAINT group would have read permission, the SCAT 
group write permission, and the ADMIN and SCAT groups execute permission. 
Most accounts have read access to the PTL, but only SCAT has default write 
access to it. The PTL (and other files) may be modified in the $EDIT 
utility. Alternately the PTL.TXT file could be downloaded using $XFER (the 
file transfer command/program), modified, and re-uploaded.


Memory Reading-

An alternate way of reading/analyzing the information in various files such
as the PTL, though of slightly limited usefulness, lies in the use of 
utilities such as $DUMPER to dump the contents of the file in question in a
base of one's selection or ASCII. Note that, unfortunately, it is 
impossible to dump the contents of a file to which one does not already 
have access, for the file would have to be read by the utility in order for
its contents to be output. Still, the indirect access of files in this 
manner may prove useful in a few situations-for instance, if everything on 
a particular terminal was heavily monitored (echoed to the SCC, perhaps?) 
and the direct reading and/or editing of files an extremely revealing 
factor. Then again, if one follows the procedures described throughout 
these notes for concealing one's presence on the switch even rather heavy 
monitoring ought not to be a major obstruction.

$DUMPER /NODIAL

DUM> FILE NAME (FILE=HELP) > /ROOT/PTL.TXT

DUM> BASE (BASE=HELP) > 

   DECIMAL OR 10 - WILL OUTPUT THE DATA AND ADDRESSES IN DECIMAL
   OCTAL OR 8 - WILL OUTPUT THE DATA AND ADDRESSES IN OCTAL
   HEXIDECIMAL OR 16 - WILL OUTPUT THE DATA AND ADDRESSES IN HEXIDECIMAL
   IF YOU PRECEED THE RESPONSE WITH AN A, SUCH AS A10 OR AOCTAL,
   THEN THE DATA WILL BE OUTPUT IN ASCII AND THE ADDRESS IN THE BASE
   EXIT - WILL EXIT THIS TASK

DUM> BASE (BASE=HELP) > AHEX

DUM> TYPE (TYPE=HELP) > 

   HEADER - WILL OUTPUT THE FILE HEADER
   DATA - WILL OUTPUT THE ACTUAL CONTENTS OF THE FILE
   EXIT - WILL EXIT THIS TASK

DUM> TYPE (TYPE=HELP) > DATA

DUM> START ADDRESS (START=HELP) > 3000

DUM> STOP ADDRESS (STOP=HELP) > 9000
             00  01  02  03  04  05  06  07  08  09  0A  0B  0C  0D  0E  0F
   003000     -           B   E   G   I   N       P   R   O   C   E   S   S
   003010     O   R       D   E   F   I   N   I   T   I   O   N   S
   003020     -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
   003030     -   -   -   -   -   -   -   -  \n   !  \n   !
   003040     T   h   e       f   o   l   l   o   w   i   n   g       i   s
   003050         t   h   e       l   i   s   t       o   f       v   a   l
   003060     i   d       p   r   o   c   e   s   s   o   r       i   d   s
   003070         f   o   r       t   h   i   s       r   e   l   e   a   s
   003080     e       t   o       b   e  \n   !                   u   s   e
   003090     d       w   i   t   h       t   h   e       -   p   r   o   c
   0030a0         s   w   i   t   c   h   .           E   a   c   h       p
   0030b0     r   o   c   e   s   s   o   r       i   d       i   s       u
   0030c0     s   u   a   l   l   y       a   s   s   o   c   i   a   t   e
   0030d0     d       w   i   t   h  \n   !                   a   n       u
   0030e0     n   i   q   u   e       S   C   M       s   o   f   t   w   a
   0030f0     r   e       s   e   t   .  \n   !  \n   !                   a
   003100     c                                                       =
   003110     a   c   i  \n   !                   a   l
   003120                                     =       a   l   i   t  \n   !
   003130                     a   m   p
   003140                 =       a   m   p       m   e   s   s   a   g   e
   003150         d   a   t   a   b   a   s   e  \n   !                   b
   003160     x   c                                                   =
   003170     b   x   2   5  \n   !                   c   b   c
   003180                                         =  \n   !
   003190     c   p                                                       =
   0031a0         c   a   l   l       p   r   o   c   e   s   s   o   r  \n     


Additional Information/Conclusion
---------------------------------

Other/Miscellaneous/General-

The DCO family product line is currently owned/supported by Genband, an IP 
Multimedia System company based in Texas. Interestingly, the DCO-CS is also
the only major Class 5 switch on the PSTN for which VoIP conversion 
hardware to operate in conjunction with the switching hardware has not been
widely manufactured, with the exception of a few media gateways. Its use in
the future is likely to diminish due to its aging status, although DCO 
switches are to be found servicing many rural communities. Contrary to 
popular belief, all installed DCOs have not been replaced by the EWSD or 
other, newer switches. It was estimated as of 2006 that approximately 14 
million lines were installed on North American DCO and EWSD switches, and 
that over 2,500 host and remote switches comprise the DCO install base in 
North America.
 
An Additional Note: DCO-SE-

Another member of the DCO family worthy of mention is the DCO-SE, a line 
switch capable of servicing up to 10,000 lines, as opposed to the DCO-CS, 
which is capable of servicing only a very limited number of lines and is 
primarily concerned with long distance (inter-LATA) related service. The 
software of the DCO-SE is enhanced and although the MMI is extremely 
similar, several alterations of note exist, due to its main function. In 
fact, an entire albeit brief article could be devoted to the 
differentiations between these two switches in the DCO family, but here for
reasons of succinctity only the more "interesting" aspects of the DCO-SE 
will be mentioned, those most major alterations to the MMI and switch 
utilities. First, the $ADMIN utility contains many different options, such 
as the following:

DCO>
$ADMIN

ADM>HELP

ENTER THE GROUP TYPE TO BE ADMINISTERED.
   SOME OF THESE GROUPS ARE ACCESS RESTRICTED
   ERR          - DISPLAY ERROR CODES FROM DBMS
   ACCESS       - ISDN BRI ACCESS
   BG           - BUSINESS GROUPS (CENTREX,MVP1,MVP2)
   CARRIER      - EQUAL ACCESS CARRIER CODE
   CC           - CUSTOM CALLING QUERIES
   CEI          - CUSTOMER EQUIPMENT INTERFACE
   COMM         - DATA COMMUNICATIONS
   COS          - CLASS OF SERVICE
   CODRES       - CODE RESTRICTION LIST
   CV           - CLASS VALUES (VOICE DATA PROTECTION)
   DOP          - DIAL OUT PLAN
   E911T        - EMERGENCY 911 TANDEM
   ESS          - EMERGENCY SWITCHING SERVICE, RLS-4000
   FKMP         - FEATURE KEY MANAGEMENT PROFILE
   FN           - FEATURE NAME
   HG           - HUNT GROUPS
   IG303        - INTERFACE GROUPS 303
   LAW          - LAWFUL ACCESS
   LCC          - LINE CLASS CODES  

Contrasted with a DCO-CS $ADMIN menu:


   ERR          - DISPLAY ERROR CODES FROM DBMS
   AIN          - ADVANCED INTELLIGENCE NETWORK
   CEI          - CUSTOMER EQUIPMENT INTERFACE
   COS          - CLASS OF SERVICE
   CODRES       - CODE RESTRICTION LIST
   CV           - CLASS VALUES (VOICE DATA PROTECTION)
   FN           - FEATURE NAME
   HG           - HUNT GROUPS
   LCC          - LINE CLASS CODES
   LCN          - LINE CLASS NAMES
   LINE         - EN/DN LINES
   MACRO        - MACRO DEFINITIONS
   MBG          - MAKE BUSY GROUPS
   NRT          - NETWORK DN TRANSPARENCY ROUTE TREATMENTS
   OPTIONS      - FEATURE OPTIONS
   RING         - DEFAULT RING CODES
   SITE         - SITE NAME
   SS7          - SIGNALING SYSTEM NUMBER 7

$ADMIN, as one may recall from the HELP text, is described as the utility 
used for "RECENT CHANGE/DATABASE ADMINISTRATION". Since the DCO-SE has 
support for Centrex and may service up to 10,000 lines, administration 
groups such as BG, CC, ESS, etc. have been added, and groups such as SS7, 
AIN, MACRO, MBG, etc. do not exist as they do on the DCO-CS. Second, two 
additional default account groups exist on the DCO-SE-LAW and NOVICE:

LAW-LAW is used for the lawful survellience/monitoring of lines authorized 
under legislation such as CALEA. Within the $ADMIN utility, an option "LAW"
exists to this end as seen above:

ADM> GROUP (GROUP=HG) > LAW
  It is illegal to access Lawful Access surveillance information
  without the knowledge and expressed permission of the telephone
  operating company controlling this telecommunications facility.
  Further, it is illegal to establish any surveillance activity
  without receipt of a court order issued by a federal, state or
  local court having jurisdiction to permit telecommunications
  surveillance activity. Violation of these warnings will subject
  the perpetrator to all of the penalties and consequences
  allowable under such controlling laws.

ADM> LATYPE (LATYPE=HELP) > 

   CDC           - CDC
   FSK           - FSK MODEM       
   OPTIONS       - OPTIONS
   RECEIVER      - RECEIVER
   SURVEILLANCE  - SURVEILLANCE

Invoking LAW will display a banner as seen above with the necessary legal 
warnings of accessing surveillance information. This banner is seemingly 
intended for observation by law enforcement, rather than other potential 
unauthorized users of the switch. LAW has access rights to files/utilities 
over which all groups have some degree of access.

NOVICE-Perhaps intended for use by technicians in training or employees 
untrained in DCO operation as the name suggests, NOVICE only has access to 
utilities and files to which all account groups have access, and its access
rights are always the lowest for a particular file or utility. For example,
on files such as EA24HD, EA30MD, and EA60MD to which all other account 
groups have at least read and execute permissions, both NOVICE and LAW have
only execute permission.

One gaping vulnerability present in the DCO-SE (equipped with the most 
recent software version, released in 2003) is that, unlike on the DCO-CS, 
all account groups have read AND write permissions on the PTL! Any account 
may thus directly write to the PTL, redefining access rights for files, 
etc. On the DCO-CS, release OCC150, as stated previously, only SCAT has 
write permission/access.


Utilities Diagram


Notes: Although every utility technically has some degree of influence on 
the network, certain utilities serve strictly on-switch functions (and thus
exert an indirect influence over the PSTN) and others network functions 
(and thus exert a more direct influence over the PSTN). There exists, of 
course, no such utility as a "strictly off-switch program", but, as said, 
there are varying degrees of network vs. switch influence. Naturally 
utilities concerned with the operation of switch hardware (such as the 
disk, processors, etc.) are classified as "intra-switch", whereas 
SS7-related programs, line and trunk utilities, etc. are classified as 
"extra-switch". This three-layered conception of DCO utilities is rather 
useful in determining the nature of account groups and purposes. This 
diagram is by no means intended to be inclusive of all or even most 
utilities-rather, it encompasses a small sampling of the utilities that 
best epitomize the three categories. Described differently, extra-switch 
utilities are closest to the network and intra-switch utilities are 
furthest from it.


+------------------------------------------+
Extra-Switch Utilities

$ABNUTL, $CODE, $HOTLIN,$INWANI, $INWATS, 
$NITSWC, $RGU,  $ROTL,  $ROUTE,  $RTOPT,  
$RTR,    $SCTST,$TRACE, $TSEP,  etc.



+------------------------------------------+
Intra/Extra-Switch Utilities "Bridge"

$CONUTL, $CSADM, $EQCHEK, $FLXANI, $MANUAL,
$PABX,   $PCOS,  $RNSAMA, $RTEST,  $SELNUM
$SERV,   $SPCALL,$TFM,    $TKTHRS, $TMAD,
$TTU, etc.



+------------------------------------------+
Intra-Switch Utilities

$ACTUTL, $AMOPT, $AMPUTL, $BUFDMP, $CBUG, 
$CHKUTL, $DEBUG, $DMPUTL, $DUMPER, $EDIT, 
$FILSYS, $FPBUG, $GBUG,   $HSTUTL, $INSTAL,
$ISUUTL, $MEMCHK,$PASSWM, $PATCH,  $REMOVE,
$SECTTY  $STATE, $STATUS, $TIME,   $UPACK,  
$UPDATE, $VCHECK,$XFER, etc.

+------------------------------------------+


Recommendations for Security-

In light of the above information regarding the near-absolute absence of 
preventative security measures inherent in the design of the DCO, it may 
seem a comically futile undertaking to recommend measures to the end of 
effective DCO-CS securement. Let it not be forgotten, though, that 
throughout the spirited and relished elucidation of the flaws in access 
security, a number of metaphorical "hurdles" or configurations proving 
through some often diminutive manner slightly problematic for those whose 
objective it is to access the switch are discussed. It follows logically, 
then, that the exaggeration of those in discretional configuration to as 
great a degree as is practically possible is desirable for the maximum 
security that one may extract/derive from the limited faculties of the DCO 
dedicated thereto. When discussing dialup security, alas, it seems best to 
simply disallow dialup access to the switch in order to prevent any form of
remote unauthorized intrusion. Yet, as the author is keenly aware, this 
effective albeit extreme configuration/measure is not always practical and 
efficient to implement, in which case, one is advised to affix to the 
dial-in line(s) dedicated to the purpose a callback security device, add an
additional layer of password security, etc.; while exploitable flaws 
certainly exist in these shields, they at least may provide a sufficiently 
strong barrier as to discourage all but the most determined of unauthorized
users. In all instances, regardless of the configuration of the dial-in 
port/lines, one is obviously and finally advised to mandate the use of the 
strongest passwords possible, and to review and monitor diligently the 
logs, the trails generated by the actions of users. It is simply laughable 
that systems exist, on the PSTN and elsewhere, which exhibit a tremendous 
amount of security and yet so little significance in comparison to the 
switches, the machines analogous in magnitude of purpose and nature to the 
vertebrae of the giant network that, despite recent efforts to migrate 
rapidly from it, continues to connect and maintain a continuous stream of 
interconnected communications that links the U.S. and the greater segment 
of the globe to this day. 


Acronym Glossary-

DCO-CS-Digital Central Office Carrier Switch
PSTN-Public Switched Telephone Network
LEC-Local Exchange Carrier
EWSD-Elektronisches Wahlsystem Digital/Electronic World Switch Digital
CLEC-Competitive Local Exchange Carrier
MMI-Man-Machine Interface
DCO-SE-Digital Central Office Small Exchange
RLS-Remote Line Switch
5ESS-#5 Electronic Switching System
TMRS-Traffic Measurement and Recording System
SCAT-Stromberg-Carlson Assistance Team
(IN)WATS-(Inward) Wide Area Telephone Service
ETAS-Emergency Technical Assistance
NAC-Network Access Control
ESP(F)-Essential Services Protection (Feature?)
MP-Maintenance Processor
SCC-Switching Control Center
PTL-Prioritized Task List
VoIP-Voice over Internet Protocol
LATA-Local Access and Transport Area
CALEA-Communications Assistance for Law Enforcement Act
SS7-Signalling System #7

Acknowledgements/Shoutouts-

To ThoughtPhreaker, for his patient assistance in verifying the validity of
many of the general observations within these notes and his vulnerability 
contributions, in addition to his extensive contributions to the DCO-SE 
section, rev, Andrew, whitehorse, radio_phreak, bomberman2525 (if he still 
wishes to be known by that handle), and the authors of the original DCO 
articles, for their giddy, minimal diatribes did provide a foundation, 
however full of gaps, for me to expound upon. As usual, acknowledgements 
are given to anyone not explicitly mentioned who has assisted me in my 
quest for H/P knowledge and to anyone who agrees with my concept of the 
H/P subculture and sympathizes with my efforts to improve it. Feel free to 
contact me at my email address: philosopher2600@gmail.com with any 
inquiries or comments (factual corrections welcome) regarding this article.

NYC_NY_2600_DCO 09-06-16 00:26:00 LOGOFF  TT01 
   MP .0354:TTY=TT1,USERNAME=THE_PHILOSOPHER LOGGED OFF