[ tools ]

(sorry, this page is available in english only)

-

 

Table of contents:	1 - What is sWEETM+NT
	1.1 - Some words about the program
	1.2 - Features
	2 - General overview
	2.1 - How does the program work
	2.2 - Command line parameter
	3 - Plugins support
	3.1 - How do plugins work
	3.2 - Using plugins
	3.3 - Writing your own plugins
	A - Appendix
	A.1 - Change log
	A.2 - What's coming
	A.3 - Greetings
	A.4 - Contacting me

-

[ 1 - What is sWEETM+NT ]

 
 

1.1 - Some words about the program

 

No kidding. This isn't a security tool. At least not for others' security. This is not for good angels. It's for you all devils out there. You can guess what it is meant for: scan a remote domain in order to discover the way of breaking into it. It saves a lot of hand-work. I know that there are many other similar programs, like Satan, Nessus or Mscan, sWEETM+NT isn't comparable, it exists just to save you from writing a lot of commands and remembering useful informations. Read the scan log, and have an overview of remote domain' status. When you get all the clues, it's up to you to find out HOW to exploit the whole thing.

Surely I won't tell you.

Of course, as a minor but always nice side-effect, you can use sWEETM+NT to scan your net and find remote security flaws, in order to fix them up.

But it's just a side effects... hope you understood.

I'm not evil.

I won't do anything.

I can't see.

I can't hear.

I can't talk.

Use all this stuff at your OWN risk. I cannot be held responsible for any amount of caos you spread around. It's the same as building cars, if you can't drive, don't complain with me.

h4ck 7h3 w0r1d

 

1.2 - Features

 

First of all, it works.

Only on linux boxes, but it works.

It isn't as quick as other similar tools (because still lacks of child spawn on the same list), but it's damn precise. Apart from some strange side effects of the scan (nothing dangerous, tough), sWEETM+NT will report you all what you need. Yeah, security flaws, sometimes it will even grab the passwd for you, but don't expect it to happen often, this program won't exploit the remote machines for you.

This program is a BASH script.

You may wonder WHY a bash script.

Only because it started as a simple script to automatize some basic operations anyone will do when looking for remote machines to play with, and little by little it evolved in a complete scan program. You launch it, and then take care of another thing, your attention isn't required.

It remains a bash script. 0h, who carez?

What does sWEETM+NT do?

Not much in this version (at least from my point of view), but you may find it useful.

You feed it with a domain (that should be clear), and after a little or long shaking and rolling, he hands you the wish list. Read it carefully.

It resolves the IP of all machines of the domain, does the DNS conversion, and also checks which ones are alive (i.e. reply to ping).

It collects all the remote-collectable informations about every machine in the list, such as the exportable directories, the list of all RPC services running, the banner that telnet, smtp, pop3 and ftp give you, it fingers evey user currently logged on the machines, and all the standard unix/linux accounts, returns the bind version, and some more jellyfish candies.

Oh, of course it does a portscan in the range 1-1080.

Then sWEETM+NT tries to check the exploitability of some bugs, like CGI's, pop3, smtp, bind, netbios, imap, rusers... sometimes (with the CGI's) you will find a passwd on your machine (besides from yours, of course!). It's an extra gift... crack it with care.

Maybe it will also find broadcasting addresses or wingates/socks.

It also runs plugins, if you have some. Actually it doesn't recognize the Photoshop's plugin format, but I'm working on it :)

All this nice & neat stuff can be enabled or disabled on the command line or in the config file.

 

-

[ 2 - General overview ]

 
 

2.1 - How do the program work

 

sWEETM+NT, relying heavily on some system-default programs (apart from other programs I provided in their executable form in "bin/" directory), on the first run looks for those programs, and saves the paths and some default scan options in a config file called ".smintrc" in the base directory. It reads and writes it at every run, and if you accidentially delete it, it will be recreated. Also delete it when you move some of your system executables, just to be sure.

When you scan a domain, first of all sWEETM+NT generates some temporary files in the main directory, to extract command line parameters, and during this (short) time also creates a file called "sweetmint.LOCK", that prevents another session to run during the initialization phase (otherwise two sessions of sWEETM+NT will mess command-lines and initialization each other, resulting in a lock up). This file is deleted as soon as the main scan is finished, and at this time you can fire up another scan without troubles.

