Ports 搜索

This package implements an algorithm for breaking the PkZip cipher that was devised by Eli Biham and Paul Kocher. This program applies a known plaintext attack to an encrypted file. A known-plaintext-attack recovers a password using the encrypted file and (part of) the unencrypted file. Please note that cryptographers use the word 'plaintext' for any kind of unencrypted data - not necessarily readable ASCII text. Before you ask why somebody may want to know the password when he already knows the plaintext think of the following situations: - Usually there's a large number of files in a ZIP-archive. Usually all these files are encrypted using the same password. So if you know one of the files, you can recover the password and decrypt the other files. - You need to know only a part of the plaintext (at least 13 bytes). Many files have commonly known headers, like DOS .EXE-files. Knowing a reasonably long header you can recover the password and decrypt the entire file.

Snort is a libpcap-based packet sniffer/logger which can be used as a lightweight network intrusion detection system. It features rules based logging and can perform content searching/matching in addition to being used to detect a variety of other attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more. Snort has a real-time alerting capability, with alerts being sent to syslog, a separate "alert" file, or even to a Windows computer via Samba. Packets are logged in their decoded form to directories which are generated based upon the IP address of the remote peer. This allows Snort to be used as a sort of "poor man's intrusion detection system" if you specify what traffic you want to record and what to let through. For instance, I use it to record traffic of interest to the six computers in my office at work while I'm away on travel or gone for the weekend. It's also nice for debugging network code since it shows you most of the Important Stuff(TM) about your packets (as I see it anyway). The code is pretty easy to modify to provide more complete packet decoding, so feel free to make suggestions.

This script provides functionality for manipulating collections of configuration files which can be organised so as to alter the personality of a system. Initially, the "base" personality is established. This personality contains the "reference" copies of configuration files, and is used when creating new personalities. The files which are currently considered part of the system's personality are those contained in the base personality. A new personality is established by making a copy of the base personality under a new name. Each personality maintains a separate copy of all configuration files under /etc/personality. To install a new personality, the files currently in place are saved back to the current personality as indicated in /etc/personality/current, and the files for the new personality copied into place. The 'select' and 'menu' commands which perform these installations are implemented in such a fashion as to only require the tools available on the root filesystem, so that they may be invoked at the earliest stage during system startup.

The sortu program is a replacement for the sort and uniq programs. It is common for Unix script writers to want to count how many separate patterns are in a file. For example, if you have a list of addresses, you may want to see how many are from each state. So you cut out the state part, sort these, and then pass them through uniq -c. Sortu does all this for you in a fraction of the time. Sortu uses a hash table and some decent line processing to provide this functionality. For a relatively small number of keys, it can be signifcantly smaller than using sort, because it does not have to keep temporary files. If you are dealing with a large number of unique keys then sortu will run out of memory and stop. Sortu has some basic field and delimiter handling which should do most basic awk or cut features to separate out the field that you are sorting on.

WebAuth is an authentication system for web pages and web applications. The first time a user attempts to access a web page protected by WebAuth, they will be sent to a central login server (weblogin.stanford.edu at Stanford) and prompted to authenticate. Normally, they will be asked for a username and password, although other authentication methods are possible. Once the user has logged in, the weblogin server will send their encrypted identity back to the original web page they were trying to access. Their identity will also be stored in a cookie set by the weblogin server and they will not need to authenticate again until their credentials expire, even if they visit multiple protected web sites. WebAuth works with any browser that supports cookies, requires no agents or other software installed on the client web browser systems, and works with an existing Kerberos v5 authentication realm. It can also be used as the SSO provider for a Shibboleth IdP and supports SPNEGO authentication as well as username/password over TLS/SSL. See the page on WebAuth features for more major features and a brief comparison with other web authentication systems.

