Hardware Firewall

Hardware Firewall

The best firewall is a hardware firewall that is completely separate from your operating system. It need not be a dedicated router, could be an old pentium box running Linux. Below I have found some sites that have How To's on setting up an outside hardware router using an old computer and using a little linux program that fits on a single floppy disk.

Brief Description:
floppyfw is a router with the advanced firewall-capabilities in Linux that fits on one single floppy disc.

Features:
Access lists, IP-masquerading (Network Address Translation), connection tracked packet filtering and (quite) advanced routing. Package for traffic shaping is also available.
Requires only a 386sx or better with two network interface cards, a 1.44MB floppy drive and 12MByte of RAM ( for less than 12M and no FPU, use the 1.0 series, which will stay maintained. )
Very simple packaging system. Is used for editors, PPP, VPN, traffic shaping and whatever comes up. (now this is looking even more like LRP (may it rest in peace) but floppyfw is not a fork.)
Logging through klogd/syslogd, both local and remote.
Serial support for console over serial port.
DHCP server and DNS cache for internal networks.

floppyfw
http://www.zelow.no/floppyfw/
Sentry Firewall CD-ROM is a Linux-based bootable CDROM suitable for use as an inexpensive and easy to maintain firewall, server, or IDS(Intrusion Detection System) Node. The system is designed to be immediately configurable for a variety of different operating environments via a configuration file located on a floppy disk, a local hard drive, and/or a network via HTTP(S), FTP, SFTP, or SCP.

The Sentry Firewall CD is a complete Linux system that runs off of an initial ramdisk, much like a floppy-based system, and a CD. The default kernel is a current 2.4.x series kernel with various Netfilter patches applied. An OpenWall-patched current 2.2.x kernel is also available on the CD.

Booting from the CDROM is a fairly familiar process. The BIOS execs the bootloader(Syslinux) - which then displays a bootprompt and loads the kernel and ramdisk into memory. Once the kernel is running, the ramdisk is then mounted as root(/). At this point our configuration scripts are run(written in perl) that configure the rest of the system. It is the job of these configure scripts to put the various startup and system files into the proper location using either what is declared in the configuration file(sentry.conf) or the system defaults located in the /etc/default directory.

Most of the critical files used at boot time can be replaced with your own copy when declared in the configuration file. This is essentially how we allow the user to configure the system using his/her own configuration and init files.

All of the binaries, files, scripts, etc, used to create the CD-ROM are also available on the CD-ROM. So, with a little practice, you can easily build and customize your own bootable Sentry Firewall CD. Please see the HOWTO for more details.
Sentry Firewall

CONTACT FOR ADVERTISEMENT
+919608090390

How to find Security Holes

How to find Security Holes

[quoting from the comp.security.unix FAQ]
Security holes manifest themselves in (broadly) four ways:

1) Physical Security Holes.

- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.

A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.

Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.

2) Software Security Holes

- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.

The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.

(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine.  The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)

New holes like this appear all the time, and your best hopes are to:

  a: try to structure your system so that as little software as possible
  runs with root/daemon/bin privileges, and that which does is known to
  be robust.

  b: subscribe to a mailing list which can get details of problems
  and/or fixes out to you as quickly as possible, and then ACT when you
  receive information.

>From: Wes Morgan <morgan@edu.uky.ms>
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need.  Many packages include daemons or utilities which can reveal
> information to outsiders.  For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user.  Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
> <occasionally> tftpd, all of which can present security problems.
>
> Careful system administration is the solution.  Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution.  You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS!  Such facilities
> tend to install/run everything in the package without asking you.  Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.

3) Incompatible Usage Security Holes

- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.

Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind.  It's
never too late to have a rethink, though.

Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.

4) Choosing a suitable security philosophy and maintaining it.

>From: Gene Spafford <spaf@cs.purdue.edu>
>The fourth kind of security problem is one of perception and
>understanding.  Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it.  Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.

---

From: Hacking
Subject: Hacking Ideas
Date: 11/10/93

( Please contribute by sending E-Mail to <scott@santafe.edu> ... )