Also, during initialization phase, sWEETM+NT appends to a file called ".smhistory" the current date/time of the system, and the domain/single host you scan, so you can read it one day to know what you've done. Then the script creates a temporary directory where all temp files are stored, that will be called "domain.to.scan.tmp". This directory is going to be erased as soon as the scan finishes.

During the main scan phase, you'll find, for each domain, AT LEAST two files: one called "domain.to.scan.ip", containing all the IP's of the machines found in domain, and the other called "domain.to.scan.results", where logs for that scan are stored. In case you stop the scan (pressing CTRL-C many times, for example), additional files that start with "domain.to.scan.something" will be created. Don't erase them, nor the temporary directory, or you won't be able to resume the aborted scan later.

 

 
 

2.2 - Command line parameters

 

Now, try to run the program without any parameter. Luscious and naked.

It will greet you with some chit-chat, then quits giving an error: you forgot to specify the domain to scan (I told you so :)

Here's what you will read (a little part):

Usage: sweetmint [-file:<file>][-range:<range>][-single:<host>][-resume:]<domain>[:<childs>] [-tar] [options]
 

The good part is that the only parameter you must give is the <domain>.

The bad is that if you want to tune up the scan there's a lot of flags you must know... have this little readme handy.

First note: the commandline is CASE SENSITIVE.

Second note: the domain must be the first parameter, absolutely.

 

Let's analyze the command line in detail:

The first parameter MUST be the domain/single host to scan. sWEETM+NT recognizes the difference this way:

- if  launched with "sweetmint domain.to.scan" it will scan the full domain and relative subdomains.

- if launched with "sweetmint -file:file.containing.hosts" it will read IPs to scan from that file.

- if launched with "sweetmint -range:range.of.ips" it will first generate all the IPs in specified range, then scan them all (or only the alive ones). The syntax for "range.of.ips" is very simple:
    - you MUST specify an IP in dotted quad format (example: field1.field2.field3.field4)
    - everyone of that four fields can contain a number (example: 234), a range of numbers separated by a '-' (example: 4-54 will generate all fields from 4 to 54) or an asterisk '*' (this one is equivalent to writing a 1-254 range). If you type an invalid character an error will occur, and if you write in a number out of range, as '257', it will be automatically rounded to the closest valid number, in this case '254'.

- if  launched with "sweetmint -single:host.to.scan" it will scan ONLY the host you specified on command line.

- if  launched with "sweetmint -resume:domain.to.resume" it will resume an aborted scan for that domain, but ONLY if you haven't deleted the temporary files sWEETM+NT creates during a scan. Otherwise, it will be impossible to resume a scan.

To resume a scan from a filelist, you must supply, instead of 'domain.to.resume', the filename containing the IPs. The script will
automatically filter out the already-scanned hosts. To resume a scan from a range, you must supply the filename containing the
generated list, usually called <number>.range.ip. Again the script will filter out the already-scanned hosts.
 

There is another optional parameter you can specify after the domain, AND ONLY AFTER IT. It's the "-tar" option. If you specify it (for example with a commandline "sweetmint microsux.com -tar"), after all the scan stuff is finished, the script will compress all the files related to the domain/host in a file called "domain/host.just.scanned.tar.gz", but ONLY if tar and gzip where found when config file was created.

The following options you specify are also not compulsory (because sWEETM+NT will get the scan parameters from the config file, as every time you change the scan parameters they will be saved in ".smintrc" and used for all new scans, just remember that specifying a parameter will override the saved ones).

Here's a list of possible flags, with a short description for each one:

 

'n' : do name lookup - every IP in generated list will be resolved into it's name form, and a "domain.to.scan.hosts" list will be generated and used as main scan list. This is often a VERY SLOW process. In order to use this option, "nslookup" must be present on machine, and a Domain Name Server must be specified in localhost's configuration.

 

'a' : ping for alive ip's - every IP in generated list will be ping'ed to verify if the machine is currently online, and results will be written into a "domain.to.scan.ip.alive" file, and used as main scan list. This is often a VERY SLOW process. In order to use this option, "ping" must be present on machine.

 

'f' : NFS holes - an exportable dir listing will be generated for every machine in list, and you will be notified when public mountable directories are found. In order to use this option, "showmount" must be present on machine.

 

'c' : CGI holes - machines will be checked against various CGI holes, and if an hole is found, "passwd" file will be automatically retrieved. In order to use this option, "lynx" must be present on machine.

 

