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.
LT XML is an integrated set of XML tools and a developers' tool-kit,
including a C-based API.
The LT XML tool-kit includes stand-alone tools for a wide range of
processing of well-formed XML documents, including searching and
extracting, down-translation (e.g. report generation, formatting),
tokenising and sorting.
Sequences of tool applications can be pipelined together to achieve
complex results.
For special purposes beyond what the pre-constructed tools can
achieve, extending their functionality and/or creating new tools
is easy using the LT XML API. Minimal applications require less
than one-half page of C code to express.
LT XML provides two views of an XML file; one as a flat stream of
markup elements and text; a second as a sequence of tree-structured
XML elements. The two views can be mixed, allowing great flexibility
in the manipulation of XML documents. It also includes a powerful,
yet simple, querying language, which allows the user to quickly and
easily select those parts of an XML document which are of interest.
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.
Mason is a tool for building, serving and managing large web sites. Its features
make it an ideal backend for high load sites serving dynamic content, such as
online newspapers or database driven e-commerce sites.
Mason's various pieces revolve around the notion of "components". A component is
a mix of HTML, Perl, and special Mason commands, one component per file.
So-called "top-level" components represent entire web-pages, while smaller
components typically return HTML snippets for embedding in top-level components.
This object-like architecture greatly simplifies site maintenance: change a
shared component, and you instantly changed all dependant pages that refer to it
across a site (or across many virtual sites).
Mason's component syntax lets designers separate a web page into programmatic
and design elements. This means the esoteric Perl bits can be hidden near the
bottom of a component, preloading simple variables for use above in the HTML. In
our own experience, this frees content managers (i.e., non-programmers) to work
on the layout without getting mired in programming details. Techies, however,
still enjoy the full power of Perl.
The objective of the package is to provide a fast and essential HTML check (esp.
for CGI scripts where response time is important) to prevent a piece of user
input HTML code from messing up the rest of a file, i.e., to minimize and
localize any possible damage created by including a piece of user input HTML
text in a dynamic document.
HTMLQuickCheck checks for unmatched < and >, unmatched tags and improper
nesting, which could ruin the rest of the document. Attributes and elements
with optional end tags are not checked, as they should not cause disasters with
any decent browsers (they should ignore any unrecognized tags and attributes
according to the standard). A piece of HTML that passes HTMLQuickCheck may not
necessarily be valid HTML, but it would be very unlikely to screw others but
itself. A valid piece of HTML that doesn't pass the HTMLQuickCheck is however
very likely to screw many browsers(which are obviously broken in terms of strict
conformance).
HTMLQuickCheck currently supports HTML 1.0, 2.x (draft), 3.0 (draft) and
netscape extensions (1.1).
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.