-o[ Defeating the Caller ID system ]o-
-o[ D4RKCYDE ]o-
-o[ by hybr1d <hybrid@dtmf.org> ]o----------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Defeating The Caller ID System
With Simple but Effective Stealth.
July 1999.
hybrid (hybrid@dtmf.org)
(http://hybrid.dtmf.org)
quick disclaimer: I do not encourage any of the information provided in this
file. I, or f41th cannot be held responcerble for your use of the information
provided in this article, it has been provided for informational purposes
only.
(introduction)
CallerID (CID) or CND (Calling Number Delivery), is an extension to the
widley used ANI (Automatic Number Identification) system. The telcos use ANI
as a means for billing information when you make a toll-call, however dispite
what alot of people think, ANI is not used as part of the CID system, it was
the first system used to allow the recieving party know who was calling and
was widely used before the advent of the SS7 telephony protocol, but sinse
the implementation of SS7 CID/CND has become popular, both in residential
subscriber loops, and commercial lines. In this file I am going to show how
the CID/CND system works, specific to different *bell specifications aswell
as the differences in other countrys, such as the UK. Before we go any
further, you need to know the basics of the *bell CID protocol;
CID information (data) is transmitted on the subscriber loop using a method
known as FSK (Frequency Shift Keyed) modem tones. This data is transmitted in
ASCII format and contains the information needed to display the CID mesage at
the terminating line. The actual data burst occurs between the first and
second ring of the line, and contains basic information about the originating
point of the call, such as the date, time, and of course the calling number.
On more upto date systems, or in a local area, the name of the caller will be
displayed next to their number aswell. Further advances in CID include a new
system called CIDCW or (CID on Call Waiting), where the call waiting tone is
heard and the CID of the second calling person is exposed.
(definition)
As I said before, Caller ID is the identification of the originating
subscriber line. For example, say you had a line installed under your own
name, your details would be stored alongside your line information in your
telcos directory listings. So when you call someone with a CID unit that
displays the calling partys name, your name would be displayed alongside the
number, or whoever pays the bill for the line. Obviously the telco has no
real way of knowing just _who_ is making the call, so the term Caller ID
would be inapropriate, and should technically be refered to as Calling Number
Identification because it is the name of the person associate with the line
rental, and not your docs that are transmitted. The actual CID information is
transmitted to the terminating subscriber loop, as I said before, between
the first and second ring implementing a bell202 type modem specification.
There are 2 tones that are tranmitted, one of them contains the mark
transmission (logic 1) and the other contains the space transmmision (logic
0), mark and space. The transmitted message contains a channel seizure string
and then a mark string followed by the actual caller information. If the
recieving line only has basic CID information installed (where they only
recieve the date, time and number of the caller) SDMF (Single Data Message
Format) is used in the CID data burst. If however, the recieving person has
a more advanced version of CID where they can see the name of the person
calling, MDMF (Multiple Data Message Format) is used in the data burst. If
the MDMF method is used, and you have withheld your CID, the recieving line
will only see a message saying the information was blocked by the caller, or
is unavailable. Later I will discuss ways of making your line information
completly unavailable to the called party.
In New Jersey 1987, the first CID service was offered to subscribers of
NJBell because NJBell where at that time implementing new high-speed networks
and wanted to rake in a little more money by offering this new service to its
customers. Before SS7 ANI was used as a means of obtaining the calling number
info as a means for billing purposes on certain lines. Before SS7, your ANI
would go no furthur than your central office, and would not be forwarded to
international calls. However, that was then and this is now, SS7 has been
implemented big time over the international/national PSTN (Public Switched
Telephone Network) and ANI can be a phreaks worst enemy. These days ANI
information can be transmitted internationaly, and in some cases globably,
depending on the similaritys of the concerned signalling/switching systems.
Numbers that are renowned for implementing full ANI capture are 800 and 900
services (full SS7 based) aswell as operator services, and of course 911.
ANI is _completly_ different from CID, so if you call a line that has an ANI
service installed, you will not be able to block your line information from
going through as ANI works on a different protocol than CID, ie, the *
services used to withhold your CID wont work on an ANI system because they
are designed _only_ for blocking of CID _not_ ANI, remember they are
completly different things. There are alot of rumours that I have heard from
people about ANI, such as its supposid ability to capture your line
information, which ever method you use to call a number. The fact is, ANI is
dependant on SS7, which in turn is dependant on translation tables, who says
you have to use the SS7 network to call someone ;> I'll go into this further
later in this file.
Now, back to CID; Because of the mass implementation of the SS7 protocol, CID
informaion is transmitted to the called party's central office. This is done
using SS7, and is called CPNM or (Calling Party Number Message). Now, heres
the bitch of SS7; when you call someone, your line informaion is sent to the
persons central office _regardless_ of the fact that you may have reqested
that your line informaion is withheld. If you have withheld your CID, the
remote person's central office still get your line information, but notices
that you reqested that your info is withheld (UNLESS the person you are
calling has a deal with their local telco to expose any CID information held
at their central office to be automaticaly transmited to their CID unit,
Thats where things begin to get nasty (at the end of the day, the telcos are
more concerned about the money they are recieving for providing _full_ CID
services to people, and could'nt care less if you reqested your line
informaion remains private).
(lets get technical) -- exphunged from CallerID specifications
by Michael W. Slawson
Eventually standard CID (SDMF) where only the calling number and date etc are
displayed will be completly phased out and replace by the enhanced CNAM
(Calling Name Delivery) where the MDMF data burst transmission is used.
The CID information is sent serially at a rate of 1200 bits per second using
continuous-phase binary frequency shift keying for modulation. The two
frequencies used to represent the binary states are 1200 Hz for the Mark
(logic 1) and 2200 Hz for the Space (logic 0). The data is sent
asynchronously between the first and second ring at a signal level of -13.5
dBm. The level is measured at the central office across a 900 ohm test
termination.
Following a minimum of 500 ms after the end of the first ring, the sequence
of transmission begins with a Channel Seizure. The Channel Seizure is a
string of 300 continuous bits (250 ms) of alternating "0"s and "1"s. This
string starts with a "0" and ends with a "1". A Mark Signal of 180 mark bits
(150 ms) is sent immediately following the Channel Seizure Signal. The
purpose of the Channel Seizure Signal and the Mark Signal is to prepare the
data receiver in the Customer Premise Equipment (CPE) for the reception of
the actual CID transmission.
Once the Channel Seizure and Mark Signals have been sent the CID information
is then transmitted starting with the Least Significant Bit (LSB) of the most
significant character. This is true for both SDMF and MDMF. Each character
in the message consists of 8 bits. For displayable characters these bits
represent a code defined by the American Standard Code for Information
Interchange. When transmitted the character's 8 bits are preceded by a start
bit (space) and followed by a stop bit (mark) giving a total of 10 bits sent
for each character. The CID information is followed by a checksum for error
detection. Figure 1 shows a visual layout depicting the association of the
1st Ring, Channel Seizure Signal, Mark Signal, Caller ID information,
Checksum, and the 2nd Ring.
The checksum word is a twos complement of the modulo 256 sum of each bit in
the other words of the message. The Channel Seizure and Mark Signals are not
included in this checksum. When the message is received by the CPE it checks
for errors by taking the received checksum word and adding the modulo 256 sum
of all of the other words received in the message. The addition done by the
CPE does not include the Channel Seizure and Mark Signals, nor does it
include the received checksum word. The result of this addition should be
zero to indicate that no errors have been detected.
Figure 2 shows a CID message in SDMF. For ease in describing the process of
determining the checksum, the decimal values will be used for the
calculations.
Character Decimal ASCII Actual
Description Value Value Bits (LSB)
- ------------------- ------- ----- ---------------
Message Type (SDMF) 4 0 0 0 0 0 1 0 0
Message Length (9) 18 0 0 0 1 0 0 1 0
Month (December) 49 1 0 0 1 1 0 0 0 1
50 2 0 0 1 1 0 0 1 0
Day (25) 50 2 0 0 1 1 0 0 1 0
53 5 0 0 1 1 0 1 0 1
Hour (3pm) 49 1 0 0 1 1 0 0 0 1
53 5 0 0 1 1 0 1 0 1
Minutes (30) 51 3 0 0 1 1 0 0 1 1
48 0 0 0 1 1 0 0 0 0
Number (6061234567) 54 6 0 0 1 1 0 1 1 0
48 0 0 0 1 1 0 0 0 0
54 6 0 0 1 1 0 1 1 0
49 1 0 0 1 1 0 0 0 1
50 2 0 0 1 1 0 0 1 0
51 3 0 0 1 1 0 0 1 1
52 4 0 0 1 1 0 1 0 0
53 5 0 0 1 1 0 1 0 1
54 6 0 0 1 1 0 1 1 0
55 7 0 0 1 1 0 1 1 1
Checksum 79 0 1 0 0 1 1 1 1
The first step is to add up the values of all of the fields (not including
the checksum). In this example the total would be 945. This total is then
divided by 256. The quotient is discarded and the remainder (177) is the
modulo 256 sum. The binary equivalent of 177 is 10110001. To get the twos
compliment start with the ones compliment (01001110), which is obtained by
inverting each bit, and add 1. The twos compliment of a binary 10110001 is
01001111 (decimal 79). This is the checksum that is sent at the end of the
CID information. When the CPE receives the CID message it also does a modulo
256 sum of the fields, however it does not do a twos complement. If the twos
complement of the modulo 256 sum (01001111) is added to just the modulo 256
sum (10110001) the result will be zero.
If the result is not zero then the message is discarded. It is important to
note that there is no error correction in this method. Even if the CPE were
to notify the central office of errors, the central office will not
retransmit the information. If an error is detected, the CPE receiving the
message should display an error message or nothing at all. Although Bellcore
SR-TSV-002476 recommends that the CPE display an error message if erroneous
data is received, most CPE manufacturers have elected to just ignore the
errored message.
The content of the CID message itself depends on whether it is in SDMF or
MDMF. A message in SDMF includes a Message Type word, a Message Length word,
and the actual Message words. A message in MDMF also includes a Message Type
word, a Message Length word, and the actual Message words, but additionally
includes Parameter Type and Parameter Length words. There are certain points
within these messages where up to 10 Mark bits may be inserted to allow for
equipment delays in the central office. These Stuffed Mark bits are generally
not necessary.
The Message Type word defines whether the message is in SDMF or MDMF. It will
be a binary 00000100 (decimal 4) for SDMF or a binary 10000000 (decimal 128)
for MDMF. The Message Length will include the number of characters in the
message. This length does not include the checksum at the end of the message.
For SDMF the minimum length will be 9 characters. The minimum length for MDMF
will depend on whether the customer has subscribed to CNAM service as well as
CND. In the case of CND only the minimum length will be 13 characters. If the
customer also has CNAM then the minimum will be 16 characters. In all three
of the minimums mentioned there will be no actual number or name delivered.
The field will be marked either "O" (Out of area) or "P" (Private).
Figure 3 shows an example of a minimum message layout for SDMF. The number
will not be delivered because it has been blocked by the calling party. The
CPE will receive the date, time, and a "P" to indicate that the caller's
identification has been blocked at the caller's request.
Character Decimal ASCII Actual
Description Value Value Bits (LSB)
- ------------------- ------- ----- ---------------
Message Type (SDMF) 4 0 0 0 0 0 1 0 0
Message Length (9) 9 0 0 0 0 1 0 0 1
Month (December) 49 1 0 0 1 1 0 0 0 1
50 2 0 0 1 1 0 0 1 0
Day (25) 50 2 0 0 1 1 0 0 1 0
53 5 0 0 1 1 0 1 0 1
Hour (3pm) 49 1 0 0 1 1 0 0 0 1
53 5 0 0 1 1 0 1 0 1
Minutes (30) 51 3 0 0 1 1 0 0 1 1
48 0 0 0 1 1 0 0 0 0
Private 80 P 0 1 0 1 0 0 0 0
Checksum 16 0 0 0 1 0 0 0 0
Character Decimal ASCII Actual
Description Value Value Bits (LSB)
- -------------------------- ------- ----- ---------------
Message Type (MDMF) 128 1 0 0 0 0 0 0 0
Message Length (33) 33 0 0 1 0 0 0 0 1
Parameter Type (Date/Time) 1 0 0 0 0 0 0 0 1
Parameter Length (8) 8 0 0 0 0 1 0 0 0
Month (November) 49 1 0 0 1 1 0 0 0 1
49 1 0 0 1 1 0 0 0 1
Day (28) 50 2 0 0 1 1 0 0 1 0
56 8 0 0 1 1 1 0 0 0
Hour (3pm) 49 1 0 0 1 1 0 0 0 1
53 5 0 0 1 1 0 1 0 1
Minutes (43) 52 4 0 0 1 1 0 1 0 0
51 3 0 0 1 1 0 0 1 1
Parameter Type (Number) 2 0 0 0 0 0 0 1 0
Parameter Length (10) 10 0 0 0 0 1 0 1 0
Number (6062241359) 54 6 0 0 1 1 0 1 1 0
48 0 0 0 1 1 0 0 0 0
54 6 0 0 1 1 0 1 1 0
50 2 0 0 1 1 0 0 1 0
50 2 0 0 1 1 0 0 1 0
52 4 0 0 1 1 0 1 0 0
49 1 0 0 1 1 0 0 0 1
51 3 0 0 1 1 0 0 1 1
53 5 0 0 1 1 0 1 0 1
57 9 0 0 1 1 1 0 0 1
Parameter Type (Name) 7 0 0 0 0 0 1 1 1
Parameter Length (9) 9 0 0 0 0 1 0 0 1
Name (Joe Smith) 74 J 0 1 0 0 1 0 1 0
111 o 0 1 1 0 1 1 1 1
101 e 0 1 1 0 0 1 0 1
32 0 0 1 0 0 0 0 0
83 S 0 1 0 1 0 0 1 1
109 m 0 1 1 0 1 1 0 1
105 i 0 1 1 0 1 0 0 1
116 t 0 1 1 1 0 1 0 0
104 h 0 1 1 0 1 0 0 0
Checksum 88 0 1 0 1 1 0 0 0
In Figure 4, if the number and name had not been included then the parameter
types for those fields would be different. These alternate parameter types
are used to signify that the data contained in that parameter is the reason
for its absence. The parameter type for the number section would have been a
binary 00000100 (decimal 4) and the parameter type for the name section would
have been a binary 00001000 (decimal 8). When the parameter type signifies
that the data contained is the reason for that fields absence, the parameter
length is always a binary 00000001 (decimal 1). If the reason for absence is
that the calling party does not want their number/name displayed then the
parameter data would be a binary 01010000 (ASCII "P") for Private. If the
reason for absence is that the information is just not available then the
parameter data would be a binary 01001111 (ASCII "O") for Out of area. The
number/name may not be available if the calling party is not served by a
central office capable of relaying the information on through the network.
(lets talk d1rty)
The above specifications are relevant to the US CID system, and not to the
UK specification. Enough of the technical stuff for now though, its time to
look at CID systems from an attack and deffense point of view. First the
real basics; if you are in US you can reqest that your CID is withheld by
using *67 as a prefix when dialing a number. As I said before though, this is
absolutly usless in completly withholding your CID because we know that CID
information is passed onto the called party's central office regardless of
*67 via implementation of the SS7 network. If you are in the UK you would
prefix your call with 141, but again our nice systemX digital exchanges a
real bitches at passing on our CID information to _other_ exchanges, so in
essance your call routing is loged as it passes through exchange boundarys on
the PSTN. So here I am going to discuss different techniques that can be used
to completly render your CID information useless as it is transmitted through
various excahanges and offices.
I'm going to begin with some basic concepts so you can understand the more
advanced techniques better. Now, lets consider this scenario for the
following techniques; You are in Texas (RBOC: SWBell) and you want to set-up
a call to someone in Chicago (Ameritech). Obviously, you know that *67 wont
help you if the person you are calling has full CID (or has access to there
central office ;>) so you consider the following techniques and call-setup
examples.
[ example A: simple diverting ]
Here you can use a host that will be traced back to in the advent that the
person has full CID. In other words, its real simple, you use a PBX
(preferably a long distance one located in another RBOC). This is very self
explanitory, but alot of people get it wrong. Heres how the call setup would
look in a metaphorical diagram:
______ ______ ______
| | | | | | (800)XXX-XXXX
| CO |------------->| CO |------->| PBX | POTS:(123)456-7890
|______| |______|<-------|______|
| |
| |
| __|___
( you ) | |
| CO |----------------------> ( them )
|______|
Now, whats happening here is you are calling the PBX at *671800XXXXXXX, you
then login to the PBX and from there you dial the person you want to call.
When the person checks there CID unit, they will see the number of the PBX
you are calling from instead of your actuall originating number. Now, this is
OK for very very very simple CID spoofing, but if the person you are calling
is resoursefull, they could very easily have words with the host from which
you where calling from (who would have your ANI -its an 800 number) The CO of
the PBX would also have the time, date, and trunk setup information for when
you called the PBX etc, so this example is still not quite as effective as
you would imagine it to be.
Now, to make a long story short, we can enhacne the above method by
implementing our _own_ CID blocking methods along the above routing example.
Look at the diagram in detail, and you will realise that there can be many
different alterations made that can make the routing alot safer, and _alot_
more hastle for them to pin-point your OCP, or originating point.
First we take into account the call we make to the PBX. For starters, you can
op-divert to the 800 number (depending on where you live) so the 800 PBX
recieves operator assisted call ANI instead of yours. This can be done very
easily, and involves you calling your local operator and asking them to call
the number for you. The central office located near to the PBX then has the
OPC of your operator, rather than you.
Now, the PBX host is your safgaurd when it comes to hiding your CID. For
those of you who dont know, all PBXs or privatly owned switching and trunking
mechanisms/systems log incomming and outgoing trunk setups for billing
purposses etc. These days, most PBX exchanges have administration modules
that deal with call routing. The call-setups are stored in the databases of
the PBXs and can be intercepted. Most of the time, a PBX will have 1 if not
several dialin modems that connect to the PBX administration modules for
remote maintanance. Its simply a case of internally scanning the extensions
of the remote PBX for a carrier, and checking out each one until you find
what you are looking for. Once you have access, you could do _many_ things
depending on how advanced the system is. For example, you could erase any log
of your connection to the PBX (aswell as any furture connections), you can
set up incomming and outgoing trunks on the PBX exchange that dont even
exist, you can also select which trunk you wish to call your party with and
therefore selecting which number you wish to be displayed to the called
party. I wont go into to much detail here, you get the picture right?
So now we are using a host to call through that will not log anything that
could point towards you, with the exeption of the timestamping at the central
officess along the routing path. (again, that could be delt with in a similar
fashion). You could also implement op-diverting from the PBX to the dialed
person, or triple the amount of hosts you use to place the call at the same
time using the above methods, but via more PBXs and operators.
In my opinion though, the above method is no way near as secure as you need
it to be, so in the next examples, we take adavntage of ld-carriers, and
global PSTN networks that do not co-operate with each other, ie: calling
party data is not translatable or transmitable (electromechanical).
Now, to really throw someone off track in the advent of a trace (realtime or
aftermath) we take advantage of one of the biggest flaws in the PSTN known
today: new digital exchange units such as digital ESS, systemX etc cannot
effectivly communicate with older lesser implemented electromechanical
exchanges such as crossbar, and CCITT#5 protocols implemented in lesser
developed countrys such as Indonisia, Libia etc. The worlds telcos are also
very lazy when it comes to passing on originating calling party information
from country to country, simply because it is to much hastle for them, time
and money runs into the picture once more. So ld call setups become a good
counter defense when it comes to routing un-traceable calls. Now, I can think
of literaly 100s of methods that could be implemented here, but I'm going to
discuss the structure of how this type of call would be setup, I'll leave the
rest to your imagination (if you have one)
[ example B: international routing ]
Now, consider the previous call setup example, and imagine how it would be
trunked if you placed a long distance barrier in-between. Here we will
imagine we have 2 PBXs, one in the US and one in the UK. Again, you are in
Texas and want to setup a call to someone in Chicago without revealing your
identity. The basic call setup would appear like this:
______ ______ ______
| | | | | | (800)XXX-XXXX
| CO |------------->| CO |------->| PBX | POTS:(123)456-7890
|______| |______|<-------|______|
| | ___
| [ US PSTN ] | ESS routing .--->|co |
| __|___ ____|_ |___|------ ( them )
( you ) | | | |
| CO |------->| DMS | (international DMS
|______| |______| gateway router)
:
:
:
[ super LD ] .........................\........................
\
:
So here you have op diverted :
to the US PBX, then from the :
US PBX op diverted and called ______ ___:__
the PBX in the UK, already | |------->| |
the UK PBX has lost the US | CO |<-------| DMS | (international DMS
PBXs CID, and from the UK PBX |______| |______| gateway router)
you call the person in chicago, |:
which in turn is re-routed back |:
through the international PSTN |: [ UK PSTN ] systemx routing
effectivly deteriating your __|:__
origionating line. | |
| PBX | (UK PBX)
|______|
The problem with this kind of routing example is that you are costing the 2
PBX exchanges involved big bux, and is generaly not a very nice thing to do,
heh. Again, as in the previous example, you can implement the PBX
administration for extra security, the above diagram could be used vise-versa
whether your origionating point was the UK or US. It is howver inconvinient,
both for you, and for the poor owners of the PBXs who have to falk out for
your toll-fraud adventures. There are however other ways of implementing the
above techniques.
Now, probably the most favourable technique to use would be to box your way
out of a country that runs C5, and from there re-route a call back to the US
and even implement a few PBXs along the way, therefore you would have [ 0 ]
CID worrys. A more advanced technique involves the forwarding of subscriber
lines to a designated number (A C5 country direct, PBX etc). Now, if you are
in the US, you could be super lame and simply have another US line forwarded
to another number via the means of posing to the forwarded lines co as a
field engineer requesting a line be forwarded to xxx while you carry out
field 'maintanance' on it, _or_ if you wanna stay away from the lameness, you
could so this:
Lets take Indonisia for example. You can remotely forward an Indonisian
residential line to anywhere you want (providing you can find an english
speaking exchange). Indonisia is just an example, but like the US method of
forwarding lines you have 2 options. You could a) pose a local field
engineer, or if the country has a DMS[+] architecture you could forward the
lines via the means of remote switch access. (Thats another file, but you get
the general idea). So, when it comes down to it, its all about having the
ability to route calls, not spoof them.
So, there you have it, a brief guide to CID blocking (the effective way), its
your choice, *67 (blah) or *67,00-->1800XXXXXXX-->*67,00-->1800XXXXXX(CD)-->
KP2-44-141-0800-XXXXXXX-ST -->001-1800XXXXXXX-->*67,00-->555-555-5555 hello?
<click> <click> <churchunk> <brrr> <curchunk> <click> <click> :>
I hope you enjoyed this file as much as I did writing it, take it easy and
remember to check out my website.. :)
Shouts to 9x, substance, downtime, ch1ckie, oclet, jasun, zomba, psyclone,
bodie, digiphreq, w1repa1r, gr1p, t1p, jorge, b4b0, shadowx, osiris, essgurl,
lowtek, pbxphreak, katkilla, drphace, prez, euk, simmeth, dgtlfokus, voltage,
knight, siezer, oeb, lusta, infidel, devious, werd to #9x #darkcyde #phunc
#b4b0 #2600 #2600-uk & wErd to D4RKCYDE.
: . http://hybrid.dtmf.org
___ ___ _____.___.____________________ ____________
hybrid@b4b0.org / | \\__ | |\______ \______ \/_ \______ \
hybrid@ninex.com / ~ \/ | | | | _/| _/ | || | \
hybrid@dtmf.org \ Y /\____ | | | \| | \ | || hy_ \
\___|_ / / ______| |______ /|____|_ / |___/_______ /
+++ NO CARRIER \/ \/ : \/ \/ . \/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: cp850
iQEVAwUBN5dSy7TUyHciIYgJAQGcSgf/er3ngPoYsPon9rmU4VG0klcp9koc5aoA
hBBheVxeeVQOzrUl0kPv5sCUPdHoEKbabHqAyDcoJY9feoM5aZ4U0kryuTBm415z
M57ff31CH+T+8iUaW7ZlQkBfFuJfNr2B3pro6KvDGzU2S7nJhYSCugoCf3IExlLt
+FSXEAl+HC0PCpDcEYlQ+2kNwgOBMLLQ9w3On/vFcRJnD26E9Hk4j5IMv8iv+37F
sdQDDhqQ3ah2y1CN3KGAOrcsaYRhT1OyLjbw+JDwR1buCa38yqawBjpbAuM/PTfU
eoNCmwzFEucjcFKpQJisT1428MgeuK2cWmIj8flfuIr9fhIi/7wdNA==
=570J
-----END PGP SIGNATURE-----
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