'w' : Wingate scan - after main scan, the global list will be scanned for open wingates, netproxies or socks.

  's' : Netbios shares - every machine will be checked for shared directories using the NETBIOS protocol. Also, a brute forcing of the password (if required) is attempted, reading usernames from "userlist.nat" and passwords from "passlist.nat". Feel free to add to those two dictionaries. This can be a VERY SLOW process.
 

'r' : RPC informations - for every machine will be collected RPC services informations. In order to use this option, "rpcinfo" must be present on machine.

'b' : BIND version check - it will report the installed version of BIND for every machine.
 

'B' : BIND exploit check - it will report if it's actually possible to remote exploit BIND on some machines.

 

'F' : Finger informations - standard UNIX account will be fingered, along with every user currently online, and this for every machine in the list. In order to use this option, "finger" must be present on machine.

 

'N' : NIS map listing - a map of NIS services will be generated for every machine in the list.

 

'd' : Banner dump - sWEETM+NT will connect to telnet, ftp, smtp and pop3, and save the greeting banner that is shown.

 

'R' : RUSERS informations - for every machine, a list of all users connected through the RUSERS service will be shown. In order to use this option, "rusers" must be present on machine.

 

't' : Broadcast scan - as soon as main scan is completed, the full domain will be scanned in order to find broadcast (.255) addresses in the network, useful to use with flood programs such as "smurf".

 

'i' : IMAP linux bug - every opened IMAP port will be reported, and also checked in order to verify the remote exploitability.

 

'S' : SMTP & POP3 check - with this option, sWEETM+NT will report if on scanned machines is possible to break in using remote exploitability. Also checks the version of service used, and reports if QPOPPER is installed on remote systems.

 

'x' : Use plugins - this options enables the use of plugins.

 

Remember that some of those scans are performed only if the required port is found as open during the preliminary portscan, and some other are dependent on commandline. So don't get scared if you find as enabled options you didn't specified.

Now the question you surely have is: "But how THE HELL can I enable and disable those options?"

Simple answer.

There are three parameters you pass to sWEETM+NT and those are used to enable and disable options. One is global (i.e. affects all the flags), the other aren't. These parameters are:

 

'-full' : it enables ALL the flags, no one is excluded.

 

'-enable:<flags>' : it enables only the flags (the single function specific letters) you specify after the ':' . For example a parameter like "-enable:ti" enables broadcast scan and IMAP bug check.

'-disable:<flags>' : it disables only the flags you specify. Same as '-enable'.
 

You can combine these options in many ways. REMEMBER THAT YOU CAN USE ONLY TWO OF THEM AT A TIME (you can't specify -full -enable: -disable: together).

Here's the full cases:

first: '-full'

second: none

effect: ENABLES ALL the scan options

 

first: '-full'

second: '-enable:<flags>'

effect: absolutely stupid :) ENABLES ALL the scan options

 

first: '-full'

second: '-disable:<flags>'

effect: ENABLES ALL the scan options, and DISABLES THE SPECIFIED ONES

 

first: '-enable:<flags>'

second: none

effect: ENABLES THE SPECIFIED OPTIONS, and DISABLES ALL THE OTHERS

 

first: -enable:<flags>'

second: '-disable:<flags>'

effect: ENABLES SPECIFIED OPTIONS, AND DISABLE SPECIFIED ONES (quite a mess :)

 

first: '-enable:<flags>'

second: '-full'

effect: absolutely stupid :) ENABLES ALL the scan options

 

first: '-disable:<flags>'

second: none

effect: DISABLES THE SPECIFIED OPTIONS, and ENABLES ALL THE OTHERS

 

first: '-disable:<flags>'

second: '-enable:<flags>'

effect: DISABLES SPECIFIED OPTIONS, AND ENABLES SPECIFIED ONES (quite a mess :)

 

first: '-disable:<flags>'

second: '-full'

effect: ENABLES ALL OPTIONS, and DISABLES SPECIFIED ONES

 

The combination of options and flags are saved in config file and used in all the next scans, so you don't have to specify anything rather than the domain, if you don't want to change the flags. The first time sWEETM+NT is run, it generates as default a "-full -disable:nas". Little homework, what does it do? :)))

-

 

[ 3 - Plugins support ]

 