This is a port of G-Cows, a software project consisting in: - definition of a scripting language designed for creation of web sites (Cows); - interpreter for the scripting language (cows); - a makefile generator (cows-mkgen). Cows is a scripting language whose main goal is to make the creation and updating of a web site faster, more flexible and less prone to errors without relying on server-side technologies. Cows allows to use your Unix background and your favorite tools while creating a site: you can traverse the whole directory tree with `find', extract informations with `grep', build complex pipelines, include external scripts and programs written in every language whose interpreter or compiler is installed on your system. Even if you use server side technology, you can still appreciate Cows for every task not relying on dynamic change of your site's contents mixing Cows, PHP, custom Apache modules, application servers etc. Cows gives the best results when used in conjunction with the Make utility, available on all Unix systems.

Parse::HTTP::UserAgent implements a rules-based parser and tries to identify MSIE, FireFox, Opera, Safari & Chrome first. It then tries to identify Mozilla, Netscape, Robots and the rest will be tried with a generic parser. There is also a structure dumper, useful for debugging. User agent strings are a complete mess since there is no standard format for them. They can be in various formats and can include more or less information depending on the vendor's (or the user's) choice. Also, it is not dependable since it is some arbitrary identification string. Any user agent can fake another. So, why deal with such a useless mess? You may want to see the choice of your visitors and can get some reliable data (even if some are fake) and generate some nice charts out of them or just want to send an HttpOnly cookie if the user agent seems to support it (and send a normal one if this is not the case). However, browser sniffing for client-side coding is considered a bad habit.

From the website: What is PHP Surveyor? PHP Surveyor is a set of PHP scripts that interact with MySQL to develop surveys, publish surveys and collect responses to surveys. Once a survey has been created it can be published as an online survey (displayed as single questions, group by group or all in one page) or you can use a dataentry system for administration of paper-based versions of the survey. PHP Surveyor can produced 'branching' surveys (set conditions on whether individual questions will display), can vary the look and feel of your survey through a templating system, and can provide basic statistical analysis of your survey results. PHP Surveyor includes the capacity to generate individualised 'tokens', so if you have a list of people you want to invite to participate in a survey you can issue each one with a token, and they will be able to access the survey using that token. This allows for quite good quality control of your surveys.

"twander" is a Filesystem Browser which runs on both Unix-like systems as well as Win32 systems. It embraces the best ideas of both similar GUI-driven programs (Konqueror, Windows Explorer) as well as text-based interfaces (Midnight Commander, List, Sweep). While the "twander" interface is graphical, all the major navigation, selection, and execution commands can be entered from the keyboard, not just the mouse. This means Power Users who are strong typists can minimize dependency on the mouse and materially speed up their interactions with the system. Moreover, unlike the other programs, "twander" does not have a built-in set of commands (which typically cannot be changed). Instead, "twander" supports a rich macro configuration language for virtually limitless user-definition of commands. The configuration language provides a simple mechanism for communicating the list of items currently selected in the GUI to the user-defined commands. Each user is thus free to configure a command set unique and appropriate to their needs. As with the navigation commands, user-defined commands can be invoked with either the keyboard (a single keystroke) or the mouse (a menu selection).

This utility notably decreases the startup time of your X sessions, provided that you start a number of X clients automatically during the X session startup. Most people, for instance, start X clients like xterm, xclock, xconsole and xosview from their .xinitrc, .openwin-init, .xtoolplaces or .xsession file. These X clients are started simultaneously (in the background) which puts a high load on the X server and the OS: * The X server is not multi-threaded, so all X clients are competing to get access to the X server and to use its resources, which causes a lot of overhead (= delay). * The performance of other (non X related) tasks served by the system degrades badly due to the high load. If the system has not enough RAM to hold all the X clients, it is swapping heavily, resulting again in a lot of delay. On the Sun platform there is a utility called 'toolwait' which solves these problems: it starts one X client in the background, waits until it has mapped a window and then exits. Xtoolwait is a free implementation of exactly the same idea.