[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]

NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations

  The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories

(Suggested splitting of above into main and sub-catagories)
I:   Suid binaries and scripts
     unexpected user interactions
     flawed liberary calls
     implicit assumptions of external conditions (sym links, loc. paths)
     race conditions
II:  daemons running with priviliged uid's
     race conditions
     poor file protectons
     implicit file protections
     trust
     authentication
III: Kernel problems
     Kernel race conditions
     device driver code

The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated.  Doing a comprehensive search for operating system flaws
requires four steps:

Step 1) Knowledge of system control structure.
===============================================
  To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
  One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects  : objects in both classes. ie: the password file
  With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
  Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
  Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
  It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.

Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
  Code history:
    What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
  A solid cross reference:
    Who checked which bug in what OS and what version prevents us from
duplicating work.

  A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
    rcp is suid root because it must use a privilaged port to do user
    name authentication.
  Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
  We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
  Any sugestions on how to implement such a DB?

Step 3) Confirm hypotheses. (test and exploit flaws)
====================================================

Step 4) Make generalizations of the underlying system weaknesses, for
        which the flaw represents a specific instance.
=====================================================================

Tool Box:
=========
AGREP: I suggest everyone obtain, and install agrep from:
    ftp cs.arizona.edu /agrep/agrep.tar.Z
  Agrep supports "windowing" so it can look for routines, and subroutines.
