Phrack Inc. Volume Three, Issue 29, File #1 of 12 Phrack Inc. Newsletter Issue XXIX Index
==Phrack Inc.==
Volume Three, Issue 29, File #1 of 12
Phrack Inc. Newsletter Issue XXIX Index
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
November 17, 1989
Greetings and welcome to Issue 29 of Phrack Inc. For those of you who
have been with us from the beginning, the date on this issue may hold some
historical significance:
Happy Fourth Anniversary Phrack Inc.!
This issue we feature two files dealing with electronic fund transfer
written by a member of the Legion of Doom who wishes to remain anonymous.
The second article tells a story detailing how an actual electronic fund
transfer might take place -- Is it true or is it fiction? We decided to let
you, the reader, decide that for yourself.
The Future Transcendent Saga continues as usual in this issue with part
two of "Introduction to the Internet Protocols." We also present to you the
second edition of Network Miscellany which focuses largely on Public Access
Unix systems around the country. Last, but not least, concerning the wide area
networks, we have Covert Paths -- a file about hacking on the Internet and how
to make sure you cannot be tracked down.
On a lighter note, it appears that Teleconnect Magazine liked The Mentor's
"Hacker's Manifesto" so much that they decided to print a portion of it in
their November 1989 issue. If you receive this magazine you will find it on
page 55, but only the last 4 paragraphs (they apparently did not like the
beginning of the file). The interesting thing is that Teleconnect claims that
they were given the article by MCI Security who recently discovered it on a
bulletin board. If you are a long time reader of Phrack Inc., you might
remember that this article was dated for January 8, 1986 and originally
appeared in Phrack Inc. Newsletter Issue VII (file 3 of 10) and again in issue
XXIV (file 3 of 9).
As always, we ask that anyone with network access drop us a line to either
our Bitnet or Internet addresses...
Taran King Knight Lightning
C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET
C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU
And we can also be reached via our new mail forwarding addresses (for those
that cannot mail to our Bitnet or Internet addresses):
...!netsys!phrack or phrack@netsys.COM
_______________________________________________________________________________
Table of Contents:
1. Phrack Inc. XXIX Index by Taran King and Knight Lightning
2. Phrack Pro-Phile XXIX on Emmanuel Goldstein
3. Introduction to the Internet Protocols II: Chapter Nine of the FTS by KL
4. Network Miscellany II by Taran King
5. Covert Paths by Cyber Neuron Limited and Synthecide
6. Bank Information compiled by Legion of Doom!
7. How We Got Rich Through Electronic Fund Transfer by Legion of Doom!
8. The Myth and Reality About Eavesdropping by Phone Phanatic
9. Blocking of Long-Distance Calls... Revisited by Jim Schmickley
10-12 Phrack World News XXIX/Parts 1-3 by Knight Lightning
_______________________________________________________________________________
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #2 of 12
==Phrack Pro-Phile XXIX==
Created and Presented by Taran King
Done on November 12, 1989
Welcome to Phrack Pro-Phile XXIX. Phrack Pro-Phile was created to
bring information to you, the community, about retired or highly important/
controversial people. This edition of the Phrack Pro-Phile starts a different
format as I'm sure you will notice. The skeleton of the Pro-Phile is a form
in which the people fill in the blanks. Starting now, using their words (and a
little editing), the Pro-Phile will be presented in first person format. This
month, we present to you the editor of one of the most prominent printed
phreak/hack newsletters of all times...
Emmanuel Goldstein
~~~~~~~~~~~~~~~~~~
Handle: Emmanuel Goldstein
Call Him: Call me anything. Just look me in the eye.
Past Handles: Howard Tripod, Sidney Schreiber, Bob Hardy, Gary Wilson,
Clint Eastwood, 110. There are others that I keep quiet
about.
Handle Origin: I prefer using regular names rather than descriptive
boastful titles (i.e., "The Hacker King," who,
incidentally, I don't wish to offend if he/she even exists;
this is just an example). The names I use are either
people I've "become" or names that bestow a certain image.
Emmanuel Goldstein, for instance, led the resistance in
"1984." But then, there was talk that he never really
existed and was just created by the government in order to
capture the real subversives. I don't think that's the
case with me.
Computers: I use PC compatibles for the most part. I also play around
with Macs but they're not REAL computers to me. My
favorite machine of all time is the Zenith Z-100, a
dual-processor computer that can emulate an old fashioned
H8 or an IBM PC. It runs lots of operating systems and has
a great keyboard. Too bad it was discontinued four years
ago....
Sysop/Co-Sysop Of: The old Plovernet on Long Island (1984), Private Sector in
New Jersey (1985, 1986), and the present and future 2600
boards.
Origins in Phreak/Hack World
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've been playing with phones all of my life and I started playing with
computers the first time I saw one. I always seemed to get in trouble for
doing things I wasn't supposed to... crashing the PDP-10 in high school...
flashing the switchhook on my phone 95 times and getting an angry switchman who
wouldn't release the line, claiming I broke it (I was 10). As computers and
phones started to become integrated, I realized what hacking really was -- just
asking a lot of questions and being really persistent. A lot of people don't
like that, whether it's computers or real life, but how else are you going to
learn what's REALLY happening and not just what others WANT you to know?
Origins in Phreak/Hack BBSes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't really have a BBS reputation to speak of. They tend to disappear
rather quickly and that tends to dampen my enthusiasm towards them quite a bit,
but I do want to see more and more of them come up and begin to reach out and
be creative. They also have to challenge the system some more. 2600 has a
very strong opinion on BBS privacy, namely that the same rights afforded to any
publication should be extended to a bulletin board, but every BBS owner should
know the importance of this and should be willing to fight for it. If you
didn't believe in preserving the First Amendment, you probably wouldn't go out
and buy a newspaper, would you? A BBS is the same thing and anyone who runs a
system should see this connection. Hackers tend to bring this issue to the
forefront a bit more, but this is something that applies to all bulletin
boards.
Encounters With Phreakers and Hackers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meeting Captain Crunch in Amsterdam this past summer was a real trip. Finding
out who Cable Pair really was certainly resulted in some highlights. I've met
a lot of "famous" phreaks and hackers and now I know a lot of foreign ones, but
I'm always amazed at the number of people I meet (mostly in New York) who say
they've been hacking since the sixties. There's an awful lot of people out
there who are into this kind of stuff, which is something I never knew before I
started being open about these particular interests.
Experience Gained In The Following Ways
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Social engineering, of course. I like hacking computers when I'm not feeling
social because you don't have to adjust your attitude to get a reply, but
people hacking is so much more satisfying. No matter how many security codes
and precautions are taken, as long as one person without knowledge is able to
talk to another with knowledge, it will always be possible to get things out of
them. Most of the really important bits of information I've been able to get
are through people, not computers.
Knowledge Attributed To...
~~~~~~~~~~~~~~~~~~~~~~~~~~
Ignorance. I built up my knowledge by wandering around in places others
thought unimportant. Hacking can be like trashing. It looks like garbage or a
waste of time to most, but if you keep your mind open, you can learn a lot. If
more people felt this way, hackers would stand out less because everyone would
be a bit more adventurous, but ignorance prevails and we learn what nobody else
cares about...that is until it affects them.
Work/Schooling
~~~~~~~~~~~~~~
I got an English degree at Stony Brook (it's currently gathering dust in a
closet). I should note that I've never taken a computer course, nor do I
intend to. I've worked as a limo driver, a Good Humor man, and a typesetter,
and more recently, as a freelance writer, a reporter for Pacifica Radio, and a
radio engineer/producer and talk show host.
Busted For...
~~~~~~~~~~~~~
I used to make free phone calls all the time. Now, obviously, I can't do that,
since I'm in the public eye, but that's not a drawback to me because I can
still experiment all I want. Nothing can change that. For the most part I was
careful while I was doing these things, but there was one time when my luck ran
out. I had been using Telemail to communicate with some other people and they,
unknown to us, had been looking for hackers on their system. They found us,
the members of PHALSE (Phreakers, Hackers, and Laundromat Service Employees
[I'm told the feds spent a lot of time investigating the laundry connection,
even though we only used it to spell out the word PHALSE!]). I believe four
people got indicted in that adventure. I was one of them. Bill Landreth was
another. They thought I was the ringleader so they gave me a 10 count
indictment, more than twice what anyone else got. Without hiring an expensive
lawyer, I talked to a roomful of feds about the system and what was wrong with
it. I made it clear that I wasn't turning anybody in -- even if I wanted to I
still didn't know who or where they were. I think I was dealt with fairly. I
told them what I did and paid for the time I used. Nothing more. That was in
1984 when 2600 was just getting off the ground. A couple of years ago, one of
the feds who had questioned me tried to get me to work for them. Not to entrap
hackers, but Soviet spies. And so it goes.
Interests
~~~~~~~~~
I guess I'm an explorer because everything I like doing involves exploration of
some sort. Obviously, hacking contains a good amount of that. I like
traveling quite a bit, particularly when I'm free to do whatever the hell I
want. Traveling with people is fun but it can also be a drag because something
you want to do puts them off and then you either wind up not doing it or doing
it and pissing them off. I like to ride subways to weird places and walk
through bad neighborhoods. It's all a part of exploring and seeing the world
through different eyes. A couple of years ago I went to Baffin Island and hung
out for a week with Eskimos. Everyone thought I was crazy but I had a great
time. I'm also into astronomy, but not the classroom kind. I took a course
in astronomy once and it was the biggest mistake of my life. All we did was
talk about equations. I like to look at the sky and read about what's being
discovered up there. When the space telescope goes up next year, interest in
space will rise again. Then there's free-lance writing, which I have to devote
more time to. I'm working on a couple of plays, some short stories, a
screenplay for a movie, and a screenplay for TV. I'll probably focus on the
plays only because there's so much bullshit involved in TV and movies. And
finally, there's radio. I've been in radio for just over 10 years, doing
whatever comes to mind on WUSB-FM in Stony Brook, NY, a small, noncommercial
radio station at the State University. Now I also work at WBAI-FM, a much
larger station in New York City with the same kind of free-form attitude.
There's so much you can do with radio, but so few stations want to take a
chance any more. That's why they all sound the same. Unfortunately, when you
sell commercials, you also sell your freedom. I've seen it enough times to
know it's true and that's the reason I've stayed out of commercial radio.
Right now I do a weekly talk show on WUSB called "Brain Damage" where I take
calls, play with the phones, and air tapes from Radio Moscow. On WBAI I'm
doing two shows: "News of the World" which is a compilation of foreign news
reports and "Off The Hook," a program about, you guessed it, phone phreaks.
Favorite Things
~~~~~~~~~~~~~~~
I like hanging out with fun people who are open-minded, non-judgmental, and
preferably insane to a degree. I enjoy talking on the phone with friends and
strangers alike. Strangers are different because you can be whoever you want
to be with them. They tend to believe almost anything you say. Music is
really important. Right now I like rappers and toasters the most, with soca
and hardcore close behind. Ska's real good too, but there's not much coming
out. The record I put on when I wake up sets my mood for the day. I like
music with lyrics that mean something. There's a time and a place for mindless
droning but there's too much of it around. Music should have meaning. In
Jamaica, people don't buy newspapers. They buy records and that's how they
learn what's going on and what the latest catch phrases are. Some of my
favorite rock bands include The Clash, Big Audio Dynamite, Dead Kennedys,
Donner Party, Public Enemy, Camper Van Beethoven, Pink Floyd, Fun Boy Three, De
La Soul, and Anti-Nowhere League. Some of my favorite solo artists are Tracy
Chapman, John Lennon, Elvis Costello, and Patsy Cline. I realize I'm very
lucky because I work in an environment (noncommercial radio station) that gets
over 100 new albums a week. I don't know how I would have ever found some of
the stuff I like if I didn't have that kind of access.
Inside Jokes
~~~~~~~~~~~~
"OK, if we can't have a tour, can we at least have a look around?"
"I'm not allowed to talk to you any more."
"This is the Sprint operator. I have a collect call from AT&T."
"There aren't any more supervisors, sir. You've spoken to all of them."
"Iran, will you hang up! Sir, do you speak what he speaks?"
"I said, DON'T hit return!"
"But we didn't know it was the foreign minister!"
"Repair serv-- damn! There it goes again. What the hell's wrong with
these phones?"
"Just tell me how much money you lost and I'll arrange for a trial date."
Serious Section
~~~~~~~~~~~~~~~
Being a part of the hack/phreak community, you get to experience unique little
adventures that the "average" person has no conception of. We talk to people
over the phone and have no idea what they look like, often no idea what they
even sound like (BBSes). We play with technology and are thought of as
geniuses merely because the rest of the world doesn't understand what we're
doing. I think that goes to our heads sometimes, which is bad for everyone.
We should apply our knowledge and skills not only to help ourselves by getting
a high-paying job somewhere but to help others as well. Look what happened in
China. Using FAX machines, modems, and redial functions, people forced
information into the country and tied up the government's snitch lines which
probably saved a few lives. The "average" person would never think of applying
technology in this way, but we do and we know how to do it efficiently,
quickly, and without spending money. It's because of that last one that we've
got freedom. Most people don't do things because of the cost. Without having
to worry about that, you can be a lot more imaginative. Of course, that also
makes it illegal, which is enough to stifle some of us. What we do and how we
do it is a decision we each have to make, but we should stop wasting time
boasting and get on with the exploring and the learning and the new
applications. Another thing that really gets me is the person who says,
"hacking and phreaking isn't what it used to be." First off, if nothing
changes, life gets pretty dull. Second, that statement is usually a precursor
to something like, "what kids do today isn't real hacking. What I did 5, 10,
20 years ago was REAL hacking." Generalizations like that are worthless. It's
just like yuppies going on about the Beatles, calling that real music, and
saying the sounds of today are crap (by the way, I like the Beatles a lot). At
the same time, too many hackers are just starting out and thinking they know it
all, dismissing everything that happened before they were around. The spirit
of today's hacker is often the same as that of a phone phreak of the sixties.
And there were people like us around 100 years ago but we're even more far
removed from what they could have possibly been doing. The point is that
there's a bond that ties a lot of us together -- it cuts through time and
backgrounds. Like anything else, there's too much hypocrisy and judging going
on in the hack/phreak world. I think it's a real waste of time.
Are Phreaks/Hackers You've Met Generally Computer Geeks?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Not in the least. Those people that I've come to know have turned out to be
just about everything you can imagine. White/Black, Jew/Gentile, straight/gay,
male/female, opened/closed, you name it. Everyone's got different sides to
them, stuff they don't always want others to know. Sometimes we try to squash
those other sides of us, but they still exist. I've met hackers who have
geekish qualities but once you get to know them, you realize there's more to
them. Of course, there are lots of hackers I would never want to know in a
million years; that's just the way I am with a lot of people. I think it was
Linus Van Pelt who said, "I love mankind. It's people I can't stand."
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #3 of 12
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> <>
<> Introduction to the Internet Protocols <>
<> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <>
<> Chapter Nine Of The Future Transcendent Saga <>
<> <>
<> Part Two of Two Files <>
<> <>
<> Presented by Knight Lightning <>
<> September 27, 1989 <>
<> <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Prologue - Part Two
~~~~~~~~
A great deal of the material in this file comes from "Introduction to the
Internet Protocols" by Charles L. Hedrick of Rutgers University. That material
is copyrighted and is used in this file by permission. Time differention and
changes in the wide area networks have made it neccessary for some details of
the file to updated and in some cases reworded for better understanding by our
readers. Also, Unix is a trademark of AT&T Technologies, Inc. -- Again, just
thought I'd let you know.
Table of Contents - Part Two
~~~~~~~~~~~~~~~~~
* Introduction - Part Two
* Well Known Sockets And The Applications Layer
* Protocols Other Than TCP: UDP and ICMP
* Keeping Track Of Names And Information: The Domain System
* Routing
* Details About The Internet Addresses: Subnets And Broadcasting
* Datagram Fragmentation And Reassembly
* Ethernet Encapsulation: ARP
* Getting More Information
Introduction - Part Two
~~~~~~~~~~~~
This article is a brief introduction to TCP/IP, followed by suggestions on
what to read for more information. This is not intended to be a complete
description, but it can give you a reasonable idea of the capabilities of the
protocols. However, if you need to know any details of the technology, you
will want to read the standards yourself.
Throughout this file, you will find references to the standards, in the form of
"RFC" (Request For Comments) or "IEN" (Internet Engineering Notes) numbers --
these are document numbers. The final section (Getting More Information)
explains how you can get copies of those standards.
Well-Known Sockets And The Applications Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In part one of this series, I described how a stream of data is broken up into
datagrams, sent to another computer, and put back together. However something
more is needed in order to accomplish anything useful. There has to be a way
for you to open a connection to a specified computer, log into it, tell it what
file you want, and control the transmission of the file. (If you have a
different application in mind, e.g. computer mail, some analogous protocol is
needed.) This is done by "application protocols." The application protocols
run "on top" of TCP/IP. That is, when they want to send a message, they give
the message to TCP. TCP makes sure it gets delivered to the other end.
Because TCP and IP take care of all the networking details, the applications
protocols can treat a network connection as if it were a simple byte stream,
like a terminal or phone line.
Before going into more details about applications programs, we have to describe
how you find an application. Suppose you want to send a file to a computer
whose Internet address is 128.6.4.7. To start the process, you need more than
just the Internet address. You have to connect to the FTP server at the other
end. In general, network programs are specialized for a specific set of tasks.
Most systems have separate programs to handle file transfers, remote terminal
logins, mail, etc. When you connect to 128.6.4.7, you have to specify that you
want to talk to the FTP server. This is done by having "well-known sockets"
for each server. Recall that TCP uses port numbers to keep track of individual
conversations. User programs normally use more or less random port numbers.
However specific port numbers are assigned to the programs that sit waiting for
requests. For example, if you want to send a file, you will start a program
called "ftp." It will open a connection using some random number, say 1234,
for the port number on its end. However it will specify port number 21 for the
other end. This is the official port number for the FTP server. Note that
there are two different programs involved. You run ftp on your side. This is
a program designed to accept commands from your terminal and pass them on to
the other end. The program that you talk to on the other machine is the FTP
server. It is designed to accept commands from the network connection, rather
than an interactive terminal. There is no need for your program to use a
well-known socket number for itself. Nobody is trying to find it. However the
servers have to have well-known numbers, so that people can open connections to
them and start sending them commands. The official port numbers for each
program are given in "Assigned Numbers."
Note that a connection is actually described by a set of 4 numbers: The
Internet address at each end, and the TCP port number at each end. Every
datagram has all four of those numbers in it. (The Internet addresses are in
the IP header, and the TCP port numbers are in the TCP header.) In order to
keep things straight, no two connections can have the same set of numbers.
However it is enough for any one number to be different. For example, it is
perfectly possible for two different users on a machine to be sending files to
the same other machine. This could result in connections with the following
parameters:
Internet addresses TCP ports
connection 1 128.6.4.194, 128.6.4.7 1234, 21
connection 2 128.6.4.194, 128.6.4.7 1235, 21
Since the same machines are involved, the Internet addresses are the same.
Since they are both doing file transfers, one end of the connection involves
the well-known port number for FTP. The only thing that differs is the port
number for the program that the users are running. That's enough of a
difference. Generally, at least one end of the connection asks the network
software to assign it a port number that is guaranteed to be unique. Normally,
it's the user's end, since the server has to use a well-known number.
Now that we know how to open connections, let's get back to the applications
programs. As mentioned earlier, once TCP has opened a connection, we have
something that might as well be a simple wire. All the hard parts are handled
by TCP and IP. However we still need some agreement as to what we send over
this connection. In effect this is simply an agreement on what set of commands
the application will understand, and the format in which they are to be sent.
Generally, what is sent is a combination of commands and data. They use
context to differentiate. For example, the mail protocol works like this:
Your mail program opens a connection to the mail server at the other end. Your
program gives it your machine's name, the sender of the message, and the
recipients you want it sent to. It then sends a command saying that it is
starting the message. At that point, the other end stops treating what it sees
as commands, and starts accepting the message. Your end then starts sending
the text of the message. At the end of the message, a special mark is sent (a
dot in the first column). After that, both ends understand that your program
is again sending commands. This is the simplest way to do things, and the one
that most applications use.
File transfer is somewhat more complex. The file transfer protocol involves
two different connections. It starts out just like mail. The user's program
sends commands like "log me in as this user," "here is my password," "send me
the file with this name." However once the command to send data is sent, a
second connection is opened for the data itself. It would certainly be
possible to send the data on the same connection, as mail does. However file
transfers often take a long time. The designers of the file transfer protocol
wanted to allow the user to continue issuing commands while the transfer is
going on. For example, the user might make an inquiry, or he might abort the
transfer. Thus the designers felt it was best to use a separate connection for
the data and leave the original command connection for commands. (It is also
possible to open command connections to two different computers, and tell them
to send a file from one to the other. In that case, the data couldn't go over
the command connection.)
Remote terminal connections use another mechanism still. For remote logins,
there is just one connection. It normally sends data. When it is necessary to
send a command (e.g. to set the terminal type or to change some mode), a
special character is used to indicate that the next character is a command. If
the user happens to type that special character as data, two of them are sent.
I am not going to describe the application protocols in detail in this file.
It is better to read the RFCs yourself. However there are a couple of common
conventions used by applications that will be described here. First, the
common network representation: TCP/IP is intended to be usable on any
computer. Unfortunately, not all computers agree on how data is represented.
There are differences in character codes (ASCII vs. EBCDIC), in end of line
conventions (carriage return, line feed, or a representation using counts), and
in whether terminals expect characters to be sent individually or a line at a
time. In order to allow computers of different kinds to communicate, each
applications protocol defines a standard representation. Note that TCP and IP
do not care about the representation. TCP simply sends octets. However the
programs at both ends have to agree on how the octets are to be interpreted.
The RFC for each application specifies the standard representation for that
application. Normally it is "net ASCII." This uses ASCII characters, with end
of line denoted by a carriage return followed by a line feed. For remote
login, there is also a definition of a "standard terminal," which turns out to
be a half-duplex terminal with echoing happening on the local machine. Most
applications also make provisions for the two computers to agree on other
representations that they may find more convenient. For example, PDP-10's have
36-bit words. There is a way that two PDP-10's can agree to send a 36-bit
binary file. Similarly, two systems that prefer full-duplex terminal
conversations can agree on that. However each application has a standard
representation, which every machine must support.
So that you might get a better idea of what is involved in the application
protocols, here is an imaginary example of SMTP (the simple mail transfer
protocol.) Assume that a computer called FTS.PHRACK.EDU wants to send the
following message.
Date: Fri, 17 Nov 89 15:42:06 EDT
From: knight@fts.phrack.edu
To: taran@msp.phrack.edu
Subject: Anniversary
Four years is quite a long time to be around. Happy Anniversary!
Note that the format of the message itself is described by an Internet standard
(RFC 822). The standard specifies the fact that the message must be
transmitted as net ASCII (i.e. it must be ASCII, with carriage return/linefeed
to delimit lines). It also describes the general structure, as a group of
header lines, then a blank line, and then the body of the message. Finally, it
describes the syntax of the header lines in detail. Generally they consist of
a keyword and then a value.
Note that the addressee is indicated as TARAN@MSP.PHRACK.EDU. Initially,
addresses were simply "person at machine." Today's standards are much more
flexible. There are now provisions for systems to handle other systems' mail.
This can allow automatic forwarding on behalf of computers not connected to the
Internet. It can be used to direct mail for a number of systems to one central
mail server. Indeed there is no requirement that an actual computer by the
name of FTS.PHRACK.EDU even exist (and it doesn't). The name servers could be
set up so that you mail to department names, and each department's mail is
routed automatically to an appropriate computer. It is also possible that the
part before the @ is something other than a user name. It is possible for
programs to be set up to process mail. There are also provisions to handle
mailing lists, and generic names such as "postmaster" or "operator."
The way the message is to be sent to another system is described by RFCs 821
and 974. The program that is going to be doing the sending asks the name
server several queries to determine where to route the message. The first
query is to find out which machines handle mail for the name FTS.PHRACK.EDU.
In this case, the server replies that FTS.PHRACK.EDU handles its own mail. The
program then asks for the address of FTS.PHRACK.EDU, which for the sake of this
example is is 269.517.724.5. Then the the mail program opens a TCP connection
to port 25 on 269.517.724.5. Port 25 is the well-known socket used for
receiving mail. Once this connection is established, the mail program starts
sending commands. Here is a typical conversation. Each line is labelled as to
whether it is from FTS or MSP. Note that FTS initiated the connection:
MSP 220 MSP.PHRACK.EDU SMTP Service at 17 Nov 89 09:35:24 EDT
FTS HELO fts.phrack.edu
MSP 250 MSP.PHRACK.EDU - Hello, FTS.PHRACK.EDU
FTS MAIL From:
MSP 250 MAIL accepted
FTS RCPT To:
MSP 250 Recipient accepted
FTS DATA
MSP 354 Start mail input; end with .
FTS Date: Fri, 17 Nov 89 15:42:06 EDT
FTS From: knight@fts.phrack.edu
FTS To: taran@msp.phrack.edu
FTS Subject: Anniversary
FTS
FTS Four years is quite a long time to be around. Happy Anniversary!
FTS .
MSP 250 OK
FTS QUIT
MSP 221 MSP.PHRACK.EDU Service closing transmission channel
The commands all use normal text. This is typical of the Internet standards.
Many of the protocols use standard ASCII commands. This makes it easy to watch
what is going on and to diagnose problems. The mail program keeps a log of
each conversation so if something goes wrong, the log file can simply be mailed
to the postmaster. Since it is normal text, he can see what was going on. It
also allows a human to interact directly with the mail server, for testing.
The responses all begin with numbers. This is also typical of Internet
protocols. The allowable responses are defined in the protocol. The numbers
allow the user program to respond unambiguously. The rest of the response is
text, which is normally for use by any human who may be watching or looking at
a log. It has no effect on the operation of the programs. The commands
themselves simply allow the mail program on one end to tell the mail server the
information it needs to know in order to deliver the message. In this case,
the mail server could get the information by looking at the message itself.
Every session must begin with a HELO, which gives the name of the system that
initiated the connection. Then the sender and recipients are specified. There
can be more than one RCPT command, if there are several recipients. Finally
the data itself is sent. Note that the text of the message is terminated by a
line containing just a period, but if such a line appears in the message, the
period is doubled. After the message is accepted, the sender can send another
message, or terminate the session as in the example above.
Generally, there is a pattern to the response numbers. The protocol defines
the specific set of responses that can be sent as answers to any given command.
However programs that don't want to analyze them in detail can just look at the
first digit. In general, responses that begin with a 2 indicate success.
Those that begin with 3 indicate that some further action is needed, as shown
above. 4 and 5 indicate errors. 4 is a "temporary" error, such as a disk
filling. The message should be saved, and tried again later. 5 is a permanent
error, such as a non-existent recipient. The message should be returned to the
sender with an error message.
For more details about the protocols mentioned in this section, see RFCs
821/822 for mail, RFC 959 for file transfer, and RFCs 854/855 for remote
logins. For the well-known port numbers, see the current edition of Assigned
Numbers, and possibly RFC 814.
Protocols Other Than TCP: UDP and ICMP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thus far only connections that use TCP have been described. Remember that TCP
is responsible for breaking up messages into datagrams, and reassembling them
properly. However in many applications, there are messages that will always
fit in a single datagram. An example is name lookup. When a user attempts to
make a connection to another system, he will generally specify the system by
name, rather than Internet address. His system has to translate that name to
an address before it can do anything. Generally, only a few systems have the
database used to translate names to addresses. So the user's system will want
to send a query to one of the systems that has the database.
This query is going to be very short. It will certainly fit in one datagram.
So will the answer. Thus it seems silly to use TCP. Of course TCP does more
than just break things up into datagrams. It also makes sure that the data
arrives, resending datagrams where necessary. But for a question that fits in
a single datagram, all of the complexity of TCP is not needed. If there is not
an answer after a few seconds, you can just ask again. For applications like
this, there are alternatives to TCP.
The most common alternative is UDP ("user datagram protocol"). UDP is designed
for applications where you don't need to put sequences of datagrams together.
It fits into the system much like TCP. There is a UDP header. The network
software puts the UDP header on the front of your data, just as it would put a
TCP header on the front of your data. Then UDP sends the data to IP, which
adds the IP header, putting UDP's protocol number in the protocol field instead
of TCP's protocol number.
UDP doesn't do as much as TCP does. It does not split data into multiple
datagrams and it does not keep track of what it has sent so it can resend if
necessary. About all that UDP provides is port numbers so that several
programs can use UDP at once. UDP port numbers are used just like TCP port
numbers. There are well-known port numbers for servers that use UDP.
The UDP header is shorter than a TCP header. It still has source and
destination port numbers, and a checksum, but that's about it. UDP is used by
the protocols that handle name lookups (see IEN 116, RFC 882, and RFC 883) and
a number of similar protocols.
Another alternative protocol is ICMP ("Internet control message protocol").
ICMP is used for error messages, and other messages intended for the TCP/IP
software itself, rather than any particular user program. For example, if you
attempt to connect to a host, your system may get back an ICMP message saying
"host unreachable." ICMP can also be used to find out some information about
the network. See RFC 792 for details of ICMP.
ICMP is similar to UDP, in that it handles messages that fit in one datagram.
However it is even simpler than UDP. It does not even have port numbers in its
header. Since all ICMP messages are interpreted by the network software
itself, no port numbers are needed to say where an ICMP message is supposed to
go.
Keeping Track Of Names And Information: The Domain System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As we indicated earlier, the network software generally needs a 32-bit Internet
address in order to open a connection or send a datagram. However users prefer
to deal with computer names rather than numbers. Thus there is a database that
allows the software to look up a name and find the corresponding number.
When the Internet was small, this was easy. Each system would have a file that
listed all of the other systems, giving both their name and number. There are
now too many computers for this approach to be practical. Thus these files
have been replaced by a set of name servers that keep track of host names and
the corresponding Internet addresses. (In fact these servers are somewhat more
general than that. This is just one kind of information stored in the domain
system.) A set of interlocking servers are used rather than a single central
one.
There are now so many different institutions connected to the Internet that it
would be impractical for them to notify a central authority whenever they
installed or moved a computer. Thus naming authority is delegated to
individual institutions. The name servers form a tree, corresponding to
institutional structure. The names themselves follow a similar structure. A
typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the
Laboratory for Computer Science (LCS) at MIT. In order to find its Internet
address, you might potentially have to consult 4 different servers.
First, you would ask a central server (called the root) where the EDU server
is. EDU is a server that keeps track of educational institutions. The root
server would give you the names and Internet addresses of several servers for
EDU. You would then ask EDU where the server for MIT is. It would give you
names and Internet addresses of several servers for MIT. Then you would ask
MIT where the server for LCS is, and finally you would ask one of the LCS
servers about BORAX. The final result would be the Internet address for
BORAX.LCS.MIT.EDU. Each of these levels is referred to as a "domain." The
entire name, BORAX.LCS.MIT.EDU, is called a "domain name." (So are the names
of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.)
Fortunately, you don't really have to go through all of this most of the time.
First of all, the root name servers also happen to be the name servers for the
top-level domains such as EDU. Thus a single query to a root server will get
you to MIT. Second, software generally remembers answers that it got before.
So once we look up a name at LCS.MIT.EDU, our software remembers where to find
servers for LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation
of BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live"
associated with it. Typically this is a few days. After that, the information
expires and has to be looked up again. This allows institutions to change
things.
The domain system is not limited to finding out Internet addresses. Each
domain name is a node in a database. The node can have records that define a
number of different properties. Examples are Internet address, computer type,
and a list of services provided by a computer. A program can ask for a
specific piece of information, or all information about a given name. It is
possible for a node in the database to be marked as an "alias" (or nickname)
for another node. It is also possible to use the domain system to store
information about users, mailing lists, or other objects.
There is an Internet standard defining the operation of these databases as well
as the protocols used to make queries of them. Every network utility has to be
able to make such queries since this is now the official way to evaluate host
names. Generally utilities will talk to a server on their own system. This
server will take care of contacting the other servers for them. This keeps
down the amount of code that has to be in each application program.
The domain system is particularly important for handling computer mail. There
are entry types to define what computer handles mail for a given name to
specify where an individual is to receive mail and to define mailing lists.
See RFCs 882, 883, and 973 for specifications of the domain system. RFC 974
defines the use of the domain system in sending mail.
Routing
~~~~~~~
The task of finding how to get a datagram to its destination is referred to as
"routing." Many of the details depend upon the particular implementation.
However some general things can be said.
It is necessary to understand the model on which IP is based. IP assumes that
a system is attached to some local network. It is assumed that the system can
send datagrams to any other system on its own network. (In the case of
Ethernet, it simply finds the Ethernet address of the destination system, and
puts the datagram out on the Ethernet.) The problem comes when a system is
asked to send a datagram to a system on a different network. This problem is
handled by gateways.
A gateway is a system that connects a network with one or more other networks.
Gateways are often normal computers that happen to have more than one network
interface. The software on a machine must be set up so that it will forward
datagrams from one network to the other. That is, if a machine on network
128.6.4 sends a datagram to the gateway, and the datagram is addressed to a
machine on network 128.6.3, the gateway will forward the datagram to the
destination. Major communications centers often have gateways that connect a
number of different networks.
Routing in IP is based entirely upon the network number of the destination
address. Each computer has a table of network numbers. For each network
number, a gateway is listed. This is the gateway to be used to get to that
network. The gateway does not have to connect directly to the network, it just
has to be the best place to go to get there.
When a computer wants to send a datagram, it first checks to see if the
destination address is on the system's own local network. If so, the datagram
can be sent directly. Otherwise, the system expects to find an entry for the
network that the destination address is on. The datagram is sent to the
gateway listed in that entry. This table can get quite big. For example, the
Internet now includes several hundred individual networks. Thus various
strategies have been developed to reduce the size of the routing table. One
strategy is to depend upon "default routes." There is often only one gateway
out of a network.
This gateway might connect a local Ethernet to a campus-wide backbone network.
In that case, it is not neccessary to have a separate entry for every network
in the world. That gateway is simply defined as a "default." When no specific
route is found for a datagram, the datagram is sent to the default gateway. A
default gateway can even be used when there are several gateways on a network.
There are provisions for gateways to send a message saying "I'm not the best
gateway -- use this one instead." (The message is sent via ICMP. See RFC
792.) Most network software is designed to use these messages to add entries
to their routing tables. Suppose network 128.6.4 has two gateways, 128.6.4.59
and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgers networks.
128.6.4.1 leads indirectly to the NSFnet. Suppose 128.6.4.59 is set as a
default gateway, and there are no other routing table entries. Now what
happens when you need to send a datagram to MIT? MIT is network 18. Since
there is no entry for network 18, the datagram will be sent to the default,
128.6.4.59. This gateway is the wrong one. So it will forward the datagram to
128.6.4.1. It will also send back an error saying in effect: "to get to
network 18, use 128.6.4.1." The software will then add an entry to the routing
table. Any future datagrams to MIT will then go directly to 128.6.4.1. (The
error message is sent using the ICMP protocol. The message type is called
"ICMP redirect.")
Most IP experts recommend that individual computers should not try to keep
track of the entire network. Instead, they should start with default gateways
and let the gateways tell them the routes as just described. However this
doesn't say how the gateways should find out about the routes. The gateways
can't depend upon this strategy. They have to have fairly complete routing
tables. For this, some sort of routing protocol is needed. A routing protocol
is simply a technique for the gateways to find each other and keep up to date
about the best way to get to every network. RFC 1009 contains a review of
gateway design and routing.
Details About Internet Addresses: Subnets And Broadcasting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Internet addresses are 32-bit numbers, normally written as 4 octets (in
decimal), e.g. 128.6.4.7. There are actually 3 different types of address.
The problem is that the address has to indicate both the network and the host
within the network. It was felt that eventually there would be lots of
networks. Many of them would be small, but probably 24 bits would be needed to
represent all the IP networks. It was also felt that some very big networks
might need 24 bits to represent all of their hosts. This would seem to lead to
48 bit addresses. But the designers really wanted to use 32 bit addresses. So
they adopted a kludge. The assumption is that most of the networks will be
small. So they set up three different ranges of address.
Addresses beginning with 1 to 126 use only the first octet for the network
number. The other three octets are available for the host number. Thus 24
bits are available for hosts. These numbers are used for large networks, but
there can only be 126 of these. The ARPAnet is one and there are a few large
commercial networks. But few normal organizations get one of these "class A"
addresses.
For normal large organizations, "class B" addresses are used. Class B
addresses use the first two octets for the network number. Thus network
numbers are 128.1 through 191.254. (0 and 255 are avoided for reasons to be
explained below. Addresses beginning with 127 are also avoided because they
are used by some systems for special purposes.) The last two octets are
available for host addesses, giving 16 bits of host address. This allows for
64516 computers, which should be enough for most organizations. Finally, class
C addresses use three octets in the range 192.1.1 to 223.254.254. These allow
only 254 hosts on each network, but there can be lots of these networks.
Addresses above 223 are reserved for future use as class D and E (which are
currently not defined).
0 and 255 have special meanings. 0 is reserved for machines that do not know
their address. In certain circumstances it is possible for a machine not to
know the number of the network it is on, or even its own host address. For
example, 0.0.0.23 would be a machine that knew it was host number 23, but
didn't know on what network.
255 is used for "broadcast." A broadcast is a message that you want every
system on the network to see. Broadcasts are used in some situations where you
don't know who to talk to. For example, suppose you need to look up a host
name and get its Internet address. Sometimes you don't know the address of the
nearest name server. In that case, you might send the request as a broadcast.
There are also cases where a number of systems are interested in information.
It is then less expensive to send a single broadcast than to send datagrams
individually to each host that is interested in the information. In order to
send a broadcast, you use an address that is made by using your network
address, with all ones in the part of the address where the host number goes.
For example, if you are on network 128.6.4, you would use 128.6.4.255 for
broadcasts. How this is actually implemented depends upon the medium. It is
not possible to send broadcasts on the ARPAnet, or on point to point lines, but
it is possible on an Ethernet. If you use an Ethernet address with all its
bits on (all ones), every machine on the Ethernet is supposed to look at that
datagram.
Because 0 and 255 are used for unknown and broadcast addresses, normal hosts
should never be given addresses containing 0 or 255. Addresses should never
begin with 0, 127, or any number above 223.
Datagram Fragmentation And Reassembly
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TCP/IP is designed for use with many different kinds of networks.
Unfortunately, network designers do not agree about how big packets can be.
Ethernet packets can be 1500 octets long. ARPAnet packets have a maximum of
around 1000 octets. Some very fast networks have much larger packet sizes.
You might think that IP should simply settle on the smallest possible size, but
this would cause serious performance problems. When transferring large files,
big packets are far more efficient than small ones. So it is best to be able
to use the largest packet size possible, but it is also necessary to be able to
handle networks with small limits. There are two provisions for this.
TCP has the ability to "negotiate" about datagram size. When a TCP connection
first opens, both ends can send the maximum datagram size they can handle. The
smaller of these numbers is used for the rest of the connection. This allows
two implementations that can handle big datagrams to use them, but also lets
them talk to implementations that cannot handle them. This does not completely
solve the problem. The most serious problem is that the two ends do not
necessarily know about all of the steps in between. For this reason, there are
provisions to split datagrams up into pieces. This is referred to as
"fragmentation."
The IP header contains fields indicating that a datagram has been split and
enough information to let the pieces be put back together. If a gateway
connects an Ethernet to the Arpanet, it must be prepared to take 1500-octet
Ethernet packets and split them into pieces that will fit on the Arpanet.
Furthermore, every host implementation of TCP/IP must be prepared to accept
pieces and put them back together. This is referred to as "reassembly."
TCP/IP implementations differ in the approach they take to deciding on datagram
size. It is fairly common for implementations to use 576-byte datagrams
whenever they can't verify that the entire path is able to handle larger
packets. This rather conservative strategy is used because of the number of
implementations with bugs in the code to reassemble fragments. Implementors
often try to avoid ever having fragmentation occur. Different implementors
take different approaches to deciding when it is safe to use large datagrams.
Some use them only for the local network. Others will use them for any network
on the same campus. 576 bytes is a "safe" size which every implementation must
support.
Ethernet Encapsulation: ARP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In Part One of Introduction to the Internet Protocols (Phrack Inc., Volume
Three, Issue 28, File #3 of 12) there was a brief description about what IP
datagrams look like on an Ethernet. The discription showed the Ethernet header
and checksum, but it left one hole: It did not say how to figure out what
Ethernet address to use when you want to talk to a given Internet address.
There is a separate protocol for this called ARP ("address resolution
protocol") and it is not an IP protocal as ARP datagrams do not have IP
headers.
Suppose you are on system 128.6.4.194 and you want to connect to system
128.6.4.7. Your system will first verify that 128.6.4.7 is on the same
network, so it can talk directly via Ethernet. Then it will look up 128.6.4.7
in its ARP table to see if it already knows the Ethernet address. If so, it
will stick on an Ethernet header and send the packet. Now suppose this system
is not in the ARP table. There is no way to send the packet because you need
the Ethernet address. So it uses the ARP protocol to send an ARP request.
Essentially an ARP request says "I need the Ethernet address for 128.6.4.7".
Every system listens to ARP requests. When a system sees an ARP request for
itself, it is required to respond. So 128.6.4.7 will see the request and will
respond with an ARP reply saying in effect "128.6.4.7 is 8:0:20:1:56:34". Your
system will save this information in its ARP table so future packets will go
directly.
ARP requests must be sent as "broadcasts." There is no way that an ARP request
can be sent directly to the right system because the whole reason for sending
an ARP request is that you do not know the Ethernet address. So an Ethernet
address of all ones is used, i.e. ff:ff:ff:ff:ff:ff. By convention, every
machine on the Ethernet is required to pay attention to packets with this as an
address. So every system sees every ARP requests. They all look to see
whether the request is for their own address. If so, they respond. If not,
they could just ignore it, although some hosts will use ARP requests to update
their knowledge about other hosts on the network, even if the request is not
for them. Packets whose IP address indicates broadcast (e.g. 255.255.255.255
or 128.6.4.255) are also sent with an Ethernet address that is all ones.
Getting More Information
~~~~~~~~~~~~~~~~~~~~~~~~
This directory contains documents describing the major protocols. There are
hundreds of documents, so I have chosen the ones that seem most important.
Internet standards are called RFCs (Request for Comments). A proposed standard
is initially issued as a proposal, and given an RFC number. When it is finally
accepted, it is added to Official Internet Protocols, but it is still referred
to by the RFC number. I have also included two IENs (Internet Engineering
Notes). IENs used to be a separate classification for more informal
documents, but this classification no longer exists and RFCs are now used for
all official Internet documents with a mailing list being used for more
informal reports.
The convention is that whenever an RFC is revised, the revised version gets a
new number. This is fine for most purposes, but it causes problems with two
documents: Assigned Numbers and Official Internet Protocols. These documents
are being revised all the time and the RFC number keeps changing. You will
have to look in rfc-index.txt to find the number of the latest edition. Anyone
who is seriously interested in TCP/IP should read the RFC describing IP (791).
RFC 1009 is also useful as it is a specification for gateways to be used by
NSFnet and it contains an overview of a lot of the TCP/IP technology.
Here is a list of the documents you might want:
rfc-index List of all RFCs
rfc1012 Somewhat fuller list of all RFCs
rfc1011 Official Protocols. It's useful to scan this to see what tasks
protocols have been built for. This defines which RFCs are
actual standards, as opposed to requests for comments.
rfc1010 Assigned Numbers. If you are working with TCP/IP, you will
probably want a hardcopy of this as a reference. It lists all
the offically defined well-known ports and lots of other
things.
rfc1009 NSFnet gateway specifications. A good overview of IP routing
and gateway technology.
rfc1001/2 NetBIOS: Networking for PCs
rfc973 Update on domains
rfc959 FTP (file transfer)
rfc950 Subnets
rfc937 POP2: Protocol for reading mail on PCs
rfc894 How IP is to be put on Ethernet, see also rfc825
rfc882/3 Domains (the database used to go from host names to Internet
address and back -- also used to handle UUCP these days). See
also rfc973
rfc854/5 Telnet - Protocol for remote logins
rfc826 ARP - Protocol for finding out Ethernet addresses
rfc821/2 Mail
rfc814 Names and ports - General concepts behind well-known ports
rfc793 TCP
rfc792 ICMP
rfc791 IP
rfc768 UDP
rip.doc Details of the most commonly-used routing protocol
ien-116 Old name server (still needed by several kinds of systems)
ien-48 The Catenet model, general description of the philosophy behind
TCP/IP
The following documents are somewhat more specialized.
rfc813 Window and acknowledgement strategies in TCP
rfc815 Datagram reassembly techniques
rfc816 Fault isolation and resolution techniques
rfc817 Modularity and efficiency in implementation
rfc879 The maximum segment size option in TCP
rfc896 Congestion control
rfc827,888,904,975,985 EGP and related issues
The most important RFCs have been collected into a three-volume set, the DDN
Protocol Handbook. It is available from the DDN Network Information Center at
SRI International. You should be able to get them via anonymous FTP from
SRI-NIC.ARPA. The file names are:
RFCs:
rfc:rfc-index.txt
rfc:rfcxxx.txt
IENs:
ien:ien-index.txt
ien:ien-xxx.txt
Sites with access to UUCP, but not FTP may be able to retreive them via
UUCP from UUCP host rutgers. The file names would be
RFCs:
/topaz/pub/pub/tcp-ip-docs/rfc-index.txt
/topaz/pub/pub/tcp-ip-docs/rfcxxx.txt
IENs:
/topaz/pub/pub/tcp-ip-docs/ien-index.txt
/topaz/pub/pub/tcp-ip-docs/ien-xxx.txt
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #4 of 12
Network Miscellany II
~~~~~~~~~~~~~~~~~~~~~
by Taran King
November 17, 1989
BROADCASTING NETWORKS
~~~~~~~~~~~~~~~~~~~~~
Although these articles discuss things about communicating through computer
networks, there are ways to contact broadcasting networks via the nets. The
Public Broadcasting Service (PBS) has their own UUCP node:
Public Broadcasting Service (PBS)
UUCP Node name: pbs
Node contact: pbs!postmaster (Senton R. Droppers)
Telephone number: (703) 739-5089
There are also a number of radio stations that can be contacted via Fidonet:
KFCF
Fresno, CA
Contact: Randy.Stover@f42.n205.z1.fidonet.org
KKSF
San Fransisco, CA
Contact: Tim.Pozar@fidogate.fidonet.org
KKDA
Dallas, TX
Contact: Gerry.Dalton@f1213.n124.z1.fidonet.org
ECNCDC (BITNET)
~~~~~~~~~~~~~~~
Western Illinois University, Eastern Illinois University as well as the
University of Northeastern Illinois, Chicago State University and Governors
State University are part of the Educational Computing Network. The
Educational Computing Network is a service of the Board of Governors of State
Colleges and Universities operating as a cooperative to supply mainframe
academic computing resources to each of its members (ECN is strictly for
academic use and does no administrative computing). The cooperative effort of
the members of the Educational Computing Network allows for more academic
computing resources to be made available to the members than they could supply
on their own.
Each member institution of the Educational Computing Network has a unique
letter for the first letter in all their user names. The letters are:
Chicago State University - B
Eastern Illinois University - C
Governors State University - G
Western Illinois University - M
University of Northeastern Illinois - U
Each member of ECN also has a person which is the interface between ECN and the
university called their User Coordinator. The User Coordinator's username
consists of their school letter followed by UCM000 (the User Coordinator for
WIU is MUCM000).
For more information about the Educational Computing Network, contact
XJJGUDE@ECNCDC.BITNET
MCI MAIL
~~~~~~~~
If you read the first Network Miscellany article which appeared in Phrack 28,
you may remember my mentioning CMR, the Commercial Mail Relay. Unfortunately,
due to its restrictions about who can use it (supposedly), it has potential to
become a sticky situation if the user you are sending to no longer has his MCI
Mail account or if you accidentally mistype the MCI Mail address. But to save
us from this potential problem, MCI Mail now has their own domain on the
Internet, MCIMAIL.COM so mailing to userid@MCIMAIL.COM should work just as well
as CMR without the risks of being yelled at (and possibly billed).
PUBLIC ACCESS UNIXES
~~~~~~~~~~~~~~~~~~~~
Part of the problem with the whole idea of using the Wide Area Networks is
access. For those who are not enrolled in a university or cannot pull strings
at their local business or college, the concept of communicating through the
networks is useless besides thinking that it would be neat. Thanks to Phil
Eschallier, phil@lgnp1.UUCP or phil@LS.COM, you should now be able to get
access to the Wide Area Networks via UUCP. The following is a list of Public
Access Unix systems taken from the Usenet Newsgroup pub.nixpub which Phil keeps
up and there are two versions, both of which contain the same basic information
but each has important information which the other does not necessarily have.
I urge you to attempt to get on one of these systems and drop us a line over
the networks.
nixpub long listing
Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only
[ November 12, 1989 ]
Systems listed (73):
[ agora, alphacm, althea, amazing, anet, attctc, bigtex, bucket, chariot ]
[ chinet, cinnet, conexch, cpro, cruzio, dasys1, ddsw1, dhw68k, disk ]
[ eklektik, esfenn, gensis, grebyn, i-core, igloo, jdyx, jolnet, lgnp1 ]
[ lilink, loft386, lunapark, m-net, madnix, magpie, marob, ncoast, netcom ]
[ nstar, nuchat, nucleus, oncoast, ozdaltx, pallas, pnet01, pnet02 ]
[ pnet51, point, polari, portal, raider, rpp386, rtmvax, sactoh0, sharks ]
[ sir-alan, sixhub, stanton, stb, sugar, telly, tmsoft, tnl, turnkey ]
[ ubbs-nh, usource, uuwest, vpnet, well, wet, wolves, world, wybbs ]
[ xroads, ziebmef ]
Last
Contact
Date Telephone # Sys-name Location Baud Hours
----- ------------ -------- ----------- ------- -----
08/89 201-846-2460^ althea New Brunswick NJ 3/12/24 24
AT&T 3B2/310 - Unix SVR3.1, no fee. USENET, email, C development,
games. Single line.
Contact: rjd@althea.UUCP (Robert Diamond)
10/89 206-328-4944 polari Seatle WA 3/12 24
Equip ???; 8-lines, Trailblazer on 206-328-1468; $30/year (flat rate);
Multi-user games, chat, full USENET.
Contact: uunet!microsoft!happym!polari!bruceki
10/89 212-420-0527 magpie NYC NY 3/12/24/96 24
? - UNIX SYSV - 2, Magpie BBS, no fee, Authors: Magpie/UNIX,/MSDOS
two lines plus anonymous uucp: 212-677-9487 (9600 bps Telebit modem)
NOTE: 9487 reserved for registered Magpie sysops & anon uucp
Contact: Steve Manes, {rutgers|cmcl2|uunet}!hombre!magpie!manes
10/89 212-675-7059 marob NYC NY 3/12/24 24
386 SCO-XENIX 2.2, XBBS, magpie bbs, no fee, limit 60 min
Telebit Trailblazer (9600 PEP) only 212-675-8438
Contact: {philabs|rutgers|cmcl2}!{phri|hombre}!marob!clifford
05/89 212-879-9031^ dasys1 NYC NY 12/24 24
Unistride - SYS V, multiple lines, fee $5/mo AKA Big Electric Cat
USENET, games, multi-user chat, email, login: new, passwd: new
Contact: ...!rutgers!cmcl2!rsweeney or rsweeney@dasys1.UUCP
09/89 213-376-5714^ pnet02 Redondo Bch CA 3/12/24 24
XENIX (also 213-374-7404) no fee, 90 min limit, login: pnet id: new
some USENET, net-work e-mail, multi-threaded conferencing
09/89 213-397-3137^ stb Santa Monica CA 3/12/24 24
AT&T 3b1; BBS and shell access; uucp-anon: ogin: uucp NO PASSWD
3 line on rotory -3137 2400 baud.
03/88 213-459-5891 amazing Pacific Palisades CA 3/12/24 24
AMT 286 - Microport David's Amazing BBS Fee $7.50/month;$35/6;$60/year
5 lines on rotary; Unique original software with conferencing, electronic
bar, matchmaking, no file up/downloading
07/88 214-247-2367 ozdaltx Dallas TX 3/12/24 24
INTEC/SCO XENIX 2.2.1, OZ BBS, Membership only adult BBS, fee $40
year. Multiple lines. Closed system, carries limited USENET
newsgroups. Login: guest (no PW). Voice verification on all new users.
07/89 214-824-7881 attctc Dallas TX 3/12/24 24
3b2/522 - UNIX, no fee, various time limits, 8 lines 2.8 GB online
uucp-anon --> 214-741-2130 ogin: uupdsrc word: Public
uucp-anon info in: /bbsys4/README (Formerly node name killer)
11/89 215-348-9727 lgnp1 Doylestown PA 3/12/24/96 24
SCO-XENIX -- Telebit access. Shell accounts by appointment only; Fee;
Services include E-mail, USENET News; --Home of the Nixpub lists--
Contact: phil@ls.com.
anon-uucp: nuucp NO PWD (download /usr/spool/uucppublic/nixpub
or /usr/spool/uucppublic/nixpub.short)
09/89 216-582-2441 ncoast Cleveland OH 12/24/96 24
80386 Mylex, SCO Xenix; 600 meg. storage; XBBS and Shell; USENET
(newsfeeds available), E-Mail; donations requested; login as "bbs"
for BBS and "makeuser" for new users.
Telebit used on 216-237-5486.
08/88 217-529-3223 pallas Springfield IL 3/12/24 24
Convrgnt Minifrme, multiple lines, 200 meg Minnie bbs $25 donation
10/89 219-289-0286 nstar South Bend IN 3/12/24/96 24
Equip ???, UNIX 3.2; 300 Meg On-line; 4 lines at 9600 baud --
(listed) - Hayes V-Series, (287-9020) - HST, (289-3745) - PEP;
Full USENET, AKCS Software; Contact ..!iuvax!ndcheg!ndmath!nstar!larry
08/88 312-283-0559^ chinet Chicago IL 3/12/24 24
3b2/300 - SYS V 3.1, multiple lines, Picospan BBS, system & BBS free
Extra phone lines and usenet, $50/yr.
10/89 312-338-0632^ point Chicago IL 3/12/24/96 24
North Shore / Rogers Park area of Chicago. 386 - ISC 2.01 (SysV3.2),
multiple lines, Telebit PEP on 338-3261, USRobotics HST on 338-1036,
AKCS bbs, some usenet conferences available. 200+ MB online storage.
Downloads, full usenet & shell access in the works.
04/89 313-623-6309 nucleus Clarkston MI 12/24 24
286 - Unix System V, no fee. Shell access, full usenet access, online games,
AKCS conferencing system, some public domain sources online, extensive tape
library of public domain source code
02/88 313-994-6333 m-net Ann Arbor MI 3/12 24
Altos 68020 - SYS III, limits unstated, fee for extended service
Picospan conference system, multiple lines, 160 meg, packet radio
08/89 313-996-4644^ anet Ann Arbor MI 3/12 24
Altos 68000 - Sys III, no limits, 1st month free, fees range up to $20/
month (negotiable), accepts equipment/software in lieu of fees, Picospan
conferencing, 120M, non-profit, user-supported, community-based, ideal
autodidact educational system. Tax-deductible donations okay.
08/89 314-474-4581 gensis Columbia MO 3/12/24/48/96 24
Gateway 386 system w/ SCO Xenix V/386, DataFlex, Oracle, CHARM, & VP/ix.
No fee. Online gaming, game design, and (oddly enough) data base design
are the main focus. Modem is Microcom MNP 6.
10/89 404-321-5020^ jdyx Atlanta GA 12/24/96 24
386/ix 2.0.2. XBBS. Usenet (alt, gnu, most comp and a few others) and
shell access. Second line (2400 below) (404) 325-1719. 200+ meg current
Usenet and GNU sources. Specializing in graphics and ray-tracing under
386/ix (with/with out X11). Yearly fee for shell and/or downloads.
Telebit access. Contact: ...gatech!emory!jdyx!tpf (Tom Friedel)
05/88 407-380-6228 rtmvax Orlando FL 3/12/24 24
mVAX-I - Ultrix-32 V1.2 USENET & UUCP Email Gateway. XBBS front end for
new user subscribing. No Fees. Primary function is Technical exchange.
Contact: { cbosgd!codas, hoptoad!peora }!rtmvax!rob
09/89 408-245-7726^ uuwest Sunnyvale CA 3/12/24 24
SCO-XENIX, Waffle. No fee, USENET news (news.*, music, comics, telecom, etc)
The Dark Side of the Moon BBS. This system has been in operation since 1985.
Login: new Contact: (UUCP) ames!uuwest!request (Domain) request@darkside.com
04/88 408-247-4810 sharks Santa Clara CA 3/12 24
Altos 886/80/80 - XENIX 3.2f AKA: Shark's Head BBS, BBCS Network
Multiple lines,no fee for non-members,members $25 year
Restricted sh access and UUCP/Usenet access for advanced members
11/89 408-423-9995 cruzio Santa Cruz CA 12/24 24
Tandy 4000, Xenix 2.3.*, Caucus 3.*; focus on Santa Cruz activity
(ie directory of community and goverment organizations, events, ...);
Multiple lines; no shell; fee: $18/quarter.
Contact: ...!uunet!cruzio!chris
10/89 408-725-0561^ portal Cupertino CA 3/12/24 24
Networked Suns (SunOS), multiple lines, Telenet access, no shell access
fees: $10/month + Telenet charges (if used) @ various rates/times
conferencing, multi user chats, usenet
02/89 408-997-9119^ netcom San Jose CA 3/12/24/96 24
Unix System V -- Shell Access [Bourne, Korn, C-Shell], BBS, USENET,
Languages: C, Lisp, Prolog, Clips, (Ada soon), $10 / month, login as
'guest' no password. Contact netcom!bobr.
10/89 412-431-8649 eklektik Pittsburgh PA 3/12/24 24
UNIX PC- SYSV - UNaXcess BBS, new system - donation requested for shell,
login: bbs for BBS, uucp-mail, limited Usenet news feeds. Gaming SIGS.
Contact: ...!gatech!emoryu1!eklektik!anthony
11/89 415-332-6106^ well Sausalito CA 12/24 24
6-processor Sequent Balance (32032); UUCP and USENET access; multiple
lines; access via CPN; PICOSPAN BBS; $3/hour. Contact (415) 332-4335
06/88 415-582-7691 cpro Hayward CA 12/24 24
Microport SYSV 2, UNaXcess bbs, no fee, 60 min limit, shell access
07/89 415-753-5265^ wet San Francisco CA 3/12/24 24
386 SYS V.3. Wetware Diversions. $15 registration, $0.01/minute.
Public Access UNIX System: uucp, PicoSpan bbs, full Usenet News,
multiple lines, shell access. Newusers get initial credit!
contact:{ucsfcca|claris|hoptoad}!wet!cc (Christopher Cilley)
05/89 415-783-2543 esfenn Hayward CA 3/12/24 24
System ????; USENET news; E-mail; No charges; Contact esfenn!william.
01/89 416-452-0926 telly Brampton ON 12/24/96 24
286 Xenix; proprietary menu-based BBS includes Usenet site searching.
News (all groups, incl biz, pubnet, gnu), mail (including to/from Internet),
some archives. Feeds available. Fee: $75(Cdn)/year.
Contact: Evan Leibovitch, evan@telly.on.ca, {uunet!attcan,utzoo}!telly!evan
12/88 416-461-2608 tmsoft Toronto ON 3/12/24/96 24
NS32016, Sys5r2, shell; news+mail $30/mo, general-timesharing $60/mo
All newsgroups. Willing to setup mail/news connections.
Archives:comp.sources.{unix,games,x,misc}
Contact: Dave Mason / Login: newuser
07/89 416-654-8854 ziebmef Toronto ON 3/12/24/96 24
AT&T 3B1, Sys V, shell, news, mail, no fee (donations accepted)
Carries most newsgroups (willing to add extra ones on request)
Telebit access, willing to give mail feeds
Contact: Chris Siebenmann, {utzoo!telly,ncrcan}!ziebmef!cks
08/89 502-968-5401 disk Louisville KY 3/12 24
386 clone, Microport System V, 600 meg. 6 lines 5401 thru 5406.
rarrying most USENET groups, Shell access, games, downloads,
multi-user chat, and more. Rate info available via a free trial
account.
12/88 503-254-0458 bucket Portland OR 3/12/24 24
Tektronix 6130, UTek 2.3(4.2BSD-derived). Bit Bucket BBS publically
available; login as 'bbs'. BBS is message only. Users intereseted in
access to Unix should contact SYSOP via the BBS or send EMail to
..tektronix!tessi!bucket!rickb. Unix services include USENET News,
EMail, and all tools/games/utility access. Alternate dial-in lines
available for Unix users.
05/89 503-640-4262^ agora PDX OR 3/12/24 24
Intel Xenix-286, $2/mo or $20/yr, news, mail, games, programming
two lines with trunk-hunt, 4380 supports MNP level 3.
Contact: Alan Batie, tektronix!tessi!agora!batie
10/89 512-346-2339 bigtex Austin TX 96 24
Equip unknown, no shell, no fee, anonymous uucp ONLY, Telebit 9600/PEP
mail & newsfeeds (limited) available. Carries GNU software.
anon login: nuucp NO PASSWD, file list /usr3/index
Contact: ...!uunet!utastro!bigtex!james
07/89 512-832-8835 rpp386 Austin TX 12/24 24
386 SYSV, no shell, no bbs, anonymous uucp file transfer site only, no fee
uucp and kermit server available, login uucp or kermit NO PASSWD
10/89 513-779-8209 cinnet Cincinnati OH 12/24/96 24
80386, ISC 386/ix 2.02, Telebit access, 1 line; $7.50/Month; shell
access, Usenet access; news feeds available;
login: newact password: new user to register for shell access
05/89 516-872-2137 lilink Long Island NY 12/24 24
80386/20 Mhz. , three lines, News/Mail/Shell access. Online games,
conferencing, full program development system, full text processing.
We carry ALL Usenet groups. Dues are $10/month (unlimited access).
Accounts are filled by application/phone verification. Login: new
Alternate numbers: 516-872-2138 & 516-872-2349
07/89 517-487-3356 lunapark E. Lansing MI 12/24 24
Compaq 386/20 SCO-XENIX 2.3.1, lunabbs bulletin board & conferencing
system, no fee, login: bbs no password. Primarily UNIX software
with focus on TeX and Postscript, also some ATARI-ST and IBM-PC stuff
2400/1200 --> 8 N 1
Contact: ...!uunet!frith!lunapark!larry
12/88 518-346-8033 sixhub upstate NY 3/12/24 24
PC Designs GV386. hub machine of the upstate NY UNIX users group (*IX)
two line reserved for incoming, bbs no fee, news & email fee $15/year
Smorgasboard of BBS systems, UNaXcess and XBBS online,
Citadel BBS now in production. Contact: davidsen@sixhub.uucp.
09/88 602-941-2005 xroads Phoenix AZ 12/24 24
Motorola VME1121, UNIX 5.2, Crossroads BBS, Fee $30/yr + $.50/.25 (call)
prime (evenings)/non-prime, USENET news, multi-chat, online games,
movie reviews, adventure games, dos unix/xenix files for dload, multi lines
08/89 603-880-8120 ubbs-nh Nashua NH 3/12/24/96 24
New England Unix Archive Site. Multiple lines. Services include E-Mail,
full or partial news feeds. XBBS access $25/year, User Accounts or News
Feeds available $60/year (1 hour/day) or $120/year (2 hours/day).
Contact: noel@ubbs-nh or {decvax}!ubbs-nh!noel or leave message on the
bbs. Voice: 603 595-2947
08/89 605-348-2738 loft386 Rapid City SD 3/12/24/96 24
80386 SYS V/386 Rel 3.2, Usenet mail/news via UUNET, UUNET archive access.
NO BBS! News feeds avaliable. 400 meg hd. Fees: $10/month or $25/quarter.
Call (605) 343-8760 and talk to Doug Ingraham to arrange an account or email
uunet!loft386!dpi
08/88 608-273-2657 madnix Madison WI 3/12/24 24
286 SCO-XENIX, shell, no fee, USENET news, mail, login: newuser
Contact: ray@madnix
08/89 612-473-2295 pnet51 Minneapolis MN 3/12/24 24
Equip ?, Xenix, multi-line, no fee, some Usenet news, email, multi-threaded
conferencing, login: pnet id: new, PC Pursuitable
UUCP: {rosevax, crash}!orbit!pnet51!admin
08/89 615-896-8716 raider Murfreesboro TN 12/24 24
Tandy 4000 XENIX, XBBS, shell accounts, news and mail, newsfeeds
available. Two line system; second dialup is 615-896-7905.
Contact: root@raider.MFEE.TN.US (Bob Reineri); NO CHARGE.
07/89 616-457-1964 wybbs Jenison MI 3/12/24 24
286 - SCO-XENIX 2.2.1, no fees, two lines, shell access, usenet news,
150 meg storage, XBBS, interests: ham radio, xenix
AKA: Consultants Connection Contact: danielw@wybbs.UUCP
Alternate phone #: 616-457-9909 (max 1200 baud)
11/89 617-739-9753 world Brookline MA 3/12/24/96 24
Sun 4/280, SunOS 4.03; Shell, USENET, E-Mail, UUCP and home of the
Open Book Initiative (text project); fees: 8a-6p $8/hr, 6p-12a $5/hr,
12a-8a $2.50/hr; Multiple lines: 2400 MNP used on listed number,
Telebits used on others; login as "new"; Contact: geb@world.std.com
07/88 619-444-7006^ pnet01 El Cajon CA 3/12/24 24
BSD Unix, 3 lines, login: pnet id: new, some USENET, email, conferencing
Home of P-Net software, mail to crash!bblue or pnet01!bblue for info.
Contributions requested
Unix accounts available for regulars, PC Pursuit access 2/88.
10/88 703-281-7997^ grebyn Vienna VA 3/12/24/96 24
Vax/Ultrix. $25/month. GNU EMACS, USENET, PC/BLUE archives, Telebit on 7998
and 7999, archives, Ada repository, comp.sources.(misc,unix,games) archives,
net.sources archives, 3 C compilers, Ada compiler, 500MB disk, multiple
lines
11/89 708-272-5912^ igloo Northbrook IL 12/24/96 24
3B2-300; accounts by invitation only, no limit/no fee; full usenet;
132megs HD; 2 lines rotary, 9600 telebit on 272-5917
Contact: igloo!postmaster
11/89 708-301-2100^ jolnet Joliet IL 3/12/24 24
3b2/400 - Unix, public access and contributions, No fee for postnews.
5 lines AKCS bbs. Free Newsfeeds available. >450 MB online storage.
Free Shell and Usenet access. Telebit Trailblazer access (2104).
Telenet access.
11/89 708-566-8911^ ddsw1 Mundelein IL 3/12/24/96 24
Televideo 386 -SCO XENIX 386, guest usr 1 hr daily, fee extends use
AKCS bbs, fee $30/6 months $50/year, Authors of AKCS bbs
multiple lines, 9600 bps available, anonymous uucp, >/README for info
Contact: Karl Denninger (...!ddsw1!karl) Voice: (312) 566-8910
11/89 708-833-8126^ vpnet Villa Park IL 12/24/96 24
386 Clone - Interactive 386/ix R2.0 (3.2), no fee. Akcs linked bbs
including several Usenet conf's. No charge for shells. Trailblazer.
Mail lisbon@vpnet.UUCP
07/89 713-438-5018 sugar Houston TX 3/12/24/96 24
386/AT (2) networked - Bell Technologies V/386, usenet, news, downloads
Homegrown BBS software, Trailblazer+ access, currently no charges
10/89 713-668-7176^ nuchat Houston TX 3/12/24/96 24
i386; USENET, Mail, Shell Access; 300M On-line; Trailbazer Used;
No fee.
12/88 714-635-2863 dhw68k Anaheim CA 12/24 24
Unistride 2.1, no fee, also 714-385-1915, Trailblazer on both lines,
USENET News, /bin/sh or /bin/csh available
05/89 714-662-7450 turnkey Inglewood CA 12/24 24
286 - Xenix SYSV, XBBS
11/89 714-821-9671 alphacm Cypress CA 12/24/96 24
386 - SCO-XENIX, no fee, Home of XBBS, 90 minute per login, 4 lines,
9600 baud via MicroComm/Hayes (v.29)
uucp-anon: ogin: nuucp NO PASSWD
05/89 714-842-5851 conexch Santa Ana CA 3/12/24 24
386 - SCO Xenix - Free Unix guest login and PC-DOS bbs login, one
hour inital time limit, USENET news, shell access granted on request &
$25/quarter donation. Anon uucp: ogin: nuucp NO PASSWD. List of
available Unix files resides in /usr3/public/FILES.
08/88 714-894-2246 stanton Irvine CA 3/12/24 24
286 - SCO Xenix - donation requested, limit 240 min, XBBS, USENET news
UNIX access granted on request through BBS, 20$/year, access includes
C development system (XENIX/MSDOS), PROCALC 1-2-3 clone, FOXBASE+
anon uucp: ogin: nuucp, no word, 2400/1200/300 MNP supported
05/88 719-632-4111 chariot Colo Sprgs CO 3/12 24
Convrgnt Minifrme - SYS V, multiple lines, fee $12/mo Picospan
08/89 801-943-7947^ i-core Salt Lake City UT 3/12/24/96 24
286 SYS V, Unidel BBS, a.k.a. Bitsko's Bar & Grill, no limit, no fee,
UseNet and Citadel feeds available, home of Unidel BBS, Telebit 19200 used
Contact: ken@i-core.UUCP or uunet!iconsys!caeco!i-core!ken
12/88 802-865-3614 tnl Burlington VT 3/12/24 24
80386 w/ SCO XENIX. No Fee. 2 hr session limit. XBBS/USENET, shell.
Login as 'new' for a shell account, no validation. AKA: Northern Lights.
08/88 813-952-1981 usource Sarasota FL 12/24 -24
386 - SCO-XENIX, fee depends on services provided, no fee for bbs. New users
subscribe by logging in as 'help' or 'newuser' (no password). Primary
purpose is technical forum. 6pm-8am M-Th, 24 hrs weeekends (6pm Fri-8am Mon)
uucp-anon: 1200/2400 bps --> ogin: auucp word: gateway
uucp-anon directory: /usr/spool/uucppublic; contact: frank@usource.UUCP
08/88 814-333-6728 sir-alan Meadville PA 3/12/24 24
Tandy XENIX/68000 03.01.02, Allegheny College, UNaXcess BBS
uucp-anon: ogin: pdsrc NO PASSWD
uucp-anon directory: /usr/spool/pdsrc/all.subjects
Telebit TB+ available at 814 337 0894, now operating.
Contact: sir-alan!mikes
05/88 814-337-3159 oncoast Meadville PA 3/12/24/96 24
Tandy 12/6000, no fee, no bbs, archive site, USR HST 9600, cycle 24/96/12
vols 1 - 13 of mod.sources/comp.sources.unix, comp.sources.misc
New stuff on sir-alan, older on oncoast. 2 uucp logins "uucp" and "pdsrc"
files list = /usr/spool/uucppublic/my.directory or /usr/spool/pdsrc/
all.subjects.Z
09/89 916-649-0161 sactoh0 Sacramento CA 12/24/96 24
3B2/310 SYSV.2, SAC_UNIX; $2/month, limit 90 min, 2 lines, TB on line,
2400/1200 baud on 916-722-6519; USENET, E-Mail, Games; login: new
Contact: ..pacbell!sactoh0!sysop
089 919-493-7111^ wolves Durham NC 3/12/24 24
AMS 386/25 - UNIX SysVr3.2, XBBS, no fee for bbs. Rates for UNIX access
and USENET are being determined. Developing yet another UNIX bbs (ideas
welcome!) Single line, telebit coming soon.
Contact: wolves!ggw or wolves!sysop [...duke!dukcds!wolves!...]
-------------------------------------------------------------------------------
NOTE: ^ means the site is reachable using PC Pursuit.
===============================================================================
This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions,
or corrections should be sent to one of the addresses below. The nixpub
listings are kept as current as possible. However, you use this data at your
own risk and cost -- all standard disclaimers apply!!!
------
Lists available from lgnp1 via anonomous uucp.
+1 215 348 9727 [Telebit access]
login: nuucp NO PWD [no rmail permitted]
this list: /usr/spool/uucppublic/nixpub
short list: /usr/spool/uucppublic/nixpub.short
or from news groups pubnet.nixpub, comp.misc or alt.bbs.
------
E-MAIL ...
uucp: ..!uunet!lgnp1!$ phil | nixpub $
or: $ phil | nixpub $@LS.COM
CIS: 71076,1576
===============================================================================
COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the
respective companies.
===============================================================================
nixpub short listing
Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only
[ November 12, 1989 ]
Systems listed (73)
Legend: fee/contribution ($), no fee (-$), hours (24), not (-24)
shell (S), USENET news (N), email (M), multiple lines (T)
Telebit 9600 bps on main number (+P), Telebit on other line[s] (P)
Courier 9600 bps on main number (+H), Courier on other line[s] (H)
anonymous uucp (A), archive site ONLY - see long form list (@)
@> = anonymous uucp archive site listed in ANONIX (mike@cpmain)
Dialable thru PC Pursuit (^)
Last
Contact
Date Telephone # Sys-name Location Baud Legend
----- ------------ -------- ----------- ------- ---------
08/89 201-846-2460^ althea New Brunswic NJ 3/12/24 24 -$ M N S
10/89 206-328-4944 polari Seatle WA 3/12 24 $ M N P S T
10/89 212-420-0527 magpie NYC NY 3/12/24/96 24 -$ T P
10/89 212-675-7059 marob NYC NY 12/24 24 -$ A
05/89 212-879-9031^ dasys1 NYC NY 12/24 24 $ S N M T
09/89 213-376-5714^ pnet02 Redondo Bch CA 3/12/24 24 -$ M N T
09/89 213-397-3137^ stb Santa Monica CA 3/12/24 24 -$ S A
11/88 213-459-5891 amazing Pac Palisade CA 3/12/24 24 $ T
07/88 214-247-2367 ozdaltx Dallas TX 3/12/24 24 $ N T
07/89 214-741-2130 attctc Dallas TX 3/12/24 24 -$ N M S T A
11/89 215-348-9727 lgnp1 Doylestown PA 3/12/24/96 24 $ A M N +P S
09/89 216-582-2441 ncoast Cleveland OH 12/24/96 24 $ S N M P T
08/88 217-529-3223 pallas Springfield IL 3/12/24 24 $ T
10/89 219-289-0286 nstar South Bend IN 3/12/24/96 24 -$ H M N P S T
08/88 312-283-0559^ chinet Chicago IL 3/12/24 24 $ N T
10/89 312-338-0632^ point Chicago IL 3/12/24/96 24 -$ N P S T
04/89 313-623-6309 nucleus Clarkston MI 12/24 24 $ S N M
11/88 313-994-6333 m-net Ann Arbor MI 3/12 24 $ T
08/89 313-996-4644^ anet Ann Arbor MI 3/12 24 $ T
08/89 314-474-4581 gensis Columbia MO 3/12/24/96 24 -$ M S
10/89 404-321-5020^ jdyx Atlanta GA 12/24 24 $ M N +P S T
05/88 407-380-6228 rtmvax Orlando FL 3/12/24 24 -$ N M
09/89 408-245-7726^ uuwest Sunnyvale CA 3/12/24 24 -$ N
04/88 408-247-4810 sharks Santa Clara CA 3/12 24 $ S N M T
11/89 408-423-9995 cruzio Santa Cruz CA 12/24 24 $ M T
10/89 408-725-0561^ portal Cupertino CA 3/12/24 24 $ -S N M T
02/89 408-997-9119^ netcom San Jose CA 3/12/24/96 24 $ M N S
10/89 412-431-8649 eklektik Pittsburgh PA 3/12/24 24 $ S N M
11/89 415-332-6106^ well Sausalito CA 12/24 24 $ M N S T
06/88 415-582-7691 cpro Hayward CA 12/24 24 -$ S
07/89 415-753-5265^ wet San Francisc CA 3/12/24 24 $ M N S T
05/89 415-783-2543 esfenn Hayward CA 3/12/24 24 -$ M N S
01/89 416-452-0926 telly Brampton ON 12/24/96 +P 24 $ M N
12/88 416-461-2608 tmsoft Toronto ON 3/12/24/96 24 $ S M N
07/89 416-654-8854 ziebmef Toronto ON 3/12/24/96 24 +P M N S T
08/89 502-968-5401 disk Louisville KY 3/12 24 $ M N S T
12/88 503-254-0458 bucket Portland OR 3/12/24 24 -$ N M T
05/89 503-640-4262^ agora PDX OR 3/12/24 24 $ M N S T
10/88 512-346-2339 bigtex Austin TX 96 +P 24 -S -$ A @>
07/89 512-832-8835 rpp386 Austin TX 12/24 24 @ -$ -S A T
10/89 513-779-8209 cinnet Cincinnati OH 12/24/96 24 $ M N +P S
05/89 516-872-2137 lilink Long Island NY 12/24 24 $ M N S T
07/89 517-487-3356 lunapark E. Lansing MI 12/24 24 -$
12/88 518-346-8033 sixhub upstate NY 3/12/24 24 $ S N M T
09/88 602-941-2005 xroads Phoenix AZ 3/12/24 24 $ N T
08/89 603-880-8120 ubbs-nh Nashua NH 3/12/24/96 24 -$ M N +P S T
08/89 605-348-2738 loft386 Rapid City SD 3/12/24/96 24 $ M N +P S
08/88 608-273-2657 madnix Madison WI 3/12/24 24 -$ S N M
08/89 612-473-2295 pnet51 Minneapolis MN 3/12/24 24 -$ N M T
08/89 615-896-8716 raider Murfreesboro TN 12/24 24 -$ S N M T
07/89 616-457-1964 wybbs Jenison MI 3/12/24 24 -$ S N T
11/89 617-739-9753 world Brookline MA 3/12/24/96 24 $ M N P S T
07/88 619-444-7006^ pnet01 El Cajon CA 3/12/24 24 $ N M S T
10/88 703-281-7997^ grebyn Vienna VA 3/12/24/96 24 $ N M T P
11/89 708-272-5912^ igloo Northbrook IL 12/24/96 24 -$ S N T P
11/89 708-301-2100^ jolnet Joliet IL 3/12/24 24 -$ +P M N S T
08/88 312-566-8911^ ddsw1 Mundelein IL 3/12/24/96 24 $ S N M T A P
11/89 708-833-8126^ vpnet Villa Park IL 12/24/96 24 -$ +P M N S
07/89 713-438-5018 sugar Houston TX 3/12/24/96 24 -$ N +P
10/89 713-668-7176^ nuchat Houston TX 3/12/24/96 24 -$ M N +P S
12/88 714-635-2863 dhw68k Anaheim CA 12/24 24 -$ T
05/89 714-662-7450 turnkey Inglewood CA 12/24 24 -$
11/89 714-821-9671 alphacm Cypress CA 12/24/96 24 -$ T H A
05/89 714-842-5851 conexch Santa Ana CA 3/12/24 24 $ A M N S
08/88 714-894-2246 stanton Irvine CA 3/12/24 24 $ S N
05/88 719-632-4111 chariot Colo Sprgs CO 3/12 24 $ T
08/89 801-943-7947^ i-core Salt Lake Ci UT 3/12/24/96 +P 24 -$ A N
06/88 802-865-3614 tnl Burlington VT 3/12/24 24 -$ S N M
08/88 813-952-1981 usource Sarasota FL 12/24 -24 -$ A
08/88 814-333-6728 sir-alan Meadville PA 3/12/24 24 -$ A P
05/88 814-337-3159 oncoast Meadville PA 3/12/24/96 +H 24 @ -$ -S A
09/89 916-649-0161 sactoh0 Sacramento CA 12/24/96 24 $ M N +P S T
08/89 919-493-7111^ wolves Durham NC 3/12/24 24 $ M N S
-------------------------------------------------------------------------------
NOTE: ^ means the site is reachable using PC Pursuit.
===============================================================================
This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions,
or corrections should be sent to one of the addresses below. The nixpub
listings are kept as current as possible. However, you use this data at your
own risk and cost -- all standard disclaimers apply!!!
------
Lists available from lgnp1 via anonomous uucp.
+1 215 348 9727 [Telebit access]
login: nuucp NO PWD [no rmail permitted]
this list: /usr/spool/uucppublic/nixpub.short
long list: /usr/spool/uucppublic/nixpub
or from news groups pubnet.nixpub, comp.misc or alt.bbs
------
E-MAIL ...
uucp: ..!uunet!lgnp1!{ phil | nixpub }
or: { phil | nixpub }@LS.COM
===============================================================================
COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the
respective companies.
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #5 of 12
[-][-] [-][-] [-][-] [-][-] [-][-] [-][-] [-][-]
[-] [-]
[-] Covert Paths [-]
[-] [-]
[-] by [-]
[-] [-]
[-] Cyber Neuron Limited and Synthecide [-]
[-] [-]
[-] November 1, 1989 [-]
[-] [-]
[-][-] [-][-] [-][-] [-][-] [-][-] [-][-] [-][-]
When cracking a system, it is important for you to use a path to the system
that will not lead the authorities to your door step.
There are several methods for doing this and all of them will depend on your
destination, available time, goal and the phase of the moon. This article
deals mostly with cover attacks via a connected network.
If attacking via a phone link:
o Tap in to your local payphone line and red box or "sprint" the call.
o Using a long haul service (like Sprint or MCI) to dial into systems in
remote cities. [This should hinder a track by a good order of
magnitude.]
o Use a midnight packet switching network (eg: PC-Pursuit, Tymnet, et. al.)
o All the above.
If attacking from a network (eg: the Internet) there are ways of spoofing the
packet headers, but this requires superuser privileges on the system you are
attacking from and a fair amount of 'C' programming expertise. Therefore, this
will not be discussed here in any more detail.
Another obvious trick is to use network routers and gateways along with guest
accounts to "route" your data path. This will cause the person tracking you to
have to go though more red tape and hassle to track you. This gives you more
time to cover your tracks.
Some useful paths I know of are:
accuvax.nwu.edu
cory.berkeley.edu
violet.berkeley.edu
headcrash.berkeley.edu
host: violet.berkeley.edu host: headcrash.berkeley.edu
account: nobody account: netgate
net address:128.32.136.22 net address: 128.32.234.31
host: cory.berkeley.edu host accuvax.nwu.edu
account: terminal account: telnet
net address: 128.32.134.6 net address: 129.105.49.1
host: lightning.berkeley.edu host: score.stanford.edu
port: 8033 account: guest
net address: 128.32.234.10 net address: 36.8.0.46
The accounts nobody, netgate, and terminal at Berkeley are accounts that were
installed so that people can use the system to rlogin or telnet to an account
elsewhere without a local login (or so I am told by the local hackers [Hi
Audrey...]). The lightning path/method can be accessed by the command:
"telnet lightning.berkeley.edu 8033".
I am interested in hearing about other Internet access accounts that are
available out there. If you know of any please send them in.
Tymnet is also a useful method of gaining access to systems. From Tymnet, you
can hook up to just about any computer and use the other methods to go one step
further. It's not until you are traced back to the computer you linked to from
Tymnet that they can even begin to follow you back. My understanding is that
for a systen to find your Tymnet node, they must contact Tymnet personally and
ask them to put a trap on their connection.
For more infomation concerning Tymnet see the article "Hacking & Tymnet" by
Synthecide in Phrack Inc. Newsletter Issue XXX.
**********************************
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #6 of 12
+ BANK INFORMATION +
\ /
\ /
___Compiled By___
/ \
Legion Of Doom!
EFT Division
------------
In order to exact any type of bank associated transaction by computer, one must
have a working knowledge of the various routing codes involved in the banking
processes. The following is an informational guide to the coding used in
American banking transactions.
ABA (American Bankers Association) Transit Numbers
Numbers 1 to 49 inclusive are Prefixes for Cities
Numbers 50 to 99 inclusive are Prefixes for States
Prefix Numbers 50 to 58 are Eastern States
Prefix Number 59 is for Alaska, Hawaii, and US Territories
Prefix Numbers 60 to 69 are Southeastern States
Prefix Numbers 70 to 79 are Central States
Prefix Numbers 80 to 88 are Southwestern States
Prefix Numbers 90 to 99 are Western States
1 New York, NY
2 Chicago, IL
3 Philadelphia, PA
4 St. Louis, MO
5 Boston, MA
6 Cleveland, OH
7 Baltimore, MD
8 Pittsburgh, PA
9 Detroit, MI
10 Buffalo, NY
11 San Francisco, CA
12 Milwaukee, WI
13 Cincinnati, OH
14 New Orleans, LA
15 Washington D.C.
16 Los Angeles, CA
18 Kansas City, MO
19 Seattle, WA
20 Indianapolis, IN
21 Louisville, KY
22 St. Paul, MN
23 Denver, CO
24 Portland, OR
25 Columbus, OH
26 Memphis, TN
27 Omaha, NE
28 Spokane, WA
29 Albany, NY
30 San Antonio, TX
31 Salt Lake City, UT
32 Dallas, TX
33 Des Moines, IA
34 Tacoma, WA
35 Houston, TX
36 St. Joseph, MO
37 Fort Worth, TX
38 Savannah, GA
39 Oklahoma City, OK
40 Wichita, KS
41 Sioux City, IA
42 Pueblo, CO
43 Lincoln, NE
44 Topeka, KS
45 Dubuque, IA
46 Galveston, TX
47 Cedar Rapids, IA
48 Waco, TX
49 Muskogee, OK
50 New York
51 Connecticut
52 Maine
53 Massachusetts
54 New Hampshire
55 New Jersey
56 Ohio
57 Rhode Island
58 Vermont
59 Alaska, American Samoa, Guam, Hawaii, Puerto Rico, Virgin Islands
60 Pennsylvania
61 Alabama
62 Delaware
63 Florida
64 Georgia
65 Maryland
66 North Carolina
67 South Carolina
68 Virginia
69 West Virginia
70 Illinois
71 Indiana
72 Iowa
73 Kentucky
74 Michigan
75 Minnesota
76 Nebraska
77 North Dakota
78 South Dakota
79 Wisconsin
80 Missouri
81 Arkansas
83 Kansas
84 Louisiana
85 Mississippi
86 Oklahoma
87 Tennessee
88 Texas
90 California
91 Arizona
92 Idaho
93 Montana
94 Nevada
95 New Mexico
96 Oregon
97 Utah
98 Washington
99 Wyoming
Federal Reserve Routing Symbols
* All banks in an area served by a FR bank or branch bank
carry the routing symbol of the FR bank or branch
1 Federal Reserve Bank of Boston Head 5-1
Office 110
2 Federal Reserve Bank of New York Head 1-120
Office 210
Buffalo Branch 10-26
220
3 Federal Reserve Bank of Philadelphia 3-4
Head Office 310
4 Federal Reserve Bank of Cleveland Head 0-1
Office 410
Cincinnati Branch 13-43
420
Pittsburgh Branch 8-30
430
5 Federal Reserve Bank of Richmond Head 68-3
Office 510
Baltimore Branch 7-27
520
Charlotte Branch 66-20
530
6 Federal Reserve Bank of Atlanta Head 64-14
Office 610
Birmingham Branch 61-19
620
Jacksonville Branch 63-19
630
Nashville Branch 87-10
640
New Orleans Branch 14-21
650
7 Federal Reserve Bank of Chicago Head 2-30
Office 710
Detroit Branch 9-29
720
8 Federal Reserve Bank of St. Louis Head 4-4
Office 810
Little Rock Branch 81-13
110
Louisville Branch 21-59
830
Memphis Branch 26-3
840
9 Federal Reserve Bank of Minneapolis 17-8
Head Office 910
Helena Branch 92-26
920
10 Federal Reserve Bank of Kansas City 18-4
Head Office 1010
Denver Branch 23-19
1020
Oklahoma City Branch 39-24
1030
Omaha Branch 27-12
1040
11 Federal Reserve Bank of Dallas Head 32-3
Office 1110
El Paso Branch 88-1
1120
Houston Branch 35-4
1130
San Antonio Branch 30-72
1140
12 Federal Reserve Bank of San Francisco 11-37
Head Office 1210
Los Angeles Branch 16-16
1220
Portland Branch 24-1
1230
Salt Lake City Branch 31-31
1240
Seattle Branch 19-1
1250
BANK IDENTIFICATION CODES
XX-YYY WHERE: XX = City or State
ZZZZ YYY = Bank of Origin
ZZZZ = Federal Reserve Routing Code
If three digits: The first digit identifies the Federal Reserve District
The second digit, if 1, stands for the Head Office of the
Federal Reserve District; 2-5 stand for the Branch Office of
the Federal Reserve District
The third digit signifies: 0-available for immediate credit;
others have deferred credit and the digits mean the
following: 1-5 designates the state in which the drawee bank
is located; 6-9 special collection arrangements.
If four digits: The first two digits stand for the Federal Reserve District
10-12.
The following digits are as above
EXAMPLE:
68-424 68-State of Virginia
514 424-Arlington Trust Co., Arlington, VA
5-Fifth Federal Reserve District
1-Head Office in Richmond, Virginia
4-Deferred credit and the state of Virginia
*NOTE -- For further your familiarity with the coding process, on checks, these
numbers appear at the bottom of the check according to the MICR Check
Coding System. The check number, the account number, and the ABA
Transit Number will all be encoded in magnetic ink. The ABA Number
will be enclosed in symbols like: |: ABANUMBER |: The grouping of
the ABA and Federal Reserve Codes will also usually appear at the
upper right-hand corner of the check.
Keep in mind that there are a great many checks involved in any
banking procedure, and almost any transaction evoked improperly will
draw attention. Furthermore, the documents generated in a legitimate
wire-transfer situation are quite extensive. Should a transaction be
noticed, and these documents are not available for scrutiny, again
attention will be drawn to the situation.
* BANK DOCUMENTS *
* WIRE TRANSFER *
INTERNAL CUSTOMER RECORD
Teller Tape & Proof Sheets Copy of Wire Transfer Ticket
Wire Transfer Ticket Cancelled Check (if used to
Microfilm copy of check purchase)
used to purchase wire Bank Statement (if funds came
transfer out of the account)
Microfilm copies of account
records (if fund came out
of existing account)
Cash In/Out Ticket
Vault Book Entry
Bank Security Film
Copy of CTR
Bank transactions must be swift and precise. Amounts should be kept under the
$10,000 range in order not to immediately arouse suspicion. Attacks must
executed correctly the first time, as there will be no possibilities for a
second chance. Monies must be gathered rapidly and dispersed into various
outlets to avoid additional attention. Transfers to banking systems whose
countries keep strict right to privacy laws, such as Panama, Switzerland,
et.al. are not recommended as the transactions are much more involved and there
exists a greater potential for error in international wire-transfers.
The preferred method of transfer of funds would involve one or more false
identities, complete with state approved identification or passport and social
security cards. Bank Security Film is kept on file, so it would be preferred
that some semblance of disguise be implemented, ranging from hair bleaching,
sun-tanning, makeup, false accents, facial hair, etc. Various accounts in the
assumed name would be opened in several cities with the minimum initial
balance. Within approximately two weeks, funds of no more than $7500 would be
diverted to each account. The funds would then be withdrawn in cash with no
more than $5000 from each account, the balance being left in the account. Once
the funds have been made cash, they would then be distributed to foreign banks,
or invested in foreign markets to avoid detection by the Internal Revenue
Service.
Conviction for Illegal Transference of Funds is not recommended.
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #7 of 12
The Legion of Doom!
EFT Division
Presents
HOW WE GOT RICH THROUGH ELECTRONIC FUND TRANSFERS
(OR: GEE! NO, GTE!)
A certain number of financial institutions that reside within the
packet-switched confines of the various X.25 networks use their connections to
transfer funds from one account to another, one mutual fund to another, one
stock to another, one bank to another, etc... It is conceivable that if one
could intercept these transactions and divert them into another account, they
would be transferred (and could be withdrawn) before the computer error was
noticed. Thus, with greed in our hearts, an associate and I set forth to test
this theory and conquer the international banking world.
We chose CitiCorp as our victim. This multinational had two address
prefixes of its own on Telenet (223 & 224). Starting with those two prefixes,
my associate and I began to sequentially try every possible address. We
continued through 1000 in increments of one, then A-Z, then 1000-10000 by 10's,
and finally 10000-99999 by 100's. Needless to say, many addresses were
probably skipped over in our haste to find valid ones, but many we passed over
were most likely duplicate terminals that we had already encountered.
For the next few days my associate and I went over the addresses we had
found, comparing and exchanging information, and going back to the addresses
that had shown 'NOT OPERATING,' 'REMOTE PROCEDURE ERROR,' and 'REJECTING.' We
had discovered many of the same types of systems, mostly VAX/VMS's and Primes.
We managed to get into eight of the VAXen and then went forth on the CitiCorp
DECNET, discovering many more. We entered several GS1 gateways and Decservers
and found that there were also links leading to systems belonging to other
financial institutions such as Dai-Ichi Kangyo Bank New York and Chase
Manhattan. We also found hundreds of addresses to TWX machines and many
in-house bank terminals (most of which were 'BUSY' during banking hours, and
'NOT OPERATING' during off hours). In fact, the only way we knew that these
were bank terminals was that an operator happened to be idle just as I
connected with her terminal (almost like the Whoopie Goldberg movie, "Jumpin'
Jack Flash," not quite as glamorous ...yet.)
Many of the computers we eventually did penetrate kept alluding to the
electronic fund transfer in scripts, files, and personal mail. One of the
TOPS-20 machines we found even had an account EFTMKTG.EFT, (password EFTEFT)!
All the traces pointed to a terminal (or series of terminals) that did nothing
but transfer funds. We decided that this was the case and decided to
concentrate our efforts on addresses that allowed us to CONNECT periodically
but did not respond. After another week of concentrated effort, we managed to
sort through these. Many were just terminals that had been down or
malfunctioning, but there were five left that we still had no idea of their
function. My associate said that we might be able to monitor data
transmissions on the addresses if we could get into the debug port. With this
idea in mind, we set out trying sub-addresses from .00 to .99 on the mystery
addresses. Four of the five had their debug ports at the default location
(.99). The fifth was located 23 away from the default. That intrigued us, so
we put the others aside and concentrated on the fifth. Although its location
was moved, a default password was still intact, and we entered surreptitiously.
The system was menu driven with several options available. One option,
Administrative Functions, put us into a UNIX shell with root privilege. After
an hour or so of nosing around, we found a directory that held the Telenet
Debug Tools package (which I had previously thought existed solely for Prime
computers). Using TDT, we were able to divert all data (incoming and outgoing)
into a file so we could later read and analyze it. We named the file ".trans"
and placed it in a directory named ".. ", (dot, dot, space, space) so it would
remain hidden. This was accomplished fairly late on a Sunday night. After
logging off, we opened a case of Coors Light and spent the rest of the night
(and part of the morning!) theorizing about what we might see tomorrow night
(and getting rather drunk).
At approximately 9:00 p.m. the following evening, we met again and logged
onto the system to view the capture file, hoping to find something useful. We
didn't have to look very far! The first transmission was just what we had been
dreaming about all along. The computer we were monitoring initiated by
connecting with a similar computer at another institution, waited for a
particular control sequence to be sent, and then transferred a long sequence of
numbers and letters. We captured about 170 different transactions on the first
day and several hundred more in the following week. After one business week,
we removed the file and directory, killed the TDT routine, and went through the
system removing all traces that we had been there.
We felt that we had enough to start piecing together what it all meant, so
we uploaded our findings to the LOD HP-3000 (ARMA) in Turkey. This way we
could both have access to the data, but keep it off our home systems. We
didn't bother to tell any of the other LOD members about our doings, as most
had retired, been busted, or were suspected of turning information over to the
Secret Service. Using this as a base, we analyzed the findings, sorted them,
looked for strings being sent, etc.
We came to the conclusion that the transmissions were being sent in the
following way:
XXXXXXXXXXXXTCxxxxxxxxxxxx/NNNNNNNNNNNNCnnnnnnnnnnnnAMzzzzzzz.zzOP#
X=Originating Bank ID
T=Transfer (Also could be R(ecieve), I(nquire))
C=Type of account (Checking--Also S(avings) I(RA) M(oney Market)
T(rust) W(Other wire transfer ie. Credit Transfer, etc.))
x=Originating Account Number
/=Slash to divide string
N=Destination Bank ID
C=Type of account (See above)
n=Destination Account Number
AMzzzzzzz.zz=Amount followed by dollar and cents amount
OP#=operator number supervising transaction
After this string of information was sent, the destination bank would then
echo back the transaction and, in ten seconds, unless a CONTROL-X was sent,
would send "TRANSACTION COMPLETED" followed by the Destination Bank ID.
We now needed to check out our theory about the Bank ID's, which I figured
were the Federal Reserve number for the Bank. Every bank in America that deals
with the Federal Reserve System has such a number assigned to it (as do several
European Banks). I called up CitiBank and inquired about their Federal Reserve
Number. It was the number being sent by the computer. With this information,
we were ready to start.
I consulted an accountant friend of mine for information on Swiss or
Bahamanian bank accounts. He laughed and said that a $50,000 initial deposit
was required to get a numbered account at most major Swiss banks. I told him
to obtain the forms necessary to start the ball rolling and I'd wire the money
over to the bank as soon as I was told my account number. This shook him up
considerably, but he knew me well enough not to ask for details. He did,
however, remind me of his $1000 consulting fee. A few days later he showed up
at my townhouse with an account number, several transaction slips and
paperwork. Knowing that I was up to something shady, he had used one of his
own false identities to set up the account. He also raised his "fee" to $6500
(which was, amazingly enough, the amount he owed on his wife's BMW).
My associate and I then flew to Oklahoma City to visit the hall of records
to get new birth certificates. With these, we obtained new State ID's and
Social Security Numbers. The next step was to set up bank accounts of our own.
My associate took off to Houston and I went to Dallas. We each opened new
commercial accounts at three different banks as LOD Inc. with $1000 cash.
Early the next day, armed with one Swiss and six American accounts, we
began our attack. We rigged the CitiCorp computer to direct all of its data
flow to a local Telenet node, high up in the hunt series. Amazingly, it still
allowed for connections from non-909/910 nodes. We took turns sitting on the
node, collecting the transmissions and returning the correct acknowledgments.
By 12:30 we had $184,300 in electronic funds in "Limbo." Next we turned off
the data "forwarding" on the CitiCorp computer and took control of the host
computer itself through the debug port to distribute the funds. Using its data
lines, we sent all the transactions, altering the intended bank destinations,
to our Swiss account.
After I got the confirmation from the Swiss bank I immediately filled out
six withdrawal forms and faxed them to the New York branch of the Swiss bank
along with instructions on where the funds should be distributed. I told the
bank to send $7333 to each of our six accounts (this amount being small enough
not to set off Federal alarms). I did this for three consecutive days, leaving
our Swiss account with $52,000. I signed a final withdrawal slip and gave it
to my accountant friend.
Over the next week we withdrew the $22,000 from each of our Dallas and
Houston banks in lots of $5000 per day, leaving $1000 in each account when we
were through. We were now $66,000 apiece richer.
It will be interesting to see how the CitiCorp Internal Fraud Auditors and
the Treasury Department sort this out. There are no traces of the diversion,
it just seems to have happened. CitiBank has printed proof that the funds were
sent to the correct banks, and the correct banks acknowledgment on the same
printout. The correct destination banks, however, have no record of the
transaction. There is record of CitiBank sending funds to our Swiss account,
but only the Swiss have those records. Since we were controlling the host when
the transactions were sent, there were no printouts on the sending side. Since
we were not actually at a terminal connected to one of their line printers, no
one should figure out to start contacting Swiss banks, and since CitiBank does
this sort of thing daily with large European banks, they will be all twisted
and confused by the time they find ours. Should they even get to our bank,
they will then have to start the long and tedious process of extracting
information from the Swiss. Then if they get the Swiss to cooperate, they will
have a dead-end with the account, since it was set up under the guise of a
non-entity. The accounts in Dallas and Houston were also in fake names with
fake Social Security Numbers; we even changed our appearances and handwriting
styles at each bank.
I'm glad I'm not the one who will have the job of tracking me down, or
even trying to muster up proof of what happened. Now we won't have to worry
about disposable income for awhile. I can finish college without working and
still live in relative luxury. It's kind of weird having over six-hundred $100
bills in a drawer, though. Too bad we can't earn any interest on it!
** Since the events described transpired, CitiBank has made their Banking
Transaction Ports all refuse collect connections. Even by connecting
with an NUI they now respond "<>". C'est La Vie.
>--------=====END=====--------<
==Phrack Inc.==
Volume Three, Issue 29, File #8 of 12
...........................................
||||||!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!||||||
|||!!! !!!|||
||| The Myth and Reality About |||
||| Eavesdropping |||
||| |||
||| by Phone Phanatic |||
||| |||
|||... October 8, 1989 ...|||
||||||...............................||||||
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Most Central Office (CO) eavesdropping intercepts in a Bell Operating Company
(BOC) CO are today performed using a modified Metallic Facility Termination
(MFT) circuit pack which places about a 100,000 ohm isolated bridging impedance
across the subscriber line. Supervisory signaling is detected on the
subscriber loop using a high-impedance electronic circuit, and the signaling is
repeated in an isolated fashion using the A and B leads of the repeating coil
in the MFT to "reconstruct" a CO line for the benefit of monitoring apparatus.
The entire purpose of the above effort is to prevent any trouble or noise on
the intercept line or monitoring apparatus from causing any trouble, noise or
transmission impairment on the subject line.
Some BOCs may elect to use service observing apparatus to provide the necessary
isolation and repeated loop supervisory signaling. Less common are locally
engineered variations which merely use an isolation amplifier from an MFT or
other 4-wire repeater, and which provide no repeated supervisory signaling
(which is not all that necessary, since voice-activated recorders and DTMF
signaling detectors can be used, and since dial pulses can be counted by
playing a tape at slow speed).
Today, the use of a "bridge lifter" retardation coil for the purpose of
connecting an eavesdropping intercept line is virtually non-existent since they
do not provide sufficient isolation and since they provide a fair amount of
insertion loss without loop current on the "observing" side. Bridge lifter
coils are primarily intended for answering service intercept lines, and consist
of a dual-winding inductor which passes 20 Hz ringing and whose windings easily
saturate when DC current flows. Bridge lifter coils are used to minimize the
loading effect (and consequent transmission impairment) of two subscriber loops
on one CO line. Bridge lifter coils provide a significant insertion loss at
voice frequencies toward the idle loop; i.e., the loop in use will have DC
current flow, saturating the inductor, and reducing its insertion loss to
1.0 dB or less.
Despite gadget advertised in magazines like The Sharper Image, the simple truth
of the matter is that there is NO WAY for any person using ANY type of
apparatus at the telephone set location to ascertain whether there is a
properly installed eavesdropping device connected across their line in the CO.
The only way such a determination can be made is through the cooperation of the
telephone company.
For that matter, there is virtually no way for any person using any type of
apparatus in their premises to ascertain if there is ANY type of eavesdropping
apparatus installed ANYWHERE on their telephone line outside their premises,
unless the eavesdropping apparatus was designed or installed in an
exceptionally crude manner (not likely today). Some types of eavesdropping
apparatus may be located, but only with the full cooperation of the telephone
company.
The sole capability of these nonsense gadgets is to ascertain if an extension
telephone is picked up during a telephone call, which is hardly a likely
scenario for serious eavesdropping!
These screw-in-the-handset gadgets work by sensing the voltage across the
carbon transmitter circuit, and using a control to null this voltage using a
comparator circuit. When a person makes a telephone call, the control is
adjusted until the light just goes out. If an extension telephone at the
user's end is picked up during the call, the increased current drain of a
second telephone set will decrease the voltage across the carbon transmitter
circuit, unbalancing the voltage comparator circuit, and thereby causing the
LED to light.
These voltage comparator "tap detectors" cannot even be left with their
setpoint control in the same position, because the effective voltage across a
subscriber loop will vary depending upon the nature of the call (except in the
case of an all digital CO), and upon other conditions in the CO.
Electromechanical and analog ESS CO's may present different characteristics to
the telephone line, depending upon whether it is used at the time of: An
originated intraoffice call (calling side of intraoffice trunk), an answered
intraoffice call (called side of intraoffice trunk), an originated tandem call
(interoffice tandem trunk), an originated toll call (toll trunk), or an
answered tandem/toll call (incoming tandem or toll trunk). There is usually
enough variation in battery feed resistance due to design and component
tolerance changes on these different trunks to cause a variation of up to
several volts measured at the subscriber end for a given loop and given
telephone instrument.
Even more significant are variations in CO battery voltage, which can vary
(within "normal limits") from 48 volts to slightly over 52 volts, depending
upon CO load conditions. 50 to 51 volts in most CO's is a typical daily
variation. If anyone is curious, connect an isolated voltage recorder or data
logger to a CO loop and watch the on-hook voltage variations; in many CO's the
resultant voltage vs 24-hour time curve will look just like the inverse of a
busy-hour graph from a telephone traffic engineering text!
In some all-digital CO apparatus, the subscriber loop signaling is performed by
a solid-state circuit which functions as a constant-current (or
current-limiting) device. With such a solid-state circuit controlling loop
current, there is no longer ANY meaningful reference to CO battery voltage;
i.e., one cannot even use short-circuit loop current at the subscriber location
to even estimate outside cable plant resistance.
To explode this myth even further, let's do a little Ohm's Law:
1. Assume a CO loop with battery fed from a dual-winding A-relay (or
line relay, ESS ferrod line scanner element, or whatever) having 200
ohms to CO battery and 200 ohms to ground.
2. Assume a CO loop of 500 ohms (a pretty typical loop).
3. Assume an eavesdropping device with a DC resistance of 100,000 ohms
(this is still pretty crude, but I'm being generous with my example).
4. Using some simple Ohm's law, the presence or absence of this
hypothetical eavesdropping device at the SUBSCRIBER P |