3.1 - How do plugins work

 

I know.

There are lots of things that sWEETM+NT is missing, and I'll try to implement some in the near future.

But of course I can't be always working on this thingie.

So, when dedicated users will start to appear (if it will ever be), they'll

be able to add their ideas and functions to the tool.

As plugins.

I think you all know programs like Adobe Photoshop or Jasc's Paint Shop Pro on the Winsux platform, they both make use of plugins to extend their ability of processing image files. Here happens the same, with plugins you can extend the capabilities of all the show.

Plugins accept parameters, do something and then return informations.

That's all.

 
 

3.2 - Using plugins

 

To use plugins, the file 'plugins.conf' must exist in the same dir as the main sweetmint executable. Also on command line the parameter 'x' must be specified. In the plugins configuration file it's pointed out in which directory sWEETM+NT should look for all the necessary files, feel free to change that, as long as you move all the files you find in the standard dir. Usually you won't need to make any changes to the configuration file, except maybe the status of the plugin (i.e. if it must be executed or not), that can be changed by looking for a 'PLUGINNAME_status' row and writing there 'disable' or 'enable'.

All other parameters are set up by plugin's creator, and should be left unchanged, unless you read somewhere that you can tune up something. Don't blame anyone if after some mess up the plugin, or the whole program, stops working.

 
 

3.3 - Writing your own plugin

 

A plugin can be written in any language you like, and can make use of any kind of resource on the local system. The main program doesn't do any check to see if the plugin can be run without hassle and locks-up, so it's up you to make sure *within* the plugin code if everything will be fine. Usually this is accomplished by making a  bash script that takes care of all the initialization stuff and then passes parameters to the main plugin executable. You can also do all the dirty work with a bash script, I don't care of which language you use.

The first thing you need to do is to write plugin specification in the 'plugins.conf' configuration file. A sample specification should look like this:

startplugin--SAMPLE

SAMPLE_status=disable

SAMPLE_id=Sample plugin for sWEETM+NT - by \sPIRIT\

SAMPLE_file=sample.plugin

SAMPLE_params=currentHOST resultsFILE temporaryDIR

SAMPLE_type=single

SAMPLE_level=user

SAMPLE_disable=

endplugin--SAMPLE

 

You can put comments everywhere you like, adding a '#' at the beginning of the text line.

 

Let's look in-depth what do all those names do:

 

- The two rows 'startplugin--NAME' and 'endplugin--NAME' must open and close all the other specifications, you can't write parameters outside those two delimiters. They are used to extract the plugin name and to associate options to the plugin.

 

- 'NAME_status' is the only parameter that should be changed by an end-user. It tells sWEETM+NT that the plugin should be run (enable) or not (disable).

 

- 'NAME_id' is simply a string of text that will be show to the user when the plugin is loaded. I use it to put some auto-celebration shots. The max lenght of the _id line is this:

--------------------------------------------[ Max length of ID string ]->

 

- 'NAME_file' indicates the main executable sWEETM+NT will run, it must be located in the specified plugins directory, and then can run everything he wants (if you need some other programs). *IMPORTANT* Remember that the main working directory (also for plugins) is the one in which you run sWEETM+NT, so it's a good thing to specify full local pathnames in your plugins, keeping the main dir (ex. sweetmint/ ) as the base.

 

- 'NAME_params' is the most important field. Here you will write the command line parameters that will be given to plugin. There are no limitations, as long as you provide them on one line and in the order the plugin will look for. Also, there are some standard parameters that will be expanded by sWEETM+NT BEFORE spawning the process to the plugins, so you'll be sure you'll get exactly what you want. These parameters are (capitalization COUNTS):

 

'currentHOST' will be expanded to the numeric IP or HOSTNAME that's currently being scanned.

'resultsFILE' will be expanded to the name of the log results file, where, following a kind rule of law and order, you will write all the things your plugin will find. As I already pointed out, the name is referred as being in the MAIN directory, not in the plugins' one.

'completeLIST' will be expanded to the name of the file containing the full list of machines to be checked in the domain specified on sWEETM+NT command line. It also refers to a file in the MAIN directory.