It also supports logical operators and is thus ideally suited to automating
the search for many of the following flaws. i.e. <psudocode>
      agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or    agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
            OR execvp()]} /usr/local/src/*.c

PERMUTATION PROGRAM: Another tool worth producing is a program to generate
all possible permutations of command line flags/arguments in order to uncover
undocumented features, and try to produce errors.

TCOV:

CRASH: Posted to USENET (what FTP archive?) (descrip?)

PAPERS: There are several papers that discuss methods of finding flaws, and
  present test suites.
  1) An Emphirical Study of the reliability of UNIX Utilities, by Barton P.
    Miller, Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,
    Dec '90. Describes a test suite for testing random input strings.
    Results indicated that 25% of the programs hung, crashed, or misbehaved.
    In one case the OS crashed. An understanding of buffer and register
    layout on the environment in question, and the expected input is likely
    to produce the desired results.
  2) The Mothra tools set, in Proceedings of the 22nd Hawaii International
    Conference on Systems and Software, pages 275-284, Kona, HI, January '89
  3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.
    Spafford, Software Practice and Experience, 20(2):181-189, Feb '90
  4) A paper by IBM was mentioned that was submitted to USENIX a few years
    ago. (Anyone have a citation?).

Specific Flaws to Check For:
============================
1) Look for routines that don't do boundary checking, or verify input.
   ie: the gets() family of routines, where it is possible to overwrite
   buffer boundaries. ( sprintf()?, gets(), etc. )
   also: strcpy() which is why most src has:
     #define SCYPYN((a)(b)) strcpy(a, b, sizeof(a))

2) SUID/SGID routines written in one of the shells, instead of C or
   PERL.

3) SUID/SGID routines written in PERL that don't use the "taintperl"
   program.)

4) SUID/SGID routines that use the system(), popen(), execlp(), or
   execvp() calls to run something else.

5) Any program that uses relative path names inside the program.

6) The use of relative path names to specify dynamically linked libraries.
   (look in Makefile).

7) Routines that don't check error return codes from system calls. (ie:
   fork(2), suid(2), etc), setuid() rather, as in the famous rcp bug

8) Holes can often be found in code that:
  A) is ported to a new environment.
  B) receives unexpected input.
  C) interacts with other local software.
  D) accesses system files like passwd, L.sys, etc.
  E) reads input from a publicly writable file/directory.
  F) diagnostic programs which are typically not user-proofed.

9) Test code for unexpected input. Coverage, data flow, and mutation
   testing tools are available.

10) Look in man pages, and users guides for warnings against doing X, and
   try variations of X. Ditto for "bugs" section.

11) Look for seldom used, or unusual functions or commands - read backwards.
   In particular looking for undocumented flags/arguments may prove useful.
   Check flags that were in prior releases, or in other OS versions. Check
   for options that other programs might use. For instance telnet uses -h
   option to login ...
     right, as most login.c's I've seen have:
          if((getuid()) && hflag){
                 syslog()
                 exit()
                 }

12) Look for race conditions.

13) Failure of software to authenticate that it is really communicating
   with the desired software or hardware module it wants to be accessing.

14) Lack or error detection to reset protection mechanisms following an
   error.

15) Poor implementation resulting in, for example, condition codes being
   improperly tested.

16) Implicit trust: Routine B assumes routine A's parameters are correct
   because routine A is a system process.

17) System stores it's data or references user parameters in the users
   address space.

18) Inter process communication: return conditions (passwd OK, illegal
   parameter, segment error, etc) can provide a significant wedge, esp.
   when combined with (17).

19) User parameters may not be adequately checked.

20) Addresses that overlap or refer to system areas.

21) Condition code checks may be omitted.

22) Failure to anticipate unusual or extraordinary parameters.

23) Look for system levels where the modules involved were written by
   different programmers, or groups of programmers - holes are likely
   to be found.

24) Registers that point to the location of a parameters value instead
   of passing the value itself.

25) Any program running with system privileges. (too many progs are given
   uid 0, to facilitate access to certain tables, etc.)

26) Group or world readable temporary files, buffers, etc.

27) Lack of threshold values, and lack of logging/notification once these
   have been triggered.

28) Changing parameters of critical system areas prior to their execution
   by a concurrent process. (race conditions)

29) Inadequate boundary checking at compile time, for example, a user
   may be able to execute machine code disguised as data in a data area.
   (if text and data areas are shared)

30) Improperly handling user generated asynchronous interrupts. Users
   interrupting a process, performing an operation, and either returning
   to continue the process or begin another will frequently leave the
   system in an unprotected state. Partially written files are left open,
   improper writing of protection infraction messages, improper setting
   of protection bits, etc often occur.

31) Code that uses fopen(3) without setting the umask. ( eg: at(1), etc. )
  In general, code that does not reset the real and effective uid before
  forking.

32) Trace is your friend (or truss in SVR4) for helping figure out what
  system calls a program is using.

33) Scan /usr/local fs's closely. Many admins will install software from
  the net. Often you'll find tcpdump, top, nfswatch, ... suid'd root for
  their ease of use.

34) Check suid programs to see if they are the ones originally put on the
  system. Admins will sometimes put in a passwd replacement which is less
  secure than the distributed version.

35) Look for programs that were there to install software or loadable
  kernel modules.

36) Dynamically linked programs in general. Remember LD_PRELOAD, I think
  that was the variable.

37) I/O channel programming is a prime target. Look for logical errors,
  inconsistencies, and omissions.

38) See if it's possible for a I/O channel program to modify itself, loop
  back, and then execute the newly modified code. (instruction pre-load
  may screw this up)

39) If I/O channels act as independent processors they may have unlimited
  access to memory, thus system code may be modified in memory prior to
  execution.

40) Look for bugs requiring flaws in multiple pieces of software, i.e. say
  program a can be used to change config file /etc/a now program b assumes
  the information in a to be correct and this leads to unexpected results
  (just look at how many programs trust /etc/utmp)

41) Any program, especially those suid/sgid, that allow shell escapes.

Hacking Voice Mail Systems

Hacking Voice Mail System       

                

               by:-> RB         
Voice Mail is a relatively new concept and not much has been said about it.
It is a very useful tool for the business person and the phreak.  The way it
works is that somebody wishing to get in touch with you calls a number,
usually a 1-800, and punches in on his touch-pad your mailbox number and then
he is able to leave a message for you.  Business experts report that this
almost totally eliminates telephone tag.  When a person wishes to pick up his
message all he needs to do is call the number enter a certain code and he can
hear his messages, transfer them, and do other misc. mailbox utilities.

Most VMSs are similar in the way they work.  There are a few different ways
the VMSs store the voice.  One way is that the voice is recorded digitally and
compressed and when heard it is reproduced back into the voice that recorded
it. Another method that is slower and uses more space, but costs less, stores
the voice on magnetic tape, the same type that is used to store data on a
computer, and then runs the tape at a slow speed.  Using this method the voice
does not need to be reproduced in any way and will sound normal as long as the
tape is running at a constant speed.  On some of the newer VMSs the voice is
digitally recorded and is transformed from the magnetic tape at about 2400
bits per second.

There are many different types and versions of voice mail systems.  Some of
the best and easiest to get on will be discussed.

Centagram
---------
These are direct dial (you don't have to enter a box number).  To get on one
of these, first have a number to any box on the system.  All of the other
boxes will be on the same prefix; just start scanning them until you find one
that has a message saying that person you are calling is not available.  This
usually means that the box has not been assigned to anybody yet.  Before the
nice lady's voice tells you to leave the message, hit #.  You will then be
prompted for your password.  The password will usually be the same as the last
four digits of the box's number or a simple number like 1000, 2000, etc.  Once
you get on, they are very user friendly and will prompt you with a menu of
options.  If you can't find any empty boxes or want to do more, you can hack
but the system administrators box, which will usually be 9999 on the same
prefix as the other boxes, will allow you to hear anybody's messages and
create and delete boxes.

Sperry Link
-----------
These systems are very nice.  They will usually be found on an 800 number.
These are one of the hardest to get a box on because you must hack out a user
ID (different from the person's box number) and a password.  When it answers,
if it says, "This is a Sperry Link voice station.  Please enter your user ID,"
you will have to start trying to find a valid user ID.  On most Sperrys it
will be a five digit number.  If it answers and says, "This is an X answering
service," you first have to hit *# to get the user number prompt.  Once you
get a valid user number will have oKVWV.."! password on most systems, it
will be 4 digits.  Once you get in, these are also very user friendly and have
many different options available.

RSVP
----
This is probably one of the worst VMSs but it is by far the easiest to get
yourself a box.  When it answers you can hit * for a directory of the boxes on
it (it will only hold 23).  If you hit # you will be given a menu of options
and when you choose an option you will then be prompted for your ID number.
The ID number on an RSVP system will just about always be the same as the
mailbox number, which are always only 2 digits.

A.S.P.E.N.
----------
The Aspen voice message systems made by Octel Telecommunications is in my
opinion the BEST VMS made.  To get a box on an Aspen, you need to find an
empty box.  To find an empty box, scan the box numbers and if one says, "You
entered XXXX.  Please leave a message at the tone," then this is an empty box.
You next just press # and when prompted for your box number enter the number
of the empty box and friendly voice of the nice lady will guide you through
all of the steps of setting up your box.  She first tells you what you can do
with the box and then will prompt you with, "Please enter the temporary
password assigned to you by your system manager."  This password will usually
be 4 digits long and the same as the box number like 1000, etc.  Once you get
on their are many things you can do.  You can make a distribution list where
if you want to leave a certain message to more than one person, you can enter
the list number and all of the boxes on the list will get the message. You can
also have the system call you and notify you that you have new messages. These
systems also have what they call "Information center mailboxes" that are
listen only and can also have a password on them so the person calling has to
enter the password before he hears the greeting message.  Aspen VMSs have a
system managers mailbox that will just about give you total control of the
whole system and let you listen to people's mail, create and delete boxes, and
many other things.

Thank you for reading this file and if you would like to get in touch with me
VIA VOICE MAIL call 1-800-222-0311 and hit *2155.

==========================================================================
                             Mailbox Systems
==========================================================================
   Mailbox systems are the link between information and the underworld. If
you have ever called one, then you will know the advantages of having one,
especially the ones that are  open to whole underworld, rather than just a
select few.  There are two types  of mailbox systems that are widely used.
   The first  type we will  talk about is the multiple mailbox systems, or
commonly referred to  as  message  systems.  These  systems  have  several
mailboxes set up on one number.  Usually, you  can access other  mailboxes
from that  number  by  pressing '*' or '#'.  Sometimes you  just enter the
mailbox number and you are connected.  These are the safest systems to use
to protect information from US Sprint and other  long distance  companies.
Since US Sprint and other companies  call  the destination  numbers, it is
safer to  have 800 mailbox systems, and  most  of  the time, the  multiple
mailbox systems  are on 800 numbers.  The  passcode on  these  systems can
vary in length and can be accessed by several  different methods, so it is
impossible to explain exactly how to hack these systems.
   The other type is the single mailbox system.  These  are usually set up
in a reserved  prefix in an area  code.  (Ex: 713-684-6xxx)  These systems
are usually  controlled by the  same type of hardware/software.  To access
the area  where you  enter the  passcode, just hit '0' for a second or so.
The passcodes are  four (4)  digits  long.  The only way to hack  these is
manually.  The best thing you could do is to  find one that does not  have
a recording from a person, but just the  digitized voice.  If you hack one
that  someone already  owns, they will  report it and  it will not last as
long.

       Here is a list mailboxes or prefixes to help you get started
--------------------------------------------------------------------------
   Single                          Multiple                        Digits
------------                     ------------                     --------
213-281-8xxx                     212-714-2770                         3
213-285-8xxx                     216-586-5000                         4
213-515-2xxx                     415-338-7000 Aspen Message System    3
214-733-5xxx                     714-474-2033 Western Digital
214-855-6xxx                     800-222-0651 Vincent and Elkins      4
214-978-2xxx                     800-233-8488                         3
215-949-2xxx                     800-447-8477 Fairylink               7
312-450-8xxx                     800-521-5344                         3
313-768-1xxx                     800-524-2133 RCA                     4
405-557-8xxx                     800-527-0027 TTE TeleMessager        6
602-230-4xxx                     800-632-7777 Asynk                   6
619-492-8xxx                     800-645-7778 SoftCell Computers      4
713-684-6xxx                     800-648-9675 Zoykon                  4
                                 800-847-0003 Communications World    3
=================================================
                           HACKING VOICE MAIL SYSTEMS
               
DISCLAIMER

I, Night Ranger, or anyone else associated with Phrack, am not responsible
for anything the readers of this text may do.  This file is for informational
and educational purposes only and should not be used on any system or network
without written permission of the authorized persons in charge.


INTRODUCTION

I decided to write this text file because I received numerous requests for
vmbs from people.  Vmbs are quite easy to hack, but if one doesn't know where
to start it can be hard.  Since there aren't any decent text files on this
subject, I couldn't refer them to read anything, and decided to write one
myself.  To the best of my knowledge, this is the most complete text on
hacking vmb systems.  If you have any comments or suggestions, please let me
know.

Voice Mail Boxes (vmbs) have become a very popular way for hackers to get in
touch with each other and share information.  Probably the main reason for
this is their simplicity and availability.  Anyone can call a vmb regardless
of their location or computer type.  Vmbs are easily accessible because most
are toll free numbers, unlike bulletin boards.  Along with their advantages,
they do have their disadvantages.  Since they are easily accessible this
means not only hackers and phreaks can get information from them, but feds
and narcs as well.  Often they do not last longer than a week when taken
improperly.  After reading this file and practicing the methods described,
you should be able to hack voice mail systems with ease.  With these thoughts
in mind, let's get started.


FINDING A VMB SYSTEM

The first thing you need to do is find a VIRGIN (unhacked) vmb system.  If
you hack on a system that already has hackers on it, your chance of finding
a box is considerably less and it increases the chance that the system
administrator will find the hacked boxes.  To find a virgin system, you need
to SCAN some 800 numbers until you find a vmb.  A good idea is to take the
number of a voice mail system you know, and scan the same exchange but not
close to the number you have.  


FINDING VALID BOXES ON THE SYSTEM

If you get a high quality recording (not an answering machine) then it is
probably a vmb system.  Try entering the number 100, the recording should
stop.  If it does not, you may have to enter a special key (such as '*' '#'
'8' or '9') to enter the voice mail system.  After entering 100 it should
either connect you to something or do nothing.  If it does nothing, keep
entering (0)'s until it does something.  Count the number of digits you
entered and this will tell you how many digits the boxes on the system are. 
You should note that many systems can have more than one box length depending
on the first number you enter, Eg. Boxes starting with a six can be five
digits while boxes starting with a seven can only be four.  For this file we
will assume you have found a four digit system, which is pretty common.  It
should do one of the following things...

1)  Give you an error message, Eg. 'Mailbox xxxx is invalid.'
2)  Ring the extension and then one of the following..
    1)  Someone or no one answers.
    2)  Connects you to a box.
3)  Connect you to mailbox xxxx.

If you get #1 then try some more numbers.  If you get #2 or #3 then you have
found a valid vmb (or extension in the case of 2-1).  Extensions usually have
a vmb for when they are not at their extension.  If you get an extension,
move on.  Where you find one box you will probably find more surrounding it. 
Sometimes a system will try to be sneaky and put one valid vmb per 10 numbers.
Eg. Boxes would be at 105, 116, 121, ... with none in between.  Some systems 
start boxes at either 10 after a round number or 100 after, depending on 
whether it is a three or four box system.  For example, if you do not find
any around 100, try 110 and if you do not find any around 1000 try 1100.  The
only way to be sure is to try EVERY possible box number.  This takes time but
can be worth it.

Once you find a valid box (even if you do not know the passcode) there is a
simple trick to use when scanning for boxes outside of a vmb so that it does
not disconnect you after three invalid attempts.  What you do is try two box
numbers and then the third time enter a box number you know is valid.  Then
abort ( usually by pressing (*) or (#) ) and it will start over again.  From
there you can keep repeating this until you find a box you can hack on.  


FINDING THE LOGIN SEQUENCE

Different vmb systems have different login sequences (the way the vmb owner
gets into his box).  The most common way is to hit the pound (#) key from the
main menu.  This pound method works on most systems, including Aspens (more
on specific systems later).  It should respond with something like 'Enter
your mailbox.' and then 'Enter your passcode.'  Some systems have the
asterisk (*) key perform this function.  Another login method is hitting a
special key during the greeting (opening message) of the vmb.  On a Cindy or
Q Voice Mail system you hit the zero (0) key during the greet and since
you've already entered your mailbox number it will respond with 'Enter your
passcode.'  If (0) doesn't do anything try (#) or (*).  These previous two
methods of login are the most common, but it is possible some systems will
not respond to these commands.  If this should happen, keep playing around
with it and trying different keys.   If for some reason you cannot find the
login sequence, then save this system for later and move on.


GETTING IN

This is where the basic hacking skills come to use.  When a system
administrator creates a box for someone, they use what's called a default
passcode.  This same code is used for all the new boxes on the system, and
often on other systems too.  Once the legitimate owner logs into his new vmb,
they are usually prompted to change the passcode, but not everyone realizes
that someone will be trying to get into their mailbox and quite a few people
leave their box with the default passcode or no passcode at all.  You should
try ALL the defaults I have listed first.  


DEFAULTS           BOX NUMBER      TRY         

box number (bn)    3234            3234        Most Popular
bn backwards       2351            1532        Popular
bn+'0'             323             3230        Popular With Aspens 

Some additional defaults in order of most to least common are:  

4d        5d        6d 
0000      00000     000000    *MOST POPULAR*
9999      99999     999999    *POPULAR*
1111      11111     111111    *POPULAR*
1234      12345     123456    *VERY POPULAR WITH OWNERS*
4321      54321     654321
6789      56789     456789
9876      98765     987654
2222      22222     222222         
3333      33333     333333
4444      44444     444444
5555      55555     555555
6666      66666     666666
7777      77777     777777         
8888      88888     888888
1991


It is important to try ALL of these before giving up on a system.  If none of
these defaults work, try anything you think may be their passcode.  Also
remember that just because the system can have a four digit passcode the vmb
owner does not have to have use all four digits.  If you still cannot get
into the box, either the box owner has a good passcode or the system uses a
different default.  In either case, move on to another box.  If you seem to
be having no luck, then come back to this system later.  There are so many
vmb systems you should not spend too much time on one hard system.

If there's one thing I hate, it's a text file that says 'Hack into the
system.  Once you get in...' but unlike computer systems, vmb systems really
are easy to get into.  If you didn't get in, don't give up!  Try another
system and soon you will be in.  I would say that 90% of all voice mail
systems have a default listed above.  All you have to do is find a box with
one of the defaults.


ONCE YOU'RE IN

The first thing you should do is listen to the messages in the box, if there
are any.  Take note of the dates the messages were left.  If they are more
than four weeks old, then it is pretty safe to assume the owner is not using
his box.  If there are any recent messages on it, you can assume he is
currently using his box.  NEVER take a box in use.  It will be deleted soon,
and will alert the system administrator that people are hacking the system. 
This is the main reason vmb systems either go down, or tighten security.  If
you take a box that is not being used, it's probable no one will notice for
quite a while.


SCANNING BOXES FROM THE INSIDE

>From the main menu, see if there is an option to either send a message to
another user or check receipt of a message.  If there is you can search for
VIRGIN (unused) boxes) without being disconnected like you would from
outside of a box.  Virgin boxes have a 'generic' greeting and name.  Eg.
'Mailbox xxx' or 'Please leave your message for mailbox xxx...'   Write down
any boxes you find with a generic greeting or name, because they will
probably have the default passcode.  Another sign of a virgin box is a name
or greeting like 'This mailbox is for ...' or a women's voice saying a man's
name and vice versa, which is the system administrator's voice.  If the box
does not have this feature, simply use the previous method of scanning boxes
from the outside.  For an example of interior scanning, when inside an Aspen
box, chose (3) from the main menu to check for receipt.  It will respond with
'Enter box number.'  It is a good idea to start at a location you know there
are boxes present and scan consecutively, noting any boxes with a 'generic'
greeting.  If you enter an invalid box it will alert you and allow you to
enter another.  You can enter invalid box numbers forever, instead of the
usual three incorrect attempts from outside a box.


TAKING A BOX

Now you need to find a box you can take over.  NEVER take a box in use; it
simply won't last.  Deserted boxes (with messages from months ago) are the
best and last the longest.  Take these first.  New boxes have a chance of
lasting, but if the person for whom the box was created tries to login,
you'll probably lose it.  If you find a box with the system administrator's
voice saying either the greeting or name (quite common), keeping it that way
will prolong the box life, especially the name.

This is the most important step in taking over a box!  Once you pick a box take over, watch it for at least three days BEFORE changing anything!  Once
you think it's not in use, then change only the passcode, nothing else! 
Then login frequently for two to three days to monitor the box and make sure
no one is leaving messages in it.  Once you are pretty sure it is deserted,
change your greeting to something like 'Sorry I'm not in right now, please
leave your name and number and I'll get back to you.'  DO NOT say 'This is
Night Ranger dudes...' because if someone hears that it's good as gone.  Keep
your generic greeting for one week.  After that week, if there are no
messages from legitimate people, you can make your greeting say whatever you
want.  The whole process of getting a good vmb (that will last) takes about
7-10 days, the more time you take the better chance you have of keeping it
for long time.  If you take it over as soon as you get in, it'll probably
last you less than a week.  If you follow these instructions, chances are it
will last for months.  When you take some boxes, do not take too many at one
time.  You may need some to scan from later.  Plus listening to the messages
of the legitimate users can supply you with needed information, such as the
company's name, type of company, security measures, etc.


SYSTEM IDENTIFICATION

After you have become familiar with various systems, you will recognize them
by their characteristic female (or male) voice and will know what defaults
are most common and what tricks you can use.  The following is a few of a few
popular vmb systems.

ASPEN is one of the best vmb systems with the most features.  Many of them
will allow you to have two greetings (a regular and an extended absence
greeting), guest accounts, urgent or regular messages, and numerous other
features.  Aspens are easy to recognize because the female voice is very
annoying and often identifies herself as Aspen.  When you dial up an Aspen
system, sometimes you have to enter an (*) to get into the vmb system.  Once
you're in you hit (#) to login.  The system will respond with 'Mailbox number
please?'  If you enter an invalid mailbox the first time it will say 'Mailbox
xxx is invalid...' and the second time it will say 'You dialed xxx, there is
no such number...'  and after a third incorrect entry it will hang up.  If
you enter a valid box, it will say the box owner's name and 'Please enter
your passcode.'  The most common default for Aspens is either box number or
box number + (0).  You only get three attempts to enter a correct box number
and then three attempts to enter a correct passcode until it will disconnect
you.  From the main menu of an Aspen box you can enter (3) to scan for other
boxes so you won't be hung up like you would from outside the box.

CINDY is another popular system.  The system will start by saying 'Good
Morning/Afternoon/Evening.  Please enter the mailbox number you wish...' and
is easy to identify.  After three invalid box entries the system will say
'Good Day/Evening!' and hang up.  To login, enter the box number and during
the greet press (0) then your passcode.  The default for ALL Cindy systems is
(0).  From the main menu you can enter (6) to scan for other boxes so you
won't be hung up.  Cindy voice mail systems also have a guest feature, like
Aspens.  You can make a guest account for someone, and give them
password, and leave them messages.  To access their guest account, they just
login as you would except they enter their guest passcode.  Cindy systems
also have a feature where you can have it call a particular number and
deliver a recorded message.  However, I have yet to get this feature to work
on any Cindy boxes that I have.

MESSAGE CENTER is also very popular, especially with direct dials.  To login
on a Message Center, hit the (*) key during the greet and the system will
respond with 'Hello <name>.  Please enter your passcode.'  These vmbs are
very tricky with their passcode methods.  The first trick is when you enter
an invalid passcode it will stop you one digit AFTER the maximum passcode
length.  Eg. If you enter 1-2-3-4-5 and it gives you an error message you enter the fifth digit, that means the system uses a four digit passcode, 
which is most common on Message Centers.  The second trick is that if you enter
an invalid code the first time, no matter what you enter as the second passcode
it will give you an error message and ask again.  Then if you entered the
correct passcode the second and third time it will let you login.  Also, most
Message Centers do not have a default, instead the new boxes are 'open' and
when you hit (*) it will let you in.  After hitting (*) the first time to
login a box you can hit (*) again and it will say 'Welcome to the Message
Center.' and from there you can dial other extensions.  This last feature can
be useful for scanning outside a box.  To find a new box, just keep entering
box numbers and hitting (*) to login.  If it doesn't say something to the
effect of welcome to your new mailbox then just hit (*) again and it will
send you back to the main system so you can enter another box.  This way you
will not be disconnected.  Once you find a box, you can enter (6) 'M'ake a
message to scan for other boxes with generic names.  After hitting (6) it
will ask for a mailbox number.  You can keep entering mailbox numbers until
you find a generic one.  Then you can cancel your message and go hack it out.


Q VOICE MAIL is a rather nice system but not as common.  It identifies itself
'Welcome to Q Voice Mail Paging' so there is no question about what system it
is.  The box numbers are usually five digits and to login you enter (0) like
a Cindy system.  From the main menu you can enter (3) to scan other boxes.

There are many more systems I recognize but do not know the name for them. 
You will become familiar with these systems too.  


CONCLUSION

You can use someone else's vmb system to practice the methods outlined above,
but if you want a box that will last you need to scan out a virgin system. 
If you did everything above and could not get a vmb, try again on another
system.  If you follow everything correctly, I guarantee you will have more
vmbs than you know what to do with.  When you start getting a lot of them, if
you are having trouble, or just want to say hi be sure to drop me a line on
either of my internet addresses, or leave me a voice mail message.

NOTE:  Some information was purposely not included in this file to prevent
abuse to various systems.  
Iam just waiting for ur feed back
yours wellwishier
                               RB
                        Raghib0.29@gmail.com

_______________________________________________________________________________