The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack2 / phrack39.006 < prev next >

Wrap

Text File | 2003-06-11 | 36.5 KB | 856 lines

==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 .....D..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 . ___ . . / X . . | o o | . . | Y | . U===== | . X___/ . 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 XCEXFFCDCDX0AX00X00X00X00X00X0AX00X00X00X00X00X0AX00X00X00X00X00X0AX00X00X00X00 X00X0AX00X00X00X00X00X0AX00X00X00X00X00X0AX00X00X00X00X00X00X00X00X00X00X00X00 X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00X00 Accepting the XCE 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 X00s. 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. _______________________________________________________________________________