'completeIPLIST' will be expanded to the name of the file containing the full list of machines to be checked IN THEIR DOTTED QUAD FORMAT (neverthless of what contained the complete list, IP's or hostnames). Il also refers to a file in the MAIN directory.

'pluginsDIRECTORY' will be expanded to the name of the dir in which plugins and their files are stored WITHOUT THE TRAILING SLASH '/'. Apply the usualrule of the main directory as the base one.

'temporaryDIR' will be expanded to the name of the current scan related temporary directory, without the '/' as before. It's a good thing to use it to store all the temporary files you'll generate during the execution, as the dir will be removed as soon as the scan is finished. Apply the usual rule of main dir as the base.

 

- 'NAME_type' tells sWEETM+NT which kind of plugin it is. Currently you have three plugin types available:

'single' is a plugin that works on a single IP or HOSTNAME, and will be executed in the main scan loop.
'list' is a plugin that works on the full machines list, and will be executed after the main scan loop.

'post' is a plugin that does some things AFTER the scan is finished, like messing up with the results file and other non-scan related stuff.

- 'NAME_level' contains the privileges the plugin should be run with. It can be 'user' or 'root'. If the privilege requirement is not met, the plugin won't be run.
 

- 'NAME_disable' tells sWEETM+NT which internal functions the plugin substitutes. This is a bitch.

In fact, you can turn off internal function of the main tool specifying here which one your plugin substitutes. Of course you can't TURN ON something.

It is performed by writing here the letters that correspond to internal functions, same as on commandline. But warning, there are some you can turn off, some you can't. Here is a list of all the functions you can turn off (writing the letter in this field, without the ''):

 

'f' --> Remote mountable directories

'c' --> Check for CGI exploits

'w' --> Wingate scanning

's' --> Netbios shared resources scan

'r' --> Collect RPC informations

'b' --> Collect BIND version

'B' --> Check for BIND exploits

'F' --> Collect FINGER informations

'N' --> Collect NIS maps listing

'd' --> Dump greet banners

'R' --> RUSERS info collection

't' --> Broadcast scanning

'T' --> .TAR.GZipping of results

'i' --> Linux IMAP bug check

'S' --> SMTP and POP3 bugs check

 

One important thing: NEVER leave any field blank, except for 'NAME_disable' if you don't want to disable any of the internal functions. And, please, don't add spaces after or before the '='.

Now that you know how to write the plugins specifications, let's spend some words about the plugins themselves. As I already said, you can write the plugin in any language you like, and make use of any resource, as long as you perform some checks to ensure that everything will go fine.

You create your program, and then put it in the plugins directory. It's a good rule to call it something like 'NAME.plugin', just to be more coherent to the style I chose :)

Let's see the sample plugin I included in this distribution. You will find it in the plugins dir and it's named 'sample.plugin'. It's a bash script, and it's disabled in the plugins config file. Besides that, it doesn't do anything relevant, so feel free to enable it, just to see how it's working.

 

------------------------<sample.plugin - cut here>--------------------------

# Sample plugin for sWEETM+NT - by \sPIRIT\ -s0ftpr0ject 98-

# It really doesn't do much... just for learning' sake.

#

# Parameters passed (in the correct order):

# (hope you know something about passing parameters to scripts)

#

# $1 --> currentHOST

# $2 --> resultsFILE

# $3 --> pluginsDIRECTORY

# $4 --> temporaryDIR

# $5 --> dummy

echo "Sample plugin for sWEETM+NT - by \sPIRIT\"

echo " "

echo "Plugin is located in $3/ directory"

echo "Plugin is processing host: $1"

echo "Plugin sample.plugin rocks!" >> $2

echo "$5" >> $4/sample.plugin.log

cat $4/sample.plugin.log

exit 0

------------------------<sample.plugin - cut here>--------------------------

 

Let's have a look at it.

The first eleven rows are, obviously, comments. There are described the command line parameters in the order they are passed.

All those "echo" rows show the usage of parameters. In row "Plugin is located in $3/ directory" will be expanded to (with default configuration) "plugins/". "Plugin sample.plugin rocks!" will be written in the scan log results file in main sWEETM+NT directory. Same for the following row, where the word "dummy" (passed as parameter) will be written to the scan temporary dir in the file "sample.plugin.log" Now you should have understood how parameters work, and what means that main dir chat I wrote before. ALWAYS refer to base sWEETM+NT dir when dealing with files, and NOT TO plugins directory.

If you need to know if a certain port is open on the remote machine, please refer to the temporary file located in temporaryDIR/portscan.temp. Do a grep on it for <port number</tcp, if successful, the port is open.
 
 

-

[ A - Appendix ]

 
 

A.1 - Change log

 

+ means ADDED

- means REMOVED

! means FIXED

* means CHANGED

 

Version 0.8.0	first test of sWEETM+NT - revision of mAGIC! 0.7.3. I decided to keep the version number, and go from this point on.
Version 0.8.1	internal tests (not released)
Version 0.8.2pre1	first beta release (beta testers only)
Version 0.8.2	first public release of sWEETM+NT
	+ much more friendlier command line interface than mAGIC!
	+ total automatization of scan process
	+ scan history file
	+ readable on-disk result file generation
	* new portscanner binary
	someone seems to like this tool, that's cool
Version 0.8.2a	+ dumping of banners on telnet, smtp, pop3 and ftp
	+ QPOPPER bug scan
	+ results now can be compressed in a .tar.gz archive
Version 0.8.3	+ -resume:<domain> option - resumes aborted domain scans
	! some bugfixes
	+ rusers info collection
	+ broadcasts scanner
Version 0.8.4	! nice fixes here and there
	! fixed dependencies of parameters on commandline
	+ -single:<host> option - scans a single host rather than a whole domain
	! range of scanned ports raised to 1080
Version 0.9.0a	+ basic external plugins support
Version 0.9.1	+ support for 'root' userid plugins
	+ support for 'post' type plugins
	+ IMAP bug check
	+ generic pop3 and smtp bu gcheck
Version 0.9.4	! now is possibile to lauch multiple sessions of sWEETM+NT on different domains (doesn't mess up anymore)
	! all temporary files moved to a domain.tmp/ dedicated dir
Version 1.0.0	first stable and usable release of sWEETM+NT
	! fixed some bugs in plugins support
	+ bKiSS pLUGIN (bROADkASTiNG sIMPLE sCANNER)
	! fixed resume of aborted scans and other stuff
Version 1.0.1	! fixed a bug in finger info collection
	+ check of remote OS plugin (root only - using QUESO)
	! more accurate IMAP bug check
	+ added and removed some CGI's
Version 1.2.0	! fixed a nasty bug in config generation (caused hangs during scan on non-debian machines)
	* stderr (finally) redirected to /dev/null
	- no more bugcheck messages during main scan
	* improved internal broadcast scanner
	* improved bKiSS plugin (now version 0.4)
	! fixed the configuration bug in queso.plugin
	+ now possible to scan a given list of IPs (parameter -file:<file containing ips to scan)
	+ now possible to scan ranges of IPs (parameter -range:<range>)
	+ preliminary child spawn control (NOT ENABLED YET!)

 
 

A.2 - What's coming

 

sWEETM+NT will be regularly updated. There are some things I want to add, including:

 

- Child spawn (a user-definable number of threads running on the same list, to improve dramatically a scan' speed).

- ANSI interface, or a menu-based one (using the DIALOG.SO lib).

- Brute forcing of remote user password using the RUSERS service and a dictionary.

- Wingate scanner as a plugin

- Ability to read a list of domains to scan, just for automatization' sake.

 

- Checking of more and new remote bugs and other plugins.

 

- A much cleaner results log.

 

 

A.3 - Greetings

 

Oh I'm damn sure someone will be left out... doh

To s0ftproject 99 - SMasteR, |Scacco|, DoLd, Dr_Slump, Dashie

To all my brothers running in the Badlands

To all in the Hackingirls staff

 

To Budah, the best betatester I've ever had. Keep tha boom boom cha man

To Lord Gothik, for too many reasons to list here

To Desdemona, OPHY, ^^Susanna and |ENGEL|

To Kaos One, Deda, and the whole Homiecyde Prod.

To ]-KooG-[, ][ndigo and Black Berry

... to everyone else I forgot

 

 

A.4 - Contacting me

 

 

You can send me your plugins. I'll be happy to include them in the next release of sWEETM+NT.

 

You can also email me, for questions and ideas, the address is spirit@s0ftpj.org
 

-

- You have just tasted a sWEETM+NT -

- EOF -

 

[ tools ]

s0ftpr0ject digital security for y2k is no (c)opyright 1997-99 of s0ftpr0ject team Webmaster is \sPIRIT\ (PGP Key) - Contact us at staff@s0ftpj.org (public PGP